diff --git a/.bowerrc b/.bowerrc deleted file mode 100644 index 107d1e8f42b..00000000000 --- a/.bowerrc +++ /dev/null @@ -1,3 +0,0 @@ -{ - "directory": "js/vendor" -} 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 new file mode 100644 index 00000000000..af9969128e0 --- /dev/null +++ b/.github/workflows/tests.yml @@ -0,0 +1,26 @@ +name: GitHub Actions CI +on: + push: + branches: master + pull_request: + merge_group: +permissions: + contents: read +jobs: + tests: + runs-on: ubuntu-latest + steps: + - name: Set up Git repository + uses: actions/checkout@v6.0.2 + - name: Set up Ruby + uses: ruby/setup-ruby@19a43a6a2428d455dbd1b85344698725179c9d8c # v1 + with: + bundler-cache: true + - name: Set up Node + uses: actions/setup-node@v6.3.0 + - name: Bootstrap + run: script/bootstrap + env: + SKIP_BUNDLER: true + - name: Tests + run: script/test 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/.travis.yml b/.travis.yml deleted file mode 100644 index b2ac01e5a87..00000000000 --- a/.travis.yml +++ /dev/null @@ -1,28 +0,0 @@ -sudo: false -language: node_js -node_js: - - 6 -before_install: - - rvm install 2.4.3 - - npm install -g npm@5 -install: - - npm install - - bundle install -script: script/test -notifications: - email: false -env: - global: - - NOKOGIRI_USE_SYSTEM_LIBRARIES=true -addons: - apt: - packages: - - libcurl4-openssl-dev -cache: - bundler: true - directories: - - node_modules - - test/node_modules -branches: - only: - - master 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 ccf722d63c9..91b9248ee9d 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -1,265 +1,367 @@ GEM remote: https://rubygems.org/ specs: - activesupport (4.2.9) - i18n (~> 0.7) - minitest (~> 5.1) - thread_safe (~> 0.3, >= 0.3.4) - tzinfo (~> 1.1) - addressable (2.5.2) - public_suffix (>= 2.0.2, < 4.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) - colorize (0.8.1) - commonmarker (0.17.9) - ruby-enum (~> 0.5) - concurrent-ruby (1.0.5) - dnsruby (1.60.2) - 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.11.0) - ffi (>= 1.3.0) - eventmachine (1.2.5) - execjs (2.7.0) - faraday (0.15.0) - multipart-post (>= 1.2, < 3) - ffi (1.9.23) + http_parser.rb (~> 0) + ethon (0.18.0) + ffi (>= 1.15.0) + logger + eventmachine (1.2.7) + execjs (2.9.1) + faraday (2.14.1) + faraday-net_http (>= 2.0, < 3.5) + json + logger + faraday-net_http (3.4.2) + net-http (~> 0.5) + ffi (1.17.3-aarch64-linux-gnu) + ffi (1.17.3-aarch64-linux-musl) + ffi (1.17.3-arm-linux-gnu) + ffi (1.17.3-arm-linux-musl) + ffi (1.17.3-arm64-darwin) + ffi (1.17.3-x64-mingw-ucrt) + ffi (1.17.3-x86-linux-gnu) + ffi (1.17.3-x86-linux-musl) + ffi (1.17.3-x86_64-darwin) + ffi (1.17.3-x86_64-linux-gnu) + ffi (1.17.3-x86_64-linux-musl) + fiber-annotation (0.2.0) + fiber-local (1.1.0) + fiber-storage + fiber-storage (1.0.1) forwardable-extended (2.6.0) - gemoji (3.0.0) - github-pages (183) - activesupport (= 4.2.9) - github-pages-health-check (= 1.7.3) - jekyll (= 3.7.3) - jekyll-avatar (= 0.5.0) - jekyll-coffeescript (= 1.1.1) - jekyll-commonmark-ghpages (= 0.1.5) - jekyll-default-layout (= 0.1.4) - jekyll-feed (= 0.9.3) + 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.9.4) - jekyll-mentions (= 1.3.0) - jekyll-optional-front-matter (= 0.3.0) + jekyll-github-metadata (= 2.16.1) + jekyll-include-cache (= 0.2.1) + jekyll-mentions (= 1.6.0) + jekyll-optional-front-matter (= 0.3.2) jekyll-paginate (= 1.1.0) - jekyll-readme-index (= 0.2.0) - jekyll-redirect-from (= 0.13.0) - jekyll-relative-links (= 0.5.3) - jekyll-remote-theme (= 0.2.3) + jekyll-readme-index (= 0.3.0) + jekyll-redirect-from (= 0.16.0) + jekyll-relative-links (= 0.6.1) + jekyll-remote-theme (= 0.4.3) jekyll-sass-converter (= 1.5.2) - jekyll-seo-tag (= 2.4.0) - jekyll-sitemap (= 1.2.0) - jekyll-swiss (= 0.4.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.3) - jekyll-theme-slate (= 0.1.1) - jekyll-theme-tactile (= 0.1.1) - jekyll-theme-time-machine (= 0.1.1) - jekyll-titles-from-headings (= 0.5.1) - jemoji (= 0.9.0) - kramdown (= 1.16.2) - liquid (= 4.0.0) - listen (= 3.1.5) + jekyll-seo-tag (= 2.8.0) + jekyll-sitemap (= 1.4.0) + jekyll-swiss (= 1.0.0) + jekyll-theme-architect (= 0.2.0) + jekyll-theme-cayman (= 0.2.0) + jekyll-theme-dinky (= 0.2.0) + jekyll-theme-hacker (= 0.2.0) + jekyll-theme-leap-day (= 0.2.0) + jekyll-theme-merlot (= 0.2.0) + jekyll-theme-midnight (= 0.2.0) + jekyll-theme-minimal (= 0.2.0) + jekyll-theme-modernist (= 0.2.0) + jekyll-theme-primer (= 0.6.0) + jekyll-theme-slate (= 0.2.0) + jekyll-theme-tactile (= 0.2.0) + jekyll-theme-time-machine (= 0.2.0) + jekyll-titles-from-headings (= 0.5.3) + jemoji (= 0.13.0) + kramdown (= 2.4.0) + kramdown-parser-gfm (= 1.1.0) + liquid (= 4.0.4) mercenary (~> 0.3) - minima (= 2.4.1) - nokogiri (>= 1.8.1, < 2.0) - rouge (= 2.2.1) + minima (= 2.5.1) + nokogiri (>= 1.16.2, < 2.0) + rouge (= 3.30.0) terminal-table (~> 1.4) - github-pages-health-check (1.7.3) + webrick (~> 1.8) + github-pages-health-check (1.18.2) addressable (~> 2.3) dnsruby (~> 1.60) - octokit (~> 4.0) - public_suffix (~> 2.0) + octokit (>= 4, < 8) + public_suffix (>= 3.0, < 6.0) typhoeus (~> 1.3) - html-pipeline (2.7.2) + hashery (2.1.2) + html-pipeline (2.14.3) activesupport (>= 2) nokogiri (>= 1.4) - html-proofer (3.8.0) - activesupport (>= 4.2, < 6.0) + html-proofer (5.2.0) addressable (~> 2.3) - colorize (~> 0.8) - mercenary (~> 0.3.2) - nokogiri (~> 1.8.1) - 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.7.3) + 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.5.0) - jekyll (~> 3.0) - jekyll-coffeescript (1.1.1) + webrick (>= 1.0) + jekyll-avatar (0.8.0) + jekyll (>= 3.0, < 5.0) + jekyll-coffeescript (1.2.2) coffee-script (~> 2.2) - coffee-script-source (~> 1.11.1) - jekyll-commonmark (1.2.0) - commonmarker (~> 0.14) - jekyll (>= 3.0, < 4.0) - jekyll-commonmark-ghpages (0.1.5) - commonmarker (~> 0.17.6) - jekyll-commonmark (~> 1) - rouge (~> 2) - jekyll-default-layout (0.1.4) - jekyll (~> 3.0) - jekyll-feed (0.9.3) - jekyll (~> 3.3) + 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.9.4) - jekyll (~> 3.1) - octokit (~> 4.0, != 4.4.0) - jekyll-mentions (1.3.0) - activesupport (~> 4.0) + 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.0) - jekyll-optional-front-matter (0.3.0) - jekyll (~> 3.0) + jekyll (>= 3.7, < 5.0) + jekyll-optional-front-matter (0.3.2) + jekyll (>= 3.0, < 5.0) jekyll-paginate (1.1.0) - jekyll-readme-index (0.2.0) - jekyll (~> 3.0) - jekyll-redirect-from (0.13.0) - jekyll (~> 3.3) - jekyll-relative-links (0.5.3) - jekyll (~> 3.3) - jekyll-remote-theme (0.2.3) - jekyll (~> 3.5) - rubyzip (>= 1.2.1, < 3.0) - typhoeus (>= 0.7, < 2.0) + jekyll-readme-index (0.3.0) + jekyll (>= 3.0, < 5.0) + jekyll-redirect-from (0.16.0) + jekyll (>= 3.3, < 5.0) + jekyll-relative-links (0.6.1) + jekyll (>= 3.3, < 5.0) + jekyll-remote-theme (0.4.3) + addressable (~> 2.0) + jekyll (>= 3.5, < 5.0) + jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0) + rubyzip (>= 1.3.0, < 3.0) jekyll-sass-converter (1.5.2) sass (~> 3.4) - jekyll-seo-tag (2.4.0) - jekyll (~> 3.3) - jekyll-sitemap (1.2.0) - jekyll (~> 3.3) - jekyll-swiss (0.4.0) - jekyll-theme-architect (0.1.1) - jekyll (~> 3.5) + jekyll-seo-tag (2.8.0) + jekyll (>= 3.8, < 5.0) + jekyll-sitemap (1.4.0) + jekyll (>= 3.7, < 5.0) + jekyll-swiss (1.0.0) + jekyll-theme-architect (0.2.0) + jekyll (> 3.5, < 5.0) jekyll-seo-tag (~> 2.0) - jekyll-theme-cayman (0.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.3) - jekyll (~> 3.5) + 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.1) - jekyll (~> 3.3) - jekyll-watch (2.0.0) + jekyll-titles-from-headings (0.5.3) + jekyll (>= 3.3, < 5.0) + jekyll-watch (2.2.1) listen (~> 3.0) - jemoji (0.9.0) - activesupport (~> 4.0, >= 4.2.9) - gemoji (~> 3.0) + jemoji (0.13.0) + gemoji (>= 3, < 5) html-pipeline (~> 2.2) - jekyll (~> 3.0) - kramdown (1.16.2) - liquid (4.0.0) - listen (3.1.5) - rb-fsevent (~> 0.9, >= 0.9.4) - rb-inotify (~> 0.9, >= 0.9.7) - ruby_dep (~> 1.2) + jekyll (>= 3.0, < 5.0) + json (2.18.1) + kramdown (2.4.0) + rexml + kramdown-parser-gfm (1.1.0) + kramdown (~> 2.0) + liquid (4.0.4) + listen (3.9.0) + rb-fsevent (~> 0.10, >= 0.10.3) + rb-inotify (~> 0.9, >= 0.9.10) + logger (1.7.0) mercenary (0.3.6) - mini_portile2 (2.3.0) - minima (2.4.1) - jekyll (~> 3.5) + 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.11.3) - multipart-post (2.0.0) - nokogiri (1.8.2) - mini_portile2 (~> 2.3.0) - octokit (4.8.0) - sawyer (~> 0.8.0, >= 0.5.3) - parallel (1.12.1) - pathutil (0.16.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 (2.0.5) - rake (12.3.1) - rb-fsevent (0.10.3) - rb-inotify (0.9.10) - ffi (>= 0.5.0, < 2) - rouge (2.2.1) - ruby-enum (0.7.2) - i18n - ruby_dep (1.5.0) - rubyzip (1.2.1) - safe_yaml (1.0.4) - sass (3.5.6) + pdf-reader (2.15.1) + Ascii85 (>= 1.0, < 3.0, != 2.0.0) + afm (>= 0.2.1, < 2) + hashery (~> 2.0) + ruby-rc4 + ttfunk + public_suffix (5.1.1) + racc (1.8.1) + rainbow (3.1.1) + rake (13.3.1) + rb-fsevent (0.11.2) + rb-inotify (0.11.1) + ffi (~> 1.0) + rexml (3.4.2) + rouge (3.30.0) + ruby-rc4 (0.1.5) + rubyzip (2.3.2) + safe_yaml (1.0.5) + sass (3.7.4) sass-listen (~> 4.0.0) sass-listen (4.0.0) rb-fsevent (~> 0.9, >= 0.9.4) rb-inotify (~> 0.9, >= 0.9.7) - sawyer (0.8.1) - addressable (>= 2.3.5, < 2.6) - faraday (~> 0.8, < 1.0) + sawyer (0.9.2) + addressable (>= 2.3.5) + faraday (>= 0.17.3, < 3) + securerandom (0.3.1) + simpleidn (0.2.3) terminal-table (1.8.0) unicode-display_width (~> 1.1, >= 1.1.1) - thread_safe (0.3.6) - typhoeus (1.3.0) + traces (0.18.2) + ttfunk (1.8.0) + bigdecimal (~> 3.1) + typhoeus (1.4.1) ethon (>= 0.9.0) - tzinfo (1.2.5) - thread_safe (~> 0.1) - unicode-display_width (1.3.2) - yell (2.0.7) + 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 719833fa599..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) -[![Build Status](https://travis-ci.org/github/opensource.guide.svg?branch=master)](https://travis-ci.org/github/opensource.guide) - -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 c2dda696624..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 Usando un lenguaje inclusivo, puede ir lejos haciendo que tus proyectos reciban de forma más cálida a los nuevos participantes. Mantén un lenguaje simple. -Luego de cómo expresarte, tu estilo a la hora de codificar puede ser importante también. [Angular](https://github.com/johnpapa/angular-styleguide) y [jQuery](http://contribute.jquery.org/style-guide/js/) son ejemplos de proyectos con un riguroso trato en este sentido. +Luego de cómo expresarte, tu estilo a la hora de codificar puede ser importante también. [Angular](https://github.com/johnpapa/angular-styleguide) y [jQuery](https://contribute.jquery.org/style-guide/js/) son ejemplos de proyectos con un riguroso trato en este sentido. No es necesario escribir una "guía de estilo" para tus proyectos cuando recién estás comenzando, y quizás hasta descubras que disfrutas al incorporar distintos estilos de codificación en tu proyecto. Pero deberías anticiparte y definir cómo tu redacción y estilo de codificación puede atraer o no a distintos tipos de personas. Define esto al comienzo. @@ -366,4 +360,4 @@ Si eres una compañía u organización: ## ¡Lo has hecho! -Felicitaciones por abrir el código de tu primer proyecto! Sin importar el devenir, trabajar en público es un regalo a la comunidad. Con cada commit, comentario y pull request, estás creando oportunidades no solo para ti, si no para que otras personas puedan aprender y crecer. +¡Felicitaciones por abrir el código de tu primer proyecto! Sin importar el devenir, trabajar en público es un regalo a la comunidad. Con cada commit, comentario y pull request, estás creando oportunidades no solo para ti, si no para que otras personas puedan aprender y crecer. diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md new file mode 100644 index 00000000000..8a22e65aa06 --- /dev/null +++ b/_articles/fa/best-practices.md @@ -0,0 +1,280 @@ +--- +lang: fa +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) نمونه‌هایی از پروژه‌ها با دستور‌العمل‌هایی برای نگهدارندگان و مشارکت‌کنندگان هستند. + +### ابلاغیه‌های خود را به صورت عمومی اعلام کنید + +تعاملات خود با بیرون را نیز ثبت کنید. در هر جایی که ممکن بود، ابلاغیه‌های مربوط به پروژ‌ه‌ی خود را به صورت عمومی اعلام کنید. اگر کسی خواست که به طور خصوصی درباره‌ی درخواستی یا پشتیبانی با شما به گفتگو بپردازد، مودبانه او را به کانال ارتباطی عمومی، همچون فهرست پستی (mailing list) یا «issue tracker» هدایت کنید. + +اگر با سایر نگهدارنده‌ها ملاقات کردید یا در خلوت تصمیم مهمی گرفتید، این مکالمه‌ها را به صورت عمومی ثبت کنید؛ حتی اگر بخواهد به صورت پست کردن یادداشت‌هایتان باشد. + +به این ترتیب، هر کسی که به انجمن شما بپیوندد به همان اطلاعاتی که سال‌ها در آنجا بوده است، دسترسی خواهد داشت. + +## نه گفتن، را یاد بگیرید + +شما مطالب خود را ثبت کردید. در حالت ایده آل، همه نوشته‌ها و مستندات شما را می‌خوانند، اما در واقع، شما باید به دیگران وجود این اطلاعات را نیز یادآوری کنید. + +درصورتی که لازم باشد قوانین خود را اجرا کنید، با نوشتن و ثبت کردن همه چیز، به شما کمک می‌کند تا شرایط را از حالت شخصی‌سازی شده در‌آورید. + +نه گفتن، لذت‌بخش نیست؛ اما گفتن «مشارکت شما با معیارهای این پروژه مطابقت ندارد» کمتر از «من مشارکت با شما را دوست ندارم»، به شخصیت طرف برمی‌خورد. + +نه گفتن در بسیاری از شرایطی که به عنوان نگهدارنده با آن روبرو خواهید شد، به کار می‌آید: درخواست‌هایی که با ویژگی‌های پروژه‌ی شما متناسب نیستند، کسی که بحث را به بیراهه می‌کشاند، انجام کارهای غیرضروری برای دیگران. + +### دوستانه با دیگران ارتباط برقرار کنید + +یکی از مهم‌ترین جاهایی که شما باید تمرین نه گفتن را انجام دهید، در سر برخی از مسائل و «درخواست‌های pull» ای است که از شما می‌شود. به عنوان نگهدارنده‌ی پروژه، ناگزیر پیشنهادهایی دریافت خواهید کرد که نمی‌خواهید آن‌ها را بپذیرید. + +چونکه شاید آن مشارکت، اهداف پروژه‌ی شما را تغییر دهد یا با چشم‌انداز شما مطابقت نداشته باشد. یا شاید ایده خوب باشد، ولی اجرای آن ضعیف باشد. + +صرف نظر از هرچه که دلیل بخواهد باشد، می‌توان مشارکت‌هایی را که مطابق با استانداردهای پروژه‌ی شما نیستند را با درایت مدیریت کرد. + +اگر مشارکتی به شما پیشنهاد بشود که نخواهید آن را بپذیرید؛ اولین واکنش شما ممکن است نادیده گرفتن آن یا تظاهر به ندیدن آن باشد. انجام این کار می‌تواند به احساسات طرف مقابل ضربه بزند و حتی باعث کاهش انگیزه‌ی سایر مشارکت‌کنندگان بالقوه‌ی اجتماع (community) شما شود. + + + +مشارکت ناخواسته را صرف اینکه آدم خوبی به نظر برسید، ادامه ندهید زیرا در ادامه‌ی راه احساس گناه خواهید کرد. با گذشت زمان، مسائل و روابط عمومی بی‌پاسخ باعث می‌شود که کارتان روی پروژه بسیار استرس‌زا و ترسناک پیش برود. + +بهتر است فوراً به مشارکت‌هایی که آن‌ها را نمی‌خواهید، پایان دهید. اگر پروژه شما از کمبود بک لاگ رنج می برد, @steveklabnik در مقاله [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) پیشنهاداتی در این خصوص ارائه کرده است. + +ثانیاً، بی‌توجهی به مشارکت‌هایتان، سیگنال‌های منفی‌ای به درون اجتماع می‌فرستد. مشارکت در هر پروژه‌ای می‌تواند دلهره‌آور باشد، خصوصاً اگر برای اولین بار باشد که در پروژه‌ای شرکت می‌کنید. حتی اگر مشارکت آن‌ها را قبول نکردید، از آن شخص تشکر کرده و از توجه او سپاسگزار باشید. کار پسندیده‌ای است! + +اگر نمی‌خواهید مشارکت کسی را قبول کنید: + +* از توجه آن‌ها **تشکر کنید**. +* **توضیح دهید که چرا نمی‌توانید با آن‌ها همکاری داشته باشید** و اگر می‌توانید، پیشنهادهای واضحی را برای بهبود آن‌ها برای آینده ارائه دهید؛ مهربان باشید، اما مصمم. +* در صورت داشتن دسترسی، آن‌ها را **به مستندات مربوطه ارجاع دهید**. اگر با درخواست‌های مکرر برای مواردی که نمی‌خواهید آن‌ها را بپذیرید، مواجه شدید؛ آن موارد را برای جلوگیری از مکررات به مستندات خود اضافه کنید. +* **درخواست مشارکت را ببندید**. + +شما به 1 یا 2 جمله بیشتر، برای پاسخگویی نیاز نخواهید داشت. به عنوان مثال، هنگامی که [celery](https://github.com/celery/celery/)، خطایی مربوط به ویندوز را گزارش داد، «berkerpeksag» [اینگونه پاسخ](https://github.com/celery/celery/issues/3383) داد: + +![Celery screenshot](/assets/images/best-practices/celery.png) + +اگر فکر نه گفتن شما را وحشت زده می‌کند، بدانید که شما تنها نیستید. همانطور که @jessfraz می‌گوید: + +> من با نگهدارنده‌هایی از پروژه‌های اوپن سورس مختلف مانندMesos» ،«Kubernetes» «Chromium صحبت کرده‌ام و همه موافق هستند که یکی از سخت‌ترین قسمت‌های نگهدارنده بودن، «نه» گفتن به اصلاحاتی است که نمی‌خواهید. + +در نپذیرفتن پیشنهاد مشارکت کسی، احساس گناه نکنید. [طبق گفته‌ی](https://twitter.com/solomonstre/status/715277134978113536) @shykes، اولین قانون پروژه‌های اوپن سورس این است که: «نه موقتی‌ست، بله برای همیشه». در حالی که همدردی با اشتیاق فرد دیگر، چیز پسندیده‌ای است؛ اما رد کردن پیشنهاد مشارکت به معنای رد کردن هویت فرد پشت سر آن پیشنهاد نیست. + +ختم کلام این است که اگر مشارکت با دیگری به اندازه کافی خوب نباشد، شما ملزم به پذیرفتن هیچ تعهدی نیستید. وقتی دیگران در پروژه‌ی شما مشارکت می‌کنند، مهربان و پاسخگو باشید؛ اما فقط تغییراتی را قبول کنید که واقعاً معتقد هستید پروژه‌ی شما را بهتر می‌کند. هر چه در نه گفتن، تمرین بیشتری داشته باشید؛ گفتن آن راحت‌تر می‌شود. به شما قول می‌دهم. + +### فعال باشید + +برای کاهش حجم مشارکت‌های ناخواسته در وهله‌ی اول، روند پروژه خود را در راهنمای ارسال و پذیرش مشارکت‌ها توضیح دهید. + +اگر درخواست‌های مشارکت بسیار کم کیفیت دریافت می‌کنید، از افراد متقاضی بخواهید کمی قبل از ارسال پیشنهاد، کارهایی انجام دهند؛ به عنوان مثال: + +* Fill out a issue or PR template/checklist +* قبل از ارسال درخواست Pull یک گزارش اشکال ارسال کنند. + +اگر از قوانین شما پیروی نکردند، بلافاصله درخواست را رد کنید و آن‌ها را به راهنمای ارسال مرجوع کنید. + +اگرچه ممکن است در ابتدا این رویکرد کمی خشن به نظر برسد، اما فعال بودن برای هر دو طرف خوب است. در نتیجه این احتمال را کاهش می‌دهد که کسی ساعت‌های زیادی صرف «درخواست Pull»ی که شما آن را قبول نخواهید کرد، نکند. و ثانیا حجم کاری شما را نیز کمتر می‌کند و مدیریت آن ساده‌تر می‌شود + + + +بعضی اوقات، وقتی نه می‌گویید، مشارکت‌کننده‌ی بالقوه ممکن است ناراحت شود یا از تصمیم شما انتقاد کند. اگر آن‌ها خصومت‌آمیز رفتار کردند و اگر نخواستند به طور سازنده همکاری کنند، [قدم‌هایی را برای خنثی کردن موقعیت](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) بردارید یا حتی آن‌ها را از اجتماع خودتان اخراج کنید. + +### با آغوش باز، پذیرای راهنمایی‌ و مشاوره باشید + +شاید کسانی در اجتماع شما باشند که مرتباً درخواست‌های مشارکتی پیشنهاد می‌کنند که با استانداردهای پروژه‌ی شما مطابقت نداشته باشد. مسلما رد شدن پیاپی برای هر دو طرف، طاقت‌فرساست. + +اگر دیدید کسی مشتاق پروژه‌ی شما است، اما به کمی پیشرفت نیاز دارد، صبور باشید. در هر شرایطی به روشنی توضیح دهید که چرا مشارکت آن‌ها متناسب با انتظارات پروژه‌ی شما نیست. سعی کنید ابتدا وظایفی ساده‌تر و با ابهامات کمتر به آن‌ها بسپرید تا به قول معروف «آماده‌ی کار شوند». اگر وقت داشتید، در اولین مشارکت، آن‌ها را راهنمایی کنید، یا شخص دیگری را در اجتماع خود پیدا کنید که تمایل به راهنمایی کردن آن‌ها داشته باشد. + +## از اجتماع خود بهره ببرید + +لازم نیست همه‌ی کارها را خودتان انجام دهید. دلیلی دارد که پروژه‌ی شما، اجتماعی برای خود دارد! حتی اگر هنوز اجتماعی فعال ندارید، اگر کاربران زیادی دارید، کارها را به آن‌ها بسپرید. + +### حجم کار را با دیگران تقسیم کنید + +اگر می‌خواهید که دیگران به شما کمک کنند، از آن‌ها درخواست کنید. + +راهی برای جذب مشارکت‌کنندگان این است که کارها را از نظر سختی درجه‌بندی کنید و [کارهای ساده را به مبتدی‌ها بسپرید](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). سپس GitHub این موضوعات را در فضاهای مختلف خودش به نمایش می‌گذارد و باعث افزایش دیده شدن آن‌ها می‌شود. + +وقتی مشاهده کردید که مشارکت‌کنندگان جدید به صورت مکرر همکاری می‌کنند، با دادن مسئولیت‌های بیشتر، آن‌ها را تصدیق کنید و به رسمیت بشناسید. مشخص کنید که چگونه دیگران می‌توانند در صورت اشتیاق به جایگاه‌های رهبری دست یابند. + +همانطور که @lmccart در پروژه‌ی خود متوجه شد، تشویق دیگران [به اشتراک گذاشتن مالکیت پروژه](../building-community/#مالکیت-پروژه-تان-را-به-اشتراک-بگذارید) می‌تواند حجم کاری شما را بسیار کاهش دهد[p5.js](https://github.com/processing/p5.js). + + + +اگر لازم است کمی از پروژه‌ی خود فاصله بگیرید، یا وقفه‌ای در آن ایجاد کنید یا به طور کلی کنار بکشید؛ به هیچ وجه شرم‌آمور نیست که از شخص دیگری بخواهید مسئولیت کار شما را به عهده بگیرد. + +اگر افراد دیگری مشتاق این هستند، به آن‌ها اجازه‌ی دسترسی دهید یا کنترل پروژه را به طور رسمی به شخص دیگری بسپارید. اگر کسی پروژه‌ی شما را به چند شاخه تبدیل کرد و به طور فعال آن را در جای دیگری نگهداری کرد، پیوند دادن پروژه‌ی اصلی خود به شاخه را مد نظر قرار دهید. این خیلی خوب است که مردم می‌خواهند پروژه شما ادامه یابد! + +@progrium [متوجه شد]( https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) که ثبت کردن چشم‌انداز [پروژه](https://github.com/dokku/dokku)، کمک کرد تا آن اهداف حتی پس از کنار کشیدن او ادامه یابند: + +> من یک صفحه‌ در ویکی نوشتم و آنچه را که می‌خواهم و چرایی آن را توصیف کردم. بنا به دلایلی برای من تعجب‌آور بود که نگهدارندگان شروع به انتقال پروژه به سمت و سوی دلخواه خود کردند! آیا آنطور که می‌خواستم، پیش رفت؟ نه همیشه. ولی پروژه را به آنچه که نوشته‌ بودم، نزدیک‌تر کرد. + +### به دیگران اجازه دهید تا راه حل‌های مورد نیاز خودشان را طراحی کنند + +اگر فرد مشارکت‌کننده‌ای نظر دیگری در مورد کاری که پروژه باید انجام دهد داشته باشد، بهتر است که آن‌ها را با مهربانی تشویق به کار بر روی شاخه‌ی خودشان از پروژه بکنید. + +به چند شاخه تقسیم کردن پروژه، الزاما چیز بدی نیست. امکان کپی و اصلاح پروژه‌ها، یکی از بهترین ویژگی‌های اوپن سورس بودن است. تشویق اجتماع (community) خودتان به کار بر روی شاخه‌های خودشان می‌تواند فضای خلاقانه‌ی مورد نیاز را فراهم آورد، بدون اینکه با چشم‌اندازهای پروژه‌ی شما تداخلی ایجاد کند. + + + +این موضوع همچنین درمورد کاربری صدق می‌کند که واقعاً نیاز به راه‌حلی دارد که ظرفیت طراحی آن را ندارید. ارائه‌ی APIها و هوک‌های سفارشی‌سازی (customization hooks)، بدون نیاز به تغییر مستقیم سورس، می‌توانند به دیگران در تأمین نیازهاشان کمک کنند. @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)، به بازبین‌های بالقوه برای «درخواست pull»ها خبر می دهد. +* ابزار [Danger](https://github.com/danger/danger)، به بررسی و بازبینی اتوماتیک کد کمک می‌کند. +* ابزار [no-response](https://github.com/probot/no-response)، مسائلی را که نویسنده به درخواست‌ها برای اطلاعات بیشتر پاسخ نداده است، می‌بندد. +* ابزار [dependabot](https://github.com/dependabot)، هر روز «فایل‌های وابسته» (مثل کتابخانه‌ها یا کلاس‌های جانبی یا ماژول‌ها) شما را از نظر الزامات منسوخ شده بررسی می‌کند و «درخواست‌های pull» را برای هر موردی که پیدا می‌کند، باز می‌کند. + +برای گزارش اشکالات (bug) و سایر مشارکت‌های متداول، GitHub دارای [قالب‌های طرح مشکل و قالب‌های درخواست‌های pull](https://github.com/blog/2111-issue-and-pull-request-templates) است، که می‌توانید برای کارآمد ساختن ارتباطاتی که دریافت می‌کنید، استفاده کنید. «TalAter»، برای کمک کردن به شما برای طرح مشکلات و مسائل روابط عمومی (PR templates)، ابزار [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) را ساخت. + +برای مدیریت اعلان‌های ایمیل خود، می‌توانید [فیلترهای ایمیل](https://github.com/blog/2203-email-updates-about-your-own-activity) را تنظیم کنید تا ایمیل‌ها براساس اولویت سازماندهی شوند. + +اگر می خواهید فراتر از حد معمول باشید، شیوه‌نامه‌ها (style guides) و ابزار «linters» می‌توانند مشارکت‌های پروژه را استاندارد کرده و بررسی و پذیرش آن‌ها را آسان کنند. + +اگرچه اگر استانداردهای شما بسیار پیچیده باشد، می تواند موانع و مسائل مشارکت را افزایش دهند. مطمئن شوید که فقط به اندازه‌ی کافی قوانینی را برای در آسایش قرار گرفتن دیگران اضافه کنید. + +اگر مطمئن نیستید که از چه ابزاری استفاده کنید، به سایر پروژه‌های معروف به ویژه آن پروژه‌هایی که مربوط به اکوسیستم خودتان است، توجه کنید. به عنوان مثال، فرآیند مشارکت برای سایر ماژول‌های «Node»، چگونه است؟ همچنین استفاده از ابزارها و رویکردهای مشابه، فرآیند کارتان را برای مشارکت‌کنندگان‌ شما آشناتر می‌کند. + +## اشکالی ندارد اگر که وقفه‌ای در کار خود ایجاد کنید + +کار کردن به صورت اوپن سورس برای شما شادی آورد. شاید اکنون باعث شده است شما احساس انزواطلبی داشته باشید یا احساس گناه کنید. + +شاید وقتی به پروژه‌های خود فکر می‌کنید بیش از حد احساس آشفتگی و یا احساس ترس می‌کنید. و در همین حال، «مشکلات» و «درخواست‌های pull» روی هم انباشته می‌شود. + +فرسودگی و خسته شدن از کار، مسئله‌ای واقعی و فراگیر در پروژه‌های اوپن سورس است؛ مخصوصاً در میان نگهدارندگان. به عنوان یک فرد نگهدارنده، خوشحالی و رضایت شما برای بقای هر پروژه‌ی‌ اوپن سورسی، ضروری است. + +پس نیازی به گفتن نیست؛ به خودتان استراحت بدهید! نیازی نیست تا سر حد خستگی و فرسودگی پیش بروید تا سپس به تعطیلات بروید. @brettcannon، توسعه‌دهنده‌ی پایتون، [تصمیم گرفت پس از 14 سال کار داوطلبانه در OSS، به تعطیلات یک ماهه برود](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/). + +درست مانند هر کار دیگری، تعطیلات منظم، شما را باطراوت نگه می‌دارد و باعث خوشحالی و هیجان شما نسبت به کارتان می‌شود. + + + +گاهی اوقات، زمان‌هایی که حس می‌کنید همه به شما احتیاج دارند؛ ممکن است فاصله گرفتن از پروژه‌ی اوپن سورس سخت باشد. حتی ممکن است دیگران، شما را به خاطر فاصله گرفتن سرزنش کنند. + +در حالی که از پروژه فاصله گرفتید، تلاش خود را برای یافتن پشتیبانی از کاربران و اجتماع خود بکنید. اگر نتوانستید پشتیبانی دیگران را به دست آورید، به هر حال کار خودتان را بکنید و فاصله‌ای را که نیاز دارید از پروژه بگیرید. زمانی که حضور نداشتید، حتماً ارتباط خود را با دیگران حفظ کنید؛ تا مردم از نبود پاسخگویی گیج نشوند. + +فاصله گرفتن، فقط منحصر به تعطیلات می‌شود. اگر نمی‌خواهید آخر هفته‌ یا در ساعات کاری، پروژه‌های اوپن سورس انجام دهید، این را به اطلاع دیگران برسانید تا بدانند که در آن اوقات مزاحم شما نشوند. + +## ابتدا به فکر خودتان باشید! + +نگهداری یک پروژه‌ی محبوب به مهارت‌های متفاوتی در مقایسه با مهارت‌های مراحل اولیه‌ی رشد نیاز دارد، اما به همان میزان پاداش بیشتری هم خواهد داشت. به عنوان یک نگهدارنده، شما باید مهارت‌های رهبری و شخصی در سطحی فرای دیگران داشته باشید. اگرچه مدیریت آن همیشه آسان نیست، اما تعیین مرزهای مشخص و تنها پذیرفتن آنچه که با آن راحت هستید به شما کمک می‌کند تا شاد، سرحال و کارآمد باشید. diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md new file mode 100644 index 00000000000..15cc1d0c63d --- /dev/null +++ b/_articles/fa/building-community.md @@ -0,0 +1,277 @@ +--- +lang: fa +title: ساخت انجمن های پذیرا +description: ساخت یک انجمن که افراد را به استفاده کردن ، اشتراک گذاری و تبلیغ کردن پروژه تان ترغیب کند. +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## پروژه تان را برای موفقیت راه اندازی کنید + +وقتی شما پروژه خود را راه اندازی کنید، مطالبی را پخش می کنید و افراد در حال بررسی آنها هستند. حالا سوال اینجا است که چطور باید از آنها بخواهید که در انتظار مطالب‌تان باشند؟ + +یک انجمن پذیرا ، یک نوع سرمایه گذاری برای شهرت و آینده پروژه تان است. اگر پروژه تان در حال آغاز کسب مشارکتهای اولیه اش است، با اعطای یک تجربه مثبت به مشارکت کننده های اولیه شروع کنید، و برای آنها به عقب برگشتن را ساده سازید + +### کاری کنید تا افراد احساس پذیرفته شدن داشته باشند + +یک راه برای تفکر درباره انجمن پروژه تان از طریق آنچه مایک مک کویید آن را [قیف مشارکت کننده](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) + +در حین اینکه شما انجمن خود را می سازید، در نظر بگیرید چطور فردی در بالای قیف( یک کاربر بالقوه) می تواند از لحاظ نظری راهش را به ته قیف ( یک نگهدارنده فعال) هموار سازد. هدف شما این است که ناسازگاری در هر مرحله تجربه مشارکت کننده را کاهش دهید. وقتی افراد، بردهای آسانی دارند، آنها انگیزه بیشتری برای ادامه کار دارند. + +با مستندات خود شروع کنید: + +* **برای افراد استفاده از پروژه خود را ساده سازید:** یک مثال از آن کد واضح و [README دوستانه](../starting-a-project/#نوشتن-راهنمای-مشارکت) است که راه اندازی پروژه تان را برای هر کسی هموارتر می سازد. +* **بطور واضح توضیح دهید که مشارکت چگونه است،** البته این کار با استفاده از [فایل مشارکت](../starting-a-project/#نوشتن-راهنمای-مشارکت) و به روز نگه داشتن موضوعات میسر است. + +* **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس GitHub ، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد. + +[نظرسنجی منبع باز( اوپن سورس) 2017 GitHub](http://opensourcesurvey.org/2017/) که مستندات ناقص و گیچ کننده ای را نشان می داد، بزرگترین مشکل برای کاربران منبع باز می باشد. مستندات خوب، افراد را دعوت می کند که با پروژه‌تان تعامل کنند. در نهایت افراد یک موضوع یا یک درخواست pull( ادغام یا یکپارچگی) را باز خواهند کرد. از این تعاملات به عنوان فرصتهایی برای سوق دادن آنها به پایین قیف استفاده کنید. + +* **وقتی شخص جدیدی وارد پروژه شما می شود، از وی از روی علاقه تشکر کنید!** این یک تجربه منفی خواهد بود که از فردی بخواهید که به پروژه تان برنگردد. +* **پاسخگو باشید:** اگر شما به موضوعاتشان در عرض یک ماه پاسخ نمی دهید، شانس اینکه پروژه تان را فراموش کنند بالا می رود. +* **درباره انواع مشارکت هایی که خواهید پذیرفت ، پذیرای عقاید و افکار جدید باشید.** بسیاری از مشارکت کننده ها با یک گزارش باگ یا ترمیم جزئی آغاز می کنند. راه های زیادی برای مشارکت در یک پروژه وجود دارد. به افراد اجازه دهید تا بازگو کنند [چطور می خواهند مساعدت کنند](../how-to-contribute/#مشارکت-به-چه-معناست). +* **اگر یک مشارکتی وجود دارد که شما با آن مخالف هستید،** از آنها به خاطر بیان ایده تشکر کرده و [توضیح دهید](../best-practices/#نه-گفتن-را-یاد-بگیرید) چرا آن ایده با محدوده پروژه تان تناسب ندارد، و اگر مستندات خوبی دارید رو کنید. + + + +اکثریت مشارکت کنندگان منبع باز، مشارکت کنندگان اتفاقی هستند: افرادی که تنها گهگاه در یک پروژه مشارکت می کنند. یک مشارکت کننده اتفاقی شاید زمان کافی برای همگامی با پروژه تان را نداشته باشد، پس کارتان این است که مشارکت را برای او تا حد ممکن ساده تر سازید. + +ترغیب کردن مشارکت کنندگان دیگر یک سرمایه گذاری روی خودتان می باشد. وقتی شما بزرگترین طرفدارانتان را توانمند می سازید تا با کاری که آنها با انجامش هیجان زده می شوند همگام شوند، فشار کمی برای انجام کامل کار توسط خودتان اعمال می شود. + +### مستند کردن همه چیز + + + +وقتی شما یک پروژه جدید را آغاز می کنید، شاید احساس طبیعی تان این باشد که کارتان را باید خصوصی ادامه دهید. اما پروژه های منبع باز هنگامی شما را برمی انگیزند که شما پروسه تان را بطور علنی مستند می سازید. + +وقتی شما کارها را می نویسید، افراد بیشتری می توانند در هر مرحله از رویه ها مشارکت کنند. شما ممکن است درباره چیزی کمک بخواهید چیزی که حتی در حد لزوم هم آن را نمی دانستید. + +مکتوب کردن چیزها معنایی بیشتر از مستندسازی فنی صرف دارد. هر زمان شما احساس می کنید که مصر هستید تا کاری را مکتوب کنید یا بطور خصوصی پروژه تان را بحث کنید، از خودتان بپرسید که آیا می توانید آنرا علنی کنید یا نه؟ + +درباره نقشه مسیر پروژه تان ، انواع مشارکت هایی که شما در پی آنها هستید، اینکه چطور مشارکت ها بررسی می شوند یا اینکه چرا تصمیمات خاصی را اتخاذ می کنید ، شفاف سازی کنید. + +اگر شما کاربران متعددی را مطلع سازید تا مسئله مشابهی را بررسی کنند، جوابها را در README مستند سازید. + +برای جلسات، منتشر کردن یادداشت ها و نقشه های مسیر خود در یک موضوع مرتبط را مدنظر قرار دهید. بازخوردی که از این سطح از شفافیت کسب می کنید شاید شما را شگفت زده کند. + +مستندسازی همه چیزها با کاری که شما انجام می دهید نیز همگام است. اگر شما در حال کار بر روی آپدیت کردن پروژه تان در حجم زیاد هستید، برای آن یک بخش درخواست pull اعمال کنید و آن را به عنوان کاری که در حال پیشرفت است نمره دهید (WIP) .از این طریق، افراد دیگر می توانند در پروسه شما اعمال نظر کنند + +### پاسخگو باشید + +در حین اینکه شما [پروژه تان را ارتقا می دهید](../finding-users)، افراد شاید بازخوردهایی برای شما داشته باشند. آنها ممکن است درباره اینکه چطور موارد کار می کنند سوالاتی داشته باشند، یا برای شروع نیاز به کمک داشته باشند. + +سعی کنید که هنگامی که شخصی یک موضوع را پیوست می کند، تحویل می دهد یا درخواستی دارد یا درباره پروژه تان سوالی می پرسد پاسخگو باشید. وقتی شما به سرعت پاسخ دهید، افراد احساس خواهند کرد که آنها بخشی از یک گفتگو هستند و درباره مشارکت با شما مشتاق تر خواهند بود. + +حتی اگر نمی توانید درخواستشان را فوراً بررسی کنید،حداقل از آنها تشکر کنید تا به افزایش مشارکت کمک کرده باشید. اینجا بیان می شود چطور @tdreyno به یک درخواست pull در سایت [Middleman](https://github.com/middleman/middleman/pull/1466) پاسخ داده است: + +![Middleman pull request](/assets/images/building-community/middleman_pr.png) + +[در‌یک مطالعه موزیلا](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) پی برده است که مشارکت کنندگانی که بررسی های کدگونه را در ظرف 48 ساعت دریافت کرده بودند میزان برگشت و تکرار مشارکت خیلی بیشتری داشتند + +همچنین مکالمات درباره پروژه تان می تواند در محل های دیگری در اینترنت مانند Stackverflow ، توییتر، یا Reddit روی دهد. شما می توانید در برخی از این محل ها نوتیفیکیشن هایی را اجرا کنید و بدین طریق هنگامی که شخصی به پروژه تان اشاره می کند، با خبر شوید. + +### محلی برای مشارکت کردن انجمن تان اختصاص دهید + +دو دلیل برای اعطای یک محل برای مشارکت در انجمن‌تان وجود دارد. + +اولین دلیل به خاطر مشارکت کنندگان است. به افراد کمک کنید تا همدیگر را بشناسند. افراد دارای منافع مشترک، بطور اجتناب ناپذیری می خواهند که محلی برای گفتگو درباره آن منافع داشته باشند و وقتی ارتباطات علنی و قابل دسترس باشد، هر کسی می تواند آرشیوهای گذشته را بخواند تا به مشارکت خود شتاب بخشد. + +دلیل دوم به خاطر خود شما است. اگر شما به افراد محل عمومی برای صحبت درباره پروژه تان ندهید، آنها احتمالاً با شما مستقیماً تماس خواهند گرفت. در شروع، ظاهراً ساده است که به پیامهای خصوصی با موضوع « فقط این بار»پاسخ دهید. اما در طول زمان مخصوصاً اگر پروژه تان معروف شود، شما کلافه خواهید شد. در برابر وسوسه ارتباط برقرار کردن با افراد درباره پروژه تان بطور خصوصی مقاومت کنید. در عوض آنها را به یک کانال عمومی معین هدایت کنید. + +ارتباطات عمومی می تواند در حقیقت هدایت کردن مردم برای باز کردن یک موضوع به جای ایمیل مستقیم یا اظهار نظر کردن روی وبلاگ‌تان باشد. همچنین شما می توانید یک لیست مِیلی داشته باشید، یا یک حساب توییتر، Slack یا کانال IRC برای افراد راه بیاندازید تا درباره پروژه تان گفتگو کنند. یا همه موارد بالا را با هم اعمال کنید! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) هر هفته وقت خود را در ساعات اداری به کمک به اعضای انجمن اختصاص می دهد: + +> همچنین کاپس هر هفته زمانی را برای پیشنهاد دادن کمک و راهنمایی به انجمن اختصاص می دهد. مالکان کاپس با اختصاص زمان اختصاصی برای کار کردن با تازه واردها، کمک به PRs ، و بحث درباره ویژگی های جدید موافقت کرده اند. + +استثنائات قابل توجهی در مورد ارتباطات عمومی وجود دارد از قبیلِ: موضوعات امنیتی و نقض کدهای رفتاری حساس. شما باید همیشه راهی پیش پای افراد بگذارید تا این موضوعات را بطور خصوصی گزارش کنند. اگر نمی خواهید که از ایمیل شخصی خود استفاده کنید، یک آدرس ایمیل اختصاصی ایجاد کنید. + +## انجمن‌تان را رشد دهید + +انجمنها بی نهایت قدرتمند هستند. این قدرت می تواند مفید یا مضر باشد که به این بستگی دارد که چطور آن را اعمال می کنید. در حین اینکه انجمن پروژه تان رشد می کند، راه هایی برای کمک به آن وجود دارد تا به جای نیروی مخرب یک نیروی سازنده باشد. + +### بازیگران بد را تحمل نکنید + +هر پروژه معروفی ناگزیر افرادی که ضرررسان هستند را نیز جذب خواهد کرد. آنها شاید بحثهای غیرضروری را شروع کنند، درباره ویژگی های جزئی خرده گیری کنند یا برای بقیه قلدری کنند. + +شما به بهترین نحو تلاش کنید تا یک خطی مشی تحمل-صفر نسبت به این نوع افراد اقتباس کنید. اگر افراد منفی را چک نکنید ، افراد دیگر در جامعه تان را نیز ناراحت خواهند ساخت. آنها حتی شاید پروژه تان را ترک کنند. + + + +بحثهای دائمی بر روی جنبه های جزئی پروژه تان، افرا دیگر از جمله خود شما را از تمرکز روی کارهای مهم دیگر بازمی دارد. افراد جدیدی که وارد پروژه تان می شوند شاید این مکالمات را ببینند و در نتیجه مشارکت نکنند. + +وقتی می بینید رفتار منفی‌ای در پروژه تان رخ می دهد، آن را علنی کنید. با لحن قاطع توضیح دهید که چرا رفتارشان قابل قبول نیست. اگر این مسئله دائماً وجود داشت شاید نیاز داشته باشید که از [آنها بخواهید تا پروژه تان را ترک کنند](../code-of-conduct/#عملیاتی-کردن-منشور-اخلاقی). [کد رفتاری‌تان](../code-of-conduct/) می تواند یک رهنمود سازنده برای این مکالمات باشد. + +### با مشارکت کنندگان تماس بگیرید و در جریان قرار بگیرید که آنها در کجای کار هستند + +مستندسازی خوب تنها هنگامی مهمتر می شود که انجمن تان رشد می کند. مشارکت کنندگان اتفاقی که ممکن است با پروژه تان آشنا نباشند ، مستنداتتان را می خوانند تا به سرعت متنی که آنها نیاز دارند را بدست آورند. + +در فایل Contributing خود، بطور آشکار به مشارکت کنندگان جدید بگویید که چگونه کار خود را شروع کنند. شما شاید حتی بخواهید که یک بخش اختصاصی برای این منظور بسازید. برای مثال [Django](https://github.com/django/django) یک صفحه ویژه برای خوشامدگویی به مشارکت کنندگان جدید دارد + +![Django new contributors page](/assets/images/building-community/django_new_contributors.png) + +در صف موضوعتان ، باگهایی که برای انواع مختلف مشارکت کنندگان مناسب هستند، وجود دارد: برای مثال [_تنها اولین دفعه_](https://kentcdodds.com/blog/first-timers-only) ، « اولین موضوع خوب» یا « مستندات» را برچسب بزنید. این برچسب ها برای فرد جدید، بررسی سریع پروژه و شروع به کار بر روی موضوعاتتان را آسان می سازد + +سرانجام از مستندات‌تان استفاده کنید تا افراد را در هر مرحله از این رویه خرسند سازید. + +شما هرگز با اکثر افرادی که وارد پروژه تان می شوند تعامل نخواهید کرد. شاید مشارکتهایی وجود داشته باشد که آنها را دریافت نکرده اید چون برخی از افراد نمی دانند از کجا باید مشارکت خود را شروع کنند. حتی کلمات کمی وجود دارند که با آن می توان افراد را از ترک کردن پروژه تان به خاطر اشباع شدن بازداشت. + +برای مثال، در اینجا ما [رهنمودهای مشارکت](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) پروژه [روبینیوس](https://github.com/rubinius/rubinius/) را می آوریم: + +> ما می خواهیم که کار خود را با قدردانی از شما برای استفاده از روبینیوس شروع کنیم. این پروژه یک کار عاشقانه است و ما از همه کاربرانی که باگها را معرفی می کنند، عملکردها را بهبود می دهند و به مستندسازی کمک می کنند، قدردانی می کنیم. هر مشارکتی مهم است پس از شما برای مشارکت سپاسگزاری می کنیم. اینکه گفته می شود اینجا رهنمودهای کمی وجود دارند که ما از شما بخواهیم تا از آنها پیروی کنید، می تواند باعث موفقیت رسیدگی به موضوعتان شود. + +### مالکیت پروژه تان را به اشتراک بگذارید + + + +افراد با مشارکت در پروژه هایتان هنگام احساس مالکیت بر آن، هیجان زده می شوند. این بدان معنی نیست که شما باید چشم انداز پروژه تان را تغییر دهید یا مشارکتهایی که شما نمی خواهید را بپذیرید. اما هرچه به دیگران اعتبار بیشتری ببخشید، آنها بیشتر انتظار آن را می کشند. + +ببینید آیا می توانید تا آنجا که ممکن است راه هایی را برای تسهیم مالکیت با انجمن تان بیابید. در اینجا بعضی ایده ها در این باره ارائه می شوند: + +* **در برابر رفع باگ های ( غیرسرنوشت ساز) ساده مقاومت کنید:** در عوض از آنها به عنوان فرصتهایی برای پذیرش مشارکت کنندگان جدید استفاده کنید، یا شخصی که تمایل به مشارکت دارد، را راهنمایی کنید. شاید در اول غیرطبیعی به نظر برسد، اما سرمایه گذاری‌تان در طول زمان بازدهی‌اش را به تدریج بدست خواهد داد. برای مثال،@michaeljoseph از یک مشارکت کننده خواست تا درخواست pull خود را درباره موضوع [Cookiecutter](https://github.com/audreyr/cookiecutter) به جای تعمیر آن توسط خودش ارائه دهد. + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **یک فایل مشارکت کننده یا مولف در پروژه تان را شروع کنید** تا همه افرادی که به پروژه تان کمک می کردند مانند [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) را لیست کنید. + +* **اگر شما یک انجمن بزرگ دارید، یک خبرنامه منتشر کنید یا یک پست وبلاگی بنویسید** که قدردان مشارکت کنندگان هستید. خبرنامه های [This Week in Rust](https://this-week-in-rust.org/) و [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) هودی دو نمونه خوب از این موارد هستند. + +* **به همه مشارکت کنندگان دسترسی Commit کردن بدهید.** @fleixge پی برد که این کار، [افراد را وادار می کند](https://felixge.de/2013/03/11/the-pull-request-hack.html) تا با هیجان بیشتری patch هایشان را اصلاح کنند و حتی باعث می شود اعضای جدید برای پروژه هایی بیابید که روی آنها سرمایه گذاری نکرده بودید. + +* اگر پروژه تان روی گیت هاب است، **آن را از حساب شخصی خود به یک [سازمان](https://help.github.com/articles/creating-a-new-organization-account/) انتقال دهید** و حداقل یک ادمین پشتیبان به آن بیافزایید. سازمان ها کار کردن روی پروژه هایی با همکاران خارجی را آسانتر می سازند. + +واقعیت این است که [اکثر پروژه ها](https://peerj.com/preprints/1233/) تنها دارای یک یا دو عضو هستند کسانی که اکثر کار را انجام می دهند. هرچه پروژه تان بزرگتر باشد، و هرچه انجمن تان بزرگتر باشد، دستیابی به کمک ساده تر خواهد بود. + +در حالی که شاید همیشه شخصی را برای جواب دادن به تماس ها نیابید، اما فرستادن سیگنالهایی به آنجا شانسی که افراد دیگر در پروژه همکاری بکنند را افزایش خواهد داد. و اینکه هرچه زودتر اقدام کنید، افراد زودتر می توانند به شما کمک کنند. + + + +## حل و فصل تضادها + +در مراحل اولیۀ پروژه تان، اتخاذ کردن تصمیمات بزرگ ساده است. وقتی می خواهید که کاری را انجام دهید، شما فقط مشغول انجام آن شوید. + +در حین اینکه پروژه تان معروف تر می شود، مردم بیشتری از تصمیماتی که شما اتخاذ می کنید سود می برند. حتی اگر انجمن بزرگی از مشارکت کنندگان را ندارید، و اگر پروژه تان دارای کاربران زیادی نیست، شما افرادی را خواهید یافت که تصمیمات را می سنجند و موضوعاتی مرتبط با خودشان را مطرح می کنند. + +برای اکثر بخش ها، اگر شما یک انجمن محترم و صمیمی را پرورش می دهید و پروسه تان را علنی مستندسازی کنید، انجمن تان باید قادر باشد تا راه حل را پیدا کند. اما گاهی اوقات شما موضوعی را مطرح می کنید که پرداختن به آن یک کمی دشوارتر است. + +### قالبی برای نوع دوستی تعیین کنید + +وقتی انجمن تان با یک موضوع خاص مواجه است، مجرب ها ممکن است داوطلب شوند. افراد ممکن است عصبی شوند یا اشباع شوند و آن وظیفه را به شما یا دیگری محول کنند. + +کارتان به عنوان یک نگاهدارنده آن است که از وخیم تر شدن شرایط جلوگیری کنید. حتی اگر شما عقیده قوی‌ای به این موضوع دارید، سعی کنید که جایگاه یک میانجی یا تسهیل کننده را داشته باشید به جای اینکه به نبرد با دیدگاه تان وارد شوید. اگر شخصی در حال بی مهر شدن است یا دارد مکالمات را انحصاری می سازد، [فوراً اقدام کنید](../building-community/#بازیگران-بد-را-تحمل-نکنید) تا مباحثات را مدنی و سودمند نگه دارید. + + + +افراد دیگر به رهنمودهای شما نگاه می کنند. یک نمونه خوب را تعیین کنید، شما هنوز می توانید ناامیدی، ناراحتی یا نگرانی را اظهار کنید اما آرامش خود را کاملاً حفظ کنید. + +خونسرد بودن آسان نیست، اما نشان دادن رهبری ، سلامت انجمن تان را بهبود می بخشد. اینترنت از شما تشکر می کند. + +### فایل README خود را به عنوان یک قانون اساسی در نظر بگیرید + +فایل README تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#نوشتن-راهنمای-مشارکت)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره README تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی README تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید. + +### تمرکز روی سفر نه مقصد + +برخی پروژه ها از یک فرایند رای گیری استفاده می کنند تا تصمیمات بزرگی را اتخاذ کنند. در حالی که در نگاه اول معقول به نظر می رسد، اما رای گیری به جای گوش دادن و پرداختن به نگرانی های همدیگر روی دستیابی به یک جواب تاکید می کند. + +رای گیری می تواند سیاسی باشد، که در آن اعضای انجمن برای انجام منافع همدیگر یا رای دادن در یک راه خاص احساس تحت فشار قرار داشتن کنند. البته همه رای نمی دهند، چه [اکثریت انجمن تان سکوت پیشه کنند](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) چه کاربران فعلی که از رای آگاهی ندارند در حال جایگزین شدن باشند. + +گاهی اوقات، رای گیری یک رهگشای ضروری است. هرچه شما بیشتر توانمند باشید به جای خودِ اجماع بیشتر روی « اجماع‌جویی» تاکید می کنید. + +تحت یک فرایند اجماع جویی ، اعضای انجمن، نگرانی های بزرگ خود را بحث می کنند تا آنها احساس کنند که حرفهایشان شنیده می شود. وقتی تنها نگرانی های کوچک باقی می ماند، انجمن روی به جلو حرکت می کند.« اجماع جویی مهر تاییدی بر این مطلب است که یک انجمن شاید قادر نباشد که به یک جواب جامع دست یابد. در عوض، آن به گوش سپاری و مباحثه اولویت می دهد. + + + +حتی اگر شما در عمل به عنوان یک نگهدارنده پروژه یک فرایند اجماع‌جویی را اقتباس کنید، مهم است که بدانید چه افرادی در حال گوش دادن هستند. وادار کنید دیگر افراد احساس کنند که شنیده می شوند و متعهد شوید که نگرانی هایشان را حل می کنید، و راه طولانی انتشار شرایط حساس را طی می کنید. سپس حرفهایتان را با اقداماتتان مقایسه کنید. + +با به خاطر داشتن یک راه حل به یک تصمیم متمایل نشوید. مطمئن شوید که همه افراد احساس شنیده شدن می کنند و اینکه همه اطلاعات قبل از حرکت به سوی راه حل علنی شده اند. + +### مکالمه را بطور متمرکز روی کار عملی حفظ کرده و پیش ببرید + +مباحثه مهم است اما یک تفاوت بین مکالمات سودمند و غیرمفید وجود دارد. + +مباحثات مادامی که فعالانه به سوی راه حل سوق می یابند را تشویق کنید. اگر واضح است که مکالمه بی فروغ شده یا به خارج از موضوع هدایت شده، گفتگوها دارد شخصی می شود یا افراد وارد بحثهای جزئی و حاشیه ای می شوند، زمان آن فرا رسیده که به مباحثات خاتمه دهید. + +اجازه دادن به این مکالمات که همچنان ادامه یابد نه تنها برای موضوع تحت بررسی بد است بلکه برای سلامت انجمن تان نیز بد است. این کار پیامی می فرستد مبنی بر اینکه این نوع مکالمات مجاز هستند یا حتی انجام آنها مورد تشویق قرار می گیرد و در نتیجه می تواند روحیه افراد را از مطرح کردن و حل کردن موضوعات آتی تضعیف کند. + +با ذکر هر نکته توسط دیگران یا خودتان، از خود بپرسید که _«چطور این نکته ما را به راه حل نزدیکتر می کند؟»_ + +اگر مکالمه به سوی حل شدن سوق یافته است از گروه بپرسید که در مرحله بعد باید _چه گامهایی را انتخاب کنید؟_ تا دوباره روی مکالمه متمرکز شوید. + +اگر یک مکالمه بطور واضح هیچ روزنه ای به سوی راه حل نیافته یا هیچ اقدام واضحی برای عملیاتی شدن وجود ندارد یا اقدام مناسب قبلا اتخاذ شده، موضوع را ببندید و توضیح دهید چرا شما آن را بسته اید. + + + +### نبردهایتان را عاقلانه سازید + +متن مهم است، در نظر بگیرید چه کسانی در بحث درگیر می شوند و چطور آنها بقیه انجمن را تحت تاثیر قرار می دهند. + +آیا همه افراد در انجمن در این باره ناراحت هستند یا حتی درگیر این موضوع هستند؟ یا آیا یک دردسرساز منحصر به فرد وجود دارد؟ فراموش نکنید که فقط صداهای فعال را در نظر نگیرید و اعضای ساکت جامعه تان را نیز لحاظ کنید. + +اگر موضوع ، نیازهای گسترده تر انجمن تان را متجلی نمی سازد، شما شاید نیاز به تایید نگرانی های افراد کمی از انجمن تان داشته باشید. اگر این یک موضوع تکرار شونده بدون یک راه حل واضح باشد، آنها را به مباحثات قبلی درباره این موضوع ارجاع دهید و موضوع را ببندید. + +### راهگشای انجمن تان را شناسایی کنید + +با یک نگرش خوب و ارتباطات واضح، اکثر شرایط دشوار قابل حل هستند. البته حتی در مکالمه سودمند، می تواند یک تفاوت در عقیده درباره چگونگی پیشرفت رویه ها وجود داشته باشد. در این موارد، یک فرد یا گروه از افرادی را شناسایی کنید که می توانند به عنوان رهگشا عمل کنند. + +یک رهگشا می تواند نگه دارنده اولیه پروژه باشد یا می تواند یک گروه کوچک از کسانی باشند که مبتنی بر رای گیری تصمیم می گیرند. بطور ایده آل شما یک رهگشا و یک فرایند مرتبط در یک فایل GOVERNANCE را شناسایی کرده اید قبل از اینکه ملزم باشید که از آن استفاده کنید. + +رهگشایتان، باید یک تصمیم گیرنده نهایی باشد. موضوعات نفاق انگیز فرصتی برای انجمن تان است تا درس بگیرد و تکامل یابد. در آغوش کشیدن این فرصتها و استفاده از یک فرایند همکارانه برای حرکت به سوی یک راه حل هرجایی شدنی است. + +## اجتماع ها و انجمن ها ❤️ متن باز هستند + +انجمنهای سالم اما کوشا هزاران ساعت را برای منبع باز در هر هفته اختصاص می دهند. خیلی از مشارکت کنندگان به افراد دیگر به عنوان دلیلی برای کار کردن یا نکردن روی منبع باز اشاره می کنند. با یادگیری اینکه چطور از قدرت بطور سازنده بهره برداری کنید شما باید به افراد خارج از آنجا کمک کنید تا از یک تجربه منبع باز فراموش نشدنی برخوردار شوند. diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md new file mode 100644 index 00000000000..219a6e62d23 --- /dev/null +++ b/_articles/fa/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: fa +title: منشور اخلاقی +description: با تصویب و اجرای منشور اخلاقی، رفتار سالم و سازنده را در انجمن (community) خود تسهیل کنید. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## چرا به منشور اخلاقی نیاز داریم؟ + +منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین میکند. تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند. + +منشور اخلاقی نه تنها از شرکت‌کنندگان پروژه بلکه از شما هم محافظت می‌کند. اگر شما از پروژه‌ای نگهداری می‌کنید، ممکن است متوجه شده باشید که نگرش‌های مخرب از طرف دیگر شرکت‌کنندگان باعث می‌شود در طول کار از کار خود خسته یا ناراضی شوید. + +منشور اخلاقی این امکان را به شما می‌دهد تا رفتاری سالم و سازنده را در جامعه تسهیل کنید. داشتن نگرشی پیشگیرانه، احتمال اینکه شما یا دیگران از پروژه خسته شوید را کاهش می‌دهد و این امکان را برای شما فراهم می‌سازد تا وقتی کسی کاری را اشتباه انجام داد بتوانید با آن مقابله و جلوی آن را بگیرید. + +## ایجاد منشور اخلاقی + +سعی کنید هر چه زودتر منشور اخلاق را ایجاد کنید: در حالت ایده‌آل، هنگامی که پروژۀ خود را شروع می‌کنید. + +علاوه بر ابلاغ انتظاراتی که دارید، منشور اخلاقی موارد زیر را شرح می‌دهد: + +* منشور اخلاقی در چه جاهایی اعمال می‌شود _(فقط در مورد مشکلات و درخواست‌های pull، یا دیگر فعالیت‌های انجمن مانند رویدادها؟)_ +* منشور اخلاقی برای چه کسانی اعمال می‌شود _(اعضای انجمن و نگه‌دارندگان، در مورد حامیان مالی چطور؟)_ +* اگر کسی منشور اخلاقی را نقض کند چه اتفاقی می‌افتد؟ +* چگونه می‌توان تخلفها را گزارش داد؟ + +در هر جا که می‌توانید، از دانش پیشین خود استفاده کنید. [عهدنامۀ مشارکت‌کنندگان](https://contributor-covenant.org/) نوعی منشور اخلاقی جا افتاده و مقبول است که بیش از 40،000 پروژۀ متن باز از جمله «Kubernetes»، « «Rails و «Swift» از آن استفاده می‌کنند. + +[منشور اخلاقی Django](https://www.djangoproject.com/conduct/) و [منشور اخلاقی Citizen](http://citizencodeofconduct.org/) نیز دو نمونۀ خوب دیگر هستند. + +فایل «منشور اخلاقی» را در فهرست اصلی پروژه قرار دهید و با لینک کردن آن با فایل‌های CONTRIBUTING یا README، آن را در دیدگاه انجمن خود قرار دهید. + +## تصمیم‌گیری در مورد نحوۀ پیش بردن منشور اخلاقی + + + +شما باید **قبل از وقوع** هر گونه تخلفی ابتدا توضیح دهید که منشور اخلاقی شما چگونه عملیاتی می‌شود. چندین دلیل برای اینکار وجود دارد: + +* نشان می‌دهد که شما جدی هستید و در صورت لزوم اقدام می‌کنید. + +* انجمن‌تان نسبت به بررسی شدن شکایات، اطمینان بیشتری پیدا می‌کند. + +* به انجمن خود در صورت مرتکب شدن به تخلفی اطمینان خواهید داد که روند بازبینی منصفانه و شفاف خواهد بود. + +شما باید روشی ویژه‌ای (مانند آدرس ایمیل) برای مردم فراهم آورید تا بتوانند تخلفات ناشی از منشور اخلاقی را گزارش دهند و توضیح دهند که چه کسی مرتکب تخلفات شده است. می‌تواند یک نگهدارنده، گروهی از نگهدارنده‌ها یا یک کارگروه ویژۀ منشور اخلاقی باشد. + +فراموش نکنید که ممکن است کسی بخواهد در مورد شخصی که این گزارشات را دریافت می‌کند تخلفی را گزارش دهد. در این صورت، برای آن‌ها گزینه‌ای تعبیه کنید تا بتوانند تخلفات را به شخص دیگری گزارش دهند. به عنوان مثال، @ctb و @mr-c در مورد [پروژۀ خود «khmer»](https://github.com/dib-lab/khmer) می‌گویند: + +> مواردی از سوءرفتار، آزار و اذیت و رفتارهای غیر‌قابل‌قبول را می توان با ایمیل زدن به **khmer project@idyll.org** گزارش داد که فقط «C. Titus Brown» و Michael R. Crusoe» به آن دسترسی دارند. برای گزارش مسئله‌ای در رابطه با هر کدام از آن‌ها، لطفاً به **Judi Brown Clarke** دکترای مدیریت در مرکز «BEACON» برای مطالعۀ تکامل در عمل، مرکز علوم و فناوری «NSF» ایمیل بزنید. + +برای ایده گرفتن، به [کتابچۀ راهنمای اجرای](https://www.djangoproject.com/conduct/enforcement-manual/) «Django» مراجعه کنید (اگرچه ممکن است بنا به اندازه پروژۀ خود، نیازی به چنین کتابچۀ جامعی نداشته باشید). + +## عملیاتی کردن منشور اخلاقی + +گاهی اوقات علی‌رغم تلاشی که می‌کنید، شخصی کاری خلاف منشور اخلاقی انجام می‌دهد. روش‌های مختلفی برای پرداختن و عکس‌العمل نشان دادن به رفتار منفی و مضر در هنگام بروز آن وجود دارد. + +### جمع‌آوری اطلاعات در مورد وضعیت + +با هر یک از اعضای انجمن خود، رفتاری یکسان داشته باشید. اگر گزارشی منوط بر نقص منشور اخلاقی دریافت کردید، آن را جدی بگیرید و موضوع را بررسی کنید، حتی اگر با آن شخص رابطه‌ای نزدیک دارید. با این کار به انجمن خود نشان می‌دهید که برای دیدگاه آن‌ها ارزش قائل هستید و به قضاوت آن‌ها اعتماد دارید. + +آن عضو خطاکار انجمن ممکن است اولین بار نباشد که مرتکب به خطایی شده و به طور مداوم دیگران را ناراحت می‌کند، یا ممکن است اولین بار آن‌ها باشد. بسته به خطایی که مرتکب می‌شوند، اقدامات لازمی باید اجرا شود. + +قبل از عکس‌العمل نشان دادن، زمان کافی را برای فهمیدن کامل ماجرا صرف کنید. نظرات و گفتگوهای مربوط به گذشتۀ شخص را بررسی کنید تا آن‌ها را بهتر بشناسید و متوجه شوید چرا ممکن است چنین رفتاری از آن‌ها سر بزند. سعی کنید دیدگاه‌های دیگری را غیر از دیدگاه‌های خودتان دربارۀ این فرد و رفتار او جمع‌آوری کنید. + + + +### اقداماتی مناسب به کار ببرید + +پس از جمع آوری و بررسی اطلاعات کافی، باید تصمیم بگیرید که چه کاری انجام دهید. همانطور که به قدم بعدی می‌اندیشید، به یاد داشته باشید که هدف شما به عنوان ناظر، ایجاد محیطی امن، محترم و فضایی مشارکتی است. در نظر داشته باشید که تنها مسئلۀ چگونگی برخورد در آن موقعیت مهم نیست، بلکه چگونگی پاسخ و عکس‌العمل شما در آینده‌ی رفتار و انتظارات افراد حاضر در انجمن شما تأثیر می‌گذارد. + +وقتی کسی گزارشی منوط بر تخلف در منشور اخلاقی می‌دهد، رسیدگی به آن وظیفۀ شماست و نه خود او. گاهی اوقات، فرد گزارش‌دهنده با افشای این اطلاعات، آیندۀ شغلی، اعتبار یا ایمنی خود را ممکن است در معرض خطر بزرگی قرار دهد. وادار کردن آن‌ها به مقابله کردن با فرد مزاحم و خاطی می‌تواند فرد گزارش‌دهنده را در موقعیتی مخاطره‌آمیز قرار دهد. شما باید شخصا ارتباط مستقیم با فرد خاطی مورد نظر را مدیریت کنید، مگر اینکه فرد گزارش‌دهنده صریحاً خلاف آن را درخواست کند. + +چند روش وجود دارد که شما می‌توانید با استفاده از آن‌ها با موارد نقض منشور اخلاقی برخورد کنید: + +* **به شخص مورد نظر ترجیحاً به طور مشخص‌ و واضح اخطار عمومی دهید** و توضیح دهید که چگونه رفتار او بر دیگران تأثیر منفی می‌گذارد. اخطار به صورت عمومی به بقیۀ افراد انجمن این پیام را می‌رساند که منشور اخلاقی را جدی می‌گیرید. در مکالمه‌های خود خوش‌برخود باشید ولی جدی بمانید. + +* **به طور خصوصی با شخص مورد نظر صحبت بکنید** تا توضیح دهید که چگونه رفتار او بر دیگران تأثیر منفی می‌گذارد. اگر موقعیت طوری باشد که اطلاعات حساس شخصی فرد در میان باشد، بهتر است از کانال‌های ارتباطی خصوصی استفاده کنید. اگر با شخص به طور خصوصی صحبت می‌کنید، بهتر است کسانی را که برای اولین بار وضعیت را گزارش کرده‌اند مطلع کنید تا بدانند که اقدام کرده‌اید. قبل از پیگیری کردن گزارش مربوطه، از شخص گزارش‌دهنده رضایت بگیرید. + +گاهی اوقات، نمی‌توان به نتیجه‌ای قطعی رسید. فرد مورد نظر ممکن است در مواجهه با او پرخاشگر یا خصمانه برخورد کند یا تغییری در رفتار خود ایجاد نکند. در این شرایط، ممکن است بخواهید اقدامات جدی‌تری را در نظر بگیرید. مثلا: + +* **فرد مورد نظر را از ادامۀ همکاری در پروژه تعلیق کنید**، که از طریق منع موقت یا شرکت در هر جنبه‌ای از پروژه اعمال می‌شود + +* **فرد مورد نظر را به طور دائمی** از ادامۀ همکاری در پروژه تعلیق کنید + +منع کردن اعضا نباید امری ساده تلقی شود و باید نشان‌دهندۀ اختلاف دائمی در دیدگاه و آشتی‌ناپذیری تلقی شود. این اقدامات را فقط باید در مواقعی پیش بگیرید که مشخص باشد امکان دستیابی به نتیجه‌ای قطعی وجود ندارد. + +## وظایف شما به عنوان یک نگهدارنده + +منشور اخلاقی آیین‌نامه‌ای نیست که به صورت خودسرانه اجرا شود. شما مجری منشور اخلاقی هستید و مسئولیت پیروی از قوانین تعیین شده به وسیله‌ی منشور اخلاقی از وظایف شماست. + +شما به عنوان نگهدارنده، دستورالعمل‌هایی را برای انجمن خود تعیین می‌کنید و آن دستورالعمل‌ها را مطابق با قوانین مندرج در منشور اخلاقی اجرا می‌کنید. این به معنای جدی گرفتن هر گونه گزارش مربوطی به نقض منشور اخلاقی است. گزارش فرد گزارش‌دهنده باید کاملا جامع و منصفانه بررسی شود. اگر تشخیص دادید رفتاری که آن‌ها گزارش داده‌اند، نقض منشور اخلاقی نیست، این مسئله را به وضوح با آن‌ها در میان بگذارید و توضیح دهید که چرا در این زمینه اقدامی نمی‌کنید. عکس‌العملی که نشان می‌دهند به خودشان مربوط است: باید رفتاری که آن‌ها با آن روبرو بوده‌اند را تحمل کنند یا مشارکت‌شان در انجمن را متوقف سازند. + +گزارش رفتاری که در واقع منشور اخلاقی شما را نقض نمی‌کند، همچنان نشان‌دهندۀ مشکلی در انجمن شما است و شما باید این مشکل بالقوه را بررسی کرده و چاره‌ای برای آن پیدا کنید. که این ممکن است شامل بازنگری در منشور اخلاقی برای روشن ساختن رفتار قابل‌قبول یا صحبت با شخصی باشد که رفتار وی گزارش شده است و شما باید به فرد بگویید که اگرچه منشور اخلاقی را نقض نکرده‌اند، اما دارند در لبۀ آنچه که از آن‌ها انتظار می‌رود راه می‌روند و موجب ناراحتی در برخی از شرکت‌کنندگان شده‌اند. + +موضوع مهم این است که شما به عنوان یک نگهدارنده، باید استانداردهای رفتار قابل‌قبول را تعیین و عملیاتی کنید. شما توانایی شکل دادن به ارزش‌های اجتماعی پروژه را دارید و شرکت‌کنندگان انتظار دارند که شما این ارزش‌ها را به صورت منصفانه و یکسان اجرا کنید. + +## ترغیب‌کنندۀ رفتاری باشید که می‌خواهید در دنیا آن را مشاهده کنید 🌎 + +هنگامی که یک پروژه خصمانه یا ناخوشایند به نظر می‌رسد، حتی اگر فقط یک نفر باشد که رفتار او غیرقابل‌تحمل باشد، ممکن است مشارکت‌کنندگان بیشتری را از دست بدهید که حتی ممکن است بعضی از آن‌ها را هرگز ملاقات نکرده باشید. اتخاذ یا اجرای منشور اخلاقی همیشه ساده نیست، اما ایجاد فضایی دوستانه به رشد انجمن شما کمک می کند. diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md new file mode 100644 index 00000000000..065db4d0644 --- /dev/null +++ b/_articles/fa/finding-users.md @@ -0,0 +1,145 @@ +--- +lang: fa +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) + +برای درک بهتر مفهوم، مورد [Personas and Pathways](https://mozillascience.github.io/working-open-workshop/personas_pathways/) موزیلا (Mozilla) را برای توسعه‌ی پرسونای کاربران بررسی کنید + +## مردم را در پیدا کردن و دنبال کردن پروژه‌ی خودتان یاری کنید + + + +طوری باشد که با اشاره‌ای کوچک، مردم پروژه‌ی شما را به یاد بیاورند. + +**برای توسعه‌ی پروژه‌ی خود، کاملا بر کار خویش آگاه و از آن اطمینان داشته باشید.** یک آدرس توییتری، آدرس 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/) چند نمونه از وب‌سایت‌های عالی و جامع هستند. + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +اکنون که برای پروژه‌ی خود رسالت و راهی آسان برای یافتن پروژه‌تان توسط مردم دارید، وقت آن است که بیرون بزنیم و با مخاطبان ارتباط برقرار کنیم و با آن‌ها صحبت کنیم! + +## هر جا که مخاطبان شما بودند، شما هم به آنجا بروید (آنلاین) + +اطلاع‌رسانی آنلاین، روشی عالی برای به اشتراک گذاشتن و انتقال سریع اخبار و اطلاعات است. با استفاده از مجرا‌های آنلاین، این امکان را خواهید داشت که به مخاطبان بسیار گسترده‌ای دسترسی پیدا کنید. + +برای دسترسی به مخاطبان خود از ارتباطات‌ و بسترهای آنلاین موجود استفاده کنید. اگر پروژه‌ی اوپن سورس شما پروژه‌ای نرم‌افزاری است، احتمالاً بتوانید مخاطبان خود را در [Stack Overflow](https://stackoverflow.com/) ،[Hacker News](https://news.ycombinator.com/) یا [Quora](https://www.quora.com/) پیدا کنید. کانال‌هایی را پیدا کنید که فکر می‌کنید مردم در آن از کار شما بیشترین استفاده را می‌برند یا مشتاق آن هستند. + + + +ببینید آیا می‌توانید روش‌هایی برای به اشتراک گذاشتن پروژه خود به صورت متناسبی پیدا کنید: + +* **با پروژه‌ها و انجمن‌های اوپن سورس مرتبط و مدنظرتان آشنا شوید.** گاهی اوقات، لازم نیست که مستقیماً پروژه‌ی خود را تبلیغ کنید. اگر پروژه‌ی شما برای متخصصین علم داده که از پایتون استفاده می‌کنند عالی است، با انجمن علوم داده‌ی پایتون ملاقات کنید و آشنا شوید. هنگامی که مردم با شما آشنا شوند، فرصت‌ها به صورت خودکار و طبیعی برای بحث و گفت و گو و به اشتراک گذاشتن کارهای شما بوجود می‌آید. +* **افرادی که مشکلاتی دارند و پروژه‌ی شما، آن مشکلات را حل و فصل می‌کند را پیدا کنید.**از طریق تالارهای گفتگوی (فروم‌ها) مرتبط، به جستجوی افرادی که می‌توانندمخاطبانِ هدفِ پروژه‌ی شما باشند، بپردازید. به سوالات آن‌ها پاسخ دهید و در زمانی مناسب، روشی مدبرانه تعبیه کنید تا پروژه‌ی خود را به عنوان یک راه‌حل پیشنهاد دهید. +* **از انتقادات و پیشنهادات روی‌گردان نباشید.** خود و کارهایتان را به مخاطب‌هایی مرتبط و متناسب که به کار شما علاقه دارند، معرفی کنید. مخاطبان خود را بشناسید و کسانی که از پروژه‌ی شما سود و منفعت حاصل می‌کنند را مشخص کنید. سعی کنید این جمله را کامل کنید: «من فکر می‌کنم پروژه‌ی من واقعاً به X، که در تلاش برای انجام کار Y است، کمک خواهد کرد». به جای اینکه صرفاً فقط کار خود را تبلیغ کنید، به بازخورد دیگران گوش دهید و پاسخگو باشید. + +به طور کلی، به کمک کردن به دیگران تمرکز کنید قبل از اینکه چیزهایی را در عوض درخواست کنید؛ چون که اگر هر کسی بخواهد پروژه‌های خودش را به صورت آنلاین تبلیغ کند، همهمه و شلوغی زیادی بر پا خواهد شد. برای اینکه در جمعی شناخته شوید، سعی کنید خود را به دیگران معرفی کنید و نه اینکه فقط آنچه که می‌خواهید را بازگو کنید. + +اگر کسی به فعالیت‌های اولیه‌ی شما پاسخی نداد و یا توجه نکرد، ناامید نشوید! اکثر راه‌اندازی‌های پروژه‌ها، فرآیندهایی هستند که باید چندین و چند بار تکرار شوند که ممکن است ماه‌ها یا سال‌ها به طول انجامد. اگر بار اول پاسخی دریافت نکردید، تاکتیک دیگری را امتحان کنید یا ابتدا به دنبال روش‌هایی برای افزودن ارزش به کار دیگران باشید. راه‌اندازی و توسعه‌ی پروژه، به وقت و تعهد نیاز دارد. + +## هر جا که مخاطبان شما بودند، شما هم به آنجا بروید (آفلاین) + +![Public speaking](/assets/images/finding-users/public_speaking.jpg) + +رویدادهای آفلاین، روشی متداول برای تبلیغ پروژه‌های جدید برای مخاطبان است. این رویدادها راهی عالی برای دستیابی به مخاطبان مشتاق و ایجاد ارتباطات انسانی عمیق‌تر هستند؛ به خصوص که اگر شما می‌خواهید با توسعه‌دهندگان ارتباط برقرار کنید. + +اگر [تجربه‌ی چندانی در حوزه‌ی سخنرانی در عموم](https://speaking.io/), ندارید و تازه‌کار هستید، با پیدا کردن یک جلسه‌ی محلی که مرتبط با محتوا یا اکوسیستم پروژه‌ی خودتان است شروع کنید. + + + +اگر قبلاً هرگز در رویدادی صحبت نکرده‌اید، اینکه استرس داشته باشید، کاملاً طبیعی است! به یاد داشته باشید که مخاطبان شما آنجا هستند زیرا واقعاً می‌خواهند در مورد کارهای شما بشنوند. +هنگام نوشتن سخنرانی خود، بر آنچه که مخاطبان جالب می‌پندارند و از آن ارزش و درسی می‌گیرند، تمرکز کنید. دوستانه و صمیمانه سخن بگویید. لبخند به لب داشته باشید، تنفس کنید و لذت ببرید. + +هنگامی که کار را بر روی متن سخنرانی خود آغاز می‌کنید، خواه هر چه موضوع سخنرانی شما باشد، اگر سخنرانی خود را همانند داستانی که برای مردم تعریف می‌کنید تصور کنید، می‌تواند به شما کمک بسزایی بکند. + + + +به دنبال کنفرانس‌هایی باشید که مرتبط با محتوا یا اکوسیستم مورد نظر شما باشد. قبل از ارسال سخنرانی خود، در مورد کنفرانس تحقیق کنید تا سخنرانی خود را برای حاضران تنظیم و اصلاح کرده و در نتیجه شانس پذیرفته شدن برای سخنرانی در کنفرانس را افزایش دهید. شما همچنین می‌توانید با مراجعه به لیست سخنرانان کنفرانس، از نوع و کیفیت مخاطبان خود آگاه شوید. + + + +## برای خود اعتبار و شهرت دست و پا کنید + +علاوه بر استراتژی‌های ذکر شده در بالا، بهترین راه برای دعوت مردم برای به اشتراک‌‌گذاری و مشارکت در پروژه‌ی شما، اشتراک و مشارکت در پروژه‌های آن‌ها است. + +کمک به تازه‌واردان، به اشتراک گذاشتن منابع و مشارکت مدبرانه در پروژه‌های دیگران به شما کمک می‌کند تا اعتبار خوبی برای خود بسازید. اگر عضوی فعال در اجتماع (انجمن) اوپن سورس باشید به شما کمک می‌کند تا مردم کار و محتوای شما را بشناسند و احتمال اینکه به پروژه شما توجه کنند و آن را به اشتراک بگذارند، بیشتر می‌شود. توسعه‌ی روابط با سایر پروژه‌های اوپن سورس، می‌تواند منجر به مشارکت و همکاری رسمی شود. + + + +برای ایجاد و کسب اعتبار، هیچوقت خیلی زود و یا خیلی دیر نیست. حتی اگر پروژه‌ی خود را از قبل راه‌اندازی کرده‌اید، به جستجوی راه‌هایی برای کمک به دیگران ادامه دهید. برای ایجاد و جذب مخاطب، هیچ راه‌حل یک شبه‌ای وجود ندارد. + +جلب اعتماد و احترامِ دیگران نیازمند زمان است و هیچ پایانی برای ایجاد و کسب اعتبار وجود ندارد + +## تسلیم نشوید! + +ممکن است مدت‌ها طول بکشد تا اینکه مردم متوجه پروژه‌ی اوپن سورس شما شوند. هیچ اشکالی نداره! برخی از محبوب‌ترین پروژه‌های امروزی، برای رسیدن به سطح بالایی از فعالیت، سال‌ها به طول انجامید. به جای اینکه امیدوار باشید پروژه‌ی شما به طور خود به خود محبوبیت پیدا کند، بر ایجاد روابط متمرکز شوید. صبور باشید و مدام کار خود را با کسانی که قدر آن را می‌دانند به اشتراک بگذارید. diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md new file mode 100644 index 00000000000..e3a07503504 --- /dev/null +++ b/_articles/fa/getting-paid.md @@ -0,0 +1,176 @@ +--- +lang: fa +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)، پیامدهایی اخلاقی در این میان وجود دارد، زیرا کسانی که از قبل در زندگی دارای مزایایی هستند، شانس بیشتری در کارهایی که انجام می‌شود دارند، درنتیجه بر اساس مشارکت‌های داوطلبانه‌ی خود مزایای بیشتری کسب می‌کنند، در حالی که سایر افرادی که قادر به داوطلب شدن نیستند، فرصت‌های آتی را از دست می‌دهند، که این عدم تنوع را در اجتماع کنونی (community) متن باز گسترش می‌دهد. + + + +اگر به دنبال حمایت‌های مالی هستید، دو راه وجود دارد. می‌توانید زمان مناسب را برای مشارکت پیدا کنید، یا می‌توانید بودجه‌ای برای پروژه‌ی خودتان پیدا کنید. + +## وقت خود را سرمایه‌گذاری کنید + +امروزه بسیاری از افراد برای کار به صورت پاره وقت یا تمام وقت در پروژه‌های متن باز دستمزد دریافت می‌کنند. متداول‌ترین راه برای دریافت دستمزد برای وقتی که صرف می‌کنید، صحبت کردن با کارفرمای خودتان است. + +متقاعد کردن کارفرما در پروژه‌ای که واقعا از آن استفاده ‌می‌کند آسان‌تر است، اما در مورد صحبتی که با او خواهید کرد، رویه‌ای خلاقانه در نظر بگیرید. شاید کارفرمای شما از این پروژه استفاده نکند، اما آن‌ها از پایتون استفاده می‌کنند و نگهداری از پروژه‌ی پایتون محبوب به جذب توسعه‌دهندگان جدید پایتون کمک می‌کند. شاید این امر باعث شود که کارفرمای شما به طور کلی در در ارتباط با توسعه‌دهندگان سازنده‌تر و دوستانه‌تر به نظر برسد. + +اگر در حال حاضر پروژه‌ای متن باز ندارید که بخواهید روی آن کار کنید، اما ترجیح می‌دهید که خروجی کار فعلی شما متن باز باشد، از کارفرمای خود درخواست کنید که برخی از نرم‌افزارهای داخلی خود را متن باز کند. + +بسیاری از شرکت‌ها برنامه‌هایی متن باز توسعه می‌دهند تا اعتباری برای نام برند خود ایجاد کنند و افرادی با استعداد استخدام کنند. + +به عنوان مثال، @hueniverse دریافت که دلایلی تجاری برای توجیه [سرمایه‌گذاری والمارت (Walmart)] (https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html)در متن باز وجود دارد. و jamesgpearce@، دریافت که برنامه‌ی متن باز فیس‌بوک، [تفاوت‌هایی را در استخدام ایجاد کرده است](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) + +> کاملا با فرهنگ خلاقیت‌جویانه‌ی ما و آنچه که سازمان ما با آن شناخته می‌شود، سازگار و همسو است. ما از کارمندان خود پرسیدیم، «آیا از برنامه‌ی نرم‌افزاری متن باز فیس‌بوک آگاهی داشتید؟» دو سوم آن‌ها گفتند «بله» یک دوم آن‌ها گفتند که این برنامه به تصمیم‌شان برای کار کردن در فیس‌بوک تاثیر داشت. اینها اعداد کمی نیستند و امیدواریم که این روند ادامه داشته باشد. + +اگر شرکت شما این مسیر را طی می‌کند، مهم است که مرزهای بین اجتماع و فعالیت‌های شرکتی را روشن کنید. در آخر، پروژه‌های متن باز از طریق مشارکت‌های مردم در سرتاسر جهان از خود نگهداری می‌کند؛ این پروژه‌ها بزرگ‌تر از هر شرکت یا فضایی هستند. + + + +اگر نمی‌توانید کارفرمای کنونی خودتان را متقاعد به اولویت‌بندی کارهای متن باز بکنید، سعی کنید کارفرماهای جدیدی پیدا کنید که کارمندان را تشویق به مشارکت در متن باز می‌کنند. به دنبال شرکت‌هایی بگردید که تعهد صریحی برای کار با پروژه‌های متن باز داشته باشند. به عنوان مثال: + +* برخی شرکت‌ها مانند [Netflix](https://netflix.github.io/)، وب‌سایت‌هایی دارند که مشارکت آن‌ها در متن باز را برجسته و نمایان می‌کند + +پروژه‌هایی که از شرکت‌های بزرگی مانند [Go](https://github.com/golang) یا [React](https://github.com/facebook/react) سرچشمه گرفته‌اند و به آن وصل‌اند نیز احتمالاً افرادی را برای کار با متن باز استخدام خواهند کرد + +بسته به شرایط شخصی خودتان، می‌توانید به طور مستقل برای تأمین هزینه‌های کار متن باز خود، پول جمع کنید. به عنوان مثال: + +* نرم‌افزار متن باز @Homebrew ([و بسیاری از نگهدارندگان و سازمان‌ها](https://github.com/sponsors/community))، کار خودشان را از طریق حامیان مالی [GitHub](https://github.com/sponsors) تأمین می‌کنند +* @gaearon کار خود در [Redux](https://github.com/reactjs/redux) را از طریق کمپین سرمایه‌گذاری جمعی «Patreon» تأمین مالی کرد +* @andrewgodwin از [طریق کمپین Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) کارش در مورد مایگریشن‌های دیتابیس «Django» را تأمین مالی کرد. (Schema Migration) + +در آخر اینکه گاهی اوقات پروژه‌های متن باز درمورد موضوعاتی که ممکن است در آن بخواهید کمک کنید پاداش‌هایی قرار می‌دهند. + +* @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 library» (کتابخانه‌ی جاوا اسکریپت) از طریق پاداشی‌ تعیین شده در [gitcoin](https://gitcoin.co/)، دستمزد بگیرد +* @mamiM پس از تأمین اعتبار مربوط به مشکلِ شبکه‌ی Bounties، ترجمه‌ی ژاپنی برای @MetaMask انجام داد. + +## یافتن بودجه برای پروژه‌ + +علاوه‌ بر توافق‌های اولیه با مشارکت‌کنندگان، گاهی اوقات پروژه‌ها از شرکت‌ها، افراد حقیقی یا دیگران برای تأمین بودجه‌ی کارهای جاری پول جمع‌آوری می‌کنند. + +بودجه‌های سازمانی ممکن است به پرداخت دستمزد مشارکت‌کنندگان، تأمین هزینه‌های اجرای پروژه (مانند هزینه‌های میزبانی) یا سرمایه‌گذاری بر روی ویژگی‌ها یا ایده‌های جدید اختصاص یابد. + +با افزایش محبوبیت ‌متن باز، هنوز هم یافتن بودجه برای پروژه‌ها به صورت تجربی و آزمایشی است، اما چندین گزینه‌ی متداول در دسترس است. + +### جمع‌آوری سرمایه از طریق کمپین‌های سرمایه‌گذاری جمعی یا حمایت‌های مالی + +اگر از قبل مخاطب یا اعتبار بالایی داشته باشید یا پروژه‌ی شما از محبوبیت بالایی برخوردار باشد، یافتن حمایت‌های مالی امکان‌پذیر است. چند نمونه از پروژه‌های حمایت شده: + +* پروژه‌ی **[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/npm) و [Docker](https://github.com/docker/docker)، برای حمایت از رشد کسب و کار خود، حتی سرمایه‌های مخاطره‌آمیزی را جمع‌آوری می‌کنند + +### برای بودجه، درخواست کمک هزینه (بورسیه) دهید + +برخی از موسسات و شرکت‌های نرم‌افزاری، کمک‌هزینه‌های مالی برای کارهای متن باز ارائه می‌دهند. گاهی اوقات، بدون ایجاد نهاد قانونی‌ای برای پروژه، کمک‌هزینه‌های مالی به افراد حقیقی پرداخت می‌شود. + +* **نرم‌افزار [Read the Docs](https://github.com/rtfd/readthedocs.org)**، از پشتیبانی بخش متن باز [Mozilla](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 Software Foundation)**، کمک‌های مالی برای کارهای مرتبط با پایتون ارائه می‌دهد + +برای جزئیات دقیق‌تر و مطالعات موردی، @nayafia راهنمای دریافت دستمزد برای کارهای متن باز را [نوشت](https://github.com/nayafia/lemonade-stand). انواع بودجه‌ها به مهارت‌های مختلفی نیاز دارد، بنابراین نقاط قوت خود را در نظر بگیرید تا گزینه‌ی مناسب برای کار خودتان را دریابید. + +## ایجاد پرونده‌ی موردی (فایل) به منظور دریافت حمایت مالی + +این که آیا پروژه‌ی شما ایده‌ی جدیدی است یا سال‌هاست که وجود دارد؛ باید برای شناسایی و مشخص کردن سرمایه‌گذار هدف و ایجاد یک پرونده‌‌ی اغواکننده، باید به خوبی راجع به آن فکر کنید. + +چه بخواهید هزینه‌ی زمانی که صرف می‌کنید را خودتان پرداخت کنید و یا موسسه‌ای هزینه‌ی پروژه‌ی شما را پرداخت کند، باید بتوانید به سوالات زیر پاسخ دهید. + +### تاثیرگذاری + +این پروژه به چه دردی می‌خورد؟ برای چه کاربران شما، یا کاربران بالقوه‌ی شما، پروژه‌ را دوست داشته باشند؟ پروژه‌ی خود را در پنج سال آینده چطور می‌بینید؟ + +### مقبولیت + +سعی کنید شواهدی را در مورد اهمیت پروژه‌ی خود جمع‌آوری کنید؛ چه بخواهد معیارهای سنجش، تجربه‌های گذشته، یا اظهارنظرهای مثبتی باشد. آیا شرکت‌ها یا افراد قابل ذکری وجود دارند که از پروژه‌ی شما استفاده بکنند؟ اگر نه، آیا شخص برجسته‌ای پروژه‌ی شما را تأیید کرده است؟ + +### ارزش آن برای سرمایه‌گذار + +سرمایه‌گذاران، چه کارفرمای شما باشد و یا چه یک موسسه‌ی اعطای کمک‌هزینه، اکثرا جذب فرصت‌ها می‌شوند. چرا آن‌ها باید از پروژه‌ی شما در برابر سایر فرصت‌ها حمایت کنند؟ از پروژه‌ی شما چه منفعت شخصی‌ای می‌برند؟ + +### مصارف بودجه + +با بودجه پیشنهادی، دقیقاً به چه نتیجه‌ای دست خواهید یافت؟ به جای فکر کردن به پرداخت حقوق و دستمزد، روی نقاط عطف یا نتایج پروژه متمرکز شوید. + +### چگونه بودجه را دریافت خواهید کرد + +آیا سرمایه‌گذار، الزاماتی در مورد پرداخت هزینه مدنظر دارد؟ به عنوان مثال، ممکن است لازم باشد شما سازمانی غیرانتفاعی باشید یا یک حامی مالی غیرانتفاعی داشته باشید. یا شاید بودجه باید به جای سازمان به یک پیمانکار حقیقی داده شود. هر شخص سرمایه‌گذاری الزامات متفاوتی دارد، بنابراین حتماً از قبل تحقیقات خود را انجام دهید. + + + +## آزمایش و تجربه کنید و تسلیم نشوید + +جمع‌آوری پول آسان نیست، چه پروژه‌ای متن باز باشید، چه یک سازمان غیرانتفاعی و یا یک استارت‌آپ نرم‌افزاری؛ باید در بیشتر موارد با دیدی خلاقانه به موضوع نگاه کنید. با مشخص کردن اینکه چگونه می‌خواهید دستمزد بگیرید، با تحقیقات خود و قرار دادن خود به جای سرمایه‌گذار، به شما کمک می‌کند تا پرونده‌ای قانع‌کننده برای تأمین بودجه بسازید. diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md new file mode 100644 index 00000000000..1127588f823 --- /dev/null +++ b/_articles/fa/how-to-contribute.md @@ -0,0 +1,523 @@ +--- +lang: fa +title: چگونه در یک پروژه‌ی متن باز مشارکت کنیم +description: می‌خواهید در یک پروژه‌ی متن باز مشارکت کنید؟ در ادامه‌ی مقاله نحوه‌ی مشارکت در یک پروژه‌ی متن باز برای افراد مبتدی و باتجربه شرح داده شده است. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## چرایی مشارکت در یک پروژه‌ی متن باز؟ + + + +زمانی که در پروژه‌های متن باز مشارکت می‌کنید، چیزهای زیادی یاد می‌گیرید یا یاد می‌دهید، حتی می‌توانید در هر مهارتی که تصورش را می‌کنید تجربه کسب کنید. + +چرا افراد در پروژه‌های متن باز مشارکت می‌کنند؟ خب، دلایل زیادی وجود دارد! + +### نرم‌افزاری که به آن متکی هستید را بهبود می‌دهید + +مشارکت‌کننده‌ها مشارکت خود از پروژه‌هایی شروع می‌کنند که کاربر آن می‌شوند. زمانی که در نرم‌افزار یک پروژه‌ی متن باز باگ یا خطایی مشاهده کردید، در صورتی که توانایی برطرف کردن آن را داشته باشید می‌توانید به سورس کد آن نگاهی بیندازید و خودتان اصلاحیه‌ای برایش بنویسید. اگر با چنین موردی روبه‌رو شدید، مشارکت در اصلاح آن باگ بهترین راه برای مطمئن کردن دوستان (و خودتان مخصوصاً زمانی که نسخه‌ی بعدی آن به روز شود) باشد که می‌تواند مزیت‌های داشته باشد. + +### مهارت‌های موجودتان تقویت می‌شود + +اگر به دنبال تمرین کدنویسی، طراحی رابط‌کاربری کاربر، طراحی گرافیک، نویسندگی یا سازماندهی کردن هستید، پروژه‌ی متن باز این تمرین‌ها را در اختیارتان قرار می‌دهد. + +### با افرادی ملاقات می‌کنید که علایق‌شان با شما مشابه است + +پروژه‌های متن باز با انجمن‌های گرم و گیرایش باعث می‌شود افرادی که در آن حضور دارند برای سال‌ها به آن مراجعه کنند. حتی بسیاری هستند که به واسطه‌ی همکاری‌شان در راه‌اندازی کنفرانس‌ها یا چت‌های آنلاین شبانه‌شان درباره‌ی burritos ، روابط دوستانه‌ی طولانی مدتی دارند. + +### استاد پیدا می‌کنید و به دیگران آموزش می‌دهید + +کار کردن با دیگران در پروژه‌های مشترک شما را مجبور می‌کند نحوه‌ی انجام دادن کارها را توضیح دهید و به همان اندازه هم از دیگران کمک بخواهید. هر کسی می‌تواند خود را درگیرِ فعالیت‌های یادگیری و آموزشی کند. + +### محصولی عمومی تولید کنید که به رشد اعتبار و حرفه‌ی کاری‌تان کمک کند + +بر اساس تعریف، تمام پروژه‌های متن باز شما عمومی هستند. به این معنا که نمونه پروژه‌ها را دریافت می‌کنید و می‌توانید آن را همه جا ببرید و نشان دهید که چه کارهایی می‌توانید با آن انجام دهید. + +### مهارت‌های دیگران را یاد می‌گیرید + +پروژه‌های متن باز فرصتی فراهم می‌کنند که به واسطه‌ی آن می‌توانید مهارت‌های مدیریت و رهبری پروژه‌ی خود مانند برطرف کردن تضادها، سازماندهی کردن تیم و اولویت بندی کارها، را تقویت کنید. + +### به شما قدرت اعمال تغییرات هرچند کوچک را می‌دهد + +لازم نیست برای لذت بردن از همکاری در یک پروژه‌ی متن باز، به یک مشارکت‌کننده‌ی درازمدت تبدیل شوید. تا حالا شده در یک وب‌سایت چند غلط‌ املائی ببینید و دوست داشتید یک نفر آن را اصلاح کند؟ خب، اگر چنین حالتی برای پروژه‌تان به وجود بیاید، به راحتی می‌توانید آن را برطرف کنید. پروژه‌ی متن باز می‌تواند به افراد کمک کند تا شرکتی که در آن فعالیت می‌کنند و نحوه‌ی کسب کردن تجربه‌شان را از زندگی خود مهم‌تر بدانند و همین مسئله حس رضایت‌بخشی به آن‌ها می‌دهد. + +## مشارکت به چه معناست؟ + +اگر در مشارکت یک پروژه‌ی متن باز تازه‌وارد هستید، فرآیند آن می‌تواند ترسناک باشد. شما چگونه یک پروژه درست برای مشارکت کردن در آن را انتخاب می‌کنید؟ اگر چیزی از کد نویسی ندانید، چی؟ اگر چیزی درست پیش نرود، چی؟ + +خب، نگران نباشید! راه‌های زیادی برای مشارکت در پروژه‌های متن باز وجود دارد که در ادامه‌ی مقاله مواردی از آن‌ها را می‌آوریم که می‌تواند به بدست آوردن تجربه‌های بیشتر به شما کمک کند. + +### الزماً قرار نیست در فرایند کدنویسی مشارکت کنید + +یک دید غلط و مرسومی که برای مشارکت در پروژه‌های متن باز وجود دارد این است که فکر می‌کنند برای مشارکت در آن باید حتما کدنویسی شود. در حقیقت، [اغلب بخش‌های دیگر پروژه](https://github.com/blog/2195-the-shape-of-open-source) است که از آن غفلت یا بیش از حد به آن توجه می‌شود. شما با برطرف کردن مشکلات و مشارکت در آن بخش‌ها لطف بزرگی به پروژه‌های متن باز می‌کنید. + + + +حتی اگر هم به کدنویسی در پروژه علاقه‌مند باشید، روش‌های دیگر مشارکت بهترین راه‌برای درگیر شدن در یک پروژه و ملاقات با اعضای انجمن‌های دیگر وجود دارد. ساختن این روابط به شما فرصت‌هایی می‌دهد تا در بخش‌های دیگر پروژه مشارکت کنید. + +### آیا به برگزاری رویدادها علاقه‌مند هستید؟ + +* ورکشاپ‌ها (کارگاه‌ها) را سازماندهی یا جلسات پروژه را برگزار کنید، مانند کاری که @fzamperin برای [NodeSchool](https://github.com/nodeschool/organizers/issues/406) انجام داد +* در صورت امکان، برای یک پروژه کنفرانس برگزار کنید +* به اعضای انجمن کمک کنید تا کنفرانس‌های درستی پیدا و برای کنفرانس پرپوزال خود را ارسال کنند. + +### آیا به طراحی علاقه‌مند هستید؟ + +* با هدف افزایش قابلیت استفاده به بهبود ساختار برنامه ها کمک کنید. +* مشابه [دروپال](https://www.drupal.org/community-initiatives/drupal-core/usability) می‌توانید با هدف بهبود رابط کاربری اقدام به کاربرپژوهی و مطالعاتی از این دست کنید. +* با جمع آوری و یک کاسه کردن الگوهای طراحی به کار گرفته شده در پروژه یک شیوه‌نامه (استایل گاید) متمرکز ایجاد کنید. +* اقدام به خلق کارهای هنری مثل طراحی لوگو یا تی شرت مخصوص کنید. مثل کاری که [hapi.js](https://github.com/hapijs/contrib/issues/68) انجام داد. + +### آیا به نویسندگی در پروژه علاقه‌مند هستید؟ + +* اسناد پروژه را بنویسید و اصلاح کنید +* پوشه‌ی نمونه‌ها را تنظیم کنید تا نحوه‌ی استفاده‌ی پروژه را نشان دهد +* برای پروژه یک خبرنامه راه‌اندازی کنید، یا شاخصه‌های آن را نوشته و تنظیم کنید +* برای پروژه، مطالب آموزشی بنویسید، مانند مشارکت‌کننده‌هایی که برای [PyPA](https://packaging.python.org/) مطالب آموزشی نوشتند +* مستندات پروژه را به زبانی دیگر ترجمه کنید + + + +### آیا به سازماندهی پروژه علاقه‌مند هستید؟ + +* برای سازماندهی کردن همه چیز، مشکلات تکراری را لینک کنید و مسائل جدیدی مطرح کنید +* با مسئله‌های (issue) باز رودرو شوید و پیشنهاد دهید مسائل قدیمی حل شوند، مانند کاری که @nzakas برای [ESLin](https://github.com/eslint/eslint/issues/6765) انجام داد +* برای پیشبرد بحث، سوالات شفافی درباره‌ی مسائل باز اخیر بپرسید + +### آیا به کدنویسی علاقه دارید؟ + +* مسائل باز و حل نشده را پیدا و حل کنید، مانند کاری که @dianjin برای [Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) انجام داد +* اگر می‌توانید برای اعمال یک ویژگی جدید به پروژه کمک کنید، درخواست‌تان را مطرح کنید +* نصب پروژه را خودکار کنید +* ابزارهای مرتبط و تسهیل کننده و تست پروژه را تقویت کنید + +### آیا از کمک کردن به مردم لذت می‌برید؟ + +* به سوالاتی که افراد درباره‌ی پروژه در سایت‌هایی مانند Stack، Postgres، یا Reddit می‌پرسند، جواب بدهید +* سوالات افرادی که مسائل حل نشده‌ای دارند را جواب بدهید +* در اداره کانال‌های گفتگو و تالارهای گفتمان مشارکت کنید + +### آیا دوست دارید در کدنویسی به دیگران کمک کنید؟ + +* کدنویسی سایر افراد را بررسی کنید +* برای نحوه‌ی استفاده‌ی یک پروژه‌ی متن باز، مطلب آموزشی بنویسید +* یک مشارکت کننده دیگر که می‌شناسید را پیشنهاد دهید، [مثل کاری که @ereichert در Rust برای @bronzdoc کرد](https://github.com/rust-lang/book/issues/123#issuecomment-238049666). + +### لازم نیست فقط روی پروژه‌های نرم‌افزاری وقت صرف کنید! + +با اینکه بیشتر پروژه‌های متن باز به نرم‌افزارها اطلاق می‌شود، اما می‌توانید هرچیزی از جمله کتاب‌ها، دستورالعمل، لیست چیزهای مختلف و کلاس‌ها را در پروژه‌های متن باز توسعه دهید. + +به عنوان مثال: + +* @sindresorhus [لیست‌هایی موسوم به «awesome»](https://github.com/sindresorhus/awesome) گردآوری و تنظیم می‌کند +* @h5bp [یک لیست حاوی سوالاتی جهت مصاحبه برای توسعه دهندگان فرانت اند](https://github.com/h5bp/Front-end-Developer-Interview-Questions) را نگهداری و مرتب می‌کند +* @stuartivnn و @nicole-a-tesla [مجموعه‌ای از حقایق جالب درباره‌ی طوطی دریایی](https://github.com/stuartlynn/puffin_facts) ایجاد کرده‌اند. + +حتی اگر توسعه‌دهنده‌ی نرم‌افزار هم باشید، کار روی اسناد یک پروژه می‌توانید به شما کمک کند تا پروژه‌ی متن بازتان را شروع کنید. کار روی پروژه‌هایی که کدنویسی کمتری دارد اغلب ترس کمتری دارد و فرآیند همکاری در آن باعث می‌شود اعتمادبه‌نفس و تجربه‌ی شما افزایش پیدا کند. + +## ورود و وفق دادن خودمان به یک پروژه جدید + + + +مشارکت کردن در یک پروژه‌ی متن باز که بیشتر از اصلاح غلط‌هایی املائی است، مانند وارد شدن به پارتی غریبه‌هاست. اگر در این پارتی درباره ماهی قرمز بحث عمیقی شکل گرفته، شما درباره‌ی لاماها صحبت کنید، احتمالاً نگاه عجیبی به شما می‌شود. + +بنابراین، قبل از اینکه کورکورانه با پیشنهادهای‌تان وارد کاری شوید، یاد بگیرید که چگونه در چت روم‌ها گفتگو کنید. این کار شانس شما را برای شنیده شدن و توجه به ایده‌هایتان را بالا می‌برد. + +### آناتومی یک پروژه‌ی متن باز + +جامعه‌ها در پروژه‌های متن باز متفاوت هستند. + +زمانی که سال‌ها روی یک پروژه‌ی متن باز صرف می‌کنید، باید آن پروژه‌ی متن باز را بشناسید. از طرفی، زمانی هم که به پروژه‌ی متفاوتی منتقل می‌شوید، لغات، قوائد و سبک ارتباطاتی آن که ممکن است کاملاً متفاوت باشد را باید پیدا کنید. + +گفته می‌شود بیشتر پروژه‌های متن باز از یک ساختار سازماندهی مشابه پیروی می‌کنند. شناخت و درک نقش‌ها در جوامع مختلف و فرآیند کلی آن به شما کمک می‌کند به سرعت وارد هر پروژه‌ی جدیدی شوید. + +افراد مختلفی در یک پروژه‌ی متن باز معمولی مشارکت می‌کنند: + +* **نویسنده:** شخص یا سازمانی که یک پروژه را خلق می‌کند +* **صاحب مالک:** شخص یا اشخاصی که صاحب اداری آن سازمان یا مخزن هستند (البته صاحب پروژه همیشه با نویسنده‌ی اصلی یکسان نیست) +* **مسئول‌نگهداری پروژه:** مشارکت‌کننده‌هایی که مسئول پیش بردن چشم انداز و مدیریت جنبه‌های سازمانی یک پروژه باشند (این افراد همچنین می‌توانند نویسنده یا صاحب پروژه باشند) +* **مشارکت‌کننده:** هر کسی که در پروژه مشارکت داشته باشد +* **اعضای انجمن:** افرادی که از پروژه استفاده می‌کنند، می‌توانند مکالمات فعالانه‌ای داشته باشند یا نظرات‌شان را برای مسیر دادن به پروژه ابراز کنند + +پروژه‌های بزرگ‌تر همچنین ممکن است زیرکمیته‌ها یا گروه‌های کاری داشته باشند که روی وظایف متفاوتی مانند مجهز کردن، triage (تریاژ)، معتدل کردن انجمن و سازماندهی رویداد متمرکز می‌شوند. زمانی که به صفحه‌ی «تیم» پروژه‌ی یک وب‌سایت، یا مخزن مراجعه کنید، می‌توانید اطلاعات این زیرکمیته‌ها و نقش افراد کلیدی را مشاهده کنید. + +پروژه‌های متن باز اسناد مختلفی دارند که این فایل‌ها معمولا در بالای لیست مخزن قرار می‌گیرند. + +* **لایسنس/ گواهینامه (LICENSE):** طبق تعریف، هر پروژه‌ی متن بازی باید لایسنس مخصوص به خود را داشته باشد. اگر یک پروژه لایسنس نداشته باشد، اصلاً متن باز محسوب نمی‌شود +* **فایل README:** فایل README یک دستورالعمل ساختاری برای تمام اعضای جدید انجمن است که می‌توانند آن را مطالعه می‌کنند. در این فایل به خوبی آورده شده که پروژه‌ی در دست چه فوایدی دارد و چگونه باید از آن استفاده کرد +* **فایل CONTRIBUTING:** زمانی که یک فایل README می‌تواند به مردم برای استفاده از پروژه کمک کنند، فایل CONTRIBUTING هم می‌تواند برای مشارکت افراد در پروژه به شما و به آن‌ها کمک کند. در این فایل توضیح داده شده که به چه نوع مشارکتی نیاز است و فرآیند کاری پروژه به چه نحوه است. با اینکه هر پروژه فایل CONTRIBUTING ندارد، اما در صورت وجود چنین فایلی در پروژه می‌تواند به افراد مختلف سیگنال مشارکت در پروژه بدهد. +* **CODE_OF_CONDUCT:** در فایل code of conduct می‌توانید قوائدی که شرکت‌کنندگان باید با در نظر گرفتن آن به صورت دوستانه و راحت و در یک محیط پذیرا با سایرین برخورد کنند را بنویسید. با اینکه هر پروژه ممکن است حاوی این فایل نباشد، اما زمانی که یک پروژه‌ی متن باز این فایل را داشته باشد، به مشارکت‌کننده‌ها این سیگنال را می‌فرستد می‌توانند در پروژه مشارکت داشته باشند. این فایل تقریباً حاوی توصیه‌هایی رفتاری برای تعامل است. +* **اسناد دیگر:** یک پروژه‌ی متن باز به خصوص پروژه‌های بزرگ‌تر ممکن است حاوی اسناد دیگری مانند فایل‌های آموزشی، بازنگری فنی، راهنمای گام به گام (walkthroughs) ، یا سیاست‌های دولتی باشند. + +در نهایت، پروژه‌های متن باز برای سازماندهی بحث‌ها از ابزارهای زیر استفاده می‌کنند. مطالعه‌ی آرشیو پروژه‌ها می‌تواند دید خوبی از نحوه‌ی فکر و کار انجمن‌ها بدهد. + +* **ایشو ترکر (Issue tracker):** جایی که افراد درباره‌ی مشکلات مرتبط با پروژه بحث می‌کنند +* **درخواست Pull (Pull requests):** جایی که افراد درباره‌ی تغییرات جاری بحث و بازبینی می‌کنند. +* **انجمن گفتگو یا خبرنامه های ایمیلی:** برخی از پروژه ها ممکن است برای موضوعات نیازمند بحث و گفتگو از انجمن های گفتگو یا خبرنامه ایمیلی به جای ایشو ترکر استفاده کنند. البته برخی دیگر ممکن است همین کار را به صورت کامل در بخش ایشو ترکر انجام دهند. +* **Synchronous chat channel:** بعضی از پروژه‌های از کانال‌های چت مانند Slack یا IRC برای مکالمات محاوره‌ای، همکاری یا تبادلات سریع استفاده می‌کنند. + +## یافتن یک پروژه جهت مشارکت کردن در آن + +اکنون می‌دانید نحوه‌ی کار یک پروژه‌ی متن باز چگونه است. بنابراین، زمانش رسیده تا برای مشارکت، یک پروژه‌ی متن باز پیدا کنید! + +اگر قبلا در هیچ پروژه‌ی متن بازی مشارکت نداشته‌اید، نصیحت رئیس جمهور آمریکا، جان. اف. کندی را بشنوید که گفت:«نگویید کشورتان برای شما چه کار کرده– بپرسید شما برای کشورتان چه کار کرده‌اید.» + +مشارکت‌کننده‌ها در تمام سطح‌های می‌توانند در پروژه‌های متن باز مشارکت کنند. لازم نیست بیش از حد به ذهن خود فشار بیاورید که اولین مشارکت شما در یک پروژه دقیقاً به چه صورت است، یا اولین مشارکت‌تان در آن پروژه چگونه خواهد شد. + +در عوض، به پروژه‌هایی فکر کنید که قبلا استفاده شده، یا می‌خواهید استفاده کنید. پروژه‌هایی که به صورت فعال در آن مشارکت می‌کنید، پروژه‌هایی هستند که برمی‌گردند. + +هر زمان در چنین پروژه‌هایی به این موضوع فکر کردید که می‌توانستید بهتر از این یا متفاوت‌تر باشد، بهتر است از روی غریزه کار کنید. + +فکر نکنید یک پروژه‌ی متن باز انحصاری است، چون پروژه‌های متن باز توسط افرادی مانند شما طراحی شده است. یک پروژه‌ی متن باز تنها یک لفظ فانتزی برای برطرف کردن و حل مشکلات در دنیاست. + +شما در پروژه‌های متن باز می‌توانید فایل README را مطالعه، لینک‌های خراب و غلط‌های املائی را پیدا و برطرف کنید. شما و کاربران جدیدتان هم می‌توانند متوجه مشکل یا مسئله‌ای شوند که فکر کی‌کند باید از اسناد پروژه باشد. به جای نادیده گرفتن، عبور کردن یا سپردن آن مسائل به افراد دیگر، برای اصلاح آن مشکلات می‌توانید کمک کنید. این تمام چیزی است که یک پروژه‌ی متن باز می‌تواند داشته باشد! + +> [28% از مشارکت‌کننده‌های معمولی](https://www.igor.pro.br/publica/papers/saner2016.pdf) روی اسناد پروژه‌ی متن باز مانند اصلاح غلط‌های املائی، شکل ‌دهی مجدد، یا نوشتن ترجمه مشارکت می‌کنند. + +اگر به دنبال مسائل موجود پروژه‌ی متن بازتان هستید تا آن را برطرف کنید، می‌توانید وارد صفحه‌ی `/contribute` هر پروژه‌ی متن باز شوید که مشکلات را برای تازه‌واردها برجسته می‌کند. شما می‌توانید با حل کردن آن مشکلات، در مشارکت پروژه‌ی متن باز همکاری داشته باشد. برای این منظور می‌توانید به صفحه‌ی اصلی repository (مخزن) در سایت GitHub مراجعه کنید و کلمه‌ی `/contribute` را به انتهای آدرس URL آن اضافه کنید. به عنوان مثال: +[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +شما همچنین می‌توانید از منابع زیر برای کشف و مشارکت در پروژه‌های جدید کمک بگیرید: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### بررسی چک لیست قبل از مشارکت در پروژه‌ی متن باز + +زمانی که پروژه‌ی مورد علاقه‌تان برای مشارکت را پیدا کردید، نگاهی سریعی داشته باشید که آیا آن پروژه مناسب است تا درخواست همکاری‌تان را بفرستید. در غیر این صورت، کار پُرتلاش شما ممکن است هیچوقت به نتیجه نرسد. + +در ادامه می‌توانید چک لیست دستی را ببینید که می‌تواند مشارکت‌کننده‌های جدید یک پروژه را ارزیابی کند. + +**پروژه با تعریف پروژه‌ی متن باز مطابقت داشته باشد** + +
+ + +
+ +**پروژه‌ی متن باز به صورت فعالانه‌ای حضور مشارکت‌کننده‌ها را قبول می‌کند** + +نگاهی به کامیت های اخیر در شاخه اصلی بیاندازید. در گیت‌هاب این این مورد در صفحه اصلی مخزن دیده می‌شود. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +در قدم بعدی به مسائل پروژه (issue) نگاهی بیندازید. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +حالا، تمام این مراحل را برای درخواست ادغام یا Pull Request پروژه هم در نظر بگیرید. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**پروژه پذیرای مشارکت است** + +زمانی که یک پروژه‌ی متن باز پذیرای مشارکت‌کننده‌های جدید باشد، سیگنال‌های دوستانه‌ای برای مشارکت‌کننده‌ها می‌فرستد. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## چگونه درخواست مشارکت را ارسال کنیم + +زمانی که پروژه‌ی مورد علاقه‌تان را پیدا کردید، آماده‌ی مشارکت در آن می‌شوید و در نهایت باید راهی برای ارسال مشارکت خود به آن پیدا کنید. + +### ارتباط موثر + +خواه مشارکت‌کننده‌ی یک‌باره باشید، یا سعی داشته باشید در یک انجمن عضو شوید، کار کردن با دیگران می‌تواند یکی از مهم‌ترین مهارت‌هایی باشد که در مشارکت در پروژه‌ی متن باز می‌توانید آن‌ را توسعه و بهبود دهید. + + + +قبل از درخواست ادغام یا باز کردن issue در بخش گزارش مسئله یا پرسیدن سوال در چت، نکته‌های زیر را در نظر داشته باشید تا به شما کمک کند تا ایده‌هایتان کارآمد و موثرتر باشد. + +**ارائه‌ی زمینه:** به دیگران کمک کنید تا سرعت خود را افزایش دهند. اگر خطایی پیدا کردید و در حال برطرف کردن آن هستید، به دیگران توضیح دهید که سعی دارید چه کاری انجام می‌دهید و چگونه آن مشکل را حل می‌کنید. اگر ایده‌ی جدیدی هم پیشنهاد می‌دهید، نه تنها برای خود، بلکه برای دیگران توضیح دهید که چرا فکر می‌کنید این ایده‌ی شما می‌تواند برای پروژه مفید باشد. + +> 😇 _"زمانی که Y را انجام می‌دهم، X اتفاق نمی‌افتد"_ +> +> 😢 _"X به مشکل برخورد کرده است! لطفا برطرفش کنید."_ + +**تکالیف‌تان را از قبل انجام دهید.** اگر چیزی نمی‌دانید مشکلی نیست، اما باید نشان دهید که تلاش‌تان را می‌کنید. قبل از اینکه از دیگران کمک بخواهید، مطمئن شوید که فایل README، اسناد، مسائل حل شده یا حل نشده، لیست پست پروژه را خوانده‌اید، یا در اینترنت به دنبال جواب‌تان گشته‌اید. وقتی تلاش‌تان برای یادگیری را نشان می‌دهید، مورد توجه تحسین دیگران قرار می‌گیرید + +> 😇 _"مطمئن نیستم چگونه X را اجرا کنم. برای پیدا کردن جواب، فایل‌ها را بررسی کردم و هیچ جوابی نگرفتم."_ +> +> 😢 _"چگونه مسئله X را برطرف کنم؟"_ + +**درخواست‌ها را مختصر و مفید مطرح کنید** هر مشارکتی مانند ارسال یک ایمیل، بدون در نظر گرفتن ساده یا مفید بودنش، به توجه‌ی دیگران نیاز دارد. معمولاً درخواست‌ها و سوالات اکثر پروژه‌ها از افرادی که می‌خواهند به آن‌ها جواب بدهند بیشتر است. بنابراین، درخواست‌ها باید مختصر باشد. با کوتاه بودن درخواست‌ها به افراد شانس بیشتری می‌دهید تا فرصت کمک کردن به شما را پیدا کنند. + +> 😇 _"تمایل دارم یک فایل آموزشی API بنویسم"_ +> +> 😢 _"زمانی که در بزرگ‌راه در حال رانندگی کردن بودم، کنار یک پمپ بنزین توقف کردم و ایده‌ی شگفت‌انگیزی به ذهنم رسید که باید آن را عملی کنیم، اما قبل از توضیح، اجازه دهید ایده‌ام را به شما نشان بدهم ..."_ + +**تمام ارتباطات و تعاملات را به صورت عمومی نگهدارید.** هرچند وسوسه‌کننده است، اما به طور خصوصی با مسئول‌نگهداری پروژه تماس نگیرید مگر اینکه لازم باشد اطلاعات حساس مانند مسائل امنیتی یا نقض رفتار جدیدی را رد و بدل کنید. زمانی که مکالمه‌ی شما عمومی شود، افراد بیشتری از تبادل این ارتباطات یاد می‌گیرند و بهره می‌گیرند. بحث و گفتگوها می‌تواند خودبه خود کمک‌رسان باشد. + +> 😇 (در کامنت) «@-مسئول‌نگهداری: سلام! چگونه درخواست ادغام را پیش ببریم؟"_ +> +> 😢 (در ایمیل) «سلام، ببخشید از طریق ایمیل مزاحم می‌شم، اما نمی‌دانم که می‌توانید درخواست ادغام من را بررسی کنید.»_ + +**سوال کردن عیب نیست (اما صبور باشید!).** هرکسی در ابتدای کار در پروژه تازه‌وارد بوده است. حتی مشارکت‌کننده‌های باتجربه زمانی که به پروژه‌ی جدیدی مراجعه می‌کنند، باید سرعت خود را افزایش دهند. با این حساب، حتی مسئول‌نگهدارهای طولانی مدت هم همیشه با تمام بخش‌های یک پروژه آشنا نیستند. بنابراین، سعی کنید صبور باشید تا فرصت نشان دادن آن را به شما بدهند. + +> 😇 _"بابت بررسی کردن این خطا ممنونم. پیشنهادهای شما را دنبال می‌کنم. این خروجی کار است"_ +> +> 😢 _"چرا مشکل من را نمی‌توانید حل کنید؟ این پروژه مگر پروژه‌ی شما نیست؟"_ + +**به تصمیمات انجمن احترام بگذارید.** ایده‌های شما ممکن است با اولویت‌ها و دید انجمن متفاوت باشد. آن‌ها یا می‌توانند به ایده‌های شما بازخورد بدهند یا آن را دنبال نکنند. درحالی‌که باید بحث و گفتگو کنید و به دنبال مصالحه باشید، مسئول‌نگهداری باید با تصمیمات شما بیشتر از شما زندگی کند. اگر با مسیر آن‌ها مخالف هستید، همیشه می‌توانید روی کار خود تمرکز کنید و پروژه‌ی خودتان را شروع کنید. + +> 😇 _"ناامید شدم که نمی‌توانید پرونده‌ی من را پشتیبانی کنید، اما همانطور که توضیح دادید این مسئله تنها روی بخشی از کاربران تاثیر می‌گذارد. متوجه هستم چرا. بابت شنیدن پیامم ممنون هستم"_ +> +> 😢 _"چرا مورد من را پشتیبانی نمی‌کنید؟ این کار شما غیرقابل قبول است!"_ + +**فراتر از همه اینها.** مشارکت‌کننده‌های سراسر دنیا پروژه‌های متن باز را می‌سازند. متن‌های پروژه‌ها می‌تواند با زبان‌ها، فرهنگ‌ها، جغرافیاها و مناطق زمانی زیادی باشد. مدل ارتباط نوشتاری رساندن لحن و حالت مشارکت‌کننده‌های یک پروژه را مشکل می‌کند. اما نیت خیر تمام این گفتگوها را در نظر داشته باشید. خوب است که ایده‌ی خود را مودبانه منتقل کنید، متن و محتوای بیشتری درخواست کنید، یا موقعیت‌تان را روشن‌تر کنید. فقط سعی کنید اینترنت را از زمانی که وارد شدید، را جای بهتری کرده باشید + +### Gathering context + +قبل از اینکه کاری انجام دهید، به سرعت بررسی کنید و مطمئن شوید که ایده‌ی شما در هیج جای مورد بحث قرار نگرفته باشد. فایل README، مسائل حل‌شده یا حل‌نشده، لیست پست و گفتگوهای Stack را به طور سرسری مطالعه کنید. لازم نیست ساعت‌ها صرف خواندن آن‌ها کنید، اما جستجوی سریع درباره‌ی کلمات کلیدی می‌تواند تا حد زیادی به شما کمک کند + +اگر ایده‌ی شما در جای دیگری مطرح نشده بود، می‌توانید آن را بیان کنید. اگر پروژه در GitHub باشد، با باز کردن Issue یا درخواست ادغام Pull Request احتمالاً می‌توانید مکالمه داشته باشید: + +* **Issues** مانند شروع یک مکالمه یا گفتگو است +* **Pull Requests** برای کار روی راه‌حل است +* **سایر راه های ارتباطی راه‌های ارتباطی** مانند شفاف‌سازی، نحوه‌ی پرسیدن سوال (How-to question)، پرسیدن سوال در Stack ، IRC ، Slack یا دیگر کانال‌های چت است، البته اگر یک پروژه چنین راه‌های ارتباطی را باز گذاشته باشد. + +قبل از باز کردن issue یا درخواست ادغام، اسناد مشارکت پروژه را بررسی کنید که معمولاً در فایل‌هایی به نام CONTRIBUTING یا README آورده شدند تا چیزهای خاصی که دنبالش هستید را مطالعه کنید. به عنوان مثال، آن‌ها ممکن است از شما درخواست کنند الگوها را پیروی کنید یا به این نیاز داشته باشند که از این تست‌ها استفاده کنند. + +اگر در یک پروژه مشارکت عمیق و اساسی داشته باشید، قبل از مشارکت در پروژه، یک issue باز کنید و سوال کنید. این کار مفید است و باعث می‌شود پروژه‌ی شما مدتی مشاهده شود. (در سایت GitHub می‌توانید [روی «Watch» کلیک کنید](https://help.github.com/articles/watching-repositories/) تا از تمام مکالمات مطلع شوید)، و قبل از انجام دادم کار که ممکن است پذیرفته نشود، اعضای انجمن را بشناسید. + + + +### باز کردن issue یا طرح سوال و گفتگو + +در موقعیت‌های زیر معمولاً باید یک issue باز کنید: + +* جهت گزارش خطایی که خودتان نمی‌توانید آن را حل کنید +* درباره‌ی موضوعات یا ایده‌ی سطح بالا بحث کنید (به عنوان مثال، درباره‎ی جامعه، دیدگاه یا سیاست‌ها) +* ویژگی جدید یا ایده‌ی جدیدی برای پروژه پیشنهاد دهید + +نکاتی برای برقراری ارتباط با مشکلات issue : + +* **اگر با مسئله‌ی بازی روبه‌رو شدید که می‌خواهید آن را برطرف کنید**، کامنت کردن برای یک مسئله به افراد اجازه می‌دهد بدانند که شما این مسئله را باز کردید. به این ترتیب، افراد احتمالاً کمتر با مشکلات مشابه‌ی شما برخورد می‌کنند +* **اگر یک issue مدتی پیش باز بوده است**، احتمال دارد جای دیگر به آن جواب داده شده باشد، یا قبلا حل شده است. بنابراین، قبل از شروع کار می‌توانید برای تایید حل شدن یا حل نشدن آن درخوست کامنت بدهید. +* **اگر یک issue باز کردید**، اما جواب آن را بعدها متوجه شدید، روی issue کامنت بگذارید تا مردم متوجه شوند، سپس issue را ببندید. حتی با نوشتن اسناد می‌تواند سهمی در مشارکت پروژه داشته باشید. + +### ارسال Pull request (درخواست ادغام) + +شما معمولاً در موقیعت‌های زیر باید درخواست ادغام باز کنید: + +* ارائه اصلاحات ناچیز (به عنوان نمونه، غلط‌های املائی، لینک‌های خراب یا خطاهای مشهود) +* کار کردن روی مشارکتی که قبلا درخواست شده یا درباره‌ی آن بحث و گفتگو شده باشد + +درخواست ادغام لزوماً به معنای پایان کار نیست. معمولاً بهتر است درخواست ادغام را قبلا باز کنید تا دیگران بتوانند آن را مشاهده و بازخوردهای خود را برای پیشرفت شما ارسال کنند. فقط آن را به «WIP» (کار در حال انجام) در کادر عنوان نشانه‌گذاری کنید. شما بعدها می‌توانید کامیت‌های بیشتری اضافه کنید. + +اگر پروژه در GitHub باشد، با روش‌های زیر می‌توانید درخواست ادغام ارسال کنید: + +* **[Fork the repository](https://guides.github.com/activities/forking/)** و یک نسخه برای خودتان کپی کنید. نسخه محلی خود را به مخزن بالادستی متصل کنید. هر از چندگاهی با دستور Pull آخرین نسخه تغییرات در مخزن اصلی را دریافت کنید تا پیش از اینکه تعارضی ما بین نسخه محلی و مخزن ایجاد شد بتوانید با مشکلات احتمالی کمتری تغییرات خود را به سمت مخزن اصلی ارسال کنید. [برای کسب اطلاعات بیشتر اینجا را مرور کنید](https://help.github.com/articles/syncing-a-fork/) +* **[ایجاد یک شاخه](https://guides.github.com/introduction/flow/)** برای اعمال ویرایش ها. +* در حین ارسال ها **به مسائل (issue) مرتبط ارجاع دهید** یا در کامنت مربوط به تغییرات جدید به مستندات مربوطه اشاره کنید.(مثال: این تغییر مشکل مطرح شده در مسئله شماره 37 را برطرف می‌کند.) +* اگر تغییرات شما حاوی تفاوت‌های HTML/CSS باشد، **تصاویر مربوط به قبل و بعد آن را اضافه کنید**. تصاویر را وارد بدنه‌ی درخواست ادغام کنید و رها کنید. +* تغییرات‌تان را **تست کنید!** تغییرات خود را در برابر تست‌های موجود اجرا کنید و در صورت لزوم تغییرات جدیدی خلق کنید. اگر حتی تست‌هایی تعریف نشده بود، مطمئن شوید تغییرات‌تان پروژه‌ی موجود شما را خراب نکند. +* با تمام توانایی‌تان **الگوها را رعایت کرده و مطابق سبک پروژه مشارکت کنید**. این توانایی می‌تواند به معنای استفاده از تورفتگی‌ها، نقطه ویرگول (semi-colons) ، یا کامنت‌های متفاوتی باشد که شما در مخزن‌تان خودتان دارید. این کار ادغام مسئول‌نگهداری را ساده می‌کند، دیگران هم متوجه آن می‌شوند و می‌توانند آن را برای زمان‌های آتی حفظ کنند. + +اگر این اولین درخواست ادغام شماست، فیلم آموزشی [Make a Pull Request](http://makeapullrequest.com/) که @kentcdodds آن را خلق کرده، بررسی کنید. شما همچنین می‌توانید از [Make a Pull Request](https://github.com/Roshanjossey/first-contributions) که توسط @Roshanjossey ایجاد شده به عنوان یک محزن تمرینی برای اولین تجربه خود استفاده کنید. + +## بعد از ارسال درخواست مشارکت چه اتفاقی می‌افتد + +شما درخواست‌تان را ارسال کردید! شروع مشارکت‌تان در یک پروژه‌ی متن باز را تبریک می‌گوییم. امیدواریم این اولین قدم‌تان باشد. + +بعد از ارسال درخواست مشارکت‌تان، یکی از اتفاقات زیر رخ می‌دهد: + +### 😭 جوابی دریافت نمی‌کنید. + +امیدواریم قبل از ارسال درخواست مشارکت، [چک لیست فعالیت‌های پروژه](#بررسی-چک-لیست-قبل-از-مشارکت-در-پروژهی-متن-باز) را برررسی کرده باشید. هرچند، حتی در پروژه‌ی فعال هم این احتمال وجود دارد که به درخواست مشارکت شما پاسخ ندهند. + +اگر بیش از یک هفته جوابی برایتان ارسال نشد، به طور مودبانه می‌توانید درخواست جواب دهید و از کسی بخواهید درخواست شما را بررسی کند. اگر نام کسی که می‌خواهید درخواست شما را بررسی کند می‌دانید، می توانید به اون اشاره (منشن: با گذاشتن علامت @ در ابتدای نام کاربری) کنید. + +به صورت خصوصی با آن شخص **تماس نگیرید**. به یاد داشته باشید ارتباط عمومی برای پروژه‌ها بسیار حیاتی است. + +اگر به طور مودبانه درخواست‌هایتان را فرستاده باشید اما هنوز هیچ‌کس پاسخگو نیست، احتمالاً هیچ‌کس هیچوقت پاسخ شما را نخواهد داد. می‌دانیم که حس خوبی ندارد، اما اجازه ندهید این موضوع شما را دلسرد کند چون این اتفاق ممکن است برای همه رخ دهد! + +برای برطرف کردن این مشکل دلایل زیادی وجود دارد که به شما می‌گوید چرا پاسخ درخواست‌تان داده نمی‌شود؛ دلایلی مانند شرایط شخصی که ممکن است از کنترل خارج شود. شما می‌تواند پروژه‌ی دیگر یا راهی برای مشارکت پیدا کنید. قبل از اینکه اعضای یک انجمن متعهد یا پاسخگو باشند، زمان زیادی را صرف ارسال درخواست مشارکت‌تان نکنید. + +### 🚧 یک نفر برای تغییر درخواست‌تان به شما پیام می‌دهد. + +مرسوم است کسی بخواهید درخواست مشارکت خود را تغییر دهید، این درخواست تغییر می‌تواند در بازخورد ایده‌ یا در تغییرات کد شما باشد. + +اگر کسی درخواست تغییر برای‌تان ارسال کرد، پاسخگو باشید، چون آن‌ها برای بررسی درخواست مشارکت شما زمان گذاشتند. باز گذاشتن PR (درخواست ادغام) و نادیده گرفتن آن صورت خوبی ندارد. اگر نمی‌دانید چگونه روی درخواست‌تان آن تغییرات را اعمال کنید، مشکلات را جستجو کنید و در صورت نیاز از کسی کمک بخواهید. + +اگر برای برطرف کردن مسائل پروژه دیگر زمان کافی ندارید (به عنوان نمونه، اگر مکالمه‌ی شما ماه‌ها طول کشید، و اکنون شرایط شما تغییر کند)، اجازه دهید مسئول‌نگهداری پروژه از این موضوع مطلع شود تا منتظر جواب شما نباشد. حتی کسی دیگری ممکن است جای شما را بگیرد. + +### 👎 درخواست مشارکت‌تان پذیرفته نشد + +در پایان، درخواست مشارکت‌تان ممکن است پذیرفته شود یا نشود. هرچند، در صورت پذیرفته نشدن درخواست‌تان امیدواریم زمان زیادی روی آن صرف نکرده باشید. اگر مطمئن نیستید که چرا درخواست‌تان پذیرفته نشده، کاملاً معقولانه است که برای درخواست بازخورد و شفاف‌سازی از مسئول‌نگهداری جواب بخواهید. در نهایت، با احترام به تصمیم آن‌ها نباید خشمگین و عصبانی شوید. همیشه می‌توانید پروژه‌ی دیگری انتخاب کنید و اگر هم نمی‌خواهید در پروژه‌ای مشرکت کنید، می‌توانید پروژه‌ی خودتان را داشته باشید! + +### 🎉 درخواست مشارکت شما پذیرفته شد. + +هوررا! درخواست مشارکت شما برای پروژه‌ی متن باز موفقیت‌آمیز بوده است + +## انجامش دادی! + +خواه دنبال ارسال درخواست مشارکت خود برای اولین پروژه‌تان باشید، یا دنبال یک راه جدید برای مشارکت در پروژه‌ای متن باز، امیدواریم انگیزه این کار را داشته باشید. حتی اگر درخواست‌تان هم پذیرفته نشد، فراموش نکنید از تلاش مسئول‌نگهداری پروژه تشکر کنید که تمام تلاش خود را برای کمک به شما گذاشت. پروژه‌های متن باز، مسائل، درخواست ادغام، کامنت توسط افرادی مانند شما تولید می‌شود. diff --git a/_articles/fa/index.html b/_articles/fa/index.html new file mode 100644 index 00000000000..0bb1b27c4bd --- /dev/null +++ b/_articles/fa/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: راهنماهای متن‌باز +lang: fa +permalink: /fa/ +--- diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md new file mode 100644 index 00000000000..eb7330c28a9 --- /dev/null +++ b/_articles/fa/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: fa +title: مدیریت و نظارت +description: وجود نقش‌های رسمی جهت تصمیم‌گیری، منافع زیادی برای پروژه‌های متن باز در حال رشد به همراه دارد. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## نظارت درست بر روی پروژه‌ی در حال رشد + +پروژه‌ی شما رشد می‌کند، مردم درگیر پروژه‌ی شما می‌شوند، و شما به ادامه دادن این کار متعهد می‌شوید. در این مرحله، ممکن است از خود بپرسید که چگونه می‌توانید مشارکت‌کنندگان پروژه‌ی خود را منسجم و یکپارچه کنید، خواه دادن دسترسی کامیت باشد یا حل و فصل کردن بحث‌ها و گفتگوهای درون اجتماع. اگر سوالاتی دارید، جواب‌ها پیش ماست. + +## مثال‌هایی از نقش‌های رسمی مورد استفاده در پروژه های متن باز، چه هستند؟ + +بسیاری از پروژه‌ها، ساختار مشابهی را در حوزه‌ی نقش‌های مشارکتی و شناختی دنبال می‌کنند. + +مضمون و معنای این نقش‌ها، در واقع کاملا به شما بستگی دارد. در اینجا، چند نوع نقشی که ممکن است آن‌ها را تشخیص دهید، نام بردیم: + +* **نگهدارنده (Maintainer)** +* **مشارکت‌کننده (Contributor)** +* **کامیت کننده (Committer)** + +**در برخی از پروژه‌ها، نگهدارندگان** تنها افرادی در پروژه هستند که دسترسی کامیت دارند. در برخی دیگر از پروژه‌ها، فقط افرادی دسترسی دارند که در «README» به عنوان نگهدارنده ذکر شده‌اند. + +نگهدارنده لزوماً کسی نیست که برای پروژه‌ی شما کد می‌نویسد. بلکه می‌تواند کسی باشد که در تبلیغ پروژه‌ی شما کارهای زیادی انجام داده باشد یا مستنداتی را نوشته باشد که پروژه را برای دیگران قابل دسترسی‌تر کرده است. صرف نظر از کاری که آن‌ها در طی روز انجام می‌دهند، نگهدارنده کسی است که نسبت به مسیر و اجرای پروژه احساس مسئولیت می‌کند و متعهد به بهبود بخشیدن آن است. + +**مشارکت‌کننده می‌تواند هر کسی باشد**: کسی که مسئله یا درخواست «Pull»ی را مطرح می‌کند، یا افرادی باشند که به پروژه ارزش می‌بخشند (خواه این که مسائل مربوط به اولویت‌بندی درخواست‌ها، نوشتن کد یا سازماندهی رویدادها باشد) یا هر کسی باشد که درخواست «Pull»ی را ادغام (merge) بکند (جزئی‌ترین تعریف از مشارکت‌کننده) + + + +**اصطلاح «کامیت کننده»،** ممکن است برای وجه تمایز دسترسی کامیت، که نوع خاصی از مسئولیت در مقابل سایر اشکال مشارکت است، استفاده شود. + +در حالی که می‌توانید نقش‌ها را در پروژه‌ی خود به هر روشی که دوست دارید تعریف کنید، استفاده از تعاریف گسترده‌تر را برای تقویت اشکال بیشتری از مشارکت، [مد نظر خود قرار دهید](../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) همچین کاری می‌کند + +پس از اینکه نقش‌های مدیریتی را ایجاد کردید، ثبت چگونگی نحوه‌ی دسترسی افراد به آن‌ها را فراموش نکنید! فرآیند روشن و واضحی را برای چگونگی کسی که می‌خواهد نگهدارنده شود یا به کمیته‌ای فرعی در پروژه شما بپیوندد، ایجاد کنید و آن را در «GOVERNANCE.md» خود بنویسید. + +ابزارهایی مانند [Vossibility](https://github.com/icecrime/vossibility-stack)، می‌تواند به شما کمک کند تا به طور عمومی افرادی که در پروژه مشارکت می‌کنند (یا نمی‌کنند) را ردیابی کنید. ثبت این اطلاعات، جلوی این ذهنیت اجتماع که نگهدارندگان گروهی هستند که تصمیمات خود را به صورت خصوصی اتخاذ می‌کنند، می‌گیرد + +در آخر اینکه اگر پروژه‌ی شما در «GitHub» است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. [تشکل‌های «GitHub»](https://help.github.com/articles/creating-a-new-organization-account/)، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق [مالکیت مشترک](../building-community/#مالکیت-پروژه-تان-را-به-اشتراک-بگذارید) محافظت می‌کنند. + +## چه موقع باید به کسی اجازه‌ی دسترسی کامیت بدهیم؟ + +برخی از افراد فکر می‌کنند که شما باید به هر کسی که در پروژه مشارکت می‌کند، دسترسی کامیت بدهید. با انجام این کار، افراد بیشتری ترغیب به داشتن احساس مالکیت نسبت به پروژه‌ی شما، می‌شوند. + +از طرف دیگر، به خصوص برای پروژه‌های بزرگتر و پیچیده‌تر، ممکن است بخواهید فقط به افرادی که تعهد خود را نشان داده و به اثبات رسانده‌اند، دسترسی کامیت بدهید. هیچ راه درستی برای انجام این کار وجود ندارد - هر جور که راحت‌تر هستید، عمل کنید! + +اگر پروژه‌ی شما در «GitHub» است، می توانید از شاخه‌های محافظت شده [protected branches](https://help.github.com/articles/about-protected-branches/) برای مدیریت افرادی که می‌توانند تحت شرایط خاصی در شاخه‌ای خاص عمل کنند، استفاده کنید + + + +## برخی از ساختارهای نظارتی متداول برای پروژه‌های متن باز چیست؟ + +سه ساختار نظارتی متداول در ارتباط با پروژه‌های متن باز وجود دارد. + +* **BDFL** مخفف "Benevolent Dictator for Life" یا «دیکتاتور خیرخواه جاویدان» است تحت این ساختار، یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت BDFL هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی BDFL قرار گیرند + +* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از خود «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache»، به وجود آمد. تمامی پروژه‌های «Apache» بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت. + +* **Liberal contribution:** (مشارکت آزادنه) تحت مدل مشارکت آزادانه، افرادی که بیشترین کار را انجام می‌دهند به عنوان تأثیرگذارترین افراد شناخته می‌شوند، اما این مدل براساس کاری که اکنون انجام می‌دهند است و نه مشارکت‌های که در گذشته داشته‌اند. تصمیمات بزرگ‌ پروژه بر اساس فرآیندی در اجتماع به صورت اجماعی (بحث‌ در مورد مسائل اساسی) به جای رأی‌گیری تنها گرفته می‌شود، و تلاش می‌شود تا آنجا که ممکن است دیدگاه‌های بیشتری از اجتماع را شامل شود. از جمله پروژه‌هایی که از مدل مشارکت آزادانه استفاده کردند، می‌توان [Node.js](https://foundation.nodejs.org/) و [Rust](https://www.rust-lang.org/) را نام برد. + +از کدام مدل بهتر است استفاده کنید؟ به خودتان بستگی دارد! هر مدل، شامل نکات منفی و مثبتی می‌شود. اگرچه ممکن است این مدل‌ها در ابتدا کاملاً متفاوت به نظر برسند؛ اما هر سه مدل، بیشتری از آنچه که به نظر می رسد اشتراکاتی دارند: + +* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## آیا هنگام راه‌اندازی پروژه‌ی خود به اسناد نظارتی نیاز دارم؟ + +زمان مناسب و دقیقی برای نوشتن اسناد نظارتی پروژه وجود ندارد، اما هنگامی که شرایط اجتماع خود را دیدید و با جو آن آشنا گشتید، به ثبت رساندن اسناد بسیار ساده‌تر می‌شود. بهترین (و سخت‌ترین) بخش در مورد نظارت پروژه‌های متن باز این است که توسط خود اجتماع شکل می‌گیرد! + +هر چند برخی اسناد اولیه‌ی نظارتی به طور اجتناب ناپذیری در پروژه‌ی شما خواهد بود، ولی شروع به نوشتن آنچه می‌توانید بکنید. به عنوان مثال، شما می‌توانید حتی در زمان راه‌اندازی پروژه‌ی خود، انتظارات واضح و شفاف خودتان از رفتار یا فرآیند‌ مشارکت کاری را تعریف کنید. + +اگر شما عضوی از شرکتی هستید که پروژه‌ای متن باز راه‌اندازی می‌کند، بد نیست قبل از راه‌اندازی، بحثی درون‌سازمانی درباره نحوه‌ی نگهداری شرکت و تصمیم‌گیری در مورد پیشرفت پروژه داشته باشید. همچنین بهتر است در مورد مسیری که شرکت شما در رابطه با پروژه پیش خواهد گرفت، به صورت علنی صحبت دهید. + + + +## اگر کارمندان شاغل در شرکت شروع به ارائه‌ی خدمات کنند، چه می‌شود؟ + +پروژه‌های متن باز موفق، توسط بسیاری از افراد و شرکت‌ها مورد استفاده قرار می‌گیرند و در نهایت ممکن است برخی از شرکت‌ها شروع به کسب درآمد از آن پروژه‌ها بکنند. به عنوان مثال، شرکتی ممکن است از کدهای پروژه به عنوان یک بخش سازنده‌ی محصولات خدمات تجاری استفاده کند. + +هنگامی که استفاده از پروژه بیشتر شود، افراد زیادی خواستار کسانی که در آن پروژه تخصص دارند می‌شوند؛ ممکن است شما یکی از آن‌ها باشید! و گاهی اوقات نیز به خاطر کاری که در پروژه‌ می‌کنید، حقوق دریافت کنید. + +بسیار مهم است که رفتاری عادی در قبال فعالیت‌های تجاری داشت؛ درست رفتاری مانند فعالیت‌های توسعه‌ای در پروژه‌های دیگر. البته نباید برخورد خاص و رفتار ویژه‌ای با توسعه‌دهندگانی که به آن‌ها پول داده می‌شود در برابر آن‌هایی که بدون دریافت پول به کارشان مشغول هستند، قائل شد. هر یک از مشارکت‌ها باید بر اساس شایستگی‌های فنی ارزیابی شود. با این حال، افرادی که مشغول به فعالیت‌های تجاری هستند، باید احساس راحتی داشته باشند و هنگام بحث و گفتگو در مورد پیشرفت یا ویژگی خاصی، در بیان موارد کاربردی و کارهایی که قبلا داشتند، باید احساس راحتی کنند. + +پروژه‌های «تجاری» هیچ فرقی با پروژه‌های «متن باز» ندارند. «تجاری» فقط به این معنی است که پول هم در کار است؛ به این معنی که نرم افزاری که در تجارت مورد استفاده قرار می‌گیرد، نرم‌افزاری در پروژه بوده است که در فعالیت تجاری پذیرفته شده است. (هنگامی که از یک نرم‌افزار «متن باز» به عنوان بخشی سازنده از محصولی «غیر متن باز» استفاده می‌شود، محصول نهایی همچنان نرم‌افزاری «دارای حقوق انحصاری» است، هرچند مانند «متن باز» ممکن است برای اهداف تجاری یا غیر تجاری استفاده شود.) + +مانند هر کس دیگری، توسعه‌دهندگانی که انگیزه‌های تجاری دارند از طریق کیفیت و کمیت مشارکت‌های خودشان است که در پروژه اهمیت می‌یابند و تاثیرگذار می‌شوند. بدیهی است که توسعه‌دهنده‌ای که برای کاری که می‌کند حقوق می‌گیرد، احتمالا بیشتر از شخصی که حقوق نمی‌گیرد، توانایی کار کردن دارد ولی اهمیتی ندارد، پرداخت حقوق فقط یکی از بسیار عامل‌های احتمالی است که می‌تواند بر میزان کاری که شخص می‌کند، تأثیر بگذارد. مشارکت‌ها رو معطوف به بحث‌های مربوط به پروژه بکنید، و نه معطوف به موضوعاتی خارج از پروژه. + +## آیا برای حمایت و پشتیبانی از پروژه‌ی خود به نهاد قانونی نیاز خواهم داشت؟ + +شما برای پشتیبانی از پروژه‌ی متن باز خود احتیاج به نهاد قانونی نخواهید داشت، مگر اینکه با پول سر و کار داشته باشید. + +به عنوان مثال، اگر می‌خواهید کسب و کاری ایجاد کنید، باید از طریق «C Corp» یا «LLC» (اگر در ایالات متحده مستقر هستید) اقدام کنید. اگر فقط کارهای پیمانکاری مربوط به پروژه متن باز خود را انجام می‌دهید، می‌توانید به عنوان یک مالک شخصی پول را بپذیرید یا یک «LLC» (اگر در ایالات متحده مستقر هستید) ایجاد کنید. + +اگر می‌خواهید کمک‌های مالی برای پروژه‌ی متن باز خود بپذیرید، می‌توانید بستری را برای کمک‌های مالی (مثلاً با استفاده از PayPal یا Stripe) ایجاد کنید، اما این مبلغ مشمول کسر مالیات می‌شود، مگر اینکه به عنوان یک سازمان غیرانتفاعی واجد شرایط باشید (اگر در ایالات متحده مستقر هستید). + +بسیاری از پروژه‌ها مایل به پذیرفتن مشکلات ناشی از ایجاد سازمانی غیرانتفاعی نیستند، بنابراین در عوض یک حامی مالی غیرانتفاعی پیدا می‌کنند. یک حامی مالی، معمولاً در ازای درصدی از کمک مالی، کمک‌های مالی را از طرف شما قبول می‌کند. [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 package manager](https://www.python.org/psf/) و [Node.js Foundation](https://foundation.nodejs.org/) به [Express.js](https://expressjs.com/)، که مبتنی بر Node است، کمک می‌کند. diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md new file mode 100644 index 00000000000..3536bfc5eb7 --- /dev/null +++ b/_articles/fa/legal.md @@ -0,0 +1,162 @@ +--- +lang: fa +title: جنبه‌های حقوقی پروژه‌های متن باز +description: تمامی چیزهایی که در مورد جنبه‌های حقوقی متن باز برای شما سوال شده و چیزهایی که سوال نشده. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## درک پیامدهای حقوقی پروژه‌های منبع آزاد + +اشتراک گذاشتن کارهای خلاقانه با جهانیان می‌تواند تجربه‌ای هیجان‌انگیز و ارزشمند باشد. همچنین می‌تواند به معنای درگیر شدن با یک سری موارد حقوقی باشد که در رابطه با آن‌ها چیزی نمی‌دانید. خوشبختانه، نیازی نیست از ابتدا شروع کنید. ما نیازهای حقوقی شما را برآورده کرده و پوشش داده‌ایم. (قبل از شروع، حتماً متن [سلب مسئولیت](/notices/) ما را بخوانید.) + +## چرا مردم اینقدر به جنبه‌های حقوقی متن آزاد اهمیت می‌دهند؟ + +به طور کلی، به این معنی است که هیچ کس دیگری نمی‌تواند از اثر شما استفاده کند، کپی کند، پخش کند یا اصلاحاتی روی آن انجام دهد؛ بدون اینکه در معرض ریسک دعوی قضایی و پیگیری قرار بگیرد. + +هرچند پروژه‌های متن باز شرایطی غیرمعمول دارند، زیرا خالق اثر انتظار دارد که دیگران از اثر استفاده کنند و آن را اصلاح نمایند و به اشتراک بگذارند. اما از آنجا که پیش‌فرض قانونی همچنان شامل حق نشر می‌شود، شما به مجوزی نیاز دارید که صریحاً این دسترسی‌ها را میسر سازد. + +اگر مجوز (لایسنس) مربوط به پروژه‌های متن باز را اعمال نکنید، همه کسانی که در پروژۀ شما مشارکت می‌کنند نیز به عنوان دارندۀ حق نشر برای کارهای منحصر به فرد خود شناخته می‌شوند. این بدان معناست که هیچ کس نمی‌تواند از مشارکت‌های خود استفاده یا کپی کند و آن را توزیع یا اصلاح نماید و این «هیچ کس» شامل شما هم می‌شود. + +در آخر اینکه ممکن است پروژۀ شما وابستگی‌هایی با ملزومات مجوز داشته باشد که از آن‌ها اطلاع نداشته باشید. انجمن (community) پروژه یا سیاست‌های کارفرمایی شما نیز ممکن است پروژه را ملزم به استفاده از مجوز‌های متن باز خاصی بکند. در زیر دربارۀ آن توضیح می‌دهیم. + +## آیا پروژه‌های عمومی «GitHub» متن باز محسوب می‌شوند؟ + +هنگام ایجاد [پروژه‌ای جدید](https://help.github.com/articles/creating-a-new-repository/) در «GitHub»، این انتخاب را دارید که منبع را **خصوصی** یا **عمومی** مشخص کنید + +![Create repository](/assets/images/legal/repo-create-name.png) + +**عمومی کردن پروژه‌تان در «GitHub» به منزلۀ مجوزدار کردن پروژه نیست.** پروژه‌های عمومی‌ای که [تحت شرایط خدمات «GitHub»](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) قرار می‌گیرند این امکان را برای افراد میسر می‌سازد که پروژه شما را مشاهده کنند و آن را فورک (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) (مدیریت پکیج Node) استفاده خواهید کرد. هر کدام از این کتابخانه‌هایی که به آن‌ها وابسته هستید، مجوز (لایسنس، پروانه) متن باز مخصوص به خود را دارند. اگر هر یک از مجوزهای آن‌ها «اختیاری» باشد (بدون هیچ گونه شرطی برای فعالیت‌های آینده، اجازۀ استفاده، اصلاح، تغییر و اشتراک‌گذاری را به عموم مردم می‌دهد)، می‌توانید از هر مجوزی که می‌خواهید استفاده کنید. مجوزهای اختیاری متداول شامل «MIT»، «Apache 2.0»، «ISC» و «BSD» می‌شوند. + +از طرف دیگر، اگر هر یک از مجوزهای وابستگی شما، «کپی‌لفت قوی» باشند (مشروط به استفاده از همان مجوز در آینده، مجوزهای عمومی مشابهی را می‌دهد)، در این صورت پروژۀ شما باید از همان مجوز استفاده کند. مجوزهای متداول کپی‌لفت قوی شامل «GPLv2»، «GPLv3» و «AGPLv3» می‌شوند. (تعریف Copyleft : کپی‌لفت نوعی بازی با کلمهٔ کپی‌رایت است. کپی‌لفت عملی را توصیف می‌کند که در آن تضمین می‌شود که اجازهٔ نسخه‌برداری و ویرایش یک اثر برای همگان محفوظ می‌مانَد و هیچ شخصی اجازه ندارد حق ویرایش و نسخه‌برداری را از دیگر افراد سلب کند.) + +همچنین ممکن است بخواهید **انجمن‌هایی** را در نظر بگیرید که امیدوار هستید از پروژۀ شما استفاده کنند و در آن مشارکت کنند: + +* **آیا می‌خواهید پروژۀ شما به عنوان وابستگی توسط سایر پروژه‌ها مورد استفاده قرار گیرد؟** بهتر است محبوب‌ترین نوع مجوز را در انجمن‌تان استفاده کنید. به عنوان مثال، [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 سازگار باشد، در حالی که با شرایط B مطابقت دارید، با شرایط A نیز منطبق خواهید بود (اما لزوما برعکس آن درست نیست). بنابراین اگر در حال حاضر از مجوزی اختیاری استفاده می‌کنید (به عنوان مثال، «MIT»)، می‌توانید به مجوزی با شرایط بیشتری تغییر مجوز دهید، به شرطی که نسخه‌ای از مجوز «MIT» و هرگونه شرط حق نشر دیگری مربوط به آن را حفظ کنید (یعنی همچنان با حداقل شرایط مجوز «MIT» سازگار باشید). اما اگر مجوز فعلی شما اختیاری نباشد (به عنوان مثال کپی‌لفت باشد یا مجوزی نداشته باشید) و تنها دارندۀ حق نشر نیستید، نمی‌توانید مجوز پروژۀ خود را به «MIT» تغییر دهید. اساساً، صاحبان حق نشر پروژه با داشتن مجوز اختیاری از قبل اجازۀ تغییر مجوزها را داده‌اند. + +**صاحبان کنونی حق‌نشر پروژه‌تان.** اگر تنها مشارکت‌کننده در پروژه‌تان هستید، شما یا شرکت شما تنها صاحبان حق‌نشر این پروژه خواهید بود. خودتان یا شرکت می‌توانید، مجوز را تغییر دهید یا مجوز جدیدی اضافه کنید. در غیر این صورت ممکن است باید قبل از تغییر مجوز، با دیگر صاحبان حق‌نشر به توافق برسید. آن‌ها چه کسانی هستند؟ افرادی که متعهد به پروژه هستند، نقطۀ خوبی برای شروع است. اما در برخی موارد حق‌نشر توسط افراد بالادستی این افراد حفظ می‌شود. در برخی موارد افراد مشارکت کم و حداقلی داشته‌اند، اما هیچ قانون سخت و جدی وجود ندارد که بگوید افرادی که مشارکتی در برخی از خطوط کد داشته‌اند مشمول حق‌نشر نباشد. چه کار باید کرد؟ بستگی دارد. برای پروژه‌ای نسبتاً کوچک و تازه‌شکل گرفته، ممکن است امکان‌پذیر باشد که همۀ مشارکت‌کنندگان موجود با تغییر مجوز در طرح مسئله‌ای یا در درخواست pullی موافقت کنند. برای پروژه‌های بزرگ و قدیمی، ممکن است برای مثلا تغییر مجوز مجبور شوید به جستجوی بسیاری از مشارکت‌کنندگان و حتی ورثه‌های آن‌ها مشغول شوید. موزیلا سال‌ها به طول انجامید (2001 تا 2006) تا مجوز «Firefox»، «Thunderbird» و دیگر نرم‌افزارهای مربوطه را تغییر دهد. + +همچنین می‌توانید موافقت مشارکت‌کنندگان را از قبل جلب کنید (از طریق توافق‌نامه‌های مشارکتی اضافی - به زیر مراجعه کنید) تا بتوانید کارتان را در مورد برخی از تغییرات مجوز تحت شرایط خاصی را فراتر از شرایط مجاز مجوز متن باز موجود پیش ببرید. این موضوع پیچیدگی تغییر مجوزها را کمی تغییر می‌دهد. برای اینکار به کمک وکلای خود بیشتر احتیاج خواهید داشت و هنوز هم باید در هنگام اجرای تغییر مجوز، به طور واضح با ذی‌نفعان پروژۀ خود صحبت کنید. + +## آیا پروژۀ من به توافق‌نامه‌های همکاری (مشارکتی) اضافی نیاز دارد؟ + +به احتمال زیاد نه. برای اکثریت قریب به اتفاق پروژه‌های متن باز، یک مجوز متن آزاد به طور ضمنی به عنوان مجوز درونی (برای مشارکت‌کنندگان) و مجوز خارجی (برای سایر مشارکت‌کنندگان و کاربران) عمل می‌کند. اگر پروژۀ شما در «GitHub» میزبانی می‌شود، شرایط خدمات‌دهی «GitHub»، «مجوزهای درونی و مجوزهای خروجی را [صریحا پیش‌فرض](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license) درنظر می‌گیرد. + +توافق‌نامه‌های همکاری اضافی - که اغلب به آن توافق‌نامه مجوز مشارکت‌کننده (CLA) گفته می‌شود - برای نگهدارندگان پروژه می‌تواند کارهای مدیریتی ایجاد کند. اینکه توافق‌نامه چه مقدار کار اضافه می‌کند به پروژه و نحوۀ اجرای آن بستگی دارد. یک توافق‌نامه‌ی ساده ممکن است نیاز داشته باشد که مشارکت‌کنندگان با یک کلیک تأیید کنند که از حقوق لازم برای مشارکت در مجوز پروژه متن باز برخوردار هستند. یک توافق‌نامه‌ی پیچیده‌تر ممکن است نیاز به بررسی قانونی داشته باشد و مربوط به کارفرمایان مشارکت‌کنندگان شود. + +همچنین، با افزودن «تشریفات اداری» که به عقیدۀ برخی غیرضروری می‌باشد و فهم آن سخت یا ناعادلانه است (وقتی که ذی‌نفعان توافق‌نامه حقوق و مزایای بیشتری از مشارکت‌کنندگان یا عموم مردمی که کارهایی در پروژه‌ی متن باز انجام می‌دهند، به دست می‌آورند)؛ به همین خاطر ممکن است یک توافق‌نامه‌ی همکاری اضافی غیرمنصفانه نسبت به انجمن پروژه تلقی شود. + + + +برخی از شرایطی که ممکن است بخواهید یک توافق‌نامه‌ی همکاری اضافی را برای پروژۀ خود در نظر بگیرید، شامل این موارد می‌شود: + +* شما یا وکیل‌هایتان از توسعه‌دهندگان بخواهید نشان دهند هر تعهدی که روی آن کار می‌کنند مجاز است. الزام [گواهی مبدا توسعه‌دهنده](https://developercertificate.org/) برای این است که چه تعداد پروژه به این صورت هستند. به عنوان مثال، انجمن «Node.js» به جای «توافق‌نامۀ مجوز مشارکت‌کننده» قبلی خود از «گواهی مبدا توسعه‌دهنده» استفاده می کند. راهکار ساده برای اجرای خودکار «گواهی مبدا توسعه‌دهنده» در منبع (repository) شما، «ربات گواهی مبدا توسعه‌دهنده» است. + +* اگر پروژه شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache](https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است. + +* پروژۀ شما تحت مجوز کپی‌لفت باشد ، اما شما همچنین باید نسخه‌ای اختصاصی از پروژه را توزیع و پخش کنید. هر مشارکت‌کننده باید به شما حق نشر اختصاص دهد یا به شما (اما نه به عموم) مجوز اختیاری بدهد. [توافق‌نامۀ همکاری MongoDB](https://www.mongodb.com/legal/contributor-agreement) نمونه‌ای از این نوع توافق‌نامه است. + +* ممکن باشد پروژۀ شما در طول عمر خود مجوزهایش را تغییر بدهد و بخواهید مشارکت‌کنندگان از قبل با چنین تغییراتی موافقت کنند. + +اگر در پروژۀ خود نیازی به استفاده از توافق‌نامه‌های همکاری اضافی داشته باشید، استفاده از توافق‌نامه‌های یکپارچه‌سازی مانند [توافق‌نامۀ مجوز مشارکت‌کننده](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/) یک راهنمای جامع برای شناخت نشان‌های تجاری در زمینه‌ی پروژه‌های متن باز و رایگان است. + +* **حریم خصوصی:** آیا پروژۀ شما اطلاعات مربوط به کاربران را جمع‌آوری می‌کند؟ سرورهای شرکت، مکالمات را ضبط می‌کند؟ تیم حقوقی می‌تواند به شما در زمینه‌ی پیروی از سیاست‌های شرکت و آیین‌نامه‌های خارجی کمک کند. + +اگر دارید اولین پروژه متن باز شرکت خود را منتشر می‌کنید، رعایت موارد فوق کافی است (اما نگران نباشید، اکثر پروژه‌ها نگرانی‌های اساسی خاصی نباید ایجاد کنند). + +در بلند مدت، تیم حقوقی می‌تواند کمک بیشتری به شرکت کند تا از مشارکت خود در پروژه‌های متن باز بهره‌ی بیشتری ببرد و در امان بماند: + +* **سیاست های مربوط به مشارکت کارمندان:** سیاست‌هایی را تدوین کنید که مشخص سازد کارمندان شما در پروژه‌های متن باز چه نوع مشارکتی داشته باشند. داشتن سیاست‌های مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آن‌ها در مشارکت هرچه بهتر در پروژه‌های متن باز شرکت می‌شود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغت‌شان. یک مثال خوب، [مدل‌های استاندارد و سیاست‌های همکاری در پروژه‌های متن باز](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/fa/maintaining-balance-for-open-source-maintainers.md b/_articles/fa/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..ac71deba8a4 --- /dev/null +++ b/_articles/fa/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,238 @@ +--- +lang: fa +title: حفظ تعادل برای نگهدارندگان پروژه‌های متن‌باز +description: نکاتی برای مراقبت از خود و جلوگیری از فرسودگی به عنوان یک نگهدارنده +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +با رشد محبوبیت یک پروژه متن‌باز، مهم است که مرزهای مشخصی تعیین کنید تا به حفظ تعادل و ماندن در وضعیت آماده و پربازده برای مدت طولانی کمک کنید. + +برای کسب دیدگاه‌هایی از تجربیات نگهدارندگان و استراتژی‌های آن‌ها برای یافتن تعادل، ما یک کارگاه با ۴۰ عضو از جامعه نگهدارندگان برگزار کردیم که به ما این امکان را داد تا از تجربیات مستقیم آن‌ها در مورد فرسودگی شغلی در متن‌باز و روش‌هایی که به آن‌ها کمک کرده تعادل کار خود را حفظ کنند، بیاموزیم. اینجاست که مفهوم «بوم‌شناسی شخصی» وارد عمل می‌شود. + +پس بوم‌شناسی شخصی چیست؟ همانطور که توسط موسسه رهبری راکوود توضیح داده شده، این شامل «حفظ تعادل، سرعت و کارایی برای پایداری انرژی در طول عمر» است. این چارچوب به ما کمک کرد تا گفتگوهایمان را به گونه‌ای شکل دهیم که نگهدارندگان بتوانند اقدامات و مشارکت‌های خود را به عنوان بخشی از یک اکوسیستم بزرگ‌تر که با گذشت زمان تکامل می‌یابد، بشناسند. فرسودگی شغلی، یک سندرم ناشی از استرس مزمن محل کار که توسط [سازمان جهانی بهداشت](https://icd.who.int/browse/2025-01/foundation/en#129180281) تعریف شده است، در میان نگهدارندگان غیرمعمول نیست. این اغلب منجر به از دست دادن انگیزه، عدم توانایی در تمرکز و عدم همدلی برای مشارکت‌کنندگان و جامعه‌ای که با آن‌ها کار می‌کنید می‌شود. + + + +با در آغوش گرفتن مفهوم بوم‌شناسی شخصی، نگهدارندگان می‌توانند به طور پیشگیرانه از فرسودگی جلوگیری کنند، مراقبت از خود را در اولویت قرار دهند و حس تعادل را حفظ کنند تا کار خود را به نحوه احسن انجام دهند. + +## نکاتی برای مراقبت از خود و جلوگیری از فرسودگی به عنوان یک نگهدارنده: + +### انگیزه‌های خود را برای کار در متن‌باز شناسایی کنید + +زمانی را صرف کنید تا در مورد اینکه چه بخش‌هایی از نگهداری پروزه ها متن باز به شما انرژی می‌دهد، فکر کنید. درک انگیزه‌هایتان می‌تواند به شما کمک کند تا +کارها را به گونه‌ای اولویت‌بندی کنید که شما را آماده چالش‌های جدید نگه دارد. +خواه بازخورد مثبت کاربران باشد، لذت همکاری و معاشرت با جامعه متن باز یا رضایت از کدنویسی در هر صورت شناخت انگیزه می تواند به تمرکز شما کمک کند. + +### درباره عواملی که باعث از دست دادن تعادل و استرس شما می‌شوند تأمل کنید + +درک اینکه چه عاملی باعث فرسودگی می‌شود، مهم است. در ادامه به برخی از دلایل رایج در میان نگهدارندگان متن‌باز اشاره شده است: + +* **کمبود بازخورد مثبت:** کاربران در بیشتر موارد تنها نارضایتی خود را اطلاع میدهند اگر همه چیز خوب پیش برود، آن‌ها معمولاً سکوت می‌کنند. دیدن لیستی از مشکلات گزارش شده در حال رشد بدون, بازخورد مثبت می تواند دلسرد کننده باشد. اما باید توچه داشت که توسعه و نگهداری شما باعث پیشرفت پروژه میشود. + + + +* **ناتوانی در 'نه' گفتن:** بر عهده گرفتن مسئولیت های بیشتر از ظرفیت در یک پروژه منبع باز می تواند آسان باشد. چه از طرف کاربران باشد، چه مشارکت کنندگان یا سایر نگهبانان - ما همیشه نمی توانیم انتظارات همه را برآورده کنیم + + + +* **کار انفرادی :** نگهدارنده بودن می تواند فوق العاده باعث تنهایی باشد. حتی اگر با گروهی از نگهدارندگان کار می کنید، چند سال گذشته برای تشکیل تیم های توزیع شده حضوری بسیار دشوار بوده است. + + + +* **نبود زمان و منابع کافی:** این مورد به ویژه در مورد نگهدارندگان دواوطلب که باید زمان آزاد خود را فدای کار بر روی یک پروژه کنند، صادق است. + + + +* **تعارض منافع:** منبع باز پر از گروه هایی با انگیزه های مختلف است که پیمایش در آنها ممکن است دشوار باشد. اگر برای کار منبع باز پول دریافت می کنید، علایق کارفرمای شما ممکن است گاهی در تضاد با جامعه باشد. + + + +### مراقب علائم فرسودگی شغلی باشید + +آیا می توانید سرعت خود را برای 10 هفته حفظ کنید؟ 10 ماه؟ 10 سال؟ + +ابزارهایی وجود دارند که می توانند به شما کمک کنند تا روی سرعت فعلی خود فکر کنید و ببینید آیا اصلاحاتی وجود دارد که بتوانید انجام دهید. +برای نمونه ابزار +\ +[Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) +\ +ساخته شده توسط +\ +[@shaunagm](https://github.com/shaunagm). +\ +برخی از نگهدارندگان نیز از فناوری پوشیدنی برای ردیابی معیارهایی مانند کیفیت خواب و تغییرات ضربان قلب (هر دو با استرس مرتبط هستند) استفاده می کنند. + + + +### برای ادامه حفظ خود و جامعه خود به چه چیزی نیاز دارید؟ + +جواب این سوال برای هر نگهدارنده متفاوت به نظر می رسد و بسته به فاز زندگی شما و سایر عوامل خارجی تغییر می کند. اما در ادامه چند موضوع ذکر میشود: + +* * **به جامعه تکیه کنید:** تفویض اختیار و یافتن مشارکت کنندگان می تواند بار کاری را کاهش دهد. داشتن چندین نقطه تماس برای یک پروژه می تواند به شما کمک کند بدون نگرانی از کار دست بکشید. با سایر نگهدارندگان و جامعه گسترده‌تر در گروه‌هایی مانند [Maintainer Community](http://maintainers.github.com/) ارتباط برقرار کنید گروه مذکور می‌تواند منبع خوبی برای پشتیبانی و یادگیری همتایان باشد.. + +همچنین می‌توانید به دنبال راه‌هایی برای تعامل با جامعه کاربران باشید، بنابراین می‌توانید به طور منظم بازخورد شنیده و تأثیر کار منبع باز خود را درک کنید. + +* **Explore funding:** فرقی ندارد که به دنبال مقداری پول پیتزا باشید یا می‌خواهید به صورت تمام وقت متن‌باز استفاده کنید، منابع زیادی برای کمک به شما وجود دارد! به عنوان اولین قدم، [GitHub Sponsors](https://github.com/sponsors) را فعال کنید تا به دیگران اجازه دهید از کار منبع باز شما حمایت مالی کنند. اگر به فکر پرش به تمام وقت هستید، برای دور بعدی [GitHub Accelerator](http://accelerator.github.com/) اقدام کنید. + + + +* **استفاده از ابزارها:** استفاده از ابزار هایی برای اتوماتیک کردن برخی از فرایند ها و صرف زمان صرفه جویی شده در توسعه با معنا تر. ابزارهایی مانند [GitHub Copilot](https://github.com/features/copilot/) و [GitHub Actions](https://github.com/features/actions). + + + +* **Rest and recharge:** برای سرگرمی ها و علایق خود در خارج از منبع باز وقت بگذارید. آخر هفته ها را برای استراحت و تجدید قوا استراحت کنید – و [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) خود را طوری تنظیم کنید که در دسترس بودن شما را منعکس کند! یک خواب خوب شبانه می تواند تفاوت بزرگی در توانایی شما برای حفظ تلاش هایتان در طولانی مدت ایجاد کند. + +اگر جنبه های خاصی از پروژه خود را به خصوص لذت بخش می دانید، سعی کنید ساختار کار خود را طوری تنظیم کنید که بتوانید آن را در طول روز تجربه کنید. + + + +* **تغین حدود:** شما نمی توانید به هر درخواستی بله بگویید. این می تواند به سادگی بگوید: "در حال حاضر نمی توانم به آن برسم و در آینده برنامه ای ندارم" یا فهرست کردن آنچه که علاقه مند به انجام و یا انجام ندادن آن در README هستید. برای مثال، می‌توانید بگویید: «من فقط پول رکوئست هایی را ادغام می‌کنم که دلایل ایجاد آنها را به وضوح ذکر کرده‌اند» یا «من فقط مسائل را در روزهای پنج‌شنبه از ساعت 6 تا 7 بعد از ظهر بررسی می‌کنم.» این انتظارات را برای دیگران ایجاد می‌کند و چیزی به شما می‌دهد تا برای کمک به کاهش تنش‌ها از سوی مشارکت‌کنندگان یا کاربران در زمان‌های دیگر، به آن اشاره کنید. + + + +یاد بگیرید که در از بین بردن رفتار سمی و تعاملات منفی قاطع باشید. اشکالی ندارد اگر در چیزهایی که برایتان اهمیتی ندارید انرژی صرف نکنید. + + + + + +به یاد داشته باشید، بوم شناسی شخصی یک تمرین مداوم است که با ادامه داشتن در سفر منبع باز شما تکامل می یابد. با اولویت دادن به خودمراقبتی و حفظ حس تعادل، می‌توانید به طور مؤثر و پایدار به جامعه منبع باز کمک کنید و از رفاه و موفقیت پروژه‌هایتان در درازمدت اطمینان حاصل کنید. + +## منابع مرتبط + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid +* [Governing Open](https://governingopen.com/) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series + +## مشارکت کنندگان + +با تشکر فراوان از همه نگهدارندگان که تجربیات و نکات خود را برای این راهنما با ما به اشتراک گذاشتند! + +نگارنده: +[@abbycabs](https://github.com/abbycabs) + +مترجم: +[@mostafa](https://github.com/mostafayavari94) + +مشارکت کنندگان: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md new file mode 100644 index 00000000000..ea7c2da1f25 --- /dev/null +++ b/_articles/fa/metrics.md @@ -0,0 +1,124 @@ +--- +lang: fa +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 stars](https://help.github.com/articles/about-stars/) هم می‌تواند به صورت معیاری برای محبوبیت عمل کند.اگرچه «GitHub stars» لزوماً با تعداد دانلودها و استفاده از محتوا ارتباط مستقیمی ندارد، اما این قسمت می‌تواند به شما بگوید که چه تعدادی از آدم‌ها متوجه پروژۀ شما شده‌اند.. + +همچنین شاید بخواهید قابلیت کشف شدن (شناخته‌ شدن) را در [بخش‌های مشخصی ردیابی کنید](https://opensource.com/business/16/6/pirate-metrics): به عنوان مثال، «Google PageRank»، ترافیک رجوعی به وب‌سایت پروژۀ شما، یا مراجعات از سایر پروژه‌های متن‌باز یا سایر وب‌سایت‌ها. + +## استفاده + +مردم پروژۀ شما را در این دنیای عجیب‌غریبی که اینترنت می‌نامیم، پیدا می‌کنند. در بهترین حالت، وقتی پروژۀ شما را ببینند، به آن مشتاق می‌شوند و می‌خواهند کاری انجام دهند. دومین سوالی که باید از خود بپرسید این است که: _آیا مردم از این پروژه استفاده می‌کنند؟_ + +اگر از یک برنامۀ مدیریت پکیج (package manager) مانند «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» قرار گیرد، احتمالاً جهشی در میزان کشف (ترافیک) اما با نرخ گرایش پایینی را مشاهده خواهید کرد؛ زیرا در 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) + +* **مشارکت‌کنندگان تازه‌کار، عادی، همیشگی:** کمک می‌کند تا پیگیری کنید که آیا مشارکت‌کنندگان جدیدی دریافت می‌کنید یا خیر. (مشارکت‌کنندگان عادی، مشارکت‌کنندگانی با تعهدات کم هستند که البته تعریف «تعهدات کم» به خود شما بستگی دارد و می‌تواند یک یا پنج یا کمتر باشد) بدون مشارکت‌کنندگان جدید، انجمن پروژه راکد و کم‌رونق می‌شود. + +* **تعداد مسائل در جریان و درخواست‌های باز pull:** اگر بیش از حد زیاد شوند، ممکن است در اولویت‌بندی مسائل و بررسی کدها به کمک نیاز داشته باشید. + +* **تعداد مسائل باز شده (open issued) و درخواست های باز شدۀ pull:** مسائل باز شده، یعنی کسی به اندازه کافی به پروژۀ شما اهمیت بدهد تا مسئله‌ای را باز کند. اگر این تعداد با گذشت زمان افزایش یابد، نشان‌دهندۀ این است که مردم به پروژۀ شما علاقه‌مند هستند. + +* **انواع مشارکت‌ها:** به عنوان مثال، نوع تعهدها، رفع اشتباهات یا اشکالات یا اظهار نظر در مورد یک موضوع. + + + +## فعالیت‌های شخص نگهدارنده + +نگهدارنده‌هایی که پاسخگو نیستند به نقطۀ ضعف پروژه‌های متن باز تبدیل می‌شوند. اگر کسی مشارکتی از خود به جای بگذارد اما هرگز از یک نگهدارنده پاسخی دریافت نکند، ممکن است احساس دلسردی کرده و آنجا را ترک کند. + +[تحقیقات که در Mozilla شکل گرفت](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) نشان می‌دهد که پاسخگو بودن نگهدارنده عاملی حیاتی در تشویق به مشارکت‌های بیشتر است. + +در نظر بگیرید که چه مدت طول می‌کشد تا شما (یا نگهدارنده‌ای دیگر) به مشارکت‌ها پاسخ دهید، خواه مسئله‌ای باشد یا درخواست pull. پاسخگو بودن نیاز به اقدام خاصی ندارد. می‌تواند به این سادگی باشد: _«ممنون از درخواست شما! در عرض یک هفته آن را بررسی می‌کنم.»_ + +همچنین می‌توانید مدت زمانی که برای تکمیل مراحل مختلف فرآیند مشارکت لازم است را اندازه بگیرید، همچون: + +* متوسط زمان باز ماندن مسئله +* بسته شدن مسئله توسط روابط عمومی (PR) +* بسته شدن مسائل قدیمی +* متوسط زمان ادغام کردن درخواست‌های pull + +## از آمار 📊 برای درک مردم استفاده کنید + +درک معیارها (استانداردها) به شما کمک می‌کند تا پروژۀ متن باز فعال و رو به‌ رشدی داشته باشید. حتی اگر هم تمامی معیارها را پیگیری نمی‌کنید، از چارچوب بالا استفاده کنید تا توجه خود را به نوع رفتاری که به پیشرفت پروژه کمک می‌کند متمرکز کنید. diff --git a/_articles/fa/security-best-practices-for-your-project.md b/_articles/fa/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..929432f5134 --- /dev/null +++ b/_articles/fa/security-best-practices-for-your-project.md @@ -0,0 +1,83 @@ +--- +lang: fa +title: بهترین روش‌های امنیتی برای پروژه شما +description: آینده پروژه خود را با ایجاد اعتماد از طریق روش‌های امنیتی ضروری تقویت کنید - از MFA و اسکن کد گرفته تا مدیریت ایمن وابستگی‌ها و گزارش‌دهی آسیب‌پذیری خصوصی. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +گذشته از باگ‌ها و قابلیت‌های جدید، ماندگاری یک پروژه نه تنها به مفید بودن آن، بلکه به اعتمادی که از کاربرانش کسب می‌کند بستگی دارد. اقدامات امنیتی قوی برای زنده نگه داشتن این اعتماد مهم هستند. در اینجا برخی از اقدامات مهمی که می‌توانید برای بهبود چشمگیر امنیت پروژه خود انجام دهید آورده شده است. + +## اطمینان حاصل کنید که همه مشارکت‌کنندگان دارای دسترسی، احراز هویت چندعاملی (MFA) را فعال کرده‌اند + +### یک بازیگر مخرب که موفق به جعل هویت یک مشارکت کننده دارای دسترسی در پروژه شما شود، خسارات فاجعه‌باری به بار خواهد آورد. + +پس از به دست آوردن دسترسی privileged، این بازیگر می‌تواند کد شما را تغییر دهد تا اقدامات ناخواسته انجام دهد (مانند استخراج ارز دیجیتال)، یا می‌تواند بدافزار را به زیرساخت کاربران شما توزیع کند، یا می‌تواند به مخازن کد خصوصی دسترسی یابد تا مالکیت فکری و داده‌های حساس، از جمله اعتبارنامه‌های سرویس‌های دیگر را سرقت کند. + +MFA یک لایه امنیتی اضافی در برابر تصاحب حساب ارائه می‌دهد. پس از فعال‌سازی، باید با نام کاربری و رمز عبور خود وارد شوید و شکل دیگری از احراز هویت را ارائه دهید که فقط شما آن را می‌دانید یا به آن دسترسی دارید. + +## کد خود را به عنوان بخشی از گردش کار توسعه خود ایمن کنید + +### رفع آسیب‌پذیری‌های امنیتی در کد شما، در صورت تشخیص زودهنگام در فرآیند، بسیار کم‌هزینه‌تر از زمانی است که در محیط production استفاده می‌شوند. + +از یک ابزار Static Application Security Testing (SAST) برای تشخیص آسیب‌پذیری‌های امنیتی در کد خود استفاده کنید. این ابزارها در سطح کد عمل می‌کنند و به محیط اجرایی نیاز ندارند، و بنابراین می‌توانند در مراحل اولیه فرآیند اجرا شوند و به طور یکپارچه در گردش کار توسعه معمول شما، در طول مرحله build یا مرور کد، ادغام شوند. + +این مانند داشتن یک متخصص ماهر است که مخزن کد شما را بررسی می‌کند و به شما کمک می‌کند آسیب‌پذیری‌های امنیتی رایجی که ممکن است در حین کدنویسی در معرض دید باشند را پیدا کنید. + +چگونه ابزار SAST خود را انتخاب کنیم؟ + +* مجوز را بررسی کنید: برخی ابزارها برای پروژه‌های متن‌باز رایگان هستند. برای مثال GitHub CodeQL یا SemGrep. +* پوشش زبان(های) برنامه‌نویسی خود را بررسی کنید. +* ابزاری را انتخاب کنید که به راحتی با ابزارها و فرآیندهای موجود شما ادغام می‌شود. برای مثال، بهتر است که هشدارها به عنوان بخشی از فرآیند و ابزار مرور کد موجود شما در دسترس باشند، نه اینکه برای مشاهده آنها به ابزار دیگری مراجعه کنید. +* مراقب هشدارهای کاذب (False Positives) باشید! شما نمی‌خواهید ابزار بدون دلیل شما را کند کند! +* ویژگی‌ها را بررسی کنید: برخی ابزارها بسیار قدرتمند هستند و می‌توانند ردیابی نشت داده (Taint Tracking) انجام دهند (مثال: GitHub CodeQL)، برخی پیشنهادات رفع مشکل تولید شده توسط هوش مصنوعی ارائه می‌دهند، و برخی نوشتن کوئری‌های سفارشی را آسان‌تر می‌کنند (مثال: SemGrep). + +## اسرار خود را به اشتراک نگذارید + +### داده‌های حساس، مانند کلیدهای API، توکن‌ها و رمزهای عبور، گاهی اوقات ممکن است به طور تصادفی در مخزن شما commit شوند. + +این سناریو را تصور کنید: شما maintainer یک پروژه متن‌باز محبوب با مشارکت توسعه‌دهندگان از سراسر جهان هستید. یک روز، یک مشارکت‌کننده ناخواسته برخی از کلیدهای API یک سرویس شخص ثالث را در مخزن commit می‌کند. روزها بعد، شخصی این کلیدها را پیدا می‌کند و از آنها برای دسترسی غیرمجاز به سرویس استفاده می‌کند. سرویس به خطر می‌افتد، کاربران پروژه شما downtime را تجربه می‌کنند و اعتبار پروژه شما آسیب می‌بیند. به عنوان maintainer، اکنون با وظایف دلهره‌آور لغو اسرار به خطر افتاده، بررسی اقدامات مخربانه‌ای که مهاجم می‌توانسته با این راز انجام دهد، اطلاع‌رسانی به کاربران affected و اجرای وصله‌ها روبرو هستید. + +برای جلوگیری از چنین حوادثی، راه‌حل‌های "اسکن اسرار" (secret scanning) وجود دارند که به شما در تشخیص این اسرار در کدتان کمک می‌کنند. برخی ابزارها مانند GitHub Secret Scanning و Trufflehog از Truffle Security اساساً از push شدن آنها به شاخه‌های remote جلوگیری می‌کنند، و برخی ابزارها به طور خودکار برخی اسرار را برای شما لغو می‌کنند. + +## وابستگی‌های خود را بررسی و به‌روز کنید + +### وابستگی‌های موجود در پروژه شما می‌توانند دارای آسیب‌پذیری‌هایی باشند که امنیت پروژه شما را به خطر می‌اندازند. به‌روز نگه داشتن دستی وابستگی‌ها می‌تواند کاری وقت‌گیر باشد. + +این را تصور کنید: پروژه‌ای که بر اساس بنیان محکم یک کتابخانه پرکاربرد ساخته شده است. این کتابخانه بعداً یک مشکل امنیتی بزرگ پیدا می‌کند، اما افرادی که برنامه را با استفاده از آن ساخته‌اند از آن اطلاعی ندارند. داده‌های حساس کاربر در معرض دید قرار می‌گیرند وقتی یک مهاجم از این ضعف سوء استفاده کرده و آنها را می‌دزدد. این یک مورد نظری نیست. این دقیقاً چیزی است که برای Equifax در سال ۲۰۱۷ اتفاق افتاد: آنها پس از اعلام تشخیص یک آسیب‌پذیری شدید، وابستگی Apache Struts خود را به‌روز نکردند. از آن سوء استفاده شد و نقض داده‌های معروف Equifax 144 میلیون کاربر را تحت تاثیر قرار داد. + +برای جلوگیری از چنین سناریوهایی، ابزارهای Software Composition Analysis (SCA) مانند Dependabot و Renovate به طور خودکار وابستگی‌های شما را برای یافتن آسیب‌پذیری‌های شناخته شده منتشر شده در پایگاه‌های داده عمومی مانند NVD یا GitHub Advisory Database بررسی می‌کنند و سپس pull requestهایی برای به‌روزرسانی آنها به نسخه‌های ایمن ایجاد می‌کنند. به‌روز ماندن با آخرین نسخه‌های ایمن وابستگی‌ها، پروژه شما را در برابر خطرات بالقوه محافظت می‌کند. + +## از تغییرات ناخواسته با شاخه‌های محافظت شده (protected branches) جلوگیری کنید + +### دسترسی بدون محدودیت به شاخه‌های اصلی شما می‌تواند منجر به تغییرات تصادفی یا مخرب شود که ممکن است آسیب‌پذیری‌ها را معرفی کرده یا ثبات پروژه شما را مختل کنند. + +یک مشارکت‌کننده جدید دسترسی write به شاخه اصلی دریافت می‌کند و به طور تصادفی تغییراتی را که تست نشده‌اند push می‌کند. یک نقص امنیتی فاجعه‌بار سپس آشکار می‌شود، به لطف آخرین تغییرات. برای جلوگیری از چنین مشکلاتی، قوانین محافظت از شاخه (branch protection rules) تضمین می‌کنند که تغییرات نمی‌توانند به شاخه‌های مهم push یا merge شوند مگر اینکه ابتدا مرور شده و بررسی‌های وضعیت مشخص شده را پشت سر بگذارند. با این اقدام اضافی در امان‌تر و در موقعیت بهتری هستید و هر بار کیفیت عالی را تضمین می‌کنید. + +## یک مکانیزم دریافت برای گزارش‌دهی آسیب‌پذیری راه‌اندازی کنید + +### این یک روش خوب است که گزارش باگ را برای کاربران خود آسان کنید، اما سوال بزرگ این است: وقتی این باگ تاثیر امنیتی دارد، چگونه می‌توانند آن را به طور ایمن به شما گزارش دهند بدون اینکه شما را در معرض هدف هکرهای مخرب قرار دهند؟ + +این را تصور کنید: یک محقق امنیتی یک آسیب‌پذیری در پروژه شما کشف می‌کند اما راه روشن یا ایمنی برای گزارش آن پیدا نمی‌کند. بدون یک فرآیند مشخص شده، ممکن است یک issue عمومی ایجاد کند یا در مورد آن به طور آشکار در رسانه‌های اجتماعی بحث کند. حتی اگر خوش‌نیت باشند و یک وصله ارائه دهند، اگر آن را با یک pull request عمومی انجام دهند، دیگران قبل از merge شدن آن را خواهند دید! این افشای عمومی، آسیب‌پذیری را قبل از اینکه شما فرصت رسیدگی به آن را داشته باشید در معرض دید بازیگران مخرب قرار می‌دهد و به طور بالقوه منجر به یک اکسپلویت zero-day شده و پروژه شما و کاربرانش را مورد حمله قرار می‌دهد. + +### خط‌مشی امنیتی (Security Policy) + +برای اجتناب از این، یک خط‌مشی امنیتی منتشر کنید. یک خط‌مشی امنیتی، که در یک فایل `SECURITY.md` تعریف می‌شود، مراحل گزارش نگرانی‌های امنیتی را به تفصیل شرح می‌دهد، یک فرآیند شفاف برای افشای هماهنگ شده ایجاد می‌کند و مسئولیت‌های تیم پروژه را برای رسیدگی به issues گزارش شده تعیین می‌کند. این خط‌مشی امنیتی می‌تواند به سادگی این باشد: "لطفاً جزئیات را در یک issue یا PR عمومی منتشر نکنید، یک ایمیل خصوصی به ما به آدرس security@example.com ارسال کنید"، اما می‌تواند حاوی جزئیات دیگری نیز باشد، مانند زمانی که باید انتظار دریافت پاسخ از شما را داشته باشند. هر چیزی که می‌تواند به اثربخشی و کارایی فرآیند افشا کمک کند. + +### گزارش‌دهی خصوصی آسیب‌پذیری (Private Vulnerability Reporting) + +در برخی پلتفرم‌ها، می‌توانید فرآیند مدیریت آسیب‌پذیری خود را از دریافت تا انتشار، با استفاده از issues خصوصی، ساده‌تر و تقویت کنید. در GitLab، این کار را می‌توان با issues خصوصی انجام داد. در GitHub، این کار گزارش‌دهی خصوصی آسیب‌پذیری (PVR) نامیده می‌شود. PVR به maintainers امکان می‌دهد گزارش‌های آسیب‌پذیری را دریافت کرده و رسیدگی کنند، همه در داخل پلتفرم GitHub. GitHub به طور خودکار یک fork خصوصی برای نوشتن وصله‌ها و یک security advisory پیش‌نویس ایجاد می‌کند. همه اینها محرمانه باقی می‌مانند تا زمانی که شما تصمیم به افشای issues و انتشار وصله‌ها بگیرید. برای تکمیل فرآیند، security advisoryها منتشر می‌شوند و از طریق ابزار SCA به همه کاربران شما اطلاع رسانی کرده و آنها را محافظت می‌کنند. + +## نتیجه‌گیری: چند قدم برای شما، یک بهبود بزرگ برای کاربران شما + +این چند قدم ممکن است برای شما آسان یا ابتدایی به نظر برسند، اما راه زیادی را برای ایمن‌تر کردن پروژه شما برای کاربرانش طی می‌کنند، زیرا در برابر رایج‌ترین مسائل محافظت ارائه می‌دهند. + +## مشارکت‌کنندگان + +### با تشکر از همه maintainerهایی که تجربیات و نکات خود را برای این راهنما با ما به اشتراک گذاشتند! + +این راهنما توسط [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) نوشته شده است با مشارکت: + +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + بسیاری دیگر! diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md new file mode 100644 index 00000000000..e2f4a891ccc --- /dev/null +++ b/_articles/fa/starting-a-project.md @@ -0,0 +1,357 @@ +--- +lang: fa +title: شروع یک پروژه‌ی متن باز / منبع باز / اوپن سورس +description: در این مقاله چیزهای زیادی درباره‌ی دنیای متن بازها می‌آموزید و آماده‌ی انتشار پروژه‌ی متن باز خودتان می‌شوید. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## چیستی و چرایی متن باز + +اگر به این فکر میکنید که پروژه‌ی متن باز خودتان را شروع کنید؟ به شما تبریک می‌گوییم! دنیا قدردان کمک و مشارکت شماست. اجازه دهید در ادامه درباره پروژه‌های متن باز بیشتر صحبت کنیم و ببینیم چرا مردم پروژه‌هایشان را متن باز می‌کنند. + +### متن باز به چه معناست؟ + +زمانی که یک پروژه متن باز یا اوپن سورس باشد، **هر کسی می‌تواند و اجازه دارد به صورت رایگان از آن استفاده، مطالعه، ویرایش و برای هر هدفی که می‌خواهد، توزیع کند**. این اجازه‌ها در [لایسنس متن باز](https://opensource.org/licenses) قید شده و قابل اجراست + +پروژه‌های متن باز قدرتمند هستند، چون موانعی که در اختیارات و مشارکت‌ها دیده می‌شود را کاهش و به افراد اجازه می‌دهد پروژه‌های خود را به سرعت گستردش و بهبود دهند. یکی دیگر از دلایل قدرتمند بودن متن بازها این است که پتانسیل کنترل محاسبه را بسته به منابع محدود به کاربران می‌دهد. اگر بخواهیم برای روشن شدن مطلب نمونه‌ای بیاوریم، می‌توانیم به کسب‌وکارهایی اشاره کنیم که به جای تکیه بر منابع محصور و محدود محصولات انحصاری فروشنده‌های نرم‌افزار، از نرم‌افزارهای متن بازی استفاده می‌کنند که به آن‌ها اجازه می‌دهد شخصی را استخدام کنند تا آن نرم‌افزار را برای آن‌ها شخصی‌سازی یا بهینه کند. + +_نرم‌افزارهای رایگان_ همچنین به پروژه‌های متن باز منسوب می‌شود. گاهی هم ممکن است برنامه‌هایی ببینید که [ترکیبی](https://en.wikipedia.org/wiki/Free_and_open-source_software) از اصلاحات «نرم‌افزار متن باز و رایگان» (FOSS) یا «نرم‌افزار متن باز، آزاد و رایگان» (FLOSS) استفاده می‌کنند. خب، باید بگوییم که کلمه‌ی _Free_ (رایگان) و _libre_ (آزاد / رایگان) هر دو به معنای آزادی در استفاده و دسترسی اطلاق می‌شود، [نه قیمت آن](#آیا-پروژهای-متن-باز-مجانی--رایگان-هستند) + +### چرا مردم پروژه‌های‌شان را متن باز می‌کنند؟ + + + +[دلایل زیادی وجود دارد](https://ben.balter.com/2015/11/23/why-open-source/) که یک شخص یا سازمان بخواهد پروژه‌های خود را متن باز کند. این دلایل عبارتند از: + +* **مشارکت:** هر فردی در دنیا می‌تواند پروژه‌های متن باز را تغییر دهد و در ویرایش آن مشارکت داشته باشد. به عنوان نمونه، Exercism که به عنوان یک پلتفرم متن باز برای تمرین برنامه‌نویسی شناخته می‌شود، با مشارکت افراد مختلف تا به الان بیش از 350 توزیع و ویرایش داشته است. + +* **اقتباس و تغییر مجدد:** هر فردی تقریباً با هر هدفی می‌تواند از پروژه‌های متن باز استفاده کند. افراد حتی می‌توانند از یک پروژه، پروژه‌های دیگری به وجود بیاورند. به عنوان مثال می‌توانیم به [وردپرس](https://github.com/WordPress) اشاره کنیم که از پروژه موجودی به نام [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) منشعب شده است. + +* **شفافیت:** هرکسی می‌تواند خطاها و تناقض پروژه‌های متن باز را بازرسی کند. از این رو، شفافیت برای دولت‌هایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرم‌افزار امنیتی مانند [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 قرار دارد، قرار دادن فایل‌های فوق به همراه نام فایل‌های توصیه‌شده در پوشه ریشه (root) می‌تواند به GitHub کمک کند تا آن‌ها را به صورت خودکار به مخاطبان‌تان شناسایی کند و نمایش دهد. + +### انتخاب لایسنس یا مجوز + +لایسنسِ یا مجوز یک پروژه‌ی متن باز به دیگران ضمانت می‌دهد از پروژه‌ی متن باز استفاده، کپی، ویرایش و بدون هیچ عواقبی در آن مشارکت کنند. لایسنس همچنین از شما در برابر موقعیت‌های سخت قانونی محافظت می‌کند. **زمانی که می‌خواهید پروژه‌ی متن بازتان را منتشر کنید، حتما لایسنس آن را هم ضمیمه کنید**. + +کارهای ادارای و حقوقی برای گرفتن لایسنس هیچ جذابیتی ندارد، اما خبر خوب اینجاست که می‌توانید لایسنس‌های موجود و در دسترس را که از قبل توسط دیگران تدوین شده را در repository (مخزن) خود کپی و پیست کنید. برای محافظت از تلاشی که برای متن باز کردن پروژه‌تان انجام دادید، این کار تنها یک دقیقه وقت شما را می‌گیرد. + +[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) و [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) جزء محبوب‌ترین لایسنس‌های متن باز هستند. هرچند، لایسنس‌های دیگری هم وجود دارد که می‌توانید از آن‌ها استفاده کنید. + +زمانی که پروژه‌ی جدیدی در GitHub ایجاد می‌کنید، به شما امکان انتخاب لایسنس داده می‌شود. انتخاب کردن لایسنس باعث می‌شود GitHub پروژه‌ی شما را متن باز نشان دهد. + +![انتخاب مجوز](/assets/images/starting-a-project/repository-license-picker.png) + +در ادامه‌ی مقاله، سایر سوالات و نگرانی‌هایتان درباره‌ی [جنبه‌های قانونی](../legal/) مدیریت پروژه‌ی متن بازتان را بررسی خواهیم کرد. + +### نوشتن فایل «README» (فایلی که توضیحات پروژه در آن آورده می‌شود) + +فایل README اطلاعات بیشتری نسبت به این دارد که نحوه‌ی استفاده از پروژه‌تان را به کاربر توضیح دهد. این فایل همچنین توضیح می‌دهد که پروژه‌ی شما چه اهمیتی دارد و کاربران‌تان با این پروژه چه کارهای می‌توانند انجام دهند. + +سعی کنید در فایل README خودتان به سوالات زیر پاسخ دهید و جواب آن‌ها را در فایل بیاورید: + +* پروژه‌ی شما چه کاری انجام می‌دهد؟ +* چرا این پروژه مفید است؟ +* چگونه شروع کردم؟ +* در صورت نیاز، از کجا می‌توانم کمک بیشتری دریافت کنم؟ + +شما با فایل README می‌توانید به سایر سوالات نیز پاسخ دهید؛ سوالاتی مانند اینکه چگونه مشارکت‌تان را مدیریت می‌کنید، اهداف پروژه‌تان چیست و اطلاعات لایسنس و اختیارات پروژه‌تان را هم می‌توانید بیاورید. اگر مشارکت کسی را نمی‌خواهید قبول کنید، یا پروژه‌ی شما هنوز برای ارائه آماده نشده باشد، می‌توانید این توضیحات را در فایل README بیاورید + + + +بعضی از افراد از نوشتن فایل README خودداری می‌کنند، چون فکر می‌کنند پروژه‌ی آن‌ها هنوز تکمیل نشده یا اینکه نمی‌خواهند کسی مشارکتی داشته باشد. همین‌ها دلایل خیلی خوبی برای نوشتن یک فایل README محسوب می‌شوند. + +برای نوشتن یک فایل README کامل، می‌توانید به مقالات @dguo's ["Make a README" guide](https://www.makeareadme.com/) یا @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) مراجعه کنید و از آن‌ها الهام بگیرید + +زمانی که فایل README را در دایرکتوری ریشه خود قرار می‌دهید، GitHub به صورت خودکار آن را در صفحه‌ی اصلی repository (انبار) نشان می‌دهد. + +### نوشتن راهنمای مشارکت + +فایل CONTRIBUTING (مشارکت) به مخاطبان‌تان می‌گوید که چگونه در پروژه‌ی شما مشارکت کنند. به عنوان مثال، می‌توانید اطلاعات زیر را در آن قید کنید: + +* چگونه یک باگ یا مشکل گزارش شود +* چگونه ویژگی جدیدی پیشنهاد دهند +* چگونه محیط پروژه‌تان را تنظیم و آن را برای تست اجرا کنند + +به علاوه، در فایل CONTRIBUTING می‌توانید جزئیات فنی و انتظارات‌تان را برای مشارکت‌کننده‌ها بیان کنید. به عنوان مثال: + +* نوع مشارکتی که به دنبال آن هستید +* نقشه‌ی راه یا دیدگاهی که به پروژه دارید +* چگونه مشارکت‌کننده‌ها باید (یا نباید) با شما در تماس باشند + +زمانی که با خونگرمی، حس دوستانه و دادن پیشنهادهای خاص (مانند نوشتن اسناد، یا طراحی وب‌سایت) با مشارکت‌کننده‌هایتان برخورد می‌کنید، بیشتر راه را برای استقبال از تازه‌واردها رفته‌اید و همین کار شما باعث می‌شود آن‌ها برای همکاری با شما هیجان‌زده شوند. + +برای روشن شدن مطلب اجازه دهید نمونه‌ای بیاوریم. به عنوان مثال، [Active Admin](https://github.com/activeadmin/activeadmin/) [راهنمای مشارکت خود](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) به مشارکت‌کننده‌ها را اینگونه شروع می‌کند + +> در ابتدا، از شما ممنون هستم که می‌خواهید با Active Admin مشارکت کنید. افرادی مثل شما هستند که باعث می‌شوند Active Admin عملکرد خوبی داشته باشد. + +در ابتدایی‌ترین مرحله‌ی پروژه‌تان، فایل CONTRIBUTING می‌تواند ساده باشد. شما در این فایل همیشه باید نحوه‌ی گزارش دادن باگ‌ها (خطاها) یا مشکلات فایل و هر نیاز فنی مانند تست کردن را برای مشارکت‌کننده‌ها توضیح دهید. + +در طول زمان، ممکن است اطلاعات و سوالات مکرر زیادی به فایل CONTRIBUTING خود اضافه کنید. از این رو، افراد کمتری پیدا می‌شوند که سوالات تکراری از شما بپرسند. + +برای اینکه بدانید چگونه اطلاعات فایل CONTRIBUTING خود را بنویسید، می‌توانید به مقالات @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) یا @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) مراجعه کنید. + +[لینک فایل CONTRIBUTING خود را در فایل README قرار دهید](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) تا افرادی که آن را مطالعه می‌کنند این فایل مشارکت را هم ببینند. اگر فایل CONTRIBUTING خود را در repository (انبار) (مخزن) پروژه‌تان قرار داده باشید، زمانی که یک مشارکت‌کننده طرح مشکل یا گزارش یک باگ یا درخواست ادغام کند، GitHub به صورت خودکار او را به لینک فایل CONTRIBUTING هدایت می‌کند + +![راهنماهای مشارکت](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### تعیین آیین نامه‌ی رفتاری (Code of Conduct) + + + +بالاخره، آیین نامه‌ی رفتاری به ما کمک می‌کند برای رفتارهای مشارکت‌کننده‌های پروژه‌تان قوائدی تعیین کنید. زمانی که بخواهید یک پروژه‌ی متن بازی را برای انجمن یا یک شرکت منتشر کنید، این قوائد می‌تواند ارزشمند باشد. آیین نامه‌ی رفتاری یا (Code of Conduct) این قدرت را به شما می‌دهد تا رفتارهای سازنده و سالم را در بین جامعه کاربران ترویج کنید که در آینده به عنوان یک مسئول‌نگهداری پروژه احساس استرس کمتری داشته باشید. + +برای اطلاعات بیشتر می‌توانید به [راهنمای آیین نامه‌ی رفتاری](../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) یک وب سرور ساده و سریع روبی است + +اگر در حال طراحی پروژه‌تان هستید، به کارگیری نام آن‌ها به عنوان پیشوند می‌تواند به شفاف کردن پروژه‌تان کمک کند. به عنوان نمونه، ([node-fetch](https://github.com/bitinn/node-fetch)، Window.fetch را به Node.js می‌آورد). + +با در نظر گرفتن توصیه بالا. می‌توان عناوین بامزه یا خوب زیادی ساخت، اما این را به یاد داشته باشید که بعضی از بازی با کلمات و جناس‌ها ممکن است در سایر فرهنگ‌ها یا افرادی که تجربه‌های متفاوتی نسبت به شما دارند، مفهوم یا ترجمه‌ی نادرستی داشته باشد. برخی از کاربران بالقوه شما هم ممکن است کارمندان یک شرکت باشند و حتما نمی‌خواهید زمانی که در حال توضیح دادن نحوه‌ی پروژه‌تان در محل کارشان هستند، احساس نامساعدی داشته باشند. + +### از نام‌گذاری‌های دارای منافات خودداری کنید + +اگر پروژه‌ی شما زبان و اکوسیستم یکسانی دارد، می‌توانید نام پروژه‌های مشابه با پروژه‌تان را [بررسی کنید](http://ivantomic.com/projects/ospnc/). اگر نام پروژه‌ی شما با پروژه‌ی دیگری شباهت زیادی داشته باشد، مخاطب شما ممکن است سردرگم شود. + +اگر در یک وب‌سایت، توئیتر یا دیگر شبکه‌های اجتماعی می‌خواهید پروژه‌تان را نشان دهید، مطمئن شوید همان نامی را انتخاب کنید که می‌خواهید. به طور ایده آل، حتی اگر هنوز نمی‌‌خواهید از آن نام استفاده کنید و برای اینکه خیال‌تان راحت باشد، آن نام را [وارونه کنید](https://instantdomainsearch.com/) + +مطمئن شوید نام پروژه‌ی شما هیچ برند تجاری را نقض نمی‌کند. اگر چنین باشد، آن شرکت می‌تواند بعدها از شما درخواست کند پروژه‌تان را کنسل کرده یا حتی به صورت قانونی با شما برخورد کند. بنابراین، ارزش این همه ریسک را ندارد و برای جلوگیری از چنین مشکلاتی حتما از نام مناسبی استفاده کنید. + +برای بررسی تضاد و منافات برندهای تجاری می‌توانید به پایگاه داده برندهای جهانی [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) مراجعه کنید. اگر شما یک شخص حقوقی هستید و در یک شرکت فعالیت می‌کنید، این یکی از چیزهایی است که [تیم حقوقی‌تان می‌تواند](../legal/) به شما کمک کند + +در نهایت، نام پروژه‌تان را به سرعت در گوگل جستجو کنید. ببینید که افراد به راحتی می‌توانند پروژه‌تان را پیدا کنند؟ در نتایج جستجوی شما چیزی دیگر پیدا می‌شود که نمی‌خواهید کاربران آن را مشاهده کنند؟ + +### چگونه نوشتن و کدنویسی شما روی برندتان اثر می‌گذارد! + +در طول عمر پروژه‌تان، در حال نوشتن چیزهای زیادی خواهید بود که می‌توان به نوشتن فایل‌های README، آموزش‌ها، اسناد انجمن، نوشتن پاسخ به مشکلات، حتی شاید نوشتن و پاسخ دادن به خبرنامه و فهرست پستی، اشاره کرد. + +سبک نویسندگی شما چه در اسناد رسمی و چه در ایمیل‌های محاوره‌ای بخشی از برند پروژه‌تان است. به این فکر کنید چگونه می‌خواهید با مخاطب‌تان برخورد کنید و ببینید این لحن نوشتاری همان چیزی است که می‌خواهید به مخاطب فرستاده شود یا خیر. + + + +زمانی که از یک زبان جامع و گرم استفاده می‌کنید و حتی زمانی که با یک فرد صحبت می‌کنید، به جای کلمه‌ی «تو» کلمه‌ی «شما» را به کار می‌برید، کمک زیادی به شما می‌کند تا مشارکت‌کننده‌های جدید از پروژه‌ی شما استقبال کنند. اگر می‌خواهید به زبان انگلیسی بنویسید، سعی کنید ساده باشد. چون زبان بیشتر خواننده‌های شما بومی نیست. + +جدا از کلماتی که در نوشتن اسناد مختلف استفاده می‌کنید، سبک کدنویسی شما هم ممکن است به بخشی از برند پروژه‌تان تبدیل شود. به عنوان مثال می‌توانیم به دو نمونه پروژه به نام‌های [Angular](https://angular.io/guide/styleguide) و [jQuery](https://contribute.jquery.org/style-guide/js/) اشاره کنیم که راهنما و سبک کدنویسی سختی دارند + +در ابتدای کار لازم نیست از راهنمای سبک نویسندگی استفاده کنید. به هر حال، به مرور از ترکیب سبک متفاوت کدنویسی خود در پروژه‌تان لذت خواهید برد. هرچند، این را باید پیش‌بینی کنید که نحوه‌ی نویسندگی و سبک کدنویسی شما ممکن است انواع مختلف افراد را جذب یا دفع کند. در ابتدای‌ترین مرحله‌ی پروژه‌تان فرصت دارید مقدماتی که می‌خواهید مخاطبان ببنند را ارائه دهید. + +## مرور (چک لیست / لیست بررسی) قبل از انتشار پروژه‌ی متن باز + +خب، آماده هستید تا پروژه‌تان را متن باز کنید؟ چک لیست در این مرحله می‌تواند به شما کمک کند. تمام گزینه‌ها و تیک‌ها را بررسی کرده‌اید؟ به محض آماده شدن، روی انتشار [publish](https://help.github.com/articles/making-a-private-repository-public/) کلیک کنید و به خودتان تبریک بگویید. + +**مستندات** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**کد** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**افراد** + +اگر شما شخص حقیقی هستید: + +
+ + +
+ +اگر شخص حقوقی هستید و در یک سازمان یا یک شرکت فعالیت می‌کنید: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## انجامش دادی! + +اولین پروژه‌ی متن بازتان را تبریک می‌گوییم. بهتر است بدانید که خروجی آن مهم نیست، فقط با این کار تجربه‌ی کار در فضای جامعه را به دست آوردید. با هر کامیت (Commit)، کامنت (Comment) و پاسخ به درخواست ادغام فرصتی برای رشد و یادگیری خود و دیگران ایجاد می‌کنید. diff --git a/_articles/finding-users.md b/_articles/finding-users.md index b52ff2e9d8e..3fa494ec3c9 100644 --- a/_articles/finding-users.md +++ b/_articles/finding-users.md @@ -3,13 +3,6 @@ lang: en title: Finding Users for Your Project description: Help your open source project grow by getting it in the hands of happy users. class: finding -toc: - spreading-the-word: "Spreading the word" - figure-out-your-message: "Figure out your message" - help-people-find-and-follow-your-project: "Help people find and follow your project" - go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)" - go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)" - build-a-reputation: "Build a reputation" order: 3 image: /assets/images/cards/finding.png related: @@ -48,7 +41,7 @@ Help people find and remember your project by pointing them to a single namespac **Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene. -If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. +If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. @@ -98,13 +91,13 @@ If nobody pays attention or responds to your initial outreach, don't get discour Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers. -If you're [new to public speaking](http://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. +If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. @@ -116,7 +109,7 @@ As you write your talk, focus on what your audience will find interesting and ge avatar When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.

-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/) +— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](https://web.archive.org/web/20201128162836/http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)

@@ -142,7 +135,7 @@ Helping newcomers, sharing resources, and making thoughtful contributions to oth avatar The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.

-— @shazow, ["How to make your open source project thrive"](https://text.sourcegraph.com/how-to-make-your-open-source-project-thrive-with-andrey-petrov-6463b935c540#.mk31f8fgf) +— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)

@@ -150,14 +143,6 @@ It's never too early, or too late, to start building your reputation. Even if yo There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends. - - ## Keep at it! It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it. diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md new file mode 100644 index 00000000000..e3252b7f877 --- /dev/null +++ b/_articles/fr/best-practices.md @@ -0,0 +1,276 @@ +--- +lang: fr +title: Bonnes pratiques pour les responsables +description: Facilitez-vous la vie en tant que responsable Open Source, de la documentation des processus à l'exploitation de votre communauté. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Que signifie être un responsable + +Si vous gérez un projet Open Source que beaucoup de personnes utilisent, vous avez peut-être remarqué que vous codez moins et que vous répondez à d'autres problèmes. + +Au début d'un projet, vous expérimentez de nouvelles idées et prenez des décisions en fonction de ce que vous voulez. Au fur et à mesure que votre projet gagne en popularité, vous travaillerez de plus en plus avec vos utilisateurs et vos contributeurs. + +Maintenir un projet nécessite plus que du code. Ces tâches sont souvent inattendues, mais elles sont tout aussi importantes pour un projet en croissance. Nous avons rassemblé quelques moyens pour vous faciliter la vie, de la documentation des processus à l'exploitation de votre communauté. + +## Documentez vos processus + +Écrire des choses est l'une des choses les plus importantes que vous pouvez faire en tant que responsable. + +La documentation clarifie non seulement votre propre pensée, mais elle aide les autres à comprendre ce dont vous avez besoin ou ce que vous attendez, avant même de le demander. + +Rédaction des choses rend plus facile de dire non quand quelque chose ne rentre pas dans votre champ d'application. Cela facilite également la tâche des gens. Vous ne savez jamais qui pourrait lire ou utiliser votre projet. + +Même si vous n'utilisez pas de paragraphes entiers, des listes de point sont mieux que de ne pas écrire du tout. + +N'oubliez pas de garder votre documentation à jour. Si vous n'êtes pas toujours en mesure de le faire, supprimez votre documentation obsolète ou indiquez qu'elle est obsolète afin que les contributeurs sachent que les mises à jour sont les bienvenues. + +### Décrivez la vision de votre projet + +Commencez par écrire les objectifs de votre projet. Ajoutez-les à votre fichier README ou créez un fichier distinct appelé VISION. S'il y a d'autres artefacts qui pourraient aider, comme une feuille de route de projet, laissez-les publics aussi. + +Avoir une vision claire et documentée vous permet de rester concentré et vous aide à éviter le «glissement de portée» des contributions des autres. + +Par exemple, @lord a découvert que le fait d'avoir une vision de projet l'aidait à déterminer les demandes pour lesquelles il devait passer du temps. En tant que nouveau responsable, il a regretté de ne pas s'en tenir à la portée de son projet quand il a obtenu sa première demande de fonctionnalité pour [Slate](https://github.com/lord/slate). + + + +### Communiquez vos attentes + +Les règles peuvent être angoissantes à écrire. Parfois, vous pourriez avoir l'impression de surveiller le comportement des autres ou de tuer tout le plaisir. + +Écrit et appliqué équitablement, cependant, de bonnes règles habilitent les responsables. Ils vous empêchent d'être entraînés à faire des choses que vous ne voulez pas faire. + +La plupart des personnes qui rencontrent votre projet ne savent rien de vous ou de votre situation. Ils peuvent supposer que vous êtes payé pour travailler dessus, surtout si c'est quelque chose qu'ils utilisent régulièrement et dont ils dépendent. Peut-être qu'à un moment donné, vous avez consacré beaucoup de temps à votre projet, mais maintenant vous êtes occupé avec un nouvel emploi ou un membre de votre famille. + +Tout cela est parfaitement correct ! Assurez-vous simplement que les autres personnes le savent. + +Si le maintien de votre projet est à temps partiel ou purement volontaire, soyez honnête quant au temps dont vous disposez. Ce n'est pas la même chose que le temps que vous estimez nécessaire au projet ou combien de temps les autres vous demandent. + +Voici quelques règles qui méritent d'être notées : + +* Comment une contribution est-elle examinée et acceptée (_A-t-elle besoin de tests ? Un modèle de question ?_) +* Les types de contributions que vous acceptez (_Vous voulez seulement de l'aide pour une partie de votre code ?_) +* Lorsqu'il est approprié de faire un suivi (_par exemple, "Vous pouvez vous attendre à recevoir une réponse d'un responsable dans les 7 jours. Dès lors Si vous n'avez pas encore de retour, n'hésitez pas à faire un ping."_) +* Combien de temps vous consacrez au projet (_par exemple, "Nous ne consacrons que 5 heures par semaine à ce projet"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), et [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) sont plusieurs exemples de projets avec des règles de base pour les responsables et les contributeurs. + +### Maintenez la communication publique + +N'oubliez pas de documenter vos interactions, aussi. Partout où vous pouvez, gardez la communication sur votre projet public. Si quelqu'un tente de vous contacter en privé pour discuter d'une demande de fonctionnalité ou d'un besoin de support, dirigez-les poliment vers un canal de communication public, tel qu'une liste de diffusion ou un outil de suivi des problèmes. + +Si vous rencontrez d'autres responsables, ou prenez une décision importante en privé, documentez ces conversations en public, même si cela ne concerne que la publication de vos notes. + +De cette façon, toute personne qui rejoint votre communauté aura accès à la même information que quelqu'un qui a été là pendant des années. + +## Apprendre à dire non + +Vous avez écrit des choses. Idéalement, tout le monde lira votre documentation, mais en réalité, vous devrez rappeler aux autres que cette connaissance existe. + +Cependant, tout noter contribue à dépersonnaliser les situations lorsque vous devez appliquer vos règles. + +Dire non n'est pas amusant, mais _"Votre contribution ne correspond pas aux critères de ce projet"_ est moins personnelle que _"Je n'aime pas votre contribution"_. + +Dire non s'applique à de nombreuses situations que vous rencontrerez en tant que responsable : des demandes de fonctionnalités qui ne correspondent pas à la portée, quelqu'un qui déraille dans une discussion, qui fait un travail inutile pour les autres. + +### Gardez la conversation amicale + +Les endroits les plus importants où pratiquer l'art du refus sont vos issues et la file d'attente des pull requests. En tant que responsable du projet, vous recevrez inévitablement des suggestions que vous ne souhaitez pas accepter. + +Peut-être que la contribution modifie la portée de votre projet ou ne correspond pas à votre vision. Peut-être que l'idée est bonne, mais la mise en œuvre est mauvaise. + +Peu importe la raison, il est possible de gérer avec tact les contributions qui ne répondent pas aux normes de votre projet. + +Si vous recevez une contribution que vous ne voulez pas accepter, votre première réaction pourrait être de l'ignorer ou de prétendre que vous ne l'avez pas vue. Cela pourrait nuire aux sentiments de l'autre et même démotiver d'autres contributeurs potentiels dans votre communauté. + + + +Ne laissez pas une contribution indésirable ouverte parce que vous avez un sentiment de culpabilité ou que vous voulez être gentil. Au fil du temps, vos issues sans réponse et les PRs rendront le travail sur votre projet beaucoup plus stressant et intimidant. + +Il est préférable de fermer immédiatement les contributions que vous ne voulez pas accepter. Si votre projet souffre déjà d'un important retard, @steveklabnik propose des suggestions pour [comment trier efficacement les issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +Deuxièmement, ignorer les contributions envoie un signal négatif à votre communauté. Contribuer à un projet peut être intimidant, surtout s'il s'agit de la première fois. Même si vous n'acceptez pas leur contribution, remerciez la personne derrière et remerciez-la de son intérêt. C'est un gros compliment! + +Si vous ne voulez pas accepter une contribution: + +* **Remercier la** pour sa contribution +* **Expliquez pourquoi cela ne rentre pas** dans la portée du projet et proposez des suggestions d'amélioration claires, si vous le pouvez. Soyez gentil, mais ferme. +* **Lien vers la documentation pertinente**, si vous l'avez. Si vous remarquez des demandes répétées pour des choses que vous ne voulez pas accepter, ajoutez-les dans votre documentation pour éviter de vous répéter. +* **Fermez la demande** + +Vous ne devriez pas avoir besoin de plus de 1-2 phrases pour répondre. Par exemple, lorsqu'un utilisateur de [celery](https://github.com/celery/celery/) a signalé une erreur liée à Windows, @berkerpeksag [a répondu ainsi](https://github.com/celery/celery/issues/3383): + +![Capture d'écran de celery](/assets/images/best-practices/celery.png) + +Si la pensée de dire non vous terrifie, vous n'êtes pas seul. Comme @jessfraz [le met](https://blog.jessfraz.com/post/the-art-of-closing/): + +> J'ai parlé à des responsables de plusieurs projets open source différents, Mesos, Kubernetes, Chromium, et ils sont tous d'accord que l'un des aspects les plus difficiles d'un responsable est de dire "Non" aux correctifs que vous ne voulez pas. + +Ne vous sentez pas coupable de ne pas vouloir accepter la contribution de quelqu'un. La première règle de l'open source, [selon](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Non est temporaire, oui est pour toujours."_. Alors que l'empathie avec l'enthousiasme d'une autre personne est une bonne chose, rejeter une contribution n'est pas la même chose que rejeter la personne derrière elle. + +En fin de compte, si une contribution n'est pas suffisante, vous n'êtes pas obligé de l'accepter. Soyez gentil et réactif lorsque les gens contribuent à votre projet, mais n'acceptez que les changements qui, selon vous, amélioreront votre projet. Le plus souvent vous pratiquez en disant non, plus cela devient facile. Promis. + +### Soyez proactif + +Pour réduire le volume des contributions non désirées, expliquez le processus de soumission et d'acceptation des contributions de votre projet dans votre guide. + +Si vous recevez trop de contributions de faible qualité, demandez aux contributeurs de faire un peu de travail à l'avance, par exemple: + +* Remplir une issue ou un modèle de PR / checklist +* Ouvrir une issue avant de soumettre une PR + +S'ils ne respectent pas vos règles, fermez immédiatement l'issue et référez à votre documentation. + +Bien que cette approche puisse sembler méchante au début, être proactif est réellement bon pour les deux parties. Cela réduit le risque que quelqu'un consacre beaucoup d'heures de travail perdues à une pull request que vous n'allez pas accepter. Et cela rend votre charge de travail plus facile à gérer. + + + +Parfois, quand vous dites non, votre contributeur potentiel peut se fâcher ou critiquer votre décision. Si leur comportement devient hostile, [prenez des mesures pour désamorcer la situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) ou même supprimez-le de votre communauté s'il ne souhaite pas collaborer de manière constructive. + +### Embrasser le mentorat + +Peut-être que quelqu'un dans votre communauté soumet régulièrement des contributions qui ne répondent pas aux normes de votre projet. Il peut être frustrant pour les deux parties de passer à plusieurs reprises par des rejets. + +Si vous voyez que quelqu'un est enthousiaste à propos de votre projet, mais qu'il a besoin d'un peu de polish, soyez patient. Expliquer clairement dans chaque situation pourquoi les contributions ne répondent pas aux attentes du projet. Essayez de le diriger vers une tâche plus facile ou moins ambiguë, comme une question marquée _"bonne première issue"_, pour se faire les pieds. Si vous avez le temps, envisagez de l'encadrer à travers sa première contribution, ou de trouver quelqu'un d'autre dans votre communauté qui pourrait être disposé à le faire. + +## Tirez parti de votre communauté + +Vous n'avez pas à tout faire vous-même. La communauté de votre projet existe pour une raison ! Même si vous n'avez pas encore de communauté de contributeurs actifs, si vous avez beaucoup d'utilisateurs, mettez-les au travail. + +### Partager la charge de travail + +Si vous cherchez d'autres personnes, commencez par demander. + +Lorsque vous voyez de nouveaux contributeurs faire des contributions répétées, reconnaissez leur travail en offrant plus de responsabilités. Documentez comment les autres peuvent devenir des leaders s'ils le souhaitent. + +Encourager les autres à [partager la propriété du projet](../building-community/#partager-la-propriété-de-votre-projet) peut réduire considérablement votre charge de travail, comme l'a découvert @lmccart sur son projet, [p5.js](https://github.com/processing/p5.js). + + + +Si vous avez besoin de quitter votre projet, que ce soit en pause ou en permanence, il n'y a pas de honte à demander à quelqu'un d'autre de vous remplacer. + +Si d'autres personnes sont enthousiastes à l'égard de sa direction, donnez-leur l'autorisation de s'engager ou remettez officiellement le contrôle à quelqu'un d'autre. Si quelqu'un a forké votre projet et le maintient activement ailleurs, envisagez de créer un lien vers le fork de votre projet d'origine. C'est génial que tant de gens veulent que votre projet continue à vivre ! + +@progrium [a trouvé que](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documentant la vision de son projet, [Dokku](https://github.com/dokku/dokku), a aidé à atteindre ces objectifs même après s'être retiré du projet: + +> J'ai écrit une page wiki décrivant ce que je voulais et pourquoi je le voulais. Pour une raison ou une autre, j'ai été surpris de constater que les responsables ont commencé à faire avancer le projet dans cette direction ! Est-ce arrivé exactement comment je le ferais ? Pas toujours. Mais cela rapprochait encore le projet de ce que j'avais écrit. + +### Laissez les autres construire les solutions dont ils ont besoin + +Si un contributeur potentiel a une opinion différente sur ce que votre projet devrait faire, vous pouvez l'encourager doucement à travailler sur son propre fork. + +Forker un projet ne doit pas être une mauvaise chose. Etre capable de copier et de modifier des projets est l'une des meilleures choses à propos de l'open source. Encourager les membres de votre communauté à travailler sur leur propre fork peut fournir le débouché créatif dont ils ont besoin, sans entrer en conflit avec la vision de votre projet. + + + +La même chose s'applique à un utilisateur qui veut vraiment une solution que vous n'avez tout simplement pas la bande passante pour la faire. L'offre d'API et de hooks de personnalisation peut aider les autres à répondre à leurs propres besoins, sans avoir à modifier directement la source. @orta [a trouvé que](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encourager les plugins pour CocoaPods a conduit à "quelques-unes des idées les plus intéressantes": + +> Il est presque inévitable qu'une fois qu'un projet prend de l'ampleur, les responsables doivent être beaucoup plus conservateurs quant à la façon dont ils introduisent un nouveau code. Vous devenez bon à dire «non», mais beaucoup de gens ont des besoins légitimes. Ainsi, vous finissez par convertir votre outil en plate-forme. + +## Donnez le aux robots + +Tout comme il existe des tâches que d'autres personnes peuvent vous aider, il y a aussi des tâches que personne ne devrait jamais avoir à faire. Les robots sont vos amis. Utilisez-les pour rendre votre vie de responsable plus facile. + +### Exiger des tests et autres vérifications pour améliorer la qualité de votre code + +L'un des moyens les plus importants pour automatiser votre projet consiste à ajouter des tests. + +Les tests aident les contributeurs à croire qu'ils ne casseront rien. Ils facilitent également la consultation et l'acceptation des contributions rapidement. Plus vous êtes réactif, plus votre communauté peut être engagée. + +Configurez des tests automatiques qui s'exécuteront sur toutes les contributions entrantes, et assurez-vous que vos tests peuvent être facilement exécutés localement par les contributeurs. Exiger que toutes les contributions de code passent vos tests avant de pouvoir être soumis. Vous aiderez à définir une norme de qualité minimale pour toutes les soumissions. La [vérification du status requis](https://help.github.com/articles/about-required-status-checks/) sur GitHub peut vous aider à vous assurer qu'aucune modification ne sera mergée sans que vos tests ne passent. + +Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dans votre fichier CONTRIBUTING. + + + +### Utiliser des outils pour automatiser les tâches de maintenance de base + +Les bonnes nouvelles à propos du maintien d'un projet populaire sont que d'autres responsables ont probablement déjà fait face à des problèmes similaires et ont construit une solution pour cela. + +Il y a une [variété d'outils disponibles](https://github.com/showcases/tools-for-open-source) pour aider à automatiser certains aspects du travail de maintenance. Quelques exemples: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automatise vos releases +* [mention-bot](https://github.com/facebook/mention-bot) mentionne les reviewers potentiels pour les pull requests +* [Danger](https://github.com/danger/danger) permet d'automatiser les revues de code + +Pour les rapports de bogues et autres contributions communes, GitHub a des [Modèles d'issues et modèles de pull requests](https://github.com/blog/2111-issue-and-pull-request-templates), que vous pouvez créer pour rationaliser la communication que vous recevez. @TalAter a fait un guide [Choisissez Votre Propre Aventure] () pour vous aider à rédiger vos issues et vos modèles de PR. + +Pour gérer vos notifications par e-mail, vous pouvez configurer [des filtres e-mail](https://github.com/blog/2203-email-updates-about-your-own-activity) pour organiser par priorité. + +Si vous souhaitez être un peu plus avancé, les guides de style et les linters peuvent standardiser les contributions de projet et les rendre plus faciles à consulter et à accepter. + +Cependant, si vos normes sont trop compliquées, elles peuvent augmenter les obstacles à la contribution. Assurez-vous d'ajouter suffisamment de règles pour faciliter la vie de tous. + +Si vous n'êtes pas sûr des outils à utiliser, regardez ce que font les autres projets populaires, en particulier ceux de votre écosystème. Par exemple, à quoi ressemble le processus de contribution pour les autres modules Node ? L'utilisation d'outils et d'approches similaires rendra votre processus plus familier à vos contributeurs cibles. + +## Il est normal de faire pause + +Le travail open source vous a déjà apporté de la joie. Peut-être que maintenant ça commence à vous faire sentir fuyant ou coupable. + +Peut-être vous sentez-vous débordé ou un sentiment croissant d'effroi quand vous pensez à vos projets. Et pendant ce temps, les issues et les pull requests s'accumulent. + +Le burnout est un problème réel et omniprésent dans le travail open source, en particulier chez les responsables. En tant que responsable, votre bonheur est une exigence non négociable pour la survie de tout projet open source. + +Bien que cela devrait aller de soi, faites une pause ! Vous ne devriez pas avoir à attendre de vous sentir usé pour prendre des vacances. @brettcannon, un développeur de base Python, a décidé de prendre [un mois de vacances](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) après 14 années de bénévolat de travail sur les logiciels open source. + +Tout comme n'importe quel autre type de travail, prendre des pauses régulières vous gardera frais, heureux et excité par votre travail. + + + +Parfois, il peut être difficile de faire une pause dans le travail open source quand on a l'impression que tout le monde a besoin de vous. Les gens peuvent même essayer de vous faire sentir coupable d'avoir abandonné. + +Faites de votre mieux pour trouver du support pour vos utilisateurs et votre communauté pendant votre absence sur un projet. Si vous ne trouvez pas le soutien dont vous avez besoin, faites une pause quand même. Assurez-vous de communiquer lorsque vous n'êtes pas disponible, afin que les gens ne soient pas perturbés par votre manque de réactivité. + +Prendre des pauses s'applique à plus que de simples vacances, aussi. Si vous ne voulez pas faire du travail open source le week-end, ou pendant les heures de travail, communiquez ces attentes aux autres, afin qu'ils sachent ne pas vous déranger. + +## Prenez soin de vous d'abord ! + +Maintenir un projet populaire nécessite des compétences différentes des étapes précédentes de la croissance, mais ce n'est pas moins gratifiant. En tant que responsable, vous pratiquerez le leadership et les compétences personnelles à un niveau que peu de gens connaissent. Bien que ce ne soit pas toujours facile à gérer, définir des limites claires et ne prendre que ce que vous êtes à l'aise vous aidera à rester heureux, frais et productif. diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md new file mode 100644 index 00000000000..1dec5be76ab --- /dev/null +++ b/_articles/fr/building-community.md @@ -0,0 +1,275 @@ +--- +lang: fr +title: Construire des communautés accueillantes +description: Construire une communauté qui encourage les gens à utiliser, contribuer et évangéliser votre projet. +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Mise en place de votre projet pour le succès + +Vous avez lancé votre projet, vous passez le mot, et les gens le vérifient. Impressionnant ! Maintenant, comment les faites-vous rester ? + +Une communauté accueillante est un investissement dans l'avenir et la réputation de votre projet. Si votre projet commence à peine à voir ses premières contributions, commencez par donner aux premiers contributeurs une expérience positive et facilitez-les pour qu'ils reviennent. + +### Faites que les gens se sentent les bienvenus + +Une façon de penser à la communauté de votre projet est ce que @MikeMcQuaid appelle l'[entonnoir du contributeur](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Entonnoir du contributeur](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +Au fur et à mesure que vous construisez votre communauté, réfléchissez à la façon dont une personne en haut de l'entonnoir (un utilisateur potentiel) pourrait théoriquement se frayer un chemin vers le bas (un responsable actif). Votre but est de réduire la friction à chaque étape de l'expérience du contributeur. Quand les gens ont des victoires faciles, ils se sentent incités à faire plus. + +Commencez avec votre documentation: + +* **Facilitez l'utilisation de votre projet par quelqu'un.** [Un fichier README amical](../starting-a-project/#ecrire-un-fichier-readme) et des exemples de code clair faciliteront la tâche à tous ceux qui atterriront votre projet pour commencer. +* **Expliquez clairement comment contribuer**, en utilisant [votre fichier CONTRIBUTING](../starting-a-project/#rédaction-de-vos-directives-de-contribution) et en gardant vos issues à jour. + +[L'enquête open source 2017 de GitHub](http://opensourcesurvey.org/2017/) a montré que la documentation incomplète ou confuse est le plus gros problème pour les utilisateurs open source. Une bonne documentation invite les gens à interagir avec votre projet. Finalement, quelqu'un va ouvrir une issue ou faire une pull request. Utilisez ces interactions comme des opportunités pour les déplacer dans l'entonnoir. + +* **Quand quelqu'un arrive sur votre projet, remerciez-le de son intérêt !** Il suffit d'une expérience négative pour que quelqu'un ne veuille pas revenir. +* **Soyez réactif.** Si vous ne répondez pas à leur problème pendant un mois, il est probable qu'ils aient déjà oublié votre projet. +* **Soyez ouvert sur les types de contributions que vous accepterez.** De nombreux contributeurs commencent par un rapport de bug ou une petite correction. Il y a [plusieurs façons de contribuer](../how-to-contribute/#que-signifie-contribuer) à un projet. Laissez les gens aider comment ils veulent aider. +* **S'il y a une contribution avec laquelle vous n'êtes pas d'accord,** remerciez-les pour leur idée et [expliquez pourquoi](../best-practices/#apprendre-à-dire-non) cela ne rentre pas dans le cadre de la projet, en reliant à la documentation pertinente si vous l'avez. + + + +La majorité des contributeurs open source sont des "contributeurs occasionnels": des personnes qui contribuent à un projet uniquement à l'occasion. Un contributeur occasionnel n'a peut-être pas le temps de se familiariser avec votre projet, alors votre travail consiste à rendre la contribution plus facile. + +Encourager les autres contributeurs est un investissement en vous aussi. Lorsque vous permettez à vos plus grands fans de courir avec le travail qui les intéresse, il y a moins de pression pour tout faire vous-même. + +### Documentez tout + + + +Lorsque vous démarrez un nouveau projet, il peut sembler naturel de garder votre travail privé. Mais les projets Open Source prospèrent lorsque vous documentez votre processus en public. + +Quand vous écrivez les choses, plus de gens peuvent participer à chaque étape du chemin. Vous pourriez obtenir de l'aide sur quelque chose dont vous ne saviez même pas que vous en aviez besoin. + +Ecrire des choses signifie plus que de la documentation technique. Chaque fois que vous ressentez le besoin d'écrire quelque chose ou de discuter en privé de votre projet, demandez-vous si vous pouvez le rendre public. + +Soyez transparent au sujet de la feuille de route de votre projet, des types de contributions que vous recherchez, de la façon dont les contributions sont examinées ou des raisons pour lesquelles vous avez pris certaines décisions. + +Si vous remarquez que plusieurs utilisateurs rencontrent le même problème, documentez les réponses dans le fichier README. + +Pour les réunions, pensez à publier vos notes ou vos plats à emporter dans un numéro pertinent. Les commentaires que vous obtiendrez de ce niveau de transparence pourraient vous surprendre. + +Documenter tout s'applique au travail que vous faites aussi. Si vous travaillez sur une mise à jour substantielle de votre projet, placez-la dans une pull request et marquez-la comme un travail en cours (WIP). De cette façon, d'autres personnes peuvent se sentir impliquées dans le processus dès le début. + +### Soyez réactif + +Comme vous [faites la promotion de votre projet](../finding-users), les gens auront des commentaires pour vous. Ils peuvent avoir des questions sur la façon dont les choses fonctionnent, ou ont besoin d'aide pour commencer. + +Essayez d'être réactif lorsque quelqu'un soumet une issue, une pull request ou une question à propos de votre projet. Lorsque vous répondez rapidement, les gens ont l'impression de participer à un dialogue, et ils seront plus enthousiastes à l'idée de participer. + +Même si vous ne pouvez pas examiner la demande immédiatement, le reconnaître au début permet d'augmenter l'engagement. Voici comment @tdreyno a répondu à une pull request sur [Middleman](https://github.com/middleman/middleman/pull/1466): + +![la pull request Middleman](/assets/images/building-community/middleman_pr.png) + +[Une étude de Mozilla a trouvé que](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) les contributeurs qui ont reçu des avis de code dans les 48 heures avaient un taux de rendement beaucoup plus élevé et recommençaient a contribuer. + +Des conversations sur votre projet pourraient également avoir lieu dans d'autres endroits sur Internet, tels que Stack Overflow, Twitter ou Reddit. Vous pouvez configurer des notifications dans certains de ces endroits afin d'être averti lorsque quelqu'un mentionne votre projet. + +### Donnez à votre communauté point de rassemblement + +Il y a deux raisons de donner à votre communauté un point de rassemblement. + +La première raison est pour eux. Aidez les gens à se connaître. Les personnes ayant des intérêts communs voudront inévitablement un endroit pour en parler. Et quand la communication est publique et accessible, n'importe qui peut lire les archives passées pour se mettre au courant et participer. + +La deuxième raison est pour vous. Si vous ne donnez pas aux gens un lieu public pour parler de votre projet, ils vous contacteront probablement directement. Au début, il peut sembler assez facile de répondre aux messages privés "juste une fois". Mais au fil du temps, surtout si votre projet devient populaire, vous serez épuisé. Résistez à la tentation de communiquer avec des personnes au sujet de votre projet en privé. Au lieu de cela, dirigez-les vers un canal public désigné. + +La communication publique peut être aussi simple que de diriger les gens à ouvrir une issue au lieu de vous envoyer directement un e-mail ou de commenter votre blog. Vous pouvez également créer une liste de diffusion ou créer un compte Twitter, Slack ou un canal IRC pour que les gens puissent parler de votre projet. Ou essayez tout ce qui précède ! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) réserve des heures de bureau toutes les deux semaines pour aider les membres de la communauté: + +> Kops a également du temps mis de côté toutes les deux semaines pour offrir de l'aide et des conseils à la communauté. Les mainteneurs de Kops ont convenu de consacrer du temps spécifiquement dédié au travail avec les nouveaux arrivants, en aidant sur les PR, et en discutant de nouvelles fonctionnalités. + +Les exceptions notables à la communication publique sont: 1) les problèmes de sécurité et 2) les violations de code de conduite sensibles. Vous devriez toujours avoir un moyen pour les gens de signaler ces problèmes en privé. Si vous ne souhaitez pas utiliser votre adresse e-mail personnelle, configurez une adresse e-mail dédiée. + +## Cultiver votre communauté + +Les communautés sont extrêmement puissantes. Ce pouvoir peut être une bénédiction ou une malédiction, selon la façon dont vous l'utilisez. Au fur et à mesure que la communauté de votre projet grandit, il existe des moyens de l'aider à devenir une force de construction, pas de destruction. + +### Ne tolérez pas les mauvais acteurs + +Tout projet populaire attirera inévitablement des gens qui nuisent à votre communauté plutôt que de l'aider. Ils peuvent lancer des débats inutiles, ergoter sur des fonctionnalités triviales, ou intimider les autres. + +Faites de votre mieux pour adopter une politique de tolérance zéro envers ces types de personnes. Si rien n'est fait, les personnes négatives mettront mal à l'aise les autres membres de votre communauté. Ils peuvent même partir. + + + +Des débats réguliers sur des aspects triviaux de votre projet distraient les autres, y compris vous, de se concentrer sur des tâches importantes. Les nouvelles personnes qui arrivent à votre projet peuvent voir ces conversations et ne veulent pas participer. + +Lorsque vous voyez un comportement négatif se produire sur votre projet, appelez-le publiquement. Expliquez, d'un ton ferme mais ferme, pourquoi leur comportement n'est pas acceptable. Si le problème persiste, vous devrez peut-être [leur demander de partir](../code-of-conduct/#appliquer-votre-code-de-conduite). Votre [code de conduite](../code-of-conduct/) peut être un guide constructif pour ces conversations. + +### Rencontrez les contributeurs là où ils sont + +Une bonne documentation devient seulement plus importante au fur et à mesure que votre communauté se développe. Les contributeurs occasionnels, qui ne connaissent peut-être pas votre projet, lisent votre documentation pour obtenir rapidement le contexte dont ils ont besoin. + +Dans votre fichier CONTRIBUTING, expliquez explicitement aux nouveaux contributeurs comment démarrer. Vous pouvez même créer une section dédiée à cet effet. [Django](https://github.com/django/django), par exemple, a une page de destination spéciale pour accueillir de nouveaux contributeurs. + +![Page des nouveaux contributeurs de Django](/assets/images/building-community/django_new_contributors.png) + +Dans votre liste d'issue en attente, étiquetez les bogues qui conviennent à différents types de contributeurs : par exemple, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, ou _"documentation"_. [Ces étiquettes](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) facilitent l'analyse rapide de vos issues par une personne nouvelle dans votre projet de commencer. + +Enfin, utilisez votre documentation pour que les gens se sentent les bienvenus à chaque étape du processus. + +Vous n'interagirez jamais avec la plupart des personnes qui atterrissent sur votre projet. Il se peut que vous ayez reçu des contributions parce que quelqu'un se sentait intimidé ou ne savait pas par où commencer. Même quelques mots gentils peuvent empêcher quelqu'un de quitter votre projet avec de la frustration. + +Par exemple, voici comment [Rubinius](https://github.com/rubinius/rubinius/) commence [son guide de contribution] (https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) : + +> Nous voulons commencer par vous dire merci d'utiliser Rubinius. Ce projet est un travail d'amour, et nous apprécions tous les utilisateurs qui détectent les bogues, améliorent les performances et aident à la documentation. Chaque contribution est significative, alors merci de votre participation. Cela étant dit, voici quelques lignes directrices que nous vous demandons de suivre afin que nous puissions résoudre votre problème avec succès. + +### Partager la propriété de votre projet + + + +Les gens sont enthousiastes à l'idée de contribuer à des projets lorsqu'ils éprouvent un sentiment d'appartenance. Cela ne signifie pas que vous devez retourner la vision de votre projet ou accepter des contributions que vous ne voulez pas. Mais plus vous donnez du crédit aux autres, plus ils resteront. + +Voyez si vous pouvez trouver le moyen de partager la propriété avec votre communauté autant que possible. Voici quelques idées: + +* **Résistez à corriger les bogues faciles (non critiques).** Utilisez-les plutôt comme des opportunités de recruter de nouveaux contributeurs, ou d'encadrer quelqu'un qui aimerait contribuer. Cela peut sembler anormal au début, mais votre investissement sera rentable au fil du temps. Par exemple, @michaeljoseph a demandé à un contributeur de soumettre une pull request sur une issue [Cookiecutter](https://github.com/audreyr/cookiecutter) ci-dessous, plutôt que de le réparer lui-même. + +![Problème de Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Démarrez un fichier CONTRIBUTORS ou AUTHORS dans votre projet** qui répertorie tous ceux qui ont contribué à votre projet, comme [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Si vous avez une communauté importante **, envoyez un bulletin d'information ou rédigez un article** remerciant les contributeurs. [La semaine de Rust](https://this-week-in-rust.org/) et celle de Hoodie [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) sont deux bons exemples. + +* **Donnez à chaque contributeur un droit de commit.** @felixge a trouvé que cela rendait les gens [plus excités de fignoler leurs patches](https://felixge.de/2013/03/11/the-pull-request-hack.html ), et il a même trouvé de nouveaux responsables pour des projets sur lesquels il n'avait pas travaillé depuis longtemps. + +* Si votre projet est sur GitHub, **déplacez votre projet de votre compte personnel vers un [compte Organisation](https://help.github.com/articles/creating-a-new-organization-account/)** et ajoutez au moins un administrateur de sauvegarde. Les organisations facilitent le travail sur des projets avec des collaborateurs externes. + +La réalité est que [la plupart des projets ont seulement](https://peerj.com/preprints/1233/) un ou deux mainteneurs qui font la plupart du travail. Plus votre projet est important et plus votre communauté est grande, plus il est facile de trouver de l'aide. + +Même s'il se peut que vous ne trouviez pas toujours quelqu'un pour répondre à l'appel, envoyer un signal augmente les chances que d'autres personnes interviennent. Plus tôt vous commencerez, plus tôt les gens pourront vous aider. + + + +## Résoudre les conflits + +Au début de votre projet, prendre des décisions importantes est facile. Quand vous voulez faire quelque chose, vous le faites simplement. + +Au fur et à mesure que votre projet gagne en popularité, de plus en plus de gens s'intéresseront aux décisions que vous prendrez. Même si vous n'avez pas une grande communauté de contributeurs, si votre projet compte beaucoup d'utilisateurs, vous trouverez des personnes qui pèsent sur les décisions ou qui soulèvent des problèmes. + +Pour la plupart, si vous avez cultivé une communauté amicale et respectueuse et documenté vos processus ouvertement, votre communauté devrait être capable de trouver une solution. Mais parfois, vous rencontrez un problème qui est un peu plus difficile à résoudre. + +### Mettre la barre pour la gentillesse + +Lorsque votre communauté est aux prises avec un problème difficile, la colère peut monter. Les gens peuvent devenir fâchés ou frustrés et s'en prendre à un autre ou à vous. + +Votre travail en tant que mainteneur consiste à éviter l'escalade de ces situations. Même si vous avez une opinion forte sur le sujet, essayez de prendre la position d'un modérateur ou d'un facilitateur, plutôt que de vous jeter dans la bagarre et de faire valoir vos points de vue. Si quelqu'un est méchant ou accapare la conversation, [agissez immédiatement](../building-community/#ne-tolérez-pas-les-mauvais-acteurs) pour garder les discussions civiles et productives. + + + +D'autres personnes se tournent vers vous pour obtenir des conseils. Donner le bon exemple. Vous pouvez toujours exprimer votre déception, votre tristesse ou votre inquiétude, mais faites-le calmement. + +Garder son calme n'est pas facile, mais faire preuve de leadership améliore la santé de votre communauté. L'internet vous remercie. + +### Traitez votre fichier README en tant que constitution + +Votre fichier README est [plus qu'un simple jeu d'instructions](../starting-a-project/#ecrire-un-fichier-readme). C'est aussi un endroit où parler de vos objectifs, de votre vision du produit et de votre feuille de route. Si les gens sont trop concentrés sur le débat sur le mérite d'une fonctionnalité particulière, il peut être utile de revoir votre fichier README et de parler de la vision plus élevée de votre projet. En vous concentrant sur votre fichier README, vous dépersonnalisez la conversation, ce qui vous permet d'avoir une discussion constructive. + +### Focus sur le voyage, pas la destination + +Certains projets utilisent un processus de vote pour prendre des décisions importantes. Bien que raisonnable à première vue, le vote met l'accent sur le fait d'arriver à une "réponse", plutôt que d'écouter et de répondre aux préoccupations de l'autre. + +Le vote peut devenir politique, où les membres de la communauté se sentent poussés à se faire des faveurs ou à voter d'une certaine manière. Pas tout le monde vote, que ce soit la [majorité silencieuse](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) dans votre communauté, ou les utilisateurs actuels qui ne savaient pas qu'un vote avait lieu. + +Parfois, le vote est un arbitre nécessaire. Cependant, autant que vous le pouvez, insistez sur ["recherche de consensus"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) plutôt que sur un consensus. + +Dans le cadre d'un processus de recherche de consensus, les membres de la communauté discutent des préoccupations majeures jusqu'à ce qu'ils sentent qu'ils ont été suffisamment entendus. Lorsque seules des préoccupations mineures subsistent, la communauté va de l'avant. La recherche d'un consensus reconnaît qu'une communauté peut ne pas être capable d'atteindre une réponse parfaite. Au lieu de cela, il donne la priorité à l'écoute et à la discussion. + + + +Même si vous n'adoptez pas un processus de recherche de consensus, en tant que responsable de projet, il est important que les gens sachent que vous écoutez. Faire en sorte que les autres se sentent entendus, et s'engager à résoudre leurs problèmes, contribue grandement à la diffusion des situations sensibles. Ensuite, suivez vos mots avec des actions. + +Ne vous précipitez pas dans une décision pour avoir une résolution. Assurez-vous que tout le monde se sente entendu et que toutes les informations ont été rendues publiques avant de passer à une résolution. + +### Maintenir la conversation centrée sur l'action + +La discussion est importante, mais il y a une différence entre les conversations productives et improductives. + +Encouragez la discussion tant qu'elle avance activement vers la résolution. S'il est clair que la conversation est en train de languir ou de sortir du sujet, les jabs deviennent personnels, ou les gens ergotent sur des détails mineurs, il est temps de les fermer. + +Permettre ces conversations de continuer n'est pas seulement mauvais pour le problème en question, mais mauvais pour la santé de votre communauté. Il envoie un message que ces types de conversations sont autorisés ou même encouragés, et cela peut décourager les gens de relever ou de résoudre des futures issues. + +Avec chaque point que vous ou d'autres avez fait valoir, demandez-vous:_"Comment cela nous rapproche-t-il d'une résolution ?"_ + +Si la conversation commence à se dérouler, demandez au groupe: _"Quelles étapes devrions-nous prendre ensuite ?"_ Pour recentrer la conversation. + +Si une conversation ne va clairement nulle part, il n'y a pas de mesures claires à prendre, ou les mesures appropriées ont déjà été prises, fermez l'issue et expliquez pourquoi vous l'avez fermé. + + + +### Choisissez vos batailles avec sagesse + +Le contexte est important. Considérez qui est impliqué dans la discussion et comment il représente le reste de la communauté. + +Est-ce que tout le monde dans la communauté est mécontent, voir même concerné par ce problème ? Ou est ce un fauteur de troubles solitaire ? N'oubliez pas de considérer vos membres de la communauté silencieuse, pas seulement les voix actives. + +Si le problème ne représente pas les besoins plus larges de votre communauté, vous devrez peut-être simplement prendre en compte les préoccupations de quelques personnes. S'il s'agit d'un problème récurrent sans résolution claire, indiquez-le aux discussions précédentes sur le sujet et fermez le fil. + +### Identifier un arbitre communautaire + +Avec une bonne attitude et une communication claire, la plupart des situations difficiles peuvent être résolues. Cependant, même dans une conversation productive, il peut simplement y avoir une différence d'opinion sur la façon de procéder. Dans ces cas, identifiez un individu ou un groupe de personnes pouvant servir d'arbitre d'égalité. + +Un arbitre pourrait être le principal responsable du projet, ou il pourrait s'agir d'un petit groupe de personnes qui prendrait une décision en fonction du vote. Idéalement, vous avez identifié une condition de départage et le processus associé dans un fichier GOVERNANCE avant de devoir l'utiliser. + +Votre bris d'égalité devrait être un dernier recours. Les problèmes diviseurs sont une opportunité pour votre communauté de grandir et d'apprendre. Adoptez ces opportunités et utilisez un processus collaboratif pour passer à une résolution dans la mesure du possible. + +## La communauté est le ❤️ de l'open source + +Des communautés saines et prospères alimentent les milliers d'heures consacrées à l'open source chaque semaine. Beaucoup de contributeurs pointent vers d'autres personnes comme la raison de travailler - ou ne pas travailler - sur l'open source. En apprenant comment exploiter ce pouvoir de manière constructive, vous aiderez quelqu'un à vivre une expérience open source inoubliable. diff --git a/_articles/fr/code-of-conduct.md b/_articles/fr/code-of-conduct.md new file mode 100644 index 00000000000..aeea86586fb --- /dev/null +++ b/_articles/fr/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: fr +title: Votre code de conduite +description: Faciliter un comportement communautaire sain et constructif en adoptant et en appliquant un code de conduite. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Pourquoi un code de conduite + +Un code de conduite est un document qui établit des attentes de comportement pour les participants de votre projet. Adopter et appliquer un code de conduite peut aider à créer une atmosphère sociale positive pour votre communauté. + +Les codes de conduite aident à protéger non seulement vos participants, mais vous-même. Si vous maintenez un projet, vous constaterez peut-être que les attitudes improductives des autres participants peuvent vous fatiguer ou vous faire sentir malheureux au sujet de votre travail au fil du temps. + +Un code de conduite vous permet de faciliter un comportement communautaire sain et constructif. Être proactif réduit la probabilité que vous, ou d'autres, soyez fatigué avec votre projet, et vous aide à agir lorsque quelqu'un fait quelque chose avec lequel vous n'êtes pas d'accord. + +## Etablir un code de conduite + +Essayez d'établir un code de conduite le plus tôt possible: idéalement, dès que vous créez votre projet. + +En plus de communiquer vos attentes, un code de conduite décrit ce qui suit: + +* Où le code de conduite prend effet _(uniquement sur les issues et les pull request, ou les activités communautaires comme les événements ?)_ +* Qui le code de conduite s'applique-t-il _(membres de la communauté et les mainteneurs, mais qu'en est-il des sponsors ?)_ +* Que se passe-t-il si quelqu'un enfreint le code de conduite +* Comment quelqu'un peut-il signaler les violations + +Quand vous le pouvez, utilisez l'existant. Le [Contributor Covenant](https://contributor-covenant.org/) est un code de conduite qui est utilisé par plus de 40 000 projets open source, y compris Kubernetes, Rails et Swift. + +Le [Django Code of Conduct](https://www.djangoproject.com/conduct/) et le [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sont également deux bons exemples de code de conduite. + +Placez un fichier CODE_OF_CONDUCT dans le répertoire racine de votre projet et rendez-le visible pour votre communauté en le liant à votre fichier CONTRIBUTING ou README. + +## Décider comment vous allez appliquer votre code de conduite + + + +Vous devrez expliquer comment votre code de conduite sera appliqué **_avant_** qu'une violation se produise. Il y a plusieurs raisons de le faire: + +* Cela montre que vous êtes capable de prendre les mesures nécessaires quand il y a besoin. + +* Votre communauté se sentira plus rassurée que les plaintes soient réellement examinées. + +* Vous rassurez votre communauté sur le fait que le processus d'examen est juste et transparent, si jamais ils se retrouvaient à enquêter sur une violation. + +Vous devriez donner aux gens un moyen privé (comme une adresse e-mail) de signaler une violation du code de conduite et d'expliquer qui reçoit ce rapport. Il pourrait s'agir d'un responsable, d'un groupe de responsables ou d'un groupe de travail sur le code de conduite. + +N'oubliez pas que quelqu'un pourrait vouloir signaler une violation à propos d'une personne qui reçoit ces rapports. Dans ce cas, donnez-leur la possibilité de signaler les violations à quelqu'un d'autre. Par exemple, @ctb et @mr-c [expliquent sur leur projet](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer) : + +> Les cas de comportement abusif, harcelant ou autrement inacceptable peuvent être signalés en envoyant un courriel à **khmer-project@idyll.org**, ce qui ne concerne que C. Titus Brown et Michael R. Crusoe. Pour signaler un problème concernant l'un ou l'autre d'entre eux, veuillez envoyer un courriel à **Judi Brown Clarke, Ph. D.** Directrice de la diversité au Centre BEACON pour l'étude de l'évolution en action, un centre NSF pour la science et la technologie.* + +Pour l'inspiration, consultez le [manuel d'application](https://www.djangoproject.com/conduct/enforcement-manual/) de Django (bien que vous n'ayez pas besoin de quelque chose d'aussi complet, selon la taille de votre projet). + +## Appliquer votre code de conduite + +Parfois, malgré tous vos efforts, quelqu'un va faire quelque chose qui viole ce code. Il existe plusieurs façons d'aborder les comportements négatifs ou nuisibles quand ils surviennent. + +### Recueillir des informations sur la situation + +Traitez la voix de chaque membre de la communauté comme étant aussi importante que la vôtre. Si vous recevez un signalement de quelqu'un qui a enfreint le code de conduite, prenez-le au sérieux et faites une enquête, même si cela ne correspond pas à votre propre expérience avec cette personne. Cela indique à votre communauté que vous appréciez leur point de vue et faites confiance à leur jugement. + +Le membre de la communauté en question peut être un récidiviste qui incite constamment les autres à se sentir mal à l'aise, ou il se peut qu'ils aient seulement dit ou fait quelque chose une fois. Les deux peuvent être des motifs d'action, selon le contexte. + +Avant de répondre, donnez-vous le temps de comprendre ce qui s'est passé. Lisez les commentaires et les conversations passés de la personne pour mieux comprendre qui ils sont et pourquoi ils ont agi de cette façon. Essayez de recueillir des points de vues autres que le vôtre au sujet de cette personne et de son comportement. + + + +### Prendre les mesures appropriées + +Après avoir recueilli et traité suffisamment d'informations, vous devrez décider quoi faire. Lorsque vous considérez vos prochaines étapes, n'oubliez pas que votre objectif en tant que modérateur est de favoriser un environnement sûr, respectueux et collaboratif. Ne considérez pas seulement comment faire face à la situation en question, mais comment votre réponse affectera le reste du comportement et les attentes de votre communauté à aller de l'avant. + +Quand quelqu'un signale une violation du code de conduite, c'est votre travail, et non le leur, que de le gérer. Parfois, le déclarant divulgue des informations mettant en péril sa carrière, sa réputation ou sa sécurité physique. Les forcer à affronter son harceleur pourrait mettre le déclarant dans une position compromettante. Vous devez gérer la communication directe avec la personne en question, à moins que le déclarant ne demande explicitement le contraire. + +Il existe plusieurs façons de répondre à une violation du code de conduite: + +* **Donnez à la personne en question un avertissement public** et expliquez comment son comportement a eu un impact négatif sur les autres, de préférence dans le canal où il s'est produit. Dans la mesure du possible, la communication publique indique au reste de la communauté que vous prenez le code de conduite au sérieux. Soyez gentil, mais ferme dans votre communication. + +* **Communiquer en privé avec la personne** en question pour lui expliquer comment son comportement a eu un impact négatif sur les autres. Vous pouvez utiliser un canal de communication privé si la situation implique des informations personnelles sensibles. Si vous communiquez avec quelqu'un en privé, c'est une bonne idée de mettre en copie ceux qui ont d'abord signalé la situation, alors ils savent que vous avez pris des mesures. Dans ce cas, demandez le consentement du déclarant avant. + +Parfois, une résolution ne peut pas être atteinte. La personne en question peut devenir agressive ou hostile lorsqu'elle est confrontée ou ne change pas son comportement. Dans cette situation, vous pouvez envisager de prendre des mesures plus énergiques. Par exemple: + +* **Suspendre la personne** en question du projet, imposée par une interdiction temporaire de participer à tout aspect du projet + +* **Interdire définitivement** la personne du projet + +Interdire les membres ne devrait pas être pris à la légère et représente une différence de perspective permanente et irréconciliable. Vous ne devriez prendre ces mesures que lorsqu'il est clair qu'une résolution ne peut pas être atteinte. + +## Vos responsabilités en tant que mainteneur + +Un code de conduite n'est pas une loi imposée arbitrairement. Vous êtes l'exécutant du code de conduite et il est de votre responsabilité de suivre les règles établies par le code de conduite. + +En tant que responsable, vous établissez les lignes directrices pour votre communauté et appliquez ces directives conformément aux règles énoncées dans votre code de conduite. Cela signifie prendre au sérieux tout rapport d'une violation du code de conduite. Les déclarants ont droit à un examen approfondi et équitable de leurs plaintes. Si vous déterminez que le comportement signalé n'est pas une violation, communiquez-le clairement et expliquez pourquoi vous n'allez pas agir. Ce qu'ils feront avec cela leur appartient: tolérer le comportement avec lequel ils ont un problème ou cesser de participer à la communauté. + +Un rapport de comportement qui ne viole pas _théoriquement_ le code de conduite peut toujours indiquer qu'il y a un problème dans votre communauté, et vous devriez étudier ce problème potentiel et agir en conséquence. Cela peut inclure la révision de votre code de conduite pour clarifier un comportement acceptable et/ou parler à la personne dont le comportement a été signalé et lui signaler que bien qu'il n'ai pas enfreint le code de conduite, il est en train de contourner ce qui en est attendu et que certain participants en sont mal à l'aise. + +En fin de compte, en tant que responsable, vous définissez et appliquez les normes pour un comportement acceptable. Vous avez la capacité de façonner les valeurs communautaires du projet, et les participants s'attendent à ce que vous appliquiez ces valeurs de manière juste et équitable. + +## Encouragez le comportement que vous voulez voir dans le monde 🌎 + +Quand un projet semble hostile ou peu accueillant, même si ce n'est qu'une personne dont le comportement est toléré par les autres, vous risquez de perdre beaucoup plus de contributeurs, dont certains ne se rencontreront peut-être jamais. Il n'est pas toujours facile d'adopter ou d'appliquer un code de conduite, mais favoriser un environnement accueillant aidera votre communauté à grandir. diff --git a/_articles/fr/finding-users.md b/_articles/fr/finding-users.md new file mode 100644 index 00000000000..ab5c6e81ac4 --- /dev/null +++ b/_articles/fr/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: fr +title: Trouver des utilisateurs pour votre projet +description: Aidez votre projet Open Source à se développer en le mettant entre les mains d'utilisateurs satisfaits. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Passer le mot + +Il n'y a pas de règle qui stipule que vous devez promouvoir un projet open source lors de votre lancement. Il existe de nombreuses raisons satisfaisantes de travailler en open source qui n'ont rien à voir avec la popularité. Au lieu d'espérer que les autres trouveront et utiliseront votre projet open source, vous devez passer le mot au sujet de votre dur labeur ! + +## Bien concevoir votre message + +Avant de commencer le travail de promotion de votre projet, vous devriez être en mesure d'expliquer ce qu'il fait et pourquoi c'est important. + +Qu'est-ce qui rend votre projet différent ou intéressant ? Pourquoi l'avez-vous créé ? Répondre à ces questions par vous-même vous aidera à communiquer l'importance de votre projet. + +Rappelez-vous que les gens s'impliquent en tant qu'utilisateurs et deviennent éventuellement des contributeurs, car votre projet résout un problème pour eux. En réfléchissant au message et à la valeur de votre projet, essayez de les voir sous l'angle de ce que les _utilisateurs et les contributeurs_ pourraient vouloir. + +Par exemple, @robb utilise des exemples de code pour expliquer clairement pourquoi son projet, [Cartography](https://github.com/robb/Cartography), est utile: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +Pour plus d'information concernant la messagerie, consultez l'exercice de Mozilla ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) pour développer des utilisateurs. + +## Aidez les gens à trouver et à suivre votre projet + + + +Aidez les internautes à trouver et à retenir votre projet en les pointant vers un espace de nom unique. + +**Ayez une poignée claire pour promouvoir votre travail.** Un Twitter, une URL GitHub, ou un canal IRC est un moyen facile de diriger les gens vers votre projet. Ces points de vente permettent également à la communauté grandissante de votre projet de se réunir. + +Si vous ne souhaitez pas encore créer de points de vente pour votre projet, faites la promotion de votre propre compte Twitter ou GitHub dans tout ce que vous faites. La promotion de votre compte Twitter ou GitHub permettra aux gens de savoir comment vous contacter ou suivre votre travail. Si vous parlez lors d'une rencontre ou d'un événement, assurez-vous que vos coordonnées sont incluses dans votre bio ou vos diapositives. + + + +**Envisagez de créer un site Web pour votre projet.** Un site Web rend votre projet plus convivial et plus facile à parcourir, surtout lorsqu'il est associé à une documentation et à des tutoriels clairs. Avoir un site Web suggère également que votre projet est actif, ce qui rendra votre auditoire plus à l'aise pour l'utiliser. Donnez des exemples pour donner aux gens des idées sur la façon d'utiliser votre projet. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-créateur de Django, a déclaré qu'un site web était _"de loin la meilleure chose que nous ayons faite avec Django au début"_. + +Si votre projet est hébergé sur GitHub, vous pouvez utiliser [les Pages GitHub](https://pages.github.com/) pour créer facilement un site web. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), et [Middleman](https://middlemanapp.com/) sont [quelques exemples](https://github.com/showcases/github-pages-examples) d'excellents sites Web complets. + +![Page d'accueil Vagrant](/assets/images/finding-users/vagrant_homepage.png) + +Maintenant que vous avez un message pour votre projet et un moyen facile pour les gens de trouver votre projet, allez-y et parlez à votre auditoire ! + +## Allez là où se trouve le public de votre projet (en ligne) + +La sensibilisation en ligne est un excellent moyen de partager et de répandre le mot rapidement. En utilisant les canaux en ligne, vous avez le potentiel d'atteindre un très large public. + +Tirez parti des communautés et des plateformes en ligne existantes pour atteindre votre public. Si votre projet open source est un projet logiciel, vous pouvez probablement trouver votre public sur [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), ou [Quora](https://www.quora.com/). Trouvez les canaux dont vous pensez que les gens vont le plus tirer profit ou seront le plus enthousiasmés par votre travail. + + + +Voyez si vous pouvez trouver des moyens de partager votre projet de manière pertinente : + +* **Apprenez à connaître les projets open source pertinents et les communautés.** Parfois, vous n'avez pas à promouvoir directement votre projet. Si votre projet est parfait pour les scientifiques de données qui utilisent Python, familiarisez-vous avec la communauté de la science des données Python. Au fur et à mesure que les gens vous connaîtront, des occasions naturelles se présenteront pour parler et partager votre travail. +* **Trouvez des personnes rencontrant le problème que votre projet résout.** Recherchez dans les forums connexes pour les personnes qui tombent dans le public cible de votre projet. Répondez à leur question et trouvez avec tact un moyen de suggérer votre projet comme solution. +* **Demandez des commentaires.** Présentez-vous et votre travail à un public qui le trouverait pertinent et intéressant. Soyez précis au sujet de qui, selon vous, bénéficierait de votre projet. Essayez de finir la phrase: _"Je pense que mon projet aiderait vraiment X, qui essaye de faire Y"_. Écoutez et répondez aux commentaires des autres, plutôt que de simplement promouvoir votre travail. + +En général, concentrez-vous sur l'aide aux autres avant de demander des choses en retour. Parce que n'importe qui peut facilement promouvoir un projet en ligne, il y aura beaucoup de bruit. Pour se démarquer de la foule, donnez aux gens un contexte pour ce que vous êtes et pas seulement ce que vous voulez. + +Si personne ne fait attention ou répond à vos premiers contacts, ne vous découragez pas ! La plupart des lancements de projets sont un processus itératif qui peut prendre des mois ou des années. Si vous n'obtenez pas de réponse la première fois, essayez une tactique différente, ou cherchez d'abord des façons d'ajouter de la valeur au travail des autres. La promotion et le lancement de votre projet demandent du temps et du dévouement. + +## Allez là où se trouve le public de votre projet (hors ligne) + +![Conférence publique](/assets/images/finding-users/public_speaking.jpg) + +Les événements hors ligne sont un moyen populaire de promouvoir de nouveaux projets auprès des publics. Ils constituent un excellent moyen d'atteindre un public engagé et de tisser des liens humains plus profonds, en particulier si vous souhaitez toucher les développeurs. + +Si vous êtes [nouveau sur la prise de parole en public](https://speaking.io/), commencez par trouver une rencontre locale liée à la langue ou à l'écosystème de votre projet. + + + +Si vous n'avez jamais parlé à un événement auparavant, il est tout à fait normal de vous sentir nerveux ! Rappelez-vous que votre auditoire est là parce qu'il veut vraiment entendre parler de votre travail. + +Au fur et à mesure que vous écrivez votre exposé, concentrez-vous sur ce que votre auditoire trouvera intéressant et dont vous tirerez profit. Gardez votre ton amical et accessible. Souriez, respirez et amusez-vous. + + + +Lorsque vous êtes prêt, envisagez de prendre la parole lors d'une conférence pour promouvoir votre projet. Les conférences peuvent vous aider à atteindre plus de gens, parfois de partout dans le monde. + +Recherchez des conférences spécifiques à votre langue ou à votre écosystème. Avant de soumettre votre exposé, faites des recherches sur la conférence pour adapter votre discours aux participants et augmenter vos chances d'être accepté pour prendre la parole à la conférence. Vous pouvez souvent avoir une idée de votre auditoire en regardant les conférenciers d'une conférence. + + + +## Construire une réputation + +En plus des stratégies décrites ci-dessus, la meilleure façon d'inviter les gens à partager et à contribuer à votre projet est de partager et de contribuer à leurs projets. + +Aider les nouveaux arrivants, partager des ressources et apporter une contribution réfléchie aux projets des autres vous aidera à vous bâtir une réputation positive. Être un membre actif dans la communauté open source aidera les gens à avoir un contexte pour votre travail et sera plus susceptible de prêter attention et de partager votre projet. Développer des relations avec d'autres projets open source peut même conduire à des partenariats officiels. + + + +Il n'est jamais trop tôt ou trop tard pour commencer à bâtir votre réputation. Même si vous avez déjà lancé votre propre projet, continuez de chercher des moyens d'aider les autres. + +Il n'y a pas de solution du jour au lendemain pour créer un public. Gagner la confiance et le respect des autres prend du temps, et bâtir votre réputation ne s'arrête jamais. + +## Persévérez ! + +Cela peut prendre beaucoup de temps avant que les gens remarquent votre projet open source. C'est bon ! Certains des projets les plus populaires aujourd'hui ont pris des années pour atteindre des niveaux d'activité élevés. Concentrez-vous sur l'établissement de relations au lieu d'espérer que votre projet gagnera spontanément en popularité. Soyez patient et continuez à partager votre travail avec ceux qui l'apprécient. diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md new file mode 100644 index 00000000000..e27b37939ff --- /dev/null +++ b/_articles/fr/getting-paid.md @@ -0,0 +1,172 @@ +--- +lang: fr +title: Etre payé pour faire de l'Open Source +description: Soutenez votre travail en Open Source en obtenant un soutien financier pour votre temps ou votre projet. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Pourquoi certaines personnes cherchent un soutien financier + +Une grande partie du travail open source est volontaire. Par exemple, une personne peut rencontrer un bogue dans un projet qu'elle utilise et soumettre une solution rapide, ou alors, elle peut s'amuser à bricoler un projet open source pendant son temps libre. + + + +Il y a plusieurs raisons pour lesquelles une personne ne voudrait pas être payée pour son travail open source. + +* **Ils ont peut-être déjà un emploi à temps plein qu'ils aiment**, ce qui leur permet de contribuer à l'open source pendant leur temps libre. +* **Ils aiment penser à l'open source comme un passe-temps** ou une évasion créative et ne veulent pas se sentir financièrement obligés de travailler sur leurs projets. +* **Ils ont d'autres avantages à contribuer à l'open source**, comme bâtir leur réputation ou leur portfolio, apprendre une nouvelle compétence ou se sentir plus proches d'une communauté. + + + +Pour d'autres, surtout lorsque les contributions sont en cours ou demandent beaucoup de temps, être payé pour contribuer à l'open source est la seule façon de participer, soit parce que le projet l'exige, soit pour des raisons personnelles. + +Maintenir des projets populaires peut être une responsabilité importante, en prenant 10 ou 20 heures par semaine au lieu de quelques heures par mois. + + + +Le travail rémunéré permet également aux personnes de différents horizons de faire des contributions significatives. Certaines personnes ne peuvent pas se permettre de consacrer du temps non rémunéré à des projets Open Source, en fonction de leur situation financière actuelle, de leur dette, de leur famille ou d'autres obligations. Cela signifie que le monde ne voit jamais les contributions de personnes talentueuses qui ne peuvent pas se permettre de faire du bénévolat. Cela a des implications éthiques, comme @ashedryden [a décrit](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), puisque le travail qui est fait est biaisés en faveur de ceux qui ont déjà des avantages dans la vie, qui obtiennent ensuite des avantages supplémentaires en fonction de leurs contributions bénévoles, tandis que d'autres qui ne peuvent pas faire de bénévolat n'obtiennent pas d'opportunités ultérieures, ce qui renforce le manque de diversité au sein de la communauté de l'open source. + + + +Si vous cherchez un soutien financier, il y a deux pistes à considérer. Vous pouvez financer votre propre temps en tant que contributeur, ou vous pouvez trouver un financement organisationnel pour le projet. + +## Financer votre temps + +Aujourd'hui, beaucoup de gens sont payés pour travailler à temps plein ou à temps partiel. La façon la plus courante d'être payé pour votre temps est de parler à votre employeur. + +Il est plus facile de plaider en faveur du travail open source si votre employeur utilise réellement le projet, mais soyez créatif avec votre argumentaire. Peut-être que votre employeur n'utilise pas le projet, mais ils utilisent Python, et le maintien d'un projet populaire Python aide à attirer de nouveaux développeurs Python. Peut-être que cela rend votre employeur plus convivial en général. + +Si vous n'avez pas de projet Open Source sur lequel vous souhaitez travailler, mais préférez que votre travail actuel soit ouvert, demandez à votre employeur d'ouvrir certains de ses logiciels internes. + +De nombreuses entreprises développent des programmes open source pour construire leur marque et recruter des talents de qualité. + +@hueniverse, par exemple, a trouvé qu'il y avait des raisons financières pour justifier [l'investissement de Walmart dans l'open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Et @jamesgpearce a trouvé que le programme open source de Facebook [a fait une différence](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) dans le recrutement: + +> Il est étroitement lié à notre culture de hackers et à la perception de notre organisation. Nous avons demandé à nos employés: "Connaissiez-vous le logiciel Open Source sur Facebook ?" Les deux tiers ont dit "Oui". La moitié a déclaré que le programme a contribué positivement à leur décision de travailler pour nous. Ce ne sont pas des chiffres marginaux, et j'espère, une tendance qui se poursuit. + +Si votre entreprise suit cette voie, il est important de garder les limites entre les activités communautaires et corporatives. En fin de compte, l'open source s'appuie sur les contributions de personnes du monde entier, et c'est plus important que n'importe quelle entreprise ou emplacement. + + + +Si vous ne pouvez pas convaincre votre employeur actuel d'accorder la priorité au travail open source, envisagez de trouver un nouvel employeur qui encourage les contributions des employés à l'open source. Cherchez des entreprises qui rendent explicite leur dévouement au travail open source. Par exemple : + +* Certaines entreprises, comme [Netflix](https://netflix.github.io/), ont des sites Web qui soulignent leur implication dans l'open source + +Les projets provenant d'une grande entreprise, tels que [Go](https://github.com/golang) ou [React](https://github.com/facebook/react), emploieront probablement des personnes pour travailler sur Open source. + +Enfin, en fonction de votre situation personnelle, vous pouvez essayer de collecter des fonds de manière indépendante pour financer votre travail open source. Par exemple : + +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) +* @gaearon a fait financer son travail sur [Redux](https://github.com/reactjs/redux) via une [campagne de crowdfunding sur Patreon](https://redux.js.org/) +* @andrewgodwin a fait financer le travail sur les migrations de schémas Django [à travers une campagne Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +## Trouver du financement pour votre projet + +Au-delà des arrangements pour les contributeurs individuels, les projets recueillent parfois des fonds auprès d'entreprises, de particuliers ou d'autres pour financer des travaux en cours. + +Le financement organisationnel pourrait servir à payer les contributeurs actuels, à couvrir les coûts de gestion du projet (tels que les frais d'hébergement) ou à investir dans de nouvelles fonctionnalités ou idées. + +À mesure que la popularité de l'open source augmente, la recherche de financement pour des projets est encore expérimentale, mais il existe quelques options communes disponibles. + +### Gagnez de l'argent pour votre travail grâce à des campagnes de crowdfunding ou de parrainage + +Trouver des commandites fonctionne bien si vous avez déjà un public ou une réputation solide, ou si votre projet est très populaire. +Quelques exemples de projets sponsorisés incluent: + +* **[webpack](https://github.com/webpack)** collecte des fonds auprès des entreprises et des particuliers [via OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** une organisation à but non lucratif qui paie pour travailler sur [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), et d'autres projets d'infrastructure Ruby + +### Créer un flux de revenus + +En fonction de votre projet, vous pouvez facturer un support commercial, des options hébergées ou des fonctionnalités supplémentaires. Quelques exemples incluent: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** propose des versions payantes pour un support supplémentaire +* **[Travis CI](https://github.com/travis-ci)** offre des versions payantes de son produit +* **[Ghost](https://github.com/TryGhost/Ghost)** est un organisme à but non lucratif avec un service géré payant + +Certains projets populaires, tels que [npm](https://github.com/npm/cli) et [Docker](https://github.com/docker/docker), permettent même de lever du capital-risque pour soutenir la croissance de leur entreprise. + +### Demande de financement + +Certaines fondations de logiciels et sociétés offrent des subventions pour le travail open source. Parfois, des subventions peuvent être versées à des personnes sans créer une entité juridique pour le projet. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** a reçu une subvention de [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** le travail a été financé par [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** a reçu une subvention de la [Sloan Foundation](https://sloan.org/programs/digital-technology) +* La **[Python Software Foundation](https://www.python.org/psf/grants/)** offre des subventions pour les travaux liés à Python + +Pour des options plus détaillées et des études de cas, @nayafia [a écrit un guide](https://github.com/nayafia/lemonade-stand) pour être payé pour le travail open source. Différents types de financement nécessitent des compétences différentes, alors considérez vos forces pour déterminer quelle option vous convient le mieux. + +## Bâtir un dossier pour un soutien financier + +Que votre projet soit une nouvelle idée, ou qu'il existe depuis des années, vous devriez vous attendre à réfléchir sérieusement à l'identification de votre bailleur de fonds cible et à présenter un cas convaincant. + +Que vous cherchiez à payer pour votre temps libre ou à collecter des fonds pour un projet, vous devriez être en mesure de répondre aux questions suivantes. + +### Impact + +Pourquoi ce projet est-il utile ? Pourquoi vos utilisateurs, ou les utilisateurs potentiels, l'apprécient-ils autant ? Où sera-ce dans cinq ans ? + +### Traction + +Essayez de recueillir des preuves que votre projet compte, que ce soit des mesures, des anecdotes ou des témoignages. Y a-t-il des entreprises ou des personnes remarquables qui utilisent votre projet en ce moment ? Si non, une personne en vue l'a-t-elle approuvée ? + +### Valeur au donateur + +Les bailleurs de fonds, que ce soit votre employeur ou une fondation subventionnaire, sont fréquemment approchés avec des opportunités. Pourquoi devraient-ils soutenir votre projet par rapport à toute autre opportunité ? Comment en bénéficient-ils personnellement ? + +### Utilisation des fonds + +Qu'allez-vous accomplir exactement avec le financement proposé ? Concentrez-vous sur les jalons ou les résultats du projet plutôt que de payer un salaire. + +### Comment vous recevrez les fonds + +Le bailleur de fonds a-t-il des exigences en matière de déboursement ? Par exemple, vous devrez peut-être être un but non lucratif ou avoir un sponsor fiscal à but non lucratif. Ou peut-être que les fonds doivent être donnés à un entrepreneur individuel plutôt qu'à une organisation. Ces exigences varient selon les bailleurs de fonds, alors assurez-vous de faire vos recherches à l'avance. + + + +## Expérimentez et n'abandonnez pas + +Il n'est pas facile de gagner de l'argent, qu'il s'agisse d'un projet open source, d'un but non lucratif ou d'un démarrage de logiciel, et dans la plupart des cas, vous devez être créatif. Identifier comment vous voulez être payé, faire votre recherche, et vous mettre dans la peau de votre bailleur de fonds vous aidera à construire un argument convaincant pour le financement. diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md new file mode 100644 index 00000000000..83df3ac2c88 --- /dev/null +++ b/_articles/fr/how-to-contribute.md @@ -0,0 +1,514 @@ +--- +lang: fr +title: Comment contribuer à l'Open Source +description: Vous voulez contribuer à l'Open Source ? Un guide pour faire des contributions Open Source, pour les débutants et pour les vétérans. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Pourquoi contribuer à l'open source + + + +Contribuer à l'open source peut être une manière enrichissante d'apprendre, d'enseigner et de construire une expérience dans presque toutes les compétences que vous pouvez imaginer. + +Pourquoi les gens contribuent-ils à l'open source ? Beaucoup de raisons ! + +### Améliorer les compétences existantes + +Que ce soit le codage, la conception de l'interface utilisateur, la conception graphique, la rédaction ou l'organisation, si vous cherchez de la pratique, il y a une tâche pour vous sur un projet open source. + +### Rencontrez des gens qui s'intéressent à des choses similaires + +Les projets Open Source avec des communautés chaleureuses et accueillantes font que les gens reviennent pendant des années. Beaucoup de gens forment des amitiés à vie grâce à leur participation à l'open source, que ce soit dans le cadre de conférences ou de bavardages en ligne tard dans la nuit sur les burritos. + +### Trouver des mentors et enseigner aux autres + +Travailler avec d'autres sur un projet partagé signifie que vous devrez expliquer comment vous faites les choses, ainsi que de demander de l'aide à d'autres personnes. Les actes d'apprentissage et d'enseignement peuvent être une activité enrichissante pour tous ceux qui sont impliqués. + +### Construire des artefacts publics qui vous aident à acquérir une réputation (et une carrière) + +Par définition, tout votre travail open source est public, ce qui signifie que vous obtenez des exemples gratuits à emporter pour démontrer ce que vous pouvez faire. + +### Apprendre les compétences des personnes + +L'Open Source offre des opportunités de pratiquer des compétences de leadership et de gestion, telles que la résolution de conflits, l'organisation d'équipes de personnes et la hiérarchisation du travail. + +### Cela permet de faire des changements, même les plus petits + +Vous n'avez pas besoin de devenir un contributeur permanent pour profiter de la participation à l'open source. Avez-vous déjà vu une faute de frappe sur un site Web et souhaité que quelqu'un la corrige ? Sur un projet open source, vous pouvez le faire. L'Open Source aide les gens à se sentir interpellés par leur vie et leur expérience du monde, ce qui est en soi gratifiant. + +## Que signifie contribuer + +Si vous êtes un nouveau contributeur open source, le processus peut être intimidant. Comment trouvez-vous le bon projet ? Que faire si vous ne savez pas coder ? Et si quelque chose ne va pas ? + +Ne pas s'inquiéter ! Il y a toutes sortes de façons de s'impliquer dans un projet open source, et quelques conseils vous aideront à tirer le meilleur parti de votre expérience. + +### Vous n'avez pas à contribuer au code + +Une idée commune fausse sur la contribution à l'open source est que vous devez contribuer au code. En fait, ce sont souvent les autres parties d'un projet qui sont [le plus négligées ou négligées](https://github.com/blog/2195-the-shape-of-open-source). Vous allez faire une faveur au projet en offrant de participer à ces types de contributions ! + + + +Même si vous aimez écrire du code, d'autres types de contributions sont un excellent moyen de s'impliquer dans un projet et de rencontrer d'autres membres de la communauté. Construire ces relations vous donnera l'opportunité de travailler sur d'autres parties du projet. + +### Aimez-vous la planification d'événements ? + +* Organiser des ateliers ou des meetups sur le projet, [comme @fzamperin a fait pour NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Organiser la conférence du projet (s'ils en ont une) +* Aider les membres de la communauté à trouver les bonnes conférences et soumettre des propositions de talk + +### Aimez-vous créer ? + +* Restructurer les mises en page pour améliorer la convivialité du projet +* Effectuer des recherches utilisateur pour réorganiser et affiner la navigation ou les menus du projet, [comme suggère Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Mettre en place un guide de style pour aider le projet à avoir un design visuel cohérent +* Créer de l'art pour des t-shirts ou un nouveau logo, [comme les contributeurs de hapi.js l'ont fait](https://github.com/hapijs/contrib/issues/68) + +### Aimez-vous écrire ? + +* Écrire et améliorer la documentation du projet +* Curate un dossier d'exemples montrant comment le projet est utilisé +* Démarrer un bulletin d'information pour le projet, ou organiser des faits marquants de la liste de diffusion +* Rédiger des tutoriels pour le projet, [comme les contributeurs de PyPA l'ont fait](https://packaging.python.org/) +* Écrire une traduction pour la documentation du projet + + + +### Aimez-vous l'organisation ? + +* Lien vers des questions en double, et suggérer de nouveaux labels pour les issues, pour garder les choses organisées +* Passer en revue les problèmes ouverts et suggérer de fermer les anciens, [comme @nzakas a fait pour ESLint](https://github.com/eslint/eslint/issues/6765) +* Posez des questions de clarification sur les issues récemment ouvertes pour faire avancer la discussion + +### Aimez-vous le code ? + +* Trouver un problème ouvert à aborder, [comme @dianjin a fait pour Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Demandez si vous pouvez aider à écrire une nouvelle fonctionnalité +* Automatiser la configuration du projet +* Améliorer l'outillage et les tests + +### Aimez-vous aider les gens ? + +* Répondez aux questions sur le projet sur, par exemple, Stack Overflow ([comme cet exemple Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) ou Reddit +* Répondre aux questions pour les personnes sur les questions ouvertes +* Aider à modérer les forums de discussion ou les canaux de conversation + +### Aimez-vous aider les autres ? + +* Réviser le code sur les soumissions d'autres personnes +* Écrire des tutoriels sur la façon dont un projet peut être utilisé +* Proposer de parrainer un autre contributeur, [comme @ereichert l'a fait pour @bronzdoc sur Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Il ne suffit pas de travailler sur des projets logiciels ! + +Alors que "open source" se réfère souvent à un logiciel, vous pouvez collaborer sur à peu près n'importe quoi. Il existe des livres, des recettes, des listes et des classes qui sont développés en tant que projets open source. + +Par exemple: + +* @sindresorhus gère une [liste de listes "géniales"](https://github.com/sindresorhus/awesome) +* @h5bp tient à jour une [liste des questions potentielles lors d'entretiens](https://github.com/h5bp/Front-end-Developer-Interview-Questions) pour les candidats développeurs +* @stuartlynn et @nicole-a-tesla ont fait une [collection de faits amusants sur les macareux](https://github.com/stuartlynn/puffin_facts) + +Même si vous êtes un développeur de logiciels, travailler sur un projet de documentation peut vous aider à démarrer en open source. Il est souvent moins intimidant de travailler sur des projets qui n'impliquent pas de code, et le processus de collaboration renforcera votre confiance et votre expérience. + +## S'orienter vers un nouveau projet + + + +Pour tout ce qui n'est pas une faute de frappe, contribuer à l'open source, c'est comme aller à un groupe d'étrangers lors d'une fête. Si vous commencez à parler des lamas, alors qu'ils étaient plongés dans une discussion sur les poissons rouges, ils vous regarderont probablement un peu étrangement. + +Avant de sauter à l'aveuglette avec vos propres suggestions, commencez par apprendre à lire la pièce. Cela augmente les chances que vos idées soient remarquées et entendues. + +### Anatomie d'un projet open source + +Chaque communauté open source est différente. + +Passer des années sur un projet open source signifie que vous avez appris à connaître un projet open source. Déplacez-vous vers un projet différent, et vous pourriez trouver le vocabulaire, les normes et les styles de communication complètement différents. + +Cela dit, de nombreux projets open source suivent une structure organisationnelle similaire. Comprendre les différents rôles de la communauté et le processus global vous aidera à vous orienter rapidement vers tout nouveau projet. + +Un projet Open Source typique comprend les types de personnes suivants: + +* **Auteur :** La personne / l'organisation qui a créé le projet +* **Propriétaire :** La ou les personnes qui ont la propriété administrative de l'organisation ou du repository (pas toujours les mêmes que l'auteur original) +* **Responsables :** Collaborateurs responsables de la vision et de la gestion des aspects organisationnels du projet. (Ils peuvent aussi être auteurs ou propriétaires du projet.) +* **Contributeurs :** Tous ceux qui ont contribué au projet. +* **Membres de la communauté :** Les personnes qui utilisent le projet. Ils peuvent être actifs dans les conversations ou exprimer leur opinion sur la direction du projet. + +Les plus grands projets peuvent également avoir des sous-comités ou des groupes de travail axés sur différentes tâches, telles que l'outillage, le triage, la modération communautaire et l'organisation d'événements. Regardez sur le site Web d'un projet pour une page «équipe», ou dans le repository pour la documentation de gouvernance, pour trouver cette information. + +Un projet a également une documentation. Ces fichiers sont généralement répertoriés à la racine d'un repository. + +* **LICENCE :** Par définition, chaque projet open source doit avoir une [licence open source](https://choosealicense.com). Si le projet n'a pas de licence, il n'est pas open source. +* **README :** Le README est le manuel d'instructions qui accueille les nouveaux membres de la communauté au projet. Cela explique pourquoi le projet est utile et comment démarrer. +* **CONTRIBUTING :** Alors que les fichiers README aident les gens à utiliser le projet, les documents de contribution aident les gens à contribuer au projet. Il explique quels types de contributions sont nécessaires et comment le processus fonctionne. Bien que tous les projets n'aient pas de fichier CONTRIBUTING, sa présence indique qu'il s'agit d'un projet accueillant auquel contribuer. +* **CODE_OF_CONDUCT :** Le code de conduite établit des règles de base pour le comportement des participants et contribue à faciliter un environnement amical et accueillant. Bien que tous les projets n'aient pas de fichier CODE_OF_CONDUCT, sa présence indique qu'il s'agit d'un projet accueillant auquel contribuer. +* **Autre documentation :** Il pourrait y avoir de la documentation supplémentaire, comme des tutoriels, des procédures pas à pas, ou des politiques de gouvernance, en particulier sur des projets plus importants. + +Enfin, les projets open source utilisent les outils suivants pour organiser la discussion. La lecture des archives vous donnera une bonne idée de la façon dont la communauté pense et travaille. + +* **Suivi des issues :** Lorsque les gens discutent des issues liés au projet. +* **Pull Requests :** Où les gens discutent et examinent les changements en cours. +* **Forums de discussion ou listes de diffusion :** Certains projets peuvent utiliser ces canaux pour des sujets conversationnels (par exemple, _"Comment puis-je..."_ ou _"Que pensez-vous de..."_ au lieu d'un rapport de bug ou demandes de fonctionnalités). D'autres utilisent le suivi des issues pour toutes les conversations. +* **Canal de discussion synchrone :** Certains projets utilisent des canaux de discussion (tels que Slack ou IRC) pour des conversations informelles, la collaboration et des échanges rapides. + +## Trouver un projet auquel contribuer + +Maintenant que vous avez compris comment fonctionnent les projets open source, il est temps de trouver un projet auquel contribuer ! + +Si vous n'avez jamais contribué à l'open source auparavant, prenez quelques conseils du président américain John F. Kennedy, qui a dit: _"Ne demandez pas ce que votre pays peut faire pour vous - demandez ce que vous pouvez faire pour votre pays."_ + +Contribuer à l'open source se produit à tous les niveaux, à travers les projets. Vous n'avez pas besoin de trop réfléchir sur ce que sera exactement votre première contribution ou sur ce à quoi elle ressemblera. + +Au lieu de cela, commencez par penser aux projets que vous utilisez déjà ou que vous voulez utiliser. Les projets auxquels vous contribuez activement sont ceux auxquels vous revenez. + +Dans ces projets, chaque fois que vous pensez que quelque chose pourrait être meilleur ou différent, agissez selon votre instinct. + +L'open source n'est pas un club exclusif. C'est fait par des gens comme vous. "Open source" est juste un terme de fantaisie pour traiter les problèmes du monde comme réparable. + +Vous pouvez scanner un fichier README et trouver un lien cassé ou une faute de frappe. Ou vous êtes un nouvel utilisateur et vous avez remarqué que quelque chose est cassé, ou un problème que vous pensez devrait vraiment être dans la documentation. Au lieu de l'ignorer et de passer à autre chose, ou de demander à quelqu'un d'autre de le réparer, voyez si vous pouvez aider en faisant un descriptif du problème. C'est cela l'open source ! + +> [28% des contributions occasionnelles](https://www.igor.pro.br/publica/papers/saner2016.pdf) à l'open source sont de la documentation, une correction de faute de frappe, un reformatage ou l'écriture d'une traduction. + +Vous pouvez également utiliser l'une des ressources suivantes pour vous aider à découvrir et à contribuer à de nouveaux projets : + +* [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/) + +### Une checklist avant de contribuer + +Lorsque vous avez trouvé un projet auquel vous souhaitez contribuer, effectuez une analyse rapide pour vous assurer que le projet est adapté à l'acceptation des contributions. Sinon, votre travail acharné pourrait ne jamais avoir de réponse. + +Voici une liste de contrôle pratique pour évaluer si un projet est bon pour les nouveaux contributeurs. + +**Répondre à la définition de l'open source** + +
+ + +
+ +**Le projet accepte activement les contributions** + +Regardez l'activité des commits sur la branche principale. Sur GitHub, vous pouvez voir cette information sur la page d'accueil d'un repository. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Ensuite, regardez les issues du projet. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Faites la même chose pour les pull requests du projet. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Le projet est accueillant** + +Un projet convivial et accueillant signale qu'il sera réceptif aux nouveaux contributeurs. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## Comment proposer une contribution + +Vous avez trouvé un projet que vous aimez et vous êtes prêt à apporter votre contribution. Enfin ! Voici comment obtenir votre contribution de la bonne façon. + +### Communiquer efficacement + +Que vous soyez un contributeur ponctuel ou que vous essayiez de rejoindre une communauté, travailler avec les autres est l'une des compétences les plus importantes que vous développerez dans l'open source. + + + +Avant d'ouvrir une issue ou une pull request, ou de poser une question dans une discussion, gardez ces points à l'esprit pour que vos idées soient bien comprises. + +**Donner le contexte.** Aider les autres à se mettre rapidement à jour. Si vous rencontrez une erreur, expliquez ce que vous essayez de faire et comment le reproduire. Si vous suggérez une nouvelle idée, expliquez pourquoi vous pensez que ce serait utile pour le projet (pas seulement pour vous !). + +> 😇 _"X n'arrive pas quand je fais Y"_ +> +> 😢 _"X est cassé ! Veuillez le réparer."_ + +**Faites vos devoirs à l'avance.** C'est OK de ne pas savoir des choses, mais montrez que vous avez essayé. Avant de demander de l'aide, assurez-vous de consulter le fichier README, la documentation, les issues (ouvertes ou fermées), la liste de diffusion et la recherche sur Internet pour obtenir une réponse. Les gens apprécieront quand vous démontrerez que vous essayez d'apprendre. + +> 😇 _"Je ne sais pas comment implémenter X. J'ai vérifié les documents d'aide et je n'ai trouvé aucune mention."_ +> +> 😢 _"Comment puis-je X ?"_ + +**Gardez les demandes courtes et directes.** Tout comme pour l'envoi d'un courriel, chaque contribution, aussi simple ou utile soit-elle, nécessite l'avis de quelqu'un d'autre. De nombreux projets ont plus de demandes entrantes que de personnes disponibles pour aider. Soyez concis. Vous augmenterez les chances que quelqu'un puisse vous aider. + +> 😇 _"J'aimerais écrire un tutoriel sur l'API."_ +> +> 😢 _"Je roulais sur l'autoroute l'autre jour et je me suis arrêté pour faire le plein d'essence, et puis j'ai eu cette idée incroyable pour quelque chose que nous devrions faire, mais avant que j'explique cela, laissez-moi vous montrer..."_ + +**Gardez toute communication publique.** Bien que cela soit tentant, ne communiquez pas avec les responsables en privé à moins que vous ayez besoin de partager des informations sensibles (comme un problème de sécurité ou une violation grave de la conduite). Lorsque vous maintenez la conversation publique, plus de personnes peuvent apprendre et bénéficier de votre échange. Les discussions peuvent être, en elles-mêmes, des contributions. + +> 😇 _(comme un commentaire) "@-mainainer Salut ! Comment devrions-nous procéder sur cette PR ?"_ +> +> 😢 _(comme un e-mail) "Hello, désolé de vous déranger par e-mail, mais je me demandais si vous aviez eu l'occasion de revoir mes pull requests ?"_ + +**Il est acceptable de poser des questions (mais soyez patient!).** Tout le monde était nouveau au projet à un moment donné, et même les contributeurs expérimentés ont besoin de se mettre à jour quand ils regardent un nouveau projet. De même, même les responsables de longue date ne sont pas toujours familiers avec chaque partie du projet. Montrez-leur la même patience que vous voudriez qu'ils vous montrent. + +> 😇 _"Merci d'avoir examiné cette erreur, j'ai suivi vos suggestions, voici la sortie."_ +> +> 😢 _"Pourquoi ne voulez-vous pas résoudre mon problème, n'est-ce pas votre projet ?"_ + +**Respectez les décisions de la communauté.** Vos idées peuvent différer des priorités ou de la vision de la communauté. Ils peuvent offrir des commentaires ou décider de ne pas poursuivre votre idée. Alors que vous devriez discuter et chercher des compromis, les responsables doivent vivre avec votre décision plus longtemps que vous ne le ferez. Si vous n'êtes pas d'accord avec leur direction, vous pouvez toujours travailler sur votre propre fork ou démarrer votre propre projet. + +> 😇 _"Je suis déçu que vous ne puissiez pas supporter mon cas d'utilisation, mais comme vous l'avez expliqué, cela ne concerne qu'une partie mineure des utilisateurs, je comprends pourquoi."_ +> +> 😢 _"Pourquoi ne soutenez-vous pas mon cas d'utilisation ? C'est inacceptable !"_ + +**Surtout, gardez-le classique.** L'open source est composé de collaborateurs du monde entier. Le contexte se perd dans les langues, les cultures, les zones géographiques et les fuseaux horaires. De plus, la communication écrite rend plus difficile la transmission d'un ton ou d'une humeur. Supposer de bonnes intentions dans ces conversations. Il est bon de repousser poliment une idée, de demander plus de contexte ou de clarifier davantage votre position. Juste essayer de laisser l'Internet un meilleur endroit que lorsque vous l'avez trouvé. + +### Rassembler le contexte + +Avant de faire quoi que ce soit, faites une vérification rapide pour vous assurer que votre idée n'a pas été discutée ailleurs. Parcourez le fichier README du projet, les issues (ouvertes et fermées), la liste de diffusion et Stack Overflow. Vous n'avez pas à passer des heures à tout faire, mais une recherche rapide de quelques termes clés va aider. + +Si vous ne trouvez pas votre idée ailleurs, vous êtes prêt à faire un geste. Si le projet est sur GitHub, vous communiquerez probablement en ouvrant une issue ou une pull request : + +* **Les issues** sont comme démarrer une conversation ou une discussion +* **Les Pull Request** sont pour commencer à travailler sur une solution +* **Pour une communication légère,** comme une question de clarification ou de procédure, essayez de demander sur Stack Overflow, IRC, Slack ou d'autres canaux de discussion, si le projet en a un. + +Avant d'ouvrir une issue ou une pull request, vérifiez les documents de contribution du projet (généralement un fichier appelé CONTRIBUTING, ou dans le fichier README), pour voir si vous devez inclure quelque chose de spécifique. Par exemple, ils peuvent vous demander de suivre un modèle ou d'exiger que vous utilisiez des tests. + +Si vous voulez apporter une contribution substantielle, ouvrez une issue pour demander avant de travailler dessus. Il est utile de regarder le projet pendant un moment (sur GitHub, [vous pouvez cliquer sur "Watch"](https://help.github.com/articles/watching-repositories/) pour être averti de toutes les conversations), et arriver à connaître les membres de la communauté, avant de faire un travail qui pourrait ne pas être accepté. + + + +### Ouvrir une issue + +Vous devrez généralement ouvrir une issue dans les situations suivantes: + +* Signaler une erreur que vous ne pouvez pas résoudre vous-même +* Discuter d'un sujet ou d'une idée de haut niveau (par exemple, communauté, vision ou politiques) +* Proposer une nouvelle fonctionnalité ou une autre idée de projet + +Conseils pour communiquer sur les problèmes: + +* **Si vous voyez un problème ouvert auquel vous voulez vous attaquer,** commentez le problème pour faire savoir aux autres que vous travaillez dessus. De cette façon, les gens seront moins susceptibles de dupliquer votre travail. +* **Si une issue a été ouverte il y a un certain temps,** il est possible qu'elle soit adressée ailleurs ou qu'elle ait déjà été résolue, alors commentez pour demander une confirmation avant de commencer le travail. +* **Si vous avez ouvert une issue, mais que vous avez trouvé la réponse plus tard,** commentez l'issue pour informer les gens, puis fermez-la. Même documenter ce résultat est une contribution au projet. + +### Ouvrir une Pull Request + +Vous devrez généralement ouvrir une pull request dans les situations suivantes : + +* Soumettre des corrections triviales (par exemple, une faute de frappe, un lien cassé ou une erreur évidente) +* Commencer à travailler sur une contribution qui a déjà été demandée, ou dont vous avez déjà discuté, dans une issue + +Une pull request n'a pas à représenter le travail fini. Il est généralement préférable d'ouvrir une pull request au début afin que les autres puissent regarder ou donner leur avis sur vos progrès. Il suffit de marquer "WIP" (Work in Progress) dans la ligne d'objet. Vous pouvez toujours ajouter plus de commits plus tard. + +Si le projet est sur GitHub, voici comment soumettre une pull request: + +* **[Forker le repository](https://guides.github.com/activities/forking/)** et clonez-le localement. Connectez votre repository local au repository original "upstream" en l'ajoutant en tant que remote. Pullez souvent des changements de "upstream" de sorte que vous restiez à jour afin que lorsque vous soumettez votre pull request, les conflits de merge seront moins probables. (Voir plus d'instructions détaillées [ici](https://help.github.com/articles/syncing-a-fork/).) +* **[Créer une branche](https://guides.github.com/introduction/flow/)** pour vos modifications. +* **Faites référence à toutes les questions pertinentes** ou aux éléments de documentations dans votre PR (par exemple, «Close #37»). +* **Inclure des captures d'écran avant et après** si vos modifications incluent des différences en HTML/CSS. Faites glisser et déposez les images dans le corps de votre pull request. +* **Testez vos modifications !** Exécutez vos modifications par rapport aux tests existants s'ils existent et créez-en de nouveaux si nécessaire. Que les tests existent ou non, assurez-vous que vos modifications ne cassent pas le projet existant. +* **Contribuer dans le style du projet** au mieux de vos capacités. Cela peut signifier utiliser des indentations, des points-virgules ou des commentaires différemment de ce que vous feriez dans votre propre repository, mais il est plus facile pour le mainteneur de fusionner, d'autres à comprendre et à maintenir dans le futur. + +S'il s'agit de votre première Pull Request, consultez [Make a Pull Request](http://makeapullrequest.com/), que @kentcdodds a créé comme didacticiel vidéo. Vous pouvez également vous entraîner à faire une pull request dans le repository [Premières contributions](https://github.com/Roshanjossey/first-contributions), créé par @Roshanjossey. + +## Que se passe-t-il après avoir proposé une contribution + +Vous l'avez fait ! Félicitations pour devenir un contributeur open source. Nous espérons que c'est le premier de plusieurs. + +Après avoir soumis une contribution, l'un des événements suivants se produira: + +### 😭 Vous n'obtenez pas de réponse. + +J'espère que vous avez [vérifié les signes d'activité dans le projet](#une-checklist-avant-de-contribuer) avant de faire une contribution. Même sur un projet actif, il est possible que votre contribution n'obtienne pas de réponse. + +Si vous n'avez pas reçu de réponse depuis plus d'une semaine, il est juste de répondre poliment dans ce même fil, en demandant à quelqu'un de donner son avis. Si vous connaissez le nom de la bonne personne à consulter votre contribution, vous pouvez @-mentionner dans ce fil. + +**Ne pas** tendre la main à cette personne en privé. Rappelez-vous que la communication publique est vitale pour les projets open source. + +Si vous faites une contribution et que personne ne répond, il est possible que personne ne réponde, jamais. Ce n'est pas génial, mais ne vous laissez pas décourager. C'est arrivé à tout le monde ! Il y a plusieurs raisons possibles pour lesquelles vous n'avez pas reçu de réponse, y compris des circonstances personnelles qui peuvent être hors de votre contrôle. Essayez de trouver un autre projet ou un moyen de contribuer. Si c'est le cas, c'est une bonne raison de ne pas consacrer trop de temps à faire une contribution avant que les autres membres de la communauté soient engagés et réceptifs. + +### 🚧 Quelqu'un demande des modifications à votre contribution. + +Il est courant que l'on vous demande d'apporter des modifications à votre contribution, qu'il s'agisse de commentaires sur la portée de votre idée ou de modifications apportées à votre code. + +Quand quelqu'un demande des changements, soyez flexible. Ils ont pris le temps d'examiner votre contribution. Ouvrir une PR et passer à autre chose est une mauvaise idée. Si vous ne savez pas comment faire des changements, recherchez le problème, puis demandez de l'aide si vous en avez besoin. + +Si vous n'avez plus le temps de travailler sur le problème (par exemple, si la conversation dure depuis des mois et que votre situation a changé), informez le responsable pour qu'il n'attende pas de réponse. Quelqu'un d'autre peut être heureux de prendre le relais. + +### 👎 Votre contribution ne sera pas acceptée. + +Votre contribution peut ou pas être acceptée à la fin. J'espère que vous n'y avez pas déjà mis trop de travail. Si vous ne savez pas pourquoi cela n'a pas été accepté, il est tout à fait raisonnable de demander des commentaires et des éclaircissements au responsable. En fin de compte, cependant, vous devrez respecter que c'est leur décision. Ne discutez pas et ne soyez pas hostile. Vous êtes toujours le bienvenu pour forker et travailler sur votre propre version si vous n'êtes pas d'accord ! + +### 🎉 Votre contribution est acceptée. + +Hourra! Vous avez réussi à faire une contribution open source! + +## Vous l'avez fait! + +Que vous veniez de faire votre première contribution open source, ou que vous cherchiez de nouvelles façons de contribuer, nous espérons que vous êtes inspirés à agir. Même si votre contribution n'a pas été acceptée, n'oubliez pas de dire merci quand un responsable a fait des efforts pour vous aider. L'open source est créé par des personnes comme vous: une issue, une pull request, un commentaire ou une salutation à la fois. diff --git a/_articles/fr/index.html b/_articles/fr/index.html new file mode 100644 index 00000000000..63180a3fe60 --- /dev/null +++ b/_articles/fr/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: Open Source Guides +lang: fr +permalink: /fr/ +--- diff --git a/_articles/fr/leadership-and-governance.md b/_articles/fr/leadership-and-governance.md new file mode 100644 index 00000000000..ca7873e3fbb --- /dev/null +++ b/_articles/fr/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: fr +title: Leadership et gouvernance +description: Les projets Open Source en croissance peuvent bénéficier de règles formelles pour prendre des décisions. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Comprendre la gouvernance pour votre projet en croissance + +Votre projet prend de l'ampleur, les gens sont mobilisés et vous êtes engagé à poursuivre dans cette voie. À ce stade, vous allez peut-être vous demander comment incorporer les contributeurs réguliers du projet dans votre flux de travail, que ce soit en donnant à quelqu'un l'accès à la validation ou en résolvant les débats de la communauté. Si vous avez des questions, nous avons des réponses. + +## Quels sont les exemples de rôles formels utilisés dans les projets open source + +De nombreux projets suivent une structure similaire pour les rôles contributeurs et la reconnaissance. + +Qu'est-ce que ces rôles signifient réellement, cependant, est entièrement à vous. Voici quelques types de rôles que vous pouvez reconnaître: + +* **Responsables** +* **Contributeur** +* **Committeur** + +**Pour certains projets, les "responsables"** sont les seules personnes dans un projet ayant un accès en validation. Dans d'autres projets, ils sont simplement les personnes répertoriées dans le fichier README en tant que responsables. + +Un responsable ne doit pas nécessairement être quelqu'un qui écrit du code pour votre projet. Ce pourrait être quelqu'un qui a fait beaucoup de travail pour évangéliser votre projet, ou une documentation écrite qui a rendu le projet plus accessible aux autres. Peu importe ce qu'ils font au jour le jour, un responsable est probablement quelqu'un qui se sent responsable de la direction du projet et qui est déterminé à l'améliorer. + +**Un contributeur peut être n'importe quel personne** qui commente un problème ou une demande d'extraction, les personnes qui ajoutent de la valeur au projet (qu'il s'agisse de problèmes de triage, d'écriture de code ou d'organisation d'événements) ou toute personne ayant une pull request mergée (sans doute la définition la plus proche d'un contributeur). + + + +**Le terme "committeur"** pourrait être utilisé pour distinguer le droit de commit, qui est un type spécifique de responsabilité, des autres formes de contribution. + +Alors que vous pouvez définir vos rôles de projet comme vous le souhaitez, [pensez à utiliser des définitions plus larges](../how-to-contribute/#que-signifie-contribuer) pour encourager plus de formes de contribution. Vous pouvez utiliser des rôles de leadership pour reconnaître formellement les personnes qui ont apporté des contributions exceptionnelles à votre projet, indépendamment de leurs compétences techniques. + + + +## Comment formaliser ces rôles de leadership + +La formalisation de vos rôles de leadership aide les gens à se sentir concernés et indique aux autres membres de la communauté qui chercher de l'aide. + +Pour un projet plus petit, la désignation des responsables peut être aussi simple que d'ajouter leurs noms à votre fichier texte README ou CONTRIBUTORS. + +Pour un plus grand projet, si vous avez un site web, créez une page d'équipe ou faites une liste de vos chefs de projet. Par exemple, [Postgres](https://github.com/postgres/postgres/) a une [page d'équipe complète](https://www.postgresql.org/community/contributors/) avec des profils courts pour chaque contributeur. + +Si votre projet a une communauté de contributeurs très active, vous pouvez former une équipe de responsables, ou même des sous-comités de personnes qui s'approprient différents domaines (par exemple, la sécurité, le tri des problèmes ou la conduite de la communauté). Laissez les gens s'organiser et faire du bénévolat pour les rôles qui les intéressent le plus, plutôt que de les assigner. + + + +Les équipes de direction peuvent vouloir créer une chaîne désignée (comme sur IRC) ou se rencontrer régulièrement pour discuter du projet (comme sur Gitter ou Google Hangout). Vous pouvez même rendre ces réunions publiques afin que les autres puissent les écouter. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), par exemple, [héberge des heures de bureau chaque semaine](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +Une fois que vous avez établi des rôles de leadership, n'oubliez pas de documenter comment les gens peuvent les atteindre ! Établissez un processus clair pour que quelqu'un puisse devenir responsable ou rejoindre un sous-comité dans votre projet, et l'écrire dans votre GOVERNANCE.md. + +Des outils tels que [Vossibility](https://github.com/icecrime/vossibility-stack) peuvent vous aider à savoir qui contribue (ou non) au projet. Documenter cette information évite la perception de la communauté que les responsables sont une clique qui prend ses décisions en privé. + +Enfin, si votre projet est sur GitHub, envisagez de transférer votre projet de votre compte personnel vers une organisation et d'ajouter au moins un administrateur de sauvegarde. [Les organisations GitHub](https://help.github.com/articles/creating-a-new-organization-account/) facilitent la gestion des permissions et des dépôts multiples et protègent l'héritage de votre projet par [propriété partagée](../building-community/#partager-la-propriété-de-votre-projet). + +## Quand dois-je donner à quelqu'un le droit de commit + +Certaines personnes pensent que vous devriez donner un droit de commit à tous ceux qui apportent une contribution. Cela pourrait encourager plus de personnes à se sentir propriétaires de votre projet. + +D'un autre côté, en particulier pour les projets plus volumineux et plus complexes, vous pouvez ne donner que le droit de commit aux personnes qui ont démontré leur engagement. Il n'y a pas une bonne façon de le faire - faites ce qui vous est le plus confortable ! + +Si votre projet est sur GitHub, vous pouvez utiliser des [branches protégées](https://help.github.com/articles/about-protected-branches/) pour gérer qui peut pousser vers une branche particulière, et dans quelles circonstances. + + + +## Quelles sont les structures de gouvernance communes pour les projets open source + +Il existe trois structures de gouvernance communes associées aux projets open source. + +* **BDFL :** BDFL, "Benevolent Dictator for Life", signifie "Dictateur bienveillant pour la vie". Sous cette structure, une personne (généralement l'auteur initial du projet) a le dernier mot sur toutes les grandes décisions de projet. [Python](https://github.com/python) est un exemple classique. Les projets plus petits sont probablement BDFL par défaut, car il n'y a qu'un ou deux responsables. Un projet qui provient d'une entreprise pourrait également tomber dans la catégorie BDFL. + +* **Méritocratie :** **(Note: le terme "méritocratie" a des connotations négatives pour certaines communautés et a une [histoire sociale et politique complexe](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Dans le cadre d'une méritocratie, les contributeurs actifs du projet (ceux qui démontrent le «mérite») ont un rôle formel de prise de décision. Les décisions sont généralement prises sur la base d'un consensus de vote pur. Le concept de méritocratie a été mis au point par la [Fondation Apache](https://www.apache.org/). [Tous les projets Apache](https://www.apache.org/index.html#projects-list) sont des méritocraties. Les contributions ne peuvent être faites que par des personnes qui se représentent elles-mêmes, et non par une entreprise. + +* **Contribution libérale :** Selon un modèle de contribution libérale, les personnes qui font le plus de travail sont reconnues comme les plus influentes, mais cela est basé sur le travail actuel et non sur les contributions historiques. Les grandes décisions de projet sont prises en fonction d'un processus de recherche de consensus (discuter des griefs majeurs) plutôt que d'un simple vote, et s'efforcent d'inclure autant de perspectives communautaires que possible. Exemples populaires de projets qui utilisent un modèle de contribution libérale : [Node.js](https://foundation.nodejs.org/) et [Rust](https://www.rust-lang.org/). + +Lequel devriez-vous utiliser ? C'est à vous de décider ! Chaque modèle a des avantages et des compromis. Et bien qu'ils puissent sembler tout à fait différents au début, les trois modèles ont plus en commun qu'ils ne le semblent. Si vous souhaitez adopter l'un de ces modèles, consultez ces modèles : + +* [Gabarit de modèle BDFL](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Gabarit de modèle de la méritocratie](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Politique de contribution libérale de Node.js](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## Ai-je besoin de documents de gouvernance lorsque je lance mon projet + +Il n'y a pas de bon moment pour écrire la gouvernance de votre projet, mais c'est beaucoup plus facile à définir une fois que vous avez vu la dynamique de votre communauté se jouer. La meilleure partie (et la plus difficile) de la gouvernance open source est qu'elle est façonnée par la communauté ! + +Certaines documentations préliminaires contribueront inévitablement à la gouvernance de votre projet, alors commencez à écrire ce que vous pouvez. Par exemple, vous pouvez définir des attentes claires pour le comportement ou le fonctionnement de votre processus contributeur, même au lancement de votre projet. + +Si vous faites partie d'une entreprise qui lance un projet open source, cela vaut la peine d'avoir une discussion interne avant le lancement sur la manière dont votre entreprise prévoit de maintenir et de prendre des décisions concernant le projet. Vous pouvez également expliquer publiquement quelque chose de particulier à la façon dont votre entreprise sera (ou ne sera pas !) impliquée dans le projet. + + + +## Que se passe-t-il si les employés de l'entreprise commencent à soumettre des contributions + +Les projets open source réussis sont utilisés par de nombreuses personnes et entreprises, et certaines entreprises peuvent éventuellement avoir des sources de revenus liées au projet. Par exemple, une entreprise peut utiliser le code du projet comme un composant dans une offre de service commercial. + +Comme le projet est de plus en plus utilisé, les personnes qui ont de l'expertise dans ce domaine deviennent de plus en plus demandées - vous pouvez être l'une d'entre elles ! - et seront parfois payés pour le travail qu'ils font dans le projet. + +Il est important de traiter l'activité commerciale comme normale et comme une autre source d'énergie de développement. Les développeurs payés ne devraient pas recevoir un traitement spécial par rapport aux non-payés, bien sûr, chaque contribution doit être évaluée sur ses mérites techniques. Cependant, les gens devraient se sentir à l'aise de s'engager dans une activité commerciale, et se sentir à l'aise d'énoncer leurs cas d'utilisation lorsqu'ils argumentent en faveur d'une amélioration ou d'une caractéristique particulière. + +"Commercial" est complètement compatible avec "open source". "Commercial" signifie simplement qu'il y a de l'argent impliqué quelque part - que le logiciel est utilisé dans le commerce, ce qui est de plus en plus probable au fur et à mesure qu'un projet est adopté. (Lorsque le logiciel open source est utilisé dans le cadre d'un produit non-open-source, le produit global est toujours un logiciel "propriétaire", bien que, comme open source, il puisse être utilisé à des fins commerciales ou non-commerciales.) + +Comme tout le monde, les développeurs motivés par le commerce acquièrent une influence sur le projet grâce à la qualité et à la quantité de leurs contributions. Évidemment, un développeur payé pour son temps peut être capable de faire plus que quelqu'un qui n'est pas payé, mais c'est bon: le paiement est juste l'un des nombreux facteurs possibles qui pourraient affecter combien quelqu'un fait. Gardez vos discussions de projet axées sur les contributions, pas sur les facteurs externes qui permettent aux gens de faire ces contributions. + +## Ai-je besoin d'une entité légale pour soutenir mon projet + +Vous n'avez pas besoin d'une entité légale pour soutenir votre projet open source à moins que vous ne manipuliez de l'argent. + +Par exemple, si vous souhaitez créer une entreprise commerciale, vous devez créer un C Corp ou LLC (si vous êtes basé aux États-Unis). Si vous ne faites que du travail contractuel lié à votre projet open source, vous pouvez accepter de l'argent en tant que propriétaire unique ou créer une LLC (si vous êtes basé aux États-Unis). + +Si vous souhaitez accepter des dons pour votre projet open source, vous pouvez configurer un bouton de don (PayPal ou Stripe, par exemple), mais l'argent ne sera pas déductible d'impôt, sauf si vous êtes un organisme à but non lucratif (501c3, si vous êtes aux États-Unis). + +Beaucoup de projets ne souhaitent pas se lancer dans la création d'un but non lucratif, ils trouvent donc un sponsor fiscal à but non lucratif. Un sponsor fiscal accepte les dons en votre nom, généralement en échange d'un pourcentage du don. [Software Freedom Conservancy](https://sfconservancy.org/), [Fondation Apache](https://www.apache.org/), [Fondation Eclipse](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) et [Open Collective](https://opencollective.com/opensource) sont des exemples d'organisations qui servent de sponsors fiscaux pour des projets open source. + + + +Si votre projet est étroitement associé à une langue ou à un écosystème donné, il peut également exister une base de logiciel connexe avec laquelle vous pouvez travailler. Par exemple, [Python Software Foundation](https://www.python.org/psf/) prend en charge [PyPI](https://pypi.org/), le gestionnaire de paquets Python et la [Fondation Node.js](https://foundation.nodejs.org/) aide à prendre en charge [Express.js](https://expressjs.com/), un framework basé sur Node. diff --git a/_articles/fr/legal.md b/_articles/fr/legal.md new file mode 100644 index 00000000000..e8288c1bfcc --- /dev/null +++ b/_articles/fr/legal.md @@ -0,0 +1,157 @@ +--- +lang: fr +title: Le côté légal de l'Open Source +description: Tout ce que vous n'avez jamais osé demander sur le côté juridique de l'Open Source, et quelques autres. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## Comprendre les implications juridiques de l'open source + +Partager votre travail créatif avec le monde peut être une expérience passionnante et enrichissante. Cela peut aussi signifier un tas de choses juridiques dont vous ne saviez pas que vous aviez à vous soucier. Heureusement, vous n'avez pas à partir de zéro. Nous avons couvert vos besoins juridiques. (Avant de creuser, assurez-vous de lire notre [avertissement](/notices/).) + +## Pourquoi les gens se soucient tellement du côté légal de l'open source + +Content que vous ayez demandé ! Lorsque vous effectuez un travail de création (tel que l'écriture, les graphiques ou le code), ce travail est sous copyright exclusif par défaut. Autrement dit, la loi suppose qu'en tant qu'auteur de votre travail, vous avez votre mot à dire sur ce que les autres peuvent en faire. + +En général, cela signifie que personne d'autre ne peut utiliser, copier, distribuer ou modifier votre travail sans risquer des démontages, des ruptures ou des litiges. + +L'open source est une circonstance inhabituelle, cependant, parce que l'auteur s'attend à ce que d'autres utilisent, modifient et partagent le travail. Mais parce que le défaut légal est toujours le droit d'auteur exclusif, vous avez besoin d'une licence qui énonce explicitement ces autorisations. + +Si vous n'appliquez pas de licence open source, tous ceux qui contribuent à votre projet deviennent également détenteurs exclusifs des droits d'auteur de leur travail. Cela signifie que personne ne peut utiliser, copier, distribuer ou modifier ses contributions - et que "personne" ne vous inclut. + +Enfin, votre projet peut avoir des dépendances avec des exigences de licence dont vous n'étiez pas au courant. La communauté de votre projet ou les politiques de votre employeur peuvent également exiger que votre projet utilise des licences Open Source spécifiques. Nous couvrirons ces situations ci-dessous. + +## Les projets publics GitHub sont-ils open source + +Lorsque vous [créez un nouveau projet](https://help.github.com/articles/creating-a-new-repository/) sur GitHub, vous avez la possibilité de créer le repository **privé** ou **public**. + +![Créer un référentiel](/assets/images/legal/repo-create-name.png) + +**Rendre public votre projet GitHub est différent d'appliquer une licence à votre projet.** Les projets publics sont couverts par les [Conditions d'utilisation de GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ce qui permet aux autres de voir et de forker votre projet, mais par défaut aucune permission ne leur est accordé sur votre travail. + +Si vous souhaitez que d'autres personnes utilisent, distribuent, modifient ou contribuent à votre projet, vous devez inclure une licence open source. Par exemple, quelqu'un ne peut légalement utiliser aucune partie de votre projet GitHub dans son code, même s'il est public, à moins que vous ne lui donniez explicitement le droit de le faire. + +## Donnez-moi juste l'essentiel sur ce dont j'ai besoin pour protéger mon projet + +Vous avez de la chance, car aujourd'hui, les licences open source sont standardisées et faciles à utiliser. Vous pouvez copier-coller une licence existante directement dans votre projet. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), et [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sont les licences open source les plus populaires, mais il existe d'autres options à choisir. Vous pouvez trouver le texte intégral de ces licences, et des instructions sur la façon de les utiliser, sur [choosealicense.com](https://choosealicense.com/). + +Lorsque vous créez un nouveau projet sur GitHub, vous serez [invité à ajouter une licence](https://help.github.com/articles/open-source-licensing/). + + + +## Quelle licence open source est appropriée pour mon projet + +Si vous démarrez à partir d'une page vierge, il est difficile de se tromper avec la [Licence MIT](https://choosealicense.com/licenses/mit/). Elle est courte, très facile à comprendre et permet à quiconque de faire quoi que ce soit tant qu'il conserve une copie de la licence, comprenant vos droits d'auteur. Vous pourrez lancer le projet sous une licence différente si vous en avez besoin. + +Sinon, choisir la bonne licence open source pour votre projet dépend de vos objectifs. + +Votre projet a très probablement (ou aura) **des dépendances**. Par exemple, si vous ouvrez un projet Node.js, vous utiliserez probablement des bibliothèques du Node Package Manager (npm). Chacune de ces bibliothèques dépendra de sa propre licence open source. Si chacune de leurs licences est "permissive" (donne au public l'autorisation d'utiliser, de modifier et de partager, sans condition pour les licences en aval), vous pouvez utiliser la licence que vous voulez. Les licences permissives courantes incluent MIT, Apache 2.0, ISC et BSD. + +D'un autre côté, si l'une de vos licences de dépendances est "strong copyleft" (donne également les mêmes permissions publiques, sous condition d'utiliser la même licence en aval), alors votre projet devra utiliser la même licence. GPLv2, GPLv3 et AGPLv3 sont les principales licences communes de copyleft. + +Vous pouvez également considérer les **communautés** que vous espérez utiliser et contribuer à votre projet : + +* **Voulez-vous que votre projet soit utilisé comme une dépendance par d'autres projets ?** Il sera probablement préférable d'utiliser la licence la plus populaire dans votre communauté pertinente. Par exemple, [MIT](https://choosealicense.com/licenses/mit/) est la licence la plus populaire pour [les bibliothèques npm](https://libraries.io/search?platforms=NPM). +* **Voulez-vous que votre projet attire les grandes entreprises ?** Une grande entreprise voudra probablement une licence de brevet express de tous les contributeurs. Dans ce cas, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) vous couvrent (vous et eux). +* **Souhaitez-vous que votre projet fasse appel à des contributeurs qui ne souhaitent pas que leurs contributions soient utilisées dans des logiciels à code source fermé ?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) ou (si ils ne souhaitent pas non plus contribuer aux services à code source fermé) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) sera très bien également. + +Votre **entreprise** peut avoir des exigences de licence spécifiques pour ses projets open source. Par exemple, il peut nécessiter une licence permissive afin que l'entreprise puisse utiliser votre projet dans le produit de source fermée de l'entreprise. Votre entreprise peut également exiger une licence copyleft forte et un accord de contribution supplémentaire (voir ci-dessous) afin que seule votre entreprise, et personne d'autre, puisse utiliser votre projet dans un logiciel à source fermée. Votre entreprise peut également avoir certains besoins liés aux normes, à la responsabilité sociale ou à la transparence, qui pourraient nécessiter une stratégie de licence particulière. Parlez à votre [service juridique de l'entreprise](#que-doit-savoir-léquipe-juridique-de-mon-entreprise). + +Lorsque vous créez un nouveau projet sur GitHub, vous avez la possibilité de sélectionner une licence. Y compris l'une des licences mentionnées ci-dessus rendra votre projet open source GitHub. Si vous souhaitez voir d'autres options, consultez [choosealicense.com](https://choosealicense.com) pour trouver la bonne licence pour votre projet, même si elle [n'est pas un logiciel](https://choosealicense.com/non-software/). + +## Et si je veux changer la licence de mon projet + +La plupart des projets n'ont jamais besoin de changer de licence. Mais parfois les circonstances changent. + +Par exemple, au fur et à mesure que votre projet prend de l'ampleur, il ajoute des dépendances ou des utilisateurs, ou votre entreprise change de stratégie, chacune d'entre elles pouvant exiger ou vouloir une licence différente. En outre, si vous avez négligé d'autoriser votre projet dès le départ, l'ajout d'une licence équivaut à changer de licence. Il y a trois choses fondamentales à prendre en compte lors de l'ajout ou de la modification de la licence de votre projet : + +**C'est compliqué.** Déterminer la compatibilité et la conformité des licences et qui détient les droits d'auteur peut devenir compliqué et déroutant très rapidement. Passer à une nouvelle licence, mais compatible, pour les nouvelles versions et les contributions est différent de la redistribution de toutes les contributions existantes. Impliquez votre équipe juridique le premier indice de tout désir de changer de licence. Même si vous avez ou pouvez obtenir l'autorisation des titulaires de droits d'auteur de votre projet pour un changement de licence, tenez compte de l'impact de ce changement sur les autres utilisateurs et contributeurs de votre projet. Pensez à un changement de licence comme un "événement de gouvernance" pour votre projet qui se déroulera plus facilement avec des communications et des consultations claires avec les parties prenantes de votre projet. Raison de plus pour choisir et utiliser une licence appropriée pour votre projet dès sa création ! + +**Licence existante de votre projet.** Si la licence existante de votre projet est compatible avec la licence que vous souhaitez modifier, vous pouvez simplement commencer à utiliser la nouvelle licence. En effet, si la licence A est compatible avec la licence B, vous respecterez les termes de A tout en respectant les termes de B (mais pas nécessairement l'inverse). Donc, si vous utilisez actuellement une licence permissive (par exemple, MIT), vous pouvez changer pour une licence avec plus de conditions, tant que vous conservez une copie de la licence MIT et tous les avis de droits d'auteur associés (à savoir, continuer à se conformer à Conditions minimales de la licence MIT). Mais si votre licence actuelle n'est pas permissive (par exemple, copyleft, ou si vous n'avez pas de licence) et que vous n'êtes pas le seul détenteur des droits d'auteur, vous ne pouvez pas simplement changer la licence de votre projet au MIT. Essentiellement, avec une licence permissive, les détenteurs de droits d'auteur du projet ont donné leur permission à l'avance pour changer de licence. + +**Les détenteurs de droits d'auteur existants de votre projet.** Si vous êtes le seul contributeur à votre projet, alors vous ou votre entreprise êtes le seul détenteur des droits d'auteur du projet. Vous pouvez ajouter ou modifier n'importe quelle licence que vous ou votre entreprise souhaitez. Sinon, il peut y avoir d'autres détenteurs de droits d'auteur dont vous avez besoin d'un accord pour changer de licence. Qui sont-ils ? Les personnes qui se sont engagées dans votre projet sont un bon point de départ. Mais dans certains cas, le droit d'auteur sera détenu par les employeurs de ces personnes. Dans certains cas, les gens n'auront fait que des contributions minimes, mais il n'y a pas de règle absolue que les contributions sous un certain nombre de lignes de code ne soient pas soumises au droit d'auteur. Que faire ? Cela dépend. Pour un projet relativement petit et jeune, il peut être possible d'obtenir que tous les contributeurs existants acceptent un changement de licence dans une issue ou une pull request. Pour les projets de grande envergure et de longue durée, vous devrez peut-être chercher de nombreux contributeurs et même leurs héritiers. Mozilla a pris des années (2001-2006) pour changer la license de Firefox, Thunderbird et les logiciels associés. + +Alternativement, vous pouvez demander aux contributeurs d'accepter à l'avance (via un accord de contribution supplémentaire - voir ci-dessous) certains changements de licence sous certaines conditions, au-delà de celles autorisées par votre licence open source existante. Cela déplace un peu la complexité de la modification des licences. Vous aurez besoin de plus d'aide de la part de vos avocats et vous voudrez toujours communiquer clairement avec les parties prenantes de votre projet lors de l'exécution d'un changement de licence. + +## Mon projet a-t-il besoin d'un accord de contribution supplémentaire + +Probablement pas. Pour la grande majorité des projets open source, une licence open source sert implicitement à la fois de licence entrante (des contributeurs) et sortante (aux autres contributeurs et utilisateurs). Si votre projet est sur GitHub, les conditions d'utilisation de GitHub font de "inbound = outbound" le [paramètre par défaut explicite](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +Un accord de contribution supplémentaire - souvent appelé Accord de licence de contributeur (CLA) - peut créer un travail administratif pour les responsables de projet. La quantité de travail ajoutée par un accord dépend du projet et de la mise en œuvre. Un accord simple peut exiger que les contributeurs confirment, en un clic, qu'ils ont les droits nécessaires pour contribuer sous la licence open source du projet. Un accord plus compliqué pourrait nécessiter un examen juridique et une approbation des employeurs des cotisants. + +En outre, en ajoutant de la "paperasse" jugée inutile, difficile à comprendre ou injuste (lorsque le destinataire obtient plus de droits que les contributeurs ou le public via la licence open source du projet), un accord de contribution supplémentaire peut être perçu comme inamical à la communauté du projet. + + + +Certaines situations où vous pourriez envisager un accord de contribution supplémentaire pour votre projet incluent: + +* Vos avocats veulent que tous les contributeurs acceptent expressément les termes de contribution (_signer_, en ligne ou hors ligne), peut-être parce qu'ils pensent que la licence Open Source n'est pas suffisante (même si c'est le cas !). Si c'est la seule préoccupation, un accord de contribution qui affirme la licence open source du projet devrait être suffisant. Le [Contrat de licence de contributeur individuel jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) est un bon exemple d'accord de contributeur supplémentaire léger. Pour certains projets, un [Developer Certificate of Origin](https://github.com/probot/dco) peut être une alternative. +* Votre projet utilise une licence open source qui n'inclut pas de brevet explicite (tel que MIT), et vous avez besoin d'une licence de brevet de tous les contributeurs, dont certains peuvent travailler pour des entreprises avec de grands portefeuilles de brevets qui pourraient vous servir ou les autres contributeurs et utilisateurs du projet. Le [Contrat de licence de contributeur individuel Apache](https://www.apache.org/licenses/icla.pdf) est un accord de contributeur supplémentaire communément utilisé qui a une licence de brevet reflétant celle de la licence Apache 2.0. +* Votre projet est sous licence copyleft, mais vous devez également distribuer une version propriétaire du projet. Vous aurez besoin de chaque contributeur pour vous attribuer des droits d'auteur ou vous accorder (mais pas le public) une licence permissive. Le [Contrat de collaboration MongoDB](https://www.mongodb.com/legal/contributor-agreement) est un exemple de ce type d'accord. +* Vous pensez que votre projet pourrait avoir besoin de changer de licence au cours de sa vie et que les contributeurs soient d'accord à l'avance sur de tels changements. + +Si vous devez utiliser un accord de contributeur supplémentaire avec votre projet, envisagez d'utiliser une intégration telle que [Assistant CLA](https://github.com/cla-assistant/cla-assistant) pour minimiser la distraction des contributeurs. + +## Que doit savoir l'équipe juridique de mon entreprise + +Si vous publiez un projet open source en tant qu'employé de l'entreprise, votre équipe juridique doit d'abord savoir que vous êtes en train d'ouvrir un projet. + +Pour le meilleur ou pour le pire, envisagez de les informer même s'il s'agit d'un projet personnel. Vous avez probablement avec votre entreprise un "accord IP d'employé" qui lui donne un certain contrôle sur vos projets, surtout s'ils sont liés à l'activité de l'entreprise ou si vous utilisez les ressources de l'entreprise pour développer le projet. Votre entreprise _devrait_ vous donner facilement la permission, et peut-être déjà à travers un accord de propriété intellectuelle favorable aux employés ou une politique d'entreprise. Sinon, vous pouvez négocier (par exemple, expliquer que votre projet répond aux objectifs d'apprentissage et de développement professionnel de l'entreprise pour vous), ou éviter de travailler sur votre projet jusqu'à ce que vous trouviez une meilleure entreprise. + +**Si vous ouvrez la source d'un projet pour votre entreprise**, alors faites-le savoir. Votre équipe juridique a sans doute déjà des politiques de quelle licence open source (et peut-être un accord de contribution supplémentaire) à utiliser en fonction des besoins d'affaires de l'entreprise et de l'expertise assurant autour de votre projet est conforme aux licences de ses dépendances. Sinon, vous et ils ont de la chance! Votre équipe juridique devrait être impatiente de travailler avec vous pour comprendre ces choses. Quelques points à penser: + +* **Matériel de tiers :** Votre projet a-t-il des dépendances créées par d'autres ou inclut ou utilise le code d'autres personnes ? Si ceux-ci sont open source, vous devrez vous conformer aux licences open source des matériaux. Cela commence par choisir une licence qui fonctionne avec les licences open source tierces (voir ci-dessus). Si votre projet modifie ou distribue du matériel Open Source tiers, votre équipe juridique voudra également savoir que vous remplissez d'autres conditions des licences Open Source tierces, telles que la conservation des avis de copyright. Si votre projet utilise le code d'autres personnes n'ayant pas de licence Open Source, vous devrez probablement demander aux responsables de la maintenance tiers d'[ajouter une licence Open Source](https://choosealicense.com/no-license/#for-users), et si vous ne pouvez pas en obtenir un, arrêtez d'utiliser leur code dans votre projet. + +* **Secrets commerciaux :** Examiner s'il y a quoi que ce soit dans le projet que l'entreprise ne souhaite pas mettre à la disposition du grand public. Si c'est le cas, vous pouvez ouvrir le reste de votre projet, après avoir extrait le contenu que vous voulez garder privé. + +* **Brevets :** Votre entreprise demande-t-elle un brevet dont l'open source de votre projet constituerait [divulgation publique](https://en.wikipedia.org/wiki/Public_disclosure) ? Malheureusement, vous pourriez être invité à attendre (ou peut-être que l'entreprise reconsidérera la maturité de l'application). Si vous attendez des contributions d'employés d'entreprises ayant de grands portefeuilles de brevets, votre équipe juridique voudra peut-être utiliser une licence avec un brevet spécialement pour les contributeurs (comme Apache 2.0 ou GPLv3) ou un accord de contribution supplémentaire (voir au dessus). + +* **Marques :** Vérifiez que le nom de votre projet [n'est pas en conflit avec les marques existantes](../starting-a-project/#éviter-les-conflits-de-noms). Si vous utilisez les marques de votre propre entreprise dans le projet, vérifiez qu'il ne provoque aucun conflit. [FOSSmarks](http://fossmarks.org/) est un guide pratique pour comprendre les marques dans le contexte de projets libres et open source. + +* **Confidentialité :** Votre projet recueille-t-il des données sur les utilisateurs ? "Téléphone Maison" aux serveurs de l'entreprise ? Votre équipe juridique peut vous aider à respecter les politiques de l'entreprise et les réglementations externes. + +Si vous publiez le premier projet open source de votre entreprise, ce qui précède est plus que suffisant pour passer à travers (mais ne vous inquiétez pas, la plupart des projets ne devraient pas susciter d'inquiétudes majeures). + +À plus long terme, votre équipe juridique peut faire davantage pour aider l'entreprise à tirer le meilleur parti de son implication dans l'open source et à rester en sécurité: + +* **Règles de contribution des employés :** Envisagez de développer une politique d'entreprise qui spécifie comment vos employés contribuent aux projets open source. Une politique claire réduira la confusion parmi vos employés et les aidera à contribuer à des projets open source dans le meilleur intérêt de l'entreprise, que ce soit dans le cadre de leur travail ou pendant leur temps libre. Un bon exemple est Rackspace [Modèle IP et Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/). + + + +* **Que publier :** [(Presque) tout ?](Http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si votre équipe juridique comprend et est investie dans la stratégie open source de votre entreprise, ils seront les mieux placés pour vous aider plutôt que d'entraver vos efforts. +* **Conformité :** Même si votre entreprise ne diffuse aucun projet open source, elle utilise le logiciel open source des autres. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) peut prévenir les maux de tête, les retards de produit et les poursuites judiciaires. + + + +* **Brevets :** Votre entreprise voudra peut-être rejoindre le [Open Invention Network](https://www.openinventionnetwork.com/), un pool de brevets défensif partagé pour protéger l'utilisation de projets open source majeurs par les membres, ou explorer une autre [licence alternative de brevet](https://www.eff.org/document/hacking-patent-system-2016). +* **Gouvernance :** Surtout si et quand il est logique de transférer un projet à une [entité juridique extérieure à l'entreprise](../leadership-and-governance/#ai-je-besoin-dune-entité-légale-pour-soutenir-mon-projet). diff --git a/_articles/fr/maintaining-balance-for-open-source-maintainers.md b/_articles/fr/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..08143423a7b --- /dev/null +++ b/_articles/fr/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,225 @@ +--- +lang: fr +title: Maintenir l'équilibre chez les Mainteneurs de code Open Source +description: Conseils d'écologie personnelle et commen éviter le burnout en tant que mainteneur. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +Au fur et à mesure qu'un projet open source gagne en popularité, il devient important de fixer des limites claires pour vous aider à maintenir l'équilibre afin de rester frais et productif à long terme. + +Afin de mieux comprendre les expériences des mainteneurs et leurs stratégies pour trouver un équilibre, nous avons organisé un atelier avec 40 membres de la communauté des mainteneurs, ce qui nous a permis d'apprendre de leurs expériences directes de l'épuisement professionnel dans l'open source et des pratiques qui les ont aidés à maintenir l'équilibre dans leur travail. C'est là que le concept d'écologie personnelle entre en jeu. + +Alors, qu'est-ce que l'écologie personnelle ? Comme le décrit le Rockwood Leadership Institute, il s'agit de « maintenir l'équilibre, le rythme et l'efficacité pour soutenir notre énergie tout au long de la vie ». Cela a encadré nos conversations, en aidant les responsables à reconnaître que leurs actions et leurs contributions font partie d'un écosystème plus large qui évolue au fil du temps. L'épuisement professionnel, un syndrome résultant d'un stress chronique sur le lieu de travail [tel que défini par l'OMS](https://icd.who.int/browse/2024-01/mms/fr#129180281), n'est pas rare chez les responsables de la maintenance. Il se traduit souvent par une perte de motivation, une incapacité à se concentrer et un manque d'empathie à l'égard des contributeurs et de la communauté avec laquelle vous travaillez. + + + +En adoptant le concept d'écologie personnelle, les responsables de la maintenance peuvent éviter de manière proactive l'épuisement professionnel, donner la priorité aux soins personnels et maintenir un sens de l'équilibre afin de faire leur meilleur travail. + +## Astuces pour prendre soin de soi et éviter l'épuisement en tant que responsable de maintenance : + +### Identifier vos motivations pour travailler dans l'open source + +Prenez le temps de réfléchir aux aspects de la maintenance des logiciels libres qui vous stimulent. Comprendre vos motivations peut vous aider à prioriser le travail de manière à rester engagé et prêt à relever de nouveaux défis. Qu'il s'agisse des réactions positives des utilisateurs, de la joie de collaborer et de socialiser avec la communauté ou de la satisfaction de se plonger dans le code, le fait de reconnaître vos motivations peut vous aider à vous concentrer. + +### Réfléchissez à ce qui vous déséquilibre et vous stresse. + +Il est important de comprendre les causes de l'épuisement professionnel. Voici quelques thèmes communs aux mainteneurs de logiciels libres : + +* **Absence de retours positifs:** Les utilisateurs sont beaucoup plus enclins à se manifester lorsqu'ils ont une plainte à formuler. Si tout fonctionne parfaitement, ils ont tendance à rester silencieux. Il peut être décourageant de voir la liste des problèmes s'allonger sans que les commentaires positifs montrent que votre contribution fait la différence. + + + +* **Ne pas dire « non »:** Il peut être facile de prendre plus de responsabilités qu'on ne le devrait sur un projet open source. Que ce soit de la part des utilisateurs, des contributeurs ou d'autres mainteneurs, nous ne pouvons pas toujours répondre à leurs attentes. + + + +* **Travailler en solitaire :** Être un mainteneur peut être incroyablement solitaire. Même si vous travaillez avec un groupe de mainteneurs, les dernières années ont été difficiles pour réunir des équipes dispersées en personne. + + + +* **Manque de temps et de ressources :** C'est particulièrement vrai pour les mainteneurs bénévoles qui doivent sacrifier leur temps libre pour travailler sur un projet. + + + +* **Demandes contradictoires :** L'open source est un ensemble de groupes aux motivations diverses, dans lequel il peut être difficile de s'y retrouver. Si vous êtes payé pour faire de l'open source, les intérêts de votre employeur peuvent parfois être en contradiction avec ceux de la communauté. + + + +### Faites attention aux signes d'épuisement professionnel + +Pouvez-vous maintenir votre rythme pendant 10 semaines ? 10 mois ? 10 ans ? + +Il existe des outils comme la [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) qui peuvent vous aider à réfléchir à votre rythme actuel et à voir s'il y a des ajustements à faire. Certains mainteneurs utilisent également une technologie portable pour suivre des paramètres tels que la qualité du sommeil et la variabilité du rythme cardiaque (tous deux liés au stress). + + + +### De quoi auriez-vous besoin pour continuer à subvenir à vos besoins et à ceux de votre communauté ? + +Cela sera différent pour chaque responsable, et changera en fonction de votre phase de vie et d'autres facteurs externes. Mais voici quelques thèmes que nous avons entendus : + +* **Appuyez-vous sur la communauté:** La délégation et la recherche de collaborateurs peuvent alléger la charge de travail. Le fait d'avoir plusieurs points de contact pour un projet peut vous aider à faire une pause sans vous inquiéter. Entrez en contact avec d'autres mainteneurs et la communauté au sens large, dans des groupes tels que la [Communauté des mainteneurs](http://maintainers.github.com/). Il peut s'agir d'une excellente ressource pour l'entraide et l'apprentissage. + + Vous pouvez également chercher des moyens de vous engager auprès de la communauté des utilisateurs, afin d'obtenir régulièrement des informations en retour et de comprendre l'impact de votre travail sur les logiciels libres. + +* **Explorer le financement :** Que vous soyez à la recherche d'un peu d'argent pour une pizza ou que vous essayiez de vous lancer à plein temps dans l'open source, il existe de nombreuses ressources pour vous aider ! Dans un premier temps, pensez à activer [GitHub Sponsors](https://github.com/sponsors) pour permettre à d'autres de sponsoriser votre travail open source. Si vous envisagez de passer à temps plein, postulez pour le prochain cycle de l'[Accélérateur GitHub](http://accelerator.github.com/). + + + +* **Utilisez les outils:** Profitez d'outils tels que [GitHub Copilot](https://github.com/features/copilot/) et [GitHub Actions](https://github.com/features/actions) pour automatiser les tâches banales et libérer votre temps pour des contributions plus significatives. + + + +* **Se reposer et se ressourcer :** Consacrez du temps à vos loisirs et à vos centres d'intérêt en dehors de l'open source. Prenez vos week-ends pour vous détendre et vous ressourcer, et réglez votre [statut GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) pour qu'il reflète votre disponibilité ! Une bonne nuit de sommeil peut faire une grande différence dans votre capacité à soutenir vos efforts à long terme. +Si certains aspects de votre projet vous plaisent particulièrement, essayez de structurer votre travail de manière à en faire l'expérience tout au long de la journée. + + + +* **Definir des limites :** Vous ne pouvez pas dire oui à toutes les demandes. Cela peut être aussi simple que de dire « Je ne peux pas le faire maintenant et je n'ai pas l'intention de le faire à l'avenir », ou d'énumérer ce que vous souhaitez faire et ne pas faire dans le fichier README. Par exemple, vous pourriez dire : « Je ne fusionne que les PR dont les raisons sont clairement listées » ou "Je n'examine les problèmes qu'un jeudi sur deux, de 18 à 19 heures". Cela définit les attentes des autres et vous donne un point de repère à d'autres moments pour aider à désamorcer les demandes de contributeurs ou d'utilisateurs sur votre temps. + + + + Apprenez à faire preuve de fermeté pour mettre fin aux comportements toxiques et aux interactions négatives. Il est normal de ne pas donner d'énergie à des choses qui ne vous intéressent pas. + + + + + +N'oubliez pas que l'écologie personnelle est une pratique permanente qui évoluera au fur et à mesure que vous progresserez dans votre voyage vers l'open source. En accordant la priorité à la prise en charge de soi et au maintien d'un équilibre, vous pouvez contribuer à la communauté open source de manière efficace et durable, en assurant à la fois votre bien-être et le succès de vos projets sur le long terme. + +## Ressources complémentaires + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](hhttps://mikemcquaid.com/saying-no/), Mike McQuaid +* [Governing Open](https://governingopen.com/) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series + +## Contributors + +Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/fr/metrics.md b/_articles/fr/metrics.md new file mode 100644 index 00000000000..0d3c83adc01 --- /dev/null +++ b/_articles/fr/metrics.md @@ -0,0 +1,126 @@ +--- +lang: fr +title: Métriques Open Source +description: Prendre des décisions éclairées pour aider votre projet Open Source à prospérer en mesurant et en suivant son succès. +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Pourquoi tout mesurer + +Les données, lorsqu'elles sont utilisées à bon escient, peuvent vous aider à prendre de meilleures décisions en tant que responsable d'un projet open source. + +Avec plus d'informations, vous pouvez: + +* Comprendre comment les utilisateurs répondent à une nouvelle fonctionnalité +* Déterminer d'où viennent les nouveaux utilisateurs +* Identifier, et décider de soutenir, un cas d'utilisation aberrant ou une fonctionnalité +* Quantifier la popularité de votre projet +* Comprendre comment votre projet est utilisé +* Recueillir de l'argent grâce à des parrainages et des subventions + +Par exemple, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) trouve que Google Analytics les aide à hiérarchiser leur travail: + +> Homebrew est fourni gratuitement et géré entièrement par des bénévoles pendant leur temps libre. Par conséquent, nous ne disposons pas des ressources nécessaires pour effectuer des études détaillées des utilisateurs Homebrew afin de décider de la meilleure façon de concevoir les fonctionnalités futures et de hiérarchiser les travaux en cours. L'analyse anonyme des utilisateurs agrégés nous permet de hiérarchiser les correctifs et les fonctionnalités en fonction de comment, où et quand les utilisateurs utilisent Homebrew. + +La popularité n'est pas tout. Tout le monde entre dans l'open source pour différentes raisons. Si votre objectif, en tant que responsable de l'open source, est de montrer votre travail, d'être transparent au sujet de votre code ou de vous amuser, les métriques peuvent ne pas être importantes pour vous. + +Si vous _êtes_ intéressé à comprendre votre projet à un niveau plus profond, lisez la suite pour savoir comment analyser l'activité de votre projet. + +## Découverte + +Avant que quiconque puisse utiliser ou contribuer à votre projet, ils doivent savoir qu'il existe. Demandez-vous: _Est-ce que les gens trouvent ce projet ?_ + +![Graphique de trafic](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +Si votre projet est hébergé sur GitHub, [vous pouvez voir](https://help.github.com/articles/about-repository-graphs/#traffic) combien de personnes atterrissent sur votre projet et d'où elles viennent. À partir de la page de votre projet, cliquez sur "Insights", puis sur "Traffic". Sur cette page, vous pouvez voir: + +* **Le nombre total de pages vues :** Vous indique combien de fois votre projet a été visionné + +* **Le nombre total de visiteurs uniques :** Vous indique combien de personnes ont vu votre projet + +* **Les sites référents :** Vous indique d'où viennent les visiteurs. Cette statistique peut vous aider à déterminer où joindre votre audience et si vos efforts de promotion fonctionnent. + +* **Le contenu populaire :** Vous indique où les visiteurs vont sur votre projet, ventilé par pages vues et visiteurs uniques. + +[Les étoiles de GitHub](https://help.github.com/articles/about-stars/) peuvent également aider à fournir une mesure de base de popularité. Bien que les étoiles GitHub ne correspondent pas nécessairement aux téléchargements et à l'utilisation, elles peuvent vous dire combien de personnes prennent en compte votre travail. + +Vous pouvez également [suivre la découvrabilité dans des lieux spécifiques](https://opensource.com/business/16/6/pirate-metrics): par exemple, Google PageRank, le trafic de redirection depuis le site Web de votre projet ou les renvois d'autres sites ouverts, projets source ou sites Web. + +## Usage + +Les gens trouvent votre projet sur cette chose sauvage et folle que nous appelons l'Internet. Idéalement, quand ils verront votre projet, ils se sentiront obligés de faire quelque chose. La deuxième question que vous voudrez poser est: _Est-ce que les gens utilisent ce projet ?_ + +Si vous utilisez un gestionnaire de paquets pour distribuer votre projet, tels que npm ou RubyGems.org, vous pourrez peut-être suivre les téléchargements de votre projet. + +Chaque gestionnaire de paquets peut utiliser une définition légèrement différente de "téléchargement", et les téléchargements ne sont pas nécessairement corrélés aux installations ou à l'utilisation, mais ils fournissent une base de comparaison. Essayez d'utiliser [Libraries.io](https://libraries.io/) pour suivre les statistiques d'utilisation de nombreux gestionnaires de paquets populaires. + +Si votre projet est sur GitHub, naviguez à nouveau vers la page "Trafic". Vous pouvez utiliser le [graphe clone](https://github.com/blog/1873-clone-graphs) pour voir combien de fois votre projet a été cloné un jour donné, ventilé par clone total et clonage unique. + +![Cloner graphe](/assets/images/metrics/clone_graph.png) + +Si l'utilisation est faible par rapport au nombre de personnes découvrant votre projet, il y a deux points à considérer, pas plus: + +* Votre projet ne réussit pas à convertir votre public, ou +* Vous attirez le mauvais public + +Par exemple, si votre projet atterrit sur la première page de Hacker News, vous verrez probablement un pic de découverte (trafic), mais un taux de conversion plus faible, car vous atteignez tout le monde sur Hacker News. Toutefois, si votre projet Ruby est présenté lors d'une conférence Ruby, vous êtes plus susceptible de voir un taux de conversion élevé de la part d'un public ciblé. + +Essayez de comprendre d'où vient votre public et demandez aux autres de donner leur avis sur la page de votre projet pour savoir lequel de ces deux problèmes vous rencontrez. + +Une fois que vous savez que les gens utilisent votre projet, vous pouvez essayer de comprendre ce qu'ils font avec. Est-ce qu'ils s'appuient sur lui en forkant votre code et en ajoutant des fonctionnalités ? L'utilisent-ils pour la science ou les affaires? + +## Rétention + +Les gens trouvent votre projet et l'utilisent. La prochaine question que vous voudrez vous poser est: _Est-ce que les gens contribuent à ce projet ?_ + +Il n'est jamais trop tôt pour commencer à penser aux contributeurs. Sans d'autres personnes, vous risquez de vous mettre dans une situation malsaine où votre projet est populaire (beaucoup de gens l'utilisent) mais pas soutenu (pas assez de temps de maintenance pour répondre à la demande). + +La rétention nécessite également un [afflux de nouveaux contributeurs](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), car les contributeurs actifs finiront par passer à autre chose. + +Les exemples de statistiques de communauté que vous souhaitez suivre régulièrement incluent: + +* **Nombre total de contributeurs et nombre de commits par contributeur :** Vous indique combien de contributeurs vous avez, et qui est plus ou moins actif. Sur GitHub, vous pouvez voir ceci sous "Insights" -> "Contributors". À l'heure actuelle, ce graphique ne tient compte que des contributeurs qui se sont engagés dans la branche par défaut du référentiel. + +![Graphique des contributeurs](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **Types de contributions:** Par exemple, s'il s'agit de commits, de corrections de fautes de frappe ou de bugs, de commentaires sur une issue. + +* **Premiers contributeurs occasionnels et répétitifs :** Vous aide à savoir si vous recevez de nouveaux contributeurs et s'ils reviennent. (Les contributeurs occasionnels sont des contributeurs avec un faible nombre de commit, que ce soit un commit, moins de cinq commits, ou autre chose selon vos critères.) Sans de nouveaux contributeurs, la communauté de votre projet peut devenir stagnante. + +* **Nombre d'issues ouvertes et de Pull Request ouvertes :** Si ces chiffres sont trop élevés, vous aurez peut-être besoin d'aide pour le tri des issues et les révisions de code. + +* **Nombre d'issue _opened_ et de pull request _opened_ :** Les issues ouvertes signifient que quelqu'un se soucie suffisamment de votre projet pour ouvrir une issue. Si ce nombre augmente avec le temps, cela suggère que les gens s'intéressent à votre projet. + + + +## Activité de responsable + +Enfin, vous souhaiterez fermer la boucle en vous assurant que les responsables de votre projet sont en mesure de gérer le volume de contributions reçues. La dernière question que vous voudrez vous poser est la suivante: _suis-je (ou sommes-nous) en train de répondre à notre communauté?_ + +Les mainteneurs qui ne répondent pas deviennent un goulot d'étranglement pour les projets open source. Si quelqu'un soumet une contribution mais n'obtient jamais de retour d'un responsable, il peut se sentir découragé et partir. + +[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggère que la réactivité du responsable est un facteur critique pour encourager les contributions répétées. + +Pensez à suivre le temps qu'il vous faut (ou à un autre responsable) pour répondre aux contributions, qu'il s'agisse d'une issue ou d'une Pull Request. Répondre ne nécessite pas d'action. Cela peut être aussi simple que de dire: _"Merci pour votre soumission! Je vais examiner cela la semaine prochaine."_ + +Vous pouvez également mesurer le temps nécessaire pour passer d'une étape à l'autre du processus de contribution, par exemple: + +* Temps moyen d'ouverture d'une issue +* Si les issues sont fermées par des PR +* Si les issues périmées se ferment +* Temps moyen pour merger une pull request + +## Utilisez 📊 pour en savoir plus sur les gens + +La compréhension des métriques vous aidera à créer un projet open source actif et en croissance. Même si vous ne suivez pas toutes les mesures sur un tableau de bord, utilisez le cadre ci-dessus pour attirer votre attention sur le type de comportement qui aidera votre projet à prospérer. diff --git a/_articles/fr/security-best-practices-for-your-project.md b/_articles/fr/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..79e03a628e1 --- /dev/null +++ b/_articles/fr/security-best-practices-for-your-project.md @@ -0,0 +1,158 @@ +--- +lang: fr +untranslated: true +title: Security Best Practices for your Project +description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security. + +## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA) + +### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages. + +Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services. + +MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to. + +## Secure your code as part of your development workflow + +### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production. + +Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases. + +It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code. + +How to choose your SAST tool? +Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep. +Check the coverage for your language(s) + +* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them. +* Beware of False Positives! You don't want the tool to slow you down for no reason! +* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep). + +## Don't share your secrets + +### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository. + +Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes. + +To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you. + +## Check and update your dependencies + +### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task. + +Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data. + +To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. + +## Understand and manage open source license risks + +### Open source licenses come with terms and ignoring them can lead to legal and reputational risks. + +Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs. + +Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit. + +To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project. + +Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively. + +Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe. + +## Avoid unwanted changes with protected branches + +### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project. + +A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time. + +## Make it easy (and safe) to report security issues + +### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers? + +Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users. + +### Security Policy + +To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process. + +### Private Vulnerability Reporting + +On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool. + +### Define your threat model to help users and researchers understand scope + +Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions. + +A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies. + +A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context. + +If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own. + +Publishing a basic threat model alongside your security policy improves clarity for everyone. + +## Prepare a lightweight incident response process + +### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers. + +Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference. + + + +Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next? + +Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously. + +Your process doesn't have to be complex. At minimum, define: + +* Who reviews and triages security reports or alerts +* How severity is evaluated and how mitigation decisions are made +* What steps you take to prepare a fix and coordinate disclosure +* How you notify affected users, contributors, or downstream consumers + +An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust. + +For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan. + +This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident. + +## Treat security as a team effort + +### Security isn't a solo responsibility. It works best when shared across your project's community. + +While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively. + +Here are a few ways to make security a team sport: + +* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches. +* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly. +* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning). +* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook. +* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed. + +Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone. + +## Conclusion: A few steps for you, a huge improvement for your users + +These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues. + +Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface. + +## Contributors + +### Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: + +[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others! diff --git a/_articles/fr/starting-a-project.md b/_articles/fr/starting-a-project.md new file mode 100644 index 00000000000..e046bda6d19 --- /dev/null +++ b/_articles/fr/starting-a-project.md @@ -0,0 +1,363 @@ +--- +lang: fr +title: Lancer un projet Open Source +description: En savoir plus sur le monde de l'Open Source et préparez-vous à lancer votre propre projet. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## Le "quoi" et le "pourquoi" de l'open source + +Donc, vous songez à commencer avec l'open source ? Toutes nos félicitations ! Le monde va apprécier votre contribution. Parlons de ce qu'est l'open source et pourquoi les gens le font. + +### Que signifie "open source" ? + +Lorsqu'un projet est open source, cela signifie que **n'importe qui peut voir, utiliser, modifier et distribuer votre projet dans n'importe quel but.** Ces autorisations sont appliquées via [une licence open source](https://opensource.org/licenses). + +L'open source est puissant car il abaisse les barrières à l'adoption, permettant aux idées de se propager rapidement. + +Pour comprendre comment cela fonctionne, imaginez qu'un ami organise une collation, et que vous apportez une tarte aux cerises. + +* Tout le monde goûte la tarte (_utiliser_) +* La tarte est un succès ! Ils vous demandent la recette que vous leur fournissez (_voir_) +* Un ami, Alex, qui est chef pâtissier, suggère de réduire le sucre (_modifier_) +* Une autre amie, Lisa, demande à l'utiliser pour un dîner la semaine prochaine (_distribuer_) + +Par comparaison, un processus de source fermée serait de se rendre dans un restaurant et commander une tranche de tarte aux cerises. Vous devez payer des frais pour manger la tarte, et le restaurant ne vous donnera probablement pas leur recette. Si vous avez copié leur tarte exactement et l'avez vendue sous votre propre nom, le restaurant pourrait même prendre des mesures légales contre vous. + +### Pourquoi les gens ouvrent-ils leur travail ? + + + +[Il y a de nombreuses raisons](https://ben.balter.com/2015/11/23/why-open-source/) pour une personne ou une organisation de vouloir ouvrir un projet. Parmi celles-ci : + +* **Collaboration :** Les projets open source peuvent accepter des changements de n'importe qui dans le monde. [Exercism](https://github.com/exercism/), par exemple, est une plate-forme d'exercices de programmation avec plus de 350 contributeurs. + +* **Adoption et remixage :** Les projets open source peuvent être utilisés par n'importe qui dans presque n'importe quel but. Les gens peuvent même l'utiliser pour construire d'autres choses. [WordPress](https://github.com/WordPress), par exemple, a commencé en tant que fork (nous verrons plus tard ce qu'on appelle un fork, pour le moment voyez ceci comme une copie à un instant donné) d'un projet existant appelé [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **Transparence :** Tout le monde peut inspecter un projet open source pour y chercher des erreurs ou des incohérences. La transparence est importante pour des gouvernements comme celui de [Bulgarie](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) ou des [États-Unis](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), les industries réglementées comme les banques ou les soins de santé, et les logiciels de sécurité comme [Let's Encrypt](https://github.com/letsencrypt). + +L'open source n'est pas seulement pour les logiciels. Vous pouvez tout rendre open source depuis les jeux de données aux livres. Jetez un coup d'œil sur [GitHub Explore](https://github.com/explore) pour trouver des idées sur ce que vous pouvez faire d'autre. + +### L'open source signifie-t-il "gratuit" ? + +L'un des plus gros attraits de l'open source est qu'il ne coûte pas d'argent. La "gratuité" est toutefois une conséquence de la valeur globale de l'open source. + +Puisqu'[une licence open source nécessite](https://opensource.org/osd-annotated) que n'importe qui puisse utiliser, modifier et partager votre projet dans pratiquement n'importe quel but, les projets eux-mêmes ont tendance à être gratuits. Si le projet coûte de l'argent, n'importe qui peut légalement en faire une copie et utiliser la version gratuite à la place. + +En conséquence, la plupart des projets open source sont gratuits, mais la "gratuité" ne fait pas partie de la définition de l'open source. Il existe des moyens de facturer les projets open source indirectement à travers une double licence ou des fonctionnalités limitées, tout en respectant la définition officielle de l'open source. + +## Dois-je lancer mon propre projet open source + +La réponse courte est oui, car peu importe le résultat, le lancement de votre propre projet est une excellente façon d'apprendre comment fonctionne l'open source. + +Si vous n'avez jamais ouvert aux autres un projet auparavant, vous pourriez vous demander ce que les gens vont penser, ou être inquiet du risque que personne ne le remarquera. Si cela vous parle, sachez que vous n'êtes pas seul ! + +Le travail open source est comme toute autre activité créative, que ce soit l'écriture ou la peinture. Cela peut être effrayant de partager votre travail avec le reste du monde, mais la seule façon de s'améliorer est de pratiquer - même si vous n'avez pas de public. + +Si vous n'êtes pas encore convaincu, prenez un moment pour réfléchir à vos objectifs. + +### Fixer vos objectifs + +Les objectifs peuvent vous aider à déterminer ce sur quoi vous devez travailler, ce à quoi vous devez dire non et où vous avez besoin de l'aide des autres. Commencez par vous demander : _pourquoi est-ce que j'ouvre ce projet ?_ + +Il n'y a pas de bonne réponse à cette question. Vous pouvez avoir plusieurs objectifs pour un même projet ou différents projets avec des objectifs différents. + +Si votre seul objectif est de montrer votre travail, vous ne voulez peut-être même pas de contributions, et vous pouvez alors même le dire dans votre fichier README. D'un autre côté, si vous voulez des contributeurs, vous allez investir du temps dans une documentation claire et faire en sorte que les nouveaux arrivants se sentent les bienvenus. + + + +Au fur et à mesure que votre projet grandit, votre communauté peut commencer à avoir besoin de plus que du code. Gardez bien à l'esprit que répondre aux problèmes, réviser le code et promouvoir votre projet sont des tâches importantes dans un projet open source. + +Bien que le temps que vous consacrez à des tâches sans code dépende de la taille et de la portée de votre projet, vous devez vous préparer en tant que responsable à les résoudre par vous-même ou à trouver quelqu'un pour vous aider. + +**Si vous faites partie d'une entreprise qui ouvre le code source d'un projet,** assurez-vous que votre projet dispose des ressources internes dont il a besoin pour prospérer. Vous voudrez identifier qui est responsable de la maintenance du projet après son lancement et comment vous allez partager ces tâches avec votre communauté. + +Si vous avez besoin d'un budget ou d'un personnel dédié pour la promotion, les opérations et la maintenance du projet, commencez ces discussions au sein de votre entreprise aussi tôt que possible. + + + +### Contribuer à d'autres projets + +Si votre objectif est d'apprendre à collaborer avec d'autres ou à comprendre le fonctionnement de l'open source, envisagez de contribuer à un projet existant. Commencez avec un projet que vous utilisez déjà et que vous aimez. Contribuer à un projet peut être aussi simple que de réparer des fautes de frappe ou de mettre à jour une documentation. + +Si vous ne savez pas comment commencer en tant que contributeur, consultez notre guide [Comment contribuer à l'Open Source](../how-to-contribute/). + +## Lancer votre propre projet open source + +Il n'y a pas de moment idéal pour ouvrir votre travail. Vous pouvez ouvrir une idée, un travail en cours, ou après des années de source fermée. + +De manière générale, vous devriez ouvrir votre projet lorsque vous serez à l'aise à l'idée que les autres puissent voir et donner votre avis sur votre travail. + +Quelle que soit la phase durant laquelle vous décidez d'ouvrir votre projet, chaque projet doit inclure la documentation suivante : + +* [Licence 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) +* [Directives de contribution](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Code de conduite](../code-of-conduct/) + +En tant que responsable, ces composants vous aideront à communiquer les attentes, à gérer les contributions et à protéger les droits légaux de chacun (y compris les vôtres). Ils augmentent considérablement vos chances d'avoir une expérience positive. + +Si votre projet est sur GitHub, placer ces fichiers dans votre répertoire racine avec les noms de fichiers recommandés aidera GitHub à les reconnaître et à les faire apparaître automatiquement à vos lecteurs. + +### Choisir une licence + +Une licence open source garantit que d'autres utilisateurs peuvent utiliser, copier, modifier et contribuer à votre projet sans aucune répercussion. Elle vous protège également contre les situations juridiques épineuses. **Vous devez inclure une licence lorsque vous lancez un projet open source.** + +Le travail juridique n'est pas amusant. La bonne nouvelle est que vous pouvez copier et coller une licence existante dans votre dépôt. Cela ne prendra qu'une minute pour protéger votre dur labeur. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), et [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sont les licences Open Source les plus populaires, mais vous pouvez choisir [d'autres options](https://choosealicense.com). + +Lorsque vous créez un nouveau projet sur GitHub, vous avez la possibilité de sélectionner une licence. L'inclusion d'une licence open source rendra votre projet GitHub open source. + +![Choisissez une licence](/assets/images/starting-a-project/repository-license-picker.png) + +Si vous avez d'autres questions ou préoccupations concernant les aspects juridiques de la gestion d'un projet open source, [nous avons ce qu'il vous faut](../legal/). + +### Ecrire un fichier README + +Les fichiers README font plus qu'expliquer comment utiliser votre projet. Ils expliquent également pourquoi votre projet est important et ce que vos utilisateurs peuvent en faire. + +Dans votre fichier README, essayez de répondre aux questions suivantes : + +* Que fait ce projet ? +* Pourquoi ce projet est-il utile ? +* Par quoi puis-je commencer ? +* Où puis-je obtenir plus d'aide, si j'en ai besoin ? + +Vous pouvez utiliser votre fichier README pour répondre à d'autres questions, telles que la manière dont vous gérez les contributions, les objectifs du projet et les informations sur les licences et l'attribution. Si vous ne souhaitez pas accepter de contributions ou si votre projet n'est pas encore prêt pour la production, écrivez ces informations. + + + +Parfois, les gens évitent d'écrire un fichier README parce qu'ils ont l'impression que le projet n'est pas terminé ou qu'ils ne veulent pas de contributions. En fait ce sont toutes de très bonnes raisons d'en écrire un. + +Pour plus d'inspiration, essayez d'utiliser celui de @18F ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) ou le [modèle de README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) de @PurpleBooth pour écrire un fichier README complet. + +Lorsque vous incluez un fichier README dans le répertoire racine, GitHub l'affiche automatiquement sur la page d'accueil du dépot. + +### Rédaction de vos directives de contribution + +Un fichier CONTRIBUTING indique à votre audience comment participer à votre projet. Par exemple, vous pouvez inclure des informations sur: + +* Comment déposer un rapport de bug (essayez d'utiliser [des modèles de questions et de pull requests](https://github.com/blog/2111-issue-and-pull-request-templates)) +* Comment proposer une nouvelle fonctionnalité +* Comment configurer votre environnement et exécuter des tests + +En plus des détails techniques, un fichier CONTRIBUTING est une opportunité de communiquer vos attentes pour les contributions, telles que: + +* Les types de contributions que vous recherchez +* Votre feuille de route ou vision pour le projet +* Comment les contributeurs devraient (ou ne devraient pas) entrer en contact avec vous + +Utiliser un ton chaleureux et amical et offrir des suggestions précises pour les contributions (comme la rédaction de documentation ou la création d'un site Web) peut faire beaucoup pour que les nouveaux arrivants se sentent les bienvenus et enthousiastes à l'idée de participer. + +Par exemple, [Active Admin](https://github.com/activeadmin/activeadmin/) démarre [son guide de contribution](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) avec: + +> Tout d'abord, merci d'envisager de contribuer à Active Admin. Ce sont des gens comme vous qui font d'Active Admin un outil formidable. + +Dans les premières étapes de votre projet, votre fichier CONTRIBUTING peut être simple. Vous devez toujours expliquer comment signaler les bogues ou les problèmes de fichiers, ainsi que les exigences techniques (comme les tests) pour apporter une contribution. + +Au fil du temps, vous pouvez ajouter d'autres questions fréquemment posées à votre fichier CONTRIBUTING. La rédaction de ce genre d'informations signifie que moins de personnes vous poseront les mêmes questions encore et encore. + +Pour plus d'aide avec la rédaction de votre fichier CONTRIBUTING, consultez le [modèle de guide de contribution de @nayafia](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) ou le guide de @mozilla ["Comment Construire un CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). + +Ajoutez un lien vers votre fichier CONTRIBUTING dans votre fichier README, afin que plus de gens le voient. Si vous [placez le fichier CONTRIBUTING dans le repository de votre projet](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub affichera automatiquement un lien vers votre fichier lorsqu'un contributeur crée un problème ou ouvre une pull request. + +![Lignes directrices contributives](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Établir un code de conduite + + + +Enfin, un code de conduite permet de définir des règles de base pour le comportement des participants de votre projet. Ceci est particulièrement utile si vous lancez un projet open source pour une communauté ou une entreprise. Un code de conduite vous permet de faciliter un comportement communautaire sain et constructif, ce qui réduira votre stress en tant que responsable. + +Pour plus d'informations, consultez notre [Code de conduite](../code-of-conduct/). + +En plus d'indiquer _comment_ vous souhaitez que les participants se comportent, un code de conduite a également tendance à décrire à qui s'appliquent ces attentes, quand elles s'appliquent, et que faire en cas de violation. + +Tout comme les licences open source, il existe également des normes émergentes pour les codes de conduite, vous n'avez donc pas besoin d'écrire les vôtres. Le [Contributor Covenant](https://contributor-covenant.org/)) est un code de conduite qui est utilisé par [plus de 40 000 projets open source](https://www.contributor-covenant.org/adopters) , y compris Kubernetes, Rails et Swift. Quel que soit le texte que vous utilisez, vous devez être prêt à appliquer votre code de conduite si nécessaire. + +Collez le texte directement dans un fichier CODE_OF_CONDUCT dans votre repository. Conservez le fichier dans le répertoire racine de votre projet pour qu'il soit facile à trouver et mettez un lien vers lui dans votre fichier README. + +## Nommer et créer l'image de marque de votre projet + +La marque est plus qu'un logo flashy ou un nom de projet accrocheur. Il s'agit de la façon dont vous parlez de votre projet et à qui est destiné votre message. + +### Choisir le bon nom + +Choisissez un nom facile à retenir et, idéalement, qui donne une idée de ce que fait le projet. Par exemple: + +* [Sentry](https://github.com/getsentry/sentry) surveille les applications pour fournir des rapports d'erreur +* [Thin](https://github.com/macournoyer/thin) est un serveur web Ruby simple et rapide + +Si vous construisez sur un projet existant, l'utilisation de leur nom comme préfixe peut aider à clarifier ce que fait votre projet (par exemple, [node-fetch](https://github.com/bitinn/node-fetch) apporte `window.fetch` à Node.js). + +Pensez à la clarté avant tout. Faire des jeux de mots, c'est amusant, mais rappelez-vous que certaines blagues peuvent ne pas se traduire dans d'autres cultures et des personnes ayant des expériences différentes de vous peuvent ne pas les comprendre. Certains de vos utilisateurs potentiels peuvent être des employés dans une entreprise : vous ne voulez pas les mettre mal à l'aise quand ils devront expliquer votre projet au travail ! + +### Éviter les conflits de noms + +[Vérifiez les projets open source avec un nom similaire](http://ivantomic.com/projects/ospnc/), surtout si vous partagez le même langage ou écosystème. Si votre nom est trop proche de celui d'un projet existant populaire, vous risquez de perturber votre auditoire. + +Si vous souhaitez un site Web, un pseudo Twitter ou d'autres entités pour représenter votre projet, assurez-vous de pouvoir obtenir les noms souhaités. Idéalement, [réservez ces noms maintenant](https://instantdomainsearch.com/) pour votre tranquillité d'esprit, même si vous n'avez pas l'intention de les utiliser pour l'instant. + +Assurez-vous que le nom de votre projet ne porte pas atteinte à une marque. Une entreprise pourrait vous demander d'arrêter votre projet dans le futur, ou même intenter une action en justice contre vous. Cela ne vaut tout simplement pas le risque. + +Vous pouvez consulter la [Base de données mondiale de l'OMPI sur les marques](https://www.wipo.int/branddb/fr/) pour obtenir des informations sur les marques provenant de différentes sources aux niveaux national et international. Si vous êtes dans une entreprise, c'est un des sujets sur lesquels [votre équipe juridique peut vous aider](../legal/). + +Enfin, recherchez le nom de votre projet sur Google. Les gens pourront-ils trouver facilement votre projet ? Est-ce que quelque chose d'autre apparaît dans les résultats de recherche que vous ne voudriez pas qu'ils voient ? + +### Comment vous écrivez (et codez) affecte votre marque, aussi ! + +Tout au long de la vie de votre projet, vous allez beaucoup écrire : des fichiers README, des didacticiels, des documents communautaires, des réponses aux problèmes, peut-être même des bulletins d'informations et des listes de diffusion. + +Qu'il s'agisse d'une documentation officielle ou d'un courriel occasionnel, votre style d'écriture fait partie de la marque de votre projet. Réfléchissez à comment vous pourriez rencontrer votre public et au ton que vous souhaitez utiliser pour communiquer avec eux. + + + +L'utilisation d'un langage chaleureux et inclusif (tel que l'utilisation de «eux», même en faisant référence à la personne seule) peut faire beaucoup pour rendre votre projet accueillant pour les nouveaux contributeurs. Tenez-vous-en à un langage simple, car bon nombre de vos lecteurs ne sont peut-être pas francophones. + +Au-delà de votre façon d'écrire, votre style de codage peut également faire partie de la marque de votre projet. [Angular](https://github.com/johnpapa/angular-styleguide) et [jQuery](https://contribute.jquery.org/style-guide/js/) sont deux exemples de projets avec des lignes directrices et des styles de codage rigoureux. + +Il n'est pas nécessaire d'écrire un guide de style pour votre projet lorsque vous débutez, et vous constaterez peut-être que vous aimez incorporer différents styles de codage dans votre projet de toute façon. Mais vous devriez prévoir comment votre style d'écriture et de codage pourrait attirer ou décourager différents types de personnes. Les premières étapes de votre projet sont votre opportunité de définir le précédent que vous souhaitez voir. + +## Votre checklist de pré-lancement + +Prêt à lancer votre projet open source ? Voici une checklist pour vous aider. Toutes les cases sont cochées ? Vous êtes prêt à vous lancer ! [Cliquez sur "Publier"] (https://help.github.com/articles/making-a-private-repository-public/) et donnez vous une tape dans le dos. + +**Documentation** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Code** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Humain** + +Si vous êtes un individu: + +
+ + +
+ +Si vous êtes une entreprise ou une organisation: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## Vous l'avez réussi ! + +Félicitations pour l'ouverture de votre premier projet. Peu importe le résultat, travailler en public est un cadeau fait à la communauté. A chaque commit, commentaire et pull request, vous créez des opportunités pour vous-même et pour les autres d'apprendre et de progresser. diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md index 576a23b42f8..d8a8e07aadd 100644 --- a/_articles/getting-paid.md +++ b/_articles/getting-paid.md @@ -3,11 +3,6 @@ lang: en title: Getting Paid for Open Source Work description: Sustain your work in open source by getting financial support for your time or your project. class: getting-paid -toc: - why-some-people-seek-financial-support: "Why some people seek financial support" - funding-your-own-time: "Funding your own time" - finding-funding-for-your-project: "Finding funding for your project" - building-a-case-for-financial-support: "Building a case for financial support" order: 7 image: /assets/images/cards/getting-paid.png related: @@ -17,7 +12,7 @@ related: ## Why some people seek financial support -Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. +Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. @@ -69,15 +64,7 @@ If you're looking for financial support, there are two paths to consider. You ca Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. -It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general. - - +It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project helps attract new Python developers. Maybe it makes your employer look more developer-friendly in general. If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software. @@ -99,21 +86,26 @@ If your company goes down this route, it's important to keep the boundaries betw If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example: -* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source -* [Rackspace](https://www.rackspace.com/en-us) published its [open source contribution policy](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/) for employees +* Some companies, like [Netflix](https://netflix.github.io/), have websites that highlight their involvement in open source Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. -Finally, depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: +Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) * @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) +Finally, sometimes open source projects put bounties on issues that you might consider helping with. + +* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/). +* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). + ## Finding funding for your project Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. -Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas. +Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas. As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. @@ -123,7 +115,6 @@ Finding sponsorships works well if you have a strong audience or reputation alre A few examples of sponsored projects include: * **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack) -* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803) * **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects ### Create a revenue stream @@ -134,7 +125,7 @@ Depending on your project, you may be able to charge for commercial support, hos * **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product * **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service -Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. +Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. ### Apply for grant funding @@ -144,6 +135,8 @@ Some software foundations and companies offer grants for open source work. Somet * **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) * **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology) * The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work +* **[FLOSS/fund](https://floss.fund/)** is a dedicated fund to provide no-strings attached financial support to FOSS projects globally. +* The **[GitHub Secure Open Source Fund](https://resources.github.com/github-secure-open-source-fund/)** is a program designed to financially and programmatically improve security and sustainability of open source projects. For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you. @@ -183,6 +176,4 @@ Does the funder have any requirements around disbursal? For example, you may nee ## Experiment and don't give up -Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding. - -> +Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases requires you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding. diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md new file mode 100644 index 00000000000..db31c75bfe7 --- /dev/null +++ b/_articles/hi/best-practices.md @@ -0,0 +1,281 @@ +--- +lang: hi +title: मेंटेनर्स के लिए सर्वोत्तम प्रैक्टिस +description: आपके जीवन को आसान बनाने के तरीके, संग्रहणिक प्रक्रियाओं से लेकर आपकी समुदाय का उपयोग करने तक, एक ओपन सोर्स मेंटेनर के रूप में। +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## मेंटेनर का मतलब क्या है? + +अगर आप किसी खुले स्रोत परियोजना का पालन करते हैं जिसका बहुत सारे लोग उपयोग करते हैं, तो आपने देखा होगा कि आप कोडिंग कम और मुद्दों के जवाब देने ज्यादा कर रहे हैं। + +परियोजना के प्रारंभिक चरण में, आप नए विचारों की प्रायोगिकता कर रहे होते हैं और निर्णय वही लेते हैं जो आप चाहते हैं। जब आपकी परियोजना लोकप्रिय होने लगती है, तो आप अपने उपयोगकर्ताओं और सहयोगियों के साथ काम करने के बारे में अधिक सोचेंगे। + +परियोजना को संभालने के लिए कोड से ज्यादा की आवश्यकता होती है। ये कार्य अक्सर अप्रत्याशित होते हैं, लेकिन एक बढ़ती हुई परियोजना के लिए ये उतने ही महत्वपूर्ण होते हैं। हमने कुछ तरीके जुटाए हैं जो आपके जीवन को आसान बनाने में मदद करेंगे, प्रक्रियाओं की दस्तावेजीकरण से लेकर आपकी समुदाय का उपयोग करने तक। + +## प्रक्रियाओं की दस्तावेजीकरण + +चीजों को लिखना मेंटेनर के रूप में आपकी सबसे महत्वपूर्ण चीजों में से एक है। + +दस्तावेजीकरण न केवल आपके विचारों को स्पष्ट करता है, बल्कि यह दूसरे लोगों को समझने में मदद करता है कि आपकी क्या आवश्यकताएं हैं या आपकी क्या उम्मीदें हैं, उनसे पहले ही। + +चीजें लिखने से, कुछ आपके स्कोप में नहीं आने पर "नहीं" कहना आसान हो जाता है। यह लोगों को साथ में आने और मदद करने के लिए भी आसान बनाता है। आप कभी नहीं जान सकते कि कौन-सा व्यक्ति आपकी परियोजना को पढ़ रहा है या उसका उपयोग कर रहा है। + +चाहे आप पूरे पैराग्राफ ना भी उपयोग करें, बुलेट पॉइंट्स को लिखना बिना कुछ लिखे होने से बेहतर है। + +याद रखें कि आपकी दस्तावेजीकरण को अपडेट रखने की आवश्यकता है। अगर आप हमेशा इसे अपडेट नहीं कर पा रहे हैं, तो अपने पुराने दस्तावेजीकरण को हटा दें या इसे पुराना बताएं ताकि सहयोगी जानें कि अपडेट्स का स्वागत है। + +### अपनी परियोजना की दृष्टि लिखें + +परियोजना के लक्ष्यों को लिखने की शुरुआत करें। उन्हें अपने README में जोड़ें, या एक अलग फ़ाइल जिसे VISION के नाम से बुलाया जा सकता है, बनाएं। अगर कोई और आर्टिफैक्ट हो सकते हैं जो मदद कर सकते हैं, जैसे कि परियोजना का रोडमैप, तो उन्हें भी सार्वजनिक बनाएं। + +स्पष्ट, दस्तावेजीत दृष्टि आपको ध्यान में रखने में मदद करती है और आपको दूसरों के सहयोग से आने वाले "स्कोप क्रीप" से बचाती है। + +उदाहरण के लिए, @lord ने यह जानकर पाया कि परियोजना की दृष्टि रखने से उसने यह तय किया कि किन अनुरोधों पर समय खर्च करना चाहिए। एक नए मेंटेनर के रूप में, उसने खेद किया कि उसने अपनी परियोजना की दिशा को न अपनाकर अपने पहले विशेषता अनुरोध के लिए [Slate](https://github.com/lord/slate) को मान्यता दी। + + + +### आपकी उम्मीदाएँ संवाद करें + +नियम लिखने के लिए हो सकते हैं और समय-समय पर यह घबराने वाला होता है। कभी-कभी आपको ऐसा लग सकता है कि आप दूसरों के व्यवहार की पुलिसी बना रहे हैं या सब मज़ा खत्म कर रहे हैं। + +लेकिन यदि नियम स्पष्ट, लिखित और सावधानीपूर्वक पालन किए जाएं, तो यह मेंटेनर्स को सशक्त बनाते हैं। वे आपको उन कामों में नहीं फंसने से बचाते हैं जिन्हें आप करना नहीं चाहते। + +आपकी परियोजना के बारे में ज्यादातर लोग आपके बारे में कुछ भी नहीं जानते हैं या आपके परिस्थितियों के बारे में। वे मान सकते हैं कि आप इस पर काम करने के लिए पैसे प्राप्त करते हैं, विशेष रूप से अगर यह कुछ है जिसका वे नियमित रूप से उपयोग करते हैं और उस पर निर्भर करते हैं। शायद किसी समय आपने अपनी परियोजना में काफी समय लगाया था, लेकिन अब आप एक नई नौकरी या परिवार के सदस्य के साथ व्यस्त हैं। + +ये सब बिल्कुल ठीक है! बस यह सुनिश्चित करें कि अन्य लोग इसके बारे में जानते हैं। + +यदि आपकी परियोजना को पार्ट-टाइम या पूरी तरह से स्वयंसेवा में बनाए रखना है, तो यह स्पष्ट रूप से बताएं कि आपके पास कितना समय है। यह उस समय के समान नहीं है जिसकी परियोजना को आपकी आवश्यकता है, या उस समय के समान नहीं है जिसे दुसरों को आपके खर्च करने के लिए चाहिए। + +यहाँ कुछ नियम हैं जो लिखने योग्य हैं: + +* किसी योगदान की समीक्षा और स्वीकार कैसे की जाती है (_क्या उन्हें परीक्षण की आवश्यकता है? एक समस्या टेम्पलेट?_) +* योगदान के प्रकार जिन्हें आप स्वीकार करेंगे (_क्या आप केवल अपने कोड के एक निश्चित भाग के लिए सहायता चाहते हैं?_) +* जब फॉलो-अप करना उचित हो (_उदाहरण के लिए, "आप 7 दिनों के भीतर अनुरक्षक से प्रतिक्रिया की उम्मीद कर सकते हैं। यदि आपने तब तक कुछ नहीं सुना है, तो बेझिझक थ्रेड को पिंग करें।"_) +* आप प्रोजेक्ट पर कितना समय बिताते हैं (उदाहरण के लिए, "हम इस प्रोजेक्ट पर प्रति सप्ताह केवल 5 घंटे खर्च करते हैं"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) अनुरक्षकों और योगदानकर्ताओं के लिए बुनियादी नियमों वाली परियोजनाओं के कई उदाहरण हैं। + +### संवाद को सार्वजनिक रखें + +अपने संवादों को डॉक्युमेंट करना न भूलें। जहां भी संभव हो, अपनी परियोजना के बारे में होने वाले संवाद को सार्वजनिक रूप से रखें। यदि कोई किसी विशेषता अनुरोध या समर्थन की आवश्यकता के लिए आपसे निजी तौर पर संपर्क करने का प्रयास करता है, तो उन्हें सवालों की सार्वजनिक संवाद स्रोत, जैसे कि मेलिंग सूची या समस्या ट्रैकर, की ओर सभीष्ठता से प्रेषित करें। + +यदि आप अन्य संरक्षकों से मिलते हैं, या यदि आप निजी तौर पर महत्वपूर्ण निर्णय लेते हैं, तो इन संवादों को सार्वजनिक डॉक्युमेंट करें, चाहे आपके नोट पोस्ट करने के बारे में भी हो। + +इस तरह, जो भी आपकी समुदाय में शामिल होता है, वह उसी जानकारी तक पहुँच पाएगा जो सालों से वहाँ हैने वाले किसी के पास है। + +## ना कहना सीखना + +आपने बातें लिख दी हैं. आदर्श रूप से, हर कोई आपके दस्तावेज़ को पढ़ेगा, लेकिन वास्तव में, आपको दूसरों को याद दिलाना होगा कि यह ज्ञान मौजूद है। + +हालाँकि, सब कुछ लिखित होने से उन स्थितियों को वैयक्तिकृत करने में मदद मिलती है जब आपको अपने नियमों को लागू करने की आवश्यकता होती है। + +ना कहना मज़ेदार नहीं है, लेकिन _"आपका योगदान इस परियोजना के मानदंडों से मेल नहीं खाता"__"मुझे आपका योगदान पसंद नहीं है"_ की तुलना में कम व्यक्तिगत लगता है। + +ना कहना उन कई स्थितियों पर लागू होता है जिनका सामना आप एक अनुरक्षक के रूप में करेंगे: सुविधा अनुरोध जो दायरे में फिट नहीं होते हैं, कोई व्यक्ति चर्चा को पटरी से उतार रहा है, दूसरों के लिए अनावश्यक काम कर रहा है। + +### बातचीत मित्रवत रखें + +सबसे महत्वपूर्ण स्थानों में से एक जहां आप ना कहने का अभ्यास करेंगे, वह है आपके मुद्दे पर और अनुरोध कतार को खींचना। एक प्रोजेक्ट अनुरक्षक के रूप में, आपको अनिवार्य रूप से ऐसे सुझाव प्राप्त होंगे जिन्हें आप स्वीकार नहीं करना चाहते हैं। + +हो सकता है कि योगदान आपके प्रोजेक्ट का दायरा बदल दे या आपके दृष्टिकोण से मेल न खाए। हो सकता है कि विचार अच्छा हो, लेकिन कार्यान्वयन ख़राब हो। + +कारण चाहे जो भी हो, उन योगदानों को चतुराई से संभालना संभव है जो आपके प्रोजेक्ट के मानकों को पूरा नहीं करते हैं। + +यदि आपको कोई योगदान मिलता है जिसे आप स्वीकार नहीं करना चाहते हैं, तो आपकी पहली प्रतिक्रिया इसे अनदेखा करना या दिखावा करना हो सकता है कि आपने इसे नहीं देखा है। ऐसा करने से दूसरे व्यक्ति की भावनाएं आहत हो सकती हैं और यहां तक ​​कि आपके समुदाय में अन्य संभावित योगदानकर्ता भी हतोत्साहित हो सकते हैं। + + + +अनचाहे योगदान को खुले छोडने का कारण यह नहीं होना चाहिए कि आपको आपत्ति महसूस हो रही हो या आप अच्छे बनना चाहते हों। समय के साथ, आपके बिना उत्तरित मुद्दे और पुल रिक्वेस्ट (PRs) से आपके प्रोजेक्ट पर काम करने में अधिक तनावपूर्ण और डरावनी भावना उत्पन्न हो सकती है। + +जिन योगदानों को आप जानते हैं कि आप स्वीकार नहीं करना चाहते, उन्हें तुरंत बंद कर देना बेहतर है। यदि आपका प्रोजेक्ट पहले से ही बड़े बैकलॉग से ग्रस्त है, @steveklabnik [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) के लिए सुझाव हैं . + +योगदान को नज़रअंदाज करना आपके समुदाय को नकारात्मक संकेत भेजता है। किसी प्रोजेक्ट में योगदान देना डराने वाला हो सकता है, खासकर अगर यह किसी के लिए पहली बार हो। भले ही आप उनके योगदान को स्वीकार न करें, इसके पीछे वाले व्यक्ति को स्वीकार करें और उनकी रुचि के लिए उन्हें धन्यवाद दें। यह एक बड़ी प्रशंसा है! + +यदि आप कोई योगदान स्वीकार नहीं करना चाहते हैं: + +* **उन्हें उनके योगदान के लिए धन्यवाद** +* **स्पष्ट करें कि यह परियोजना के दायरे में क्यों फिट नहीं बैठता**, और यदि आप सक्षम हैं तो सुधार के लिए स्पष्ट सुझाव दें। दयालु बनें, लेकिन दृढ़ रहें। +* **प्रासंगिक दस्तावेज का लिंक**, यदि आपके पास है। यदि आप उन चीज़ों के लिए बार-बार अनुरोध देखते हैं जिन्हें आप स्वीकार नहीं करना चाहते हैं, तो उन्हें दोहराने से बचने के लिए उन्हें अपने दस्तावेज़ में जोड़ें। +* **अनुरोध बंद करें** + +You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383): + +![Celery screenshot](/assets/images/best-practices/celery.png) + +यदि ना कहने का विचार आपको भयभीत करता है, तो आप अकेले नहीं हैं। जैसा @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/): + +> मैंने कई अलग-अलग ओपन सोर्स प्रोजेक्ट्स, मेसोस, कुबेरनेट्स, क्रोमियम के अनुरक्षकों से बात की है, और वे सभी इस बात से सहमत हैं कि अनुरक्षक होने के सबसे कठिन हिस्सों में से एक उन पैच को "नहीं" कहना है जिन्हें आप नहीं चाहते हैं। + +किसी के योगदान को स्वीकार न करने को लेकर दोषी महसूस न करें। ओपन सोर्स का पहला नियम, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _" +नहीं अस्थायी है, हाँ हमेशा के लिए है।"_ जबकि किसी अन्य व्यक्ति के उत्साह के साथ सहानुभूति रखना अच्छी बात है, किसी योगदान को अस्वीकार करना उसके पीछे वाले व्यक्ति को अस्वीकार करने के समान नहीं है। + +अंततः, यदि कोई योगदान पर्याप्त नहीं है, तो आप इसे स्वीकार करने के लिए बाध्य नहीं हैं। जब लोग आपके प्रोजेक्ट में योगदान दें तो दयालु और उत्तरदायी बनें, लेकिन केवल उन बदलावों को स्वीकार करें जिनके बारे में आपको वास्तव में विश्वास है कि वे आपके प्रोजेक्ट को बेहतर बनाएंगे। आप जितनी बार ना कहने का अभ्यास करेंगे, यह उतना ही आसान हो जाएगा। वादा करना। + +### सक्रिय होना + +सबसे पहले अवांछित योगदान की मात्रा को कम करने के लिए, अपने योगदान मार्गदर्शिका में योगदान जमा करने और स्वीकार करने के लिए अपने प्रोजेक्ट की प्रक्रिया की व्याख्या करें। + +यदि आपको बहुत अधिक निम्न-गुणवत्ता वाले योगदान प्राप्त हो रहे हैं, तो आवश्यक है कि योगदानकर्ता पहले से ही थोड़ा काम करें, उदाहरण के लिए: + +* कोई अंक या पीआर टेम्पलेट/चेकलिस्ट भरें +* पीआर सबमिट करने से पहले एक मुद्दा खोलें + +यदि वे आपके नियमों का पालन नहीं करते हैं, तो समस्या को तुरंत बंद करें और अपने दस्तावेज़ की ओर इंगित करें। + +हालाँकि यह दृष्टिकोण पहली बार में निर्दयी लग सकता है, सक्रिय होना वास्तव में दोनों पक्षों के लिए अच्छा है। इससे इस बात की संभावना कम हो जाती है कि कोई व्यक्ति काम के कई घंटे बर्बाद करके ऐसे पुल अनुरोध में लगाएगा जिसे आप स्वीकार नहीं करेंगे। और यह आपके कार्यभार को प्रबंधित करना आसान बनाता है। + + + +कभी-कभी, जब आप ना कहते हैं, तो आपका संभावित योगदानकर्ता परेशान हो सकता है या आपके निर्णय की आलोचना कर सकता है। यदि उनका व्यवहार शत्रुतापूर्ण हो जाए, [स्थिति को शांत करने के लिए कदम उठाएं](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) या यदि वे रचनात्मक रूप से सहयोग करने के इच्छुक नहीं हैं, तो उन्हें अपने समुदाय से हटा भी दें। + +### मार्गदर्शन को गले लगाओ + +हो सकता है कि आपके समुदाय में कोई व्यक्ति नियमित रूप से ऐसे योगदान सबमिट करता हो जो आपके प्रोजेक्ट के मानकों को पूरा नहीं करता हो। बार-बार अस्वीकृतियों से गुजरना दोनों पक्षों के लिए निराशाजनक हो सकता है। + +यदि आप देखते हैं कि कोई आपके प्रोजेक्ट को लेकर उत्साहित है, लेकिन उसे थोड़ा निखारने की जरूरत है, तो धैर्य रखें। प्रत्येक स्थिति में स्पष्ट रूप से बताएं कि उनका योगदान परियोजना की अपेक्षाओं को पूरा क्यों नहीं करता है। उन्हें किसी आसान या कम अस्पष्ट कार्य की ओर इंगित करने का प्रयास करें, जैसे उनके पैरों को गीला करने के लिए _"अच्छा पहला अंक,"_ चिह्नित कोई मुद्दा। यदि आपके पास समय है, तो उनके पहले योगदान के माध्यम से उन्हें सलाह देने पर विचार करें, या अपने समुदाय में किसी और को ढूंढें जो उन्हें सलाह देने के लिए तैयार हो सकता है। + +## अपने समुदाय का लाभ उठाएं + +आपको सब कुछ खुद ही करने की ज़रूरत नहीं है. आपके प्रोजेक्ट का समुदाय किसी कारण से मौजूद है! भले ही आपके पास अभी तक कोई सक्रिय योगदानकर्ता समुदाय नहीं है, यदि आपके पास बहुत सारे उपयोगकर्ता हैं, तो उन्हें काम पर लगाएं। + +### कार्यभार साझा करें + +यदि आप मदद के लिए दूसरों की तलाश कर रहे हैं, तो आसपास पूछकर शुरुआत करें। + +नए योगदानकर्ताओं को प्राप्त करने का एक तरीका स्पष्ट रूप से है [ऐसे लेबल मुद्दे जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर प्रदर्शित करेगा, जिससे उनकी दृश्यता बढ़ेगी। + +जब आप नए योगदानकर्ताओं को बार-बार योगदान करते हुए देखें, तो अधिक जिम्मेदारी देकर उनके काम को पहचानें। दस्तावेज़ बनाएं कि यदि अन्य लोग चाहें तो नेतृत्व की भूमिका में कैसे विकसित हो सकते हैं। + +दूसरों को इसके लिए प्रोत्साहित करना [अपने प्रोजेक्ट का स्वामित्व साझा करें](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें) आपके स्वयं के कार्यभार को बहुत कम कर सकता है, जैसा कि @lmccart ने अपने प्रोजेक्ट पर पाया, [p5.js](https://github.com/processing/p5.js). + + + +यदि आपको अपने प्रोजेक्ट से हटना है, या तो अंतराल पर या स्थायी रूप से, तो किसी और को आपकी जगह लेने के लिए कहने में कोई शर्म की बात नहीं है। + +यदि अन्य लोग इसकी दिशा को लेकर उत्साहित हैं, तो उन्हें प्रतिबद्ध पहुंच प्रदान करें या औपचारिक रूप से नियंत्रण किसी और को सौंप दें। यदि किसी ने आपके प्रोजेक्ट को फोर्क किया है और इसे कहीं और सक्रिय रूप से बनाए रख रहा है, तो अपने मूल प्रोजेक्ट से फोर्क को जोड़ने पर विचार करें। यह बहुत अच्छा है कि इतने सारे लोग चाहते हैं कि आपका प्रोजेक्ट चालू रहे! + +@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) के लिए विज़न का दस्तावेजीकरण करने से, प्रोजेक्ट से जाने के बाद भी उन लक्ष्यों को जीवित रखने में मदद मिली: + +> मैंने एक विकी पेज लिखा जिसमें बताया गया कि मैं क्या चाहता था और मैं यह क्यों चाहता था। किसी कारण से यह मेरे लिए आश्चर्य की बात थी कि अनुरक्षकों ने परियोजना को उस दिशा में आगे बढ़ाना शुरू कर दिया! क्या यह बिल्कुल वैसा ही हुआ जैसा मैंने इसे किया था? हमेशा नहीं। लेकिन फिर भी यह परियोजना को मैंने जो लिखा था उसके करीब ले आया। + +### दूसरों को वे समाधान बनाने दें जिनकी उन्हें आवश्यकता है + +यदि किसी संभावित योगदानकर्ता की इस बारे में अलग राय है कि आपके प्रोजेक्ट को क्या करना चाहिए, तो आप उन्हें धीरे-धीरे अपने स्वयं के कांटे पर काम करने के लिए प्रोत्साहित करना चाह सकते हैं। + +किसी प्रोजेक्ट को फोर्क करना कोई बुरी बात नहीं है। प्रोजेक्टों को कॉपी और संशोधित करने में सक्षम होना ओपन सोर्स के बारे में सबसे अच्छी चीजों में से एक है। अपने समुदाय के सदस्यों को अपने स्वयं के फ़ोर्क पर काम करने के लिए प्रोत्साहित करना, आपके प्रोजेक्ट के दृष्टिकोण के साथ टकराव किए बिना, उन्हें आवश्यक रचनात्मक आउटलेट प्रदान कर सकता है। + + + +यही बात उस उपयोगकर्ता पर लागू होती है जो वास्तव में एक ऐसा समाधान चाहता है जिसे बनाने के लिए आपके पास बैंडविड्थ नहीं है। एपीआई और अनुकूलन हुक की पेशकश दूसरों को स्रोत को सीधे संशोधित किए बिना, अपनी जरूरतों को पूरा करने में मदद कर सकती है। @orta [ने पाया कि](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) कोकोपोड्स के लिए प्लगइन्स को प्रोत्साहित करने से "कुछ सबसे दिलचस्प विचार" सामने आए: + +> यह लगभग अपरिहार्य है कि एक बार जब कोई परियोजना बड़ी हो जाती है, तो अनुरक्षकों को इस बारे में अधिक रूढ़िवादी बनना पड़ता है कि वे नए कोड कैसे पेश करते हैं। आप "नहीं" कहने में अच्छे हो जाते हैं, लेकिन बहुत से लोगों की ज़रूरतें वैध होती हैं। तो, इसके बजाय आप अपने टूल को एक प्लेटफ़ॉर्म में परिवर्तित कर देते हैं। + +## रोबोट लाओ + +जिस प्रकार ऐसे कार्य हैं जिनमें अन्य लोग आपकी सहायता कर सकते हैं, वैसे ही ऐसे कार्य भी हैं जिन्हें किसी भी मनुष्य को कभी नहीं करना चाहिए। रोबोट आपके मित्र हैं. एक अनुरक्षक के रूप में अपने जीवन को आसान बनाने के लिए उनका उपयोग करें। + +### आपके कोड की गुणवत्ता में सुधार के लिए परीक्षण और अन्य जांच की आवश्यकता है + +परीक्षण जोड़कर अपने प्रोजेक्ट को स्वचालित करने का सबसे महत्वपूर्ण तरीका है। + +परीक्षण योगदानकर्ताओं को यह विश्वास दिलाने में मदद करते हैं कि वे कुछ भी नहीं तोड़ेंगे। वे आपके लिए योगदान की शीघ्रता से समीक्षा करना और स्वीकार करना भी आसान बनाते हैं। आप जितने अधिक संवेदनशील होंगे, आपका समुदाय उतना ही अधिक सक्रिय हो सकता है। + +स्वचालित परीक्षण सेट करें जो आने वाले सभी योगदानों पर चलेंगे, और सुनिश्चित करें कि आपके परीक्षण योगदानकर्ताओं द्वारा स्थानीय स्तर पर आसानी से चलाए जा सकें। आवश्यक है कि सबमिट किए जाने से पहले सभी कोड योगदान आपके परीक्षणों में उत्तीर्ण हों। आप सभी प्रस्तुतियों के लिए गुणवत्ता का न्यूनतम मानक निर्धारित करने में मदद करेंगे। GitHub पर [आवश्यक स्थिति जांच](https://help.github.com/articles/about-required-status-checks/) यह सुनिश्चित करने में मदद कर सकता है कि आपके परीक्षण पास किए बिना कोई भी परिवर्तन मर्ज नहीं किया जाएगा। + +यदि आप परीक्षण जोड़ते हैं, तो यह बताना सुनिश्चित करें कि वे आपकी CONTRIBUTING फ़ाइल में कैसे काम करते हैं। + + + +### बुनियादी रखरखाव कार्यों को स्वचालित करने के लिए टूल का उपयोग करें + +एक लोकप्रिय परियोजना को बनाए रखने के बारे में अच्छी खबर यह है कि अन्य रखरखावकर्ताओं ने संभवतः इसी तरह के मुद्दों का सामना किया है और उनके लिए एक समाधान तैयार किया है। + +रखरखाव कार्य के कुछ पहलुओं को स्वचालित करने में मदद के लिए [विभिन्न प्रकार के उपकरण उपलब्ध हैं](https://github.com/showcases/tools-for-open-source) हैं। कुछ उदाहरण: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases +* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests +* [Danger](https://github.com/danger/danger) helps automate code review +* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information +* [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds + +बग रिपोर्ट और अन्य सामान्य योगदानों के लिए, GitHub के पास [इश्यू टेम्प्लेट्स और पुल रिक्वेस्ट टेम्प्लेट्स](https://github.com/blog/2111-issue-and-pull-request-templates) हैं, जिन्हें आप संचार को सुव्यवस्थित करने के लिए बना सकते हैं आपको प्राप्त हुया। @TalAter ने आपके मुद्दे और पीआर टेम्प्लेट लिखने में आपकी मदद करने के लिए एक [अपनी खुद की एडवेंचर गाइड चुनें](https://www.talater.com/open-source-templates/#/) बनाई है। + +अपनी ईमेल सूचनाओं को प्रबंधित करने के लिए, आप प्राथमिकता के आधार पर व्यवस्थित करने के लिए [ईमेल फ़िल्टर](https://github.com/blog/2203-email-updates-about-your-own-activity) सेट कर सकते हैं। + +यदि आप थोड़ा और उन्नत होना चाहते हैं, तो स्टाइल गाइड और लिंटर परियोजना योगदान को मानकीकृत कर सकते हैं और उनकी समीक्षा करना और स्वीकार करना आसान बना सकते हैं। + +हालाँकि, यदि आपके मानक बहुत जटिल हैं, तो वे योगदान में बाधाएँ बढ़ा सकते हैं। सुनिश्चित करें कि आप सभी के जीवन को आसान बनाने के लिए केवल पर्याप्त नियम जोड़ रहे हैं। + +यदि आप निश्चित नहीं हैं कि कौन से टूल का उपयोग करना है, तो देखें कि अन्य लोकप्रिय प्रोजेक्ट क्या करते हैं, विशेष रूप से आपके पारिस्थितिकी तंत्र में। उदाहरण के लिए, अन्य नोड मॉड्यूल के लिए योगदान प्रक्रिया कैसी दिखती है? समान टूल और दृष्टिकोण का उपयोग करने से आपकी प्रक्रिया आपके लक्षित योगदानकर्ताओं के लिए अधिक परिचित हो जाएगी। + +## विराम देना ठीक है + +ओपन सोर्स का काम एक बार आपके लिए खुशी लेकर आया। शायद अब यह आपको टालने या दोषी महसूस कराने लगा है। + +जब आप अपनी परियोजनाओं के बारे में सोचते हैं तो शायद आप अभिभूत महसूस कर रहे हों या भय की भावना बढ़ रही हो। और इस बीच, मुद्दों और पुल अनुरोधों का ढेर लग जाता है। + +ओपन सोर्स कार्य में बर्नआउट एक वास्तविक और व्यापक मुद्दा है, विशेषकर अनुरक्षकों के बीच। एक अनुरक्षक के रूप में, किसी भी ओपन सोर्स प्रोजेक्ट के अस्तित्व के लिए आपकी खुशी एक गैर-परक्राम्य आवश्यकता है। + +हालाँकि यह बिना कहे चला जाना चाहिए, एक ब्रेक लें! आपको छुट्टी लेने के लिए तब तक इंतजार नहीं करना चाहिए जब तक आप थका हुआ महसूस न करें। @brettcannon, एक पायथन कोर डेवलपर, ने 14 साल के स्वयंसेवक OSS के बाद [एक महीने की छुट्टी](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) लेने का फैसला किया काम। + +किसी भी अन्य प्रकार के काम की तरह, नियमित ब्रेक लेने से आप अपने काम के प्रति तरोताजा, खुश और उत्साहित रहेंगे। + + + +कभी-कभी, जब ऐसा महसूस हो कि हर किसी को आपकी ज़रूरत है तो ओपन सोर्स कार्य से ब्रेक लेना कठिन हो सकता है। लोग आपको दूर जाने के लिए दोषी महसूस कराने का प्रयास भी कर सकते हैं। + +जब आप किसी प्रोजेक्ट से दूर हों तो अपने उपयोगकर्ताओं और समुदाय के लिए समर्थन पाने की पूरी कोशिश करें। यदि आपको आवश्यक सहायता नहीं मिल पा रही है, तो फिर भी एक ब्रेक ले लें। जब आप उपलब्ध न हों तो संवाद करना सुनिश्चित करें, ताकि लोग आपकी प्रतिक्रियाशीलता की कमी से भ्रमित न हों। + +ब्रेक लेना केवल छुट्टियों के अलावा और भी बहुत कुछ पर लागू होता है। यदि आप सप्ताहांत पर या काम के घंटों के दौरान ओपन सोर्स काम नहीं करना चाहते हैं, तो उन अपेक्षाओं को दूसरों को बताएं, ताकि वे जान सकें कि आपको परेशान नहीं करना है। + +## पहले अपना ख्याल रखें! + +किसी लोकप्रिय प्रोजेक्ट को बनाए रखने के लिए विकास के शुरुआती चरणों की तुलना में अलग कौशल की आवश्यकता होती है, लेकिन यह कम फायदेमंद नहीं है। एक अनुरक्षक के रूप में, आप नेतृत्व और व्यक्तिगत कौशल का उस स्तर पर अभ्यास करेंगे जिसका अनुभव बहुत कम लोगों को होता है। हालाँकि इसे प्रबंधित करना हमेशा आसान नहीं होता है, स्पष्ट सीमाएँ निर्धारित करना और केवल वही लेना जिसमें आप सहज हों, आपको खुश, तरोताज़ा और उत्पादक रहने में मदद करेगा। diff --git a/_articles/hi/building-community.md b/_articles/hi/building-community.md new file mode 100644 index 00000000000..642194d3c0b --- /dev/null +++ b/_articles/hi/building-community.md @@ -0,0 +1,278 @@ +--- +lang: hi +title: स्वागत योग्य समुदायों का निर्माण +description: एक ऐसे समुदाय का निर्माण करना जो लोगों को आपके प्रोजेक्ट का उपयोग करने, उसमें योगदान करने और उसका प्रचार-प्रसार करने के लिए प्रोत्साहित करे। +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## सफलता के लिए अपना प्रोजेक्ट तैयार करना + +आपने अपना प्रोजेक्ट लॉन्च कर दिया है, आप इसका प्रचार-प्रसार कर रहे हैं और लोग इसकी जांच कर रहे हैं। बहुत बढ़िया! अब, आप उन्हें अपने साथ कैसे जोड़े रखेंगे? + +स्वागत करने वाला समुदाय आपके प्रोजेक्ट के भविष्य और प्रतिष्ठा में एक निवेश है। यदि आपका प्रोजेक्ट अभी अपना पहला योगदान देखना शुरू कर रहा है, तो शुरुआती योगदानकर्ताओं को एक सकारात्मक अनुभव देकर शुरुआत करें, और उनके लिए वापस आना आसान बनाएं। + +### लोगों को स्वागत का एहसास कराएं + +आपके प्रोजेक्ट के समुदाय के बारे में सोचने का एक तरीका यह है कि @MikeMcQuaid इसे [योगदानकर्ता फ़नल](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) कहता है: + +![योगदानकर्ता फ़नल](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +जैसे ही आप अपना समुदाय बनाते हैं, इस बात पर विचार करें कि फ़नल के शीर्ष पर कोई व्यक्ति (एक संभावित उपयोगकर्ता) सैद्धांतिक रूप से नीचे (एक सक्रिय अनुरक्षक) तक अपना रास्ता कैसे बना सकता है। आपका लक्ष्य योगदानकर्ता अनुभव के प्रत्येक चरण में घर्षण को कम करना है। जब लोगों को आसानी से जीत मिलती है, तो वे और अधिक करने के लिए प्रोत्साहित महसूस करेंगे। + +अपने दस्तावेज़ से प्रारंभ करें: + +* **किसी के लिए आपके प्रोजेक्ट का उपयोग करना आसान बनाएं।** [एक मैत्रीपूर्ण README लिखना](../starting-a-project/#एक-रीडमी-लिखना) +और स्पष्ट कोड उदाहरण आपके प्रोजेक्ट पर आने वाले किसी भी व्यक्ति के लिए आरंभ करना आसान बना देंगे। +* **स्पष्ट रूप से बताएं कि योगदान कैसे करना है**, आपकी [योगदान CONTRIBUTING फ़ाइल का उपयोग करके](../starting-a-project/#अपने-योगदान-संबंधी-दिशानिर्देश-लिखना) और अपने मुद्दों को अद्यतन रखते हुए। +* **अच्छे प्रथम अंक**: नए योगदानकर्ताओं को आरंभ करने में मदद करने के लिए, स्पष्ट रूप से विचार करें [उन मुद्दों को लेबल करना जो शुरुआती लोगों के लिए निपटने के लिए काफी सरल हैं](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). इसके बाद GitHub इन मुद्दों को प्लेटफ़ॉर्म पर विभिन्न स्थानों पर सामने लाएगा, उपयोगी योगदान बढ़ाएगा, और उन मुद्दों से निपटने वाले उपयोगकर्ताओं के मनमुटाव को कम करेगा जो उनके स्तर के लिए बहुत कठिन हैं। + +[GitHub का 2017 ओपन सोर्स सर्वेक्षण](http://opensourcesurvey.org/2017/) अपूर्ण या भ्रमित करने वाला दस्तावेज़ दिखाना ओपन सोर्स उपयोगकर्ताओं के लिए सबसे बड़ी समस्या है। अच्छा दस्तावेज़ीकरण लोगों को आपके प्रोजेक्ट के साथ बातचीत करने के लिए आमंत्रित करता है। अंततः, कोई व्यक्ति कोई समस्या खोलेगा या अनुरोध खींच लेगा। इन इंटरैक्शन को फ़नल से नीचे ले जाने के अवसर के रूप में उपयोग करें। + +* **जब कोई नया व्यक्ति आपके प्रोजेक्ट पर आता है, तो उनकी रुचि के लिए उन्हें धन्यवाद दें!** किसी को वापस आने से रोकने के लिए केवल एक नकारात्मक अनुभव की आवश्यकता होती है। +* **उत्तरदायी बनें।** यदि आप एक महीने तक उनके मुद्दे पर प्रतिक्रिया नहीं देते हैं, तो संभावना है कि वे पहले ही आपके प्रोजेक्ट के बारे में भूल चुके होंगे। +* **आप जिस प्रकार के योगदान स्वीकार करेंगे, उसके बारे में खुले दिमाग से काम करें।** कई योगदानकर्ता बग रिपोर्ट या छोटे सुधार के साथ शुरुआत करते हैं। [योगदान करने के कई तरीके](../how-to-contribute/#योगदान-देने-का-क्या-मतलब-है) हैं। लोग जिस तरह से मदद करना चाहते हैं, उन्हें मदद करने दें। +* **यदि कोई योगदान है जिससे आप असहमत हैं,** उनके विचार के लिए उन्हें धन्यवाद दें और [समझाइए क्यों](../best-practices/#ना-कहना-सीखना) यह परियोजना के दायरे में फिट नहीं बैठता है, यदि आपके पास प्रासंगिक दस्तावेज हैं तो इसे लिंक करें। + + + +अधिकांश ओपन सोर्स योगदानकर्ता "आकस्मिक योगदानकर्ता" हैं: वे लोग जो कभी-कभार ही किसी परियोजना में योगदान करते हैं। एक आकस्मिक योगदानकर्ता के पास आपके प्रोजेक्ट को पूरी तरह से गति देने का समय नहीं हो सकता है, इसलिए आपका काम उनके लिए योगदान करना आसान बनाना है। + +अन्य योगदानकर्ताओं को प्रोत्साहित करना आपके लिए भी एक निवेश है। जब आप अपने सबसे बड़े प्रशंसकों को उस काम के लिए सशक्त बनाते हैं जिसके लिए वे उत्साहित हैं, तो सब कुछ स्वयं करने का दबाव कम होता है। + +### हर चीज़ का दस्तावेजीकरण करें + + + +जब आप कोई नया प्रोजेक्ट शुरू करते हैं, तो अपने काम को निजी रखना स्वाभाविक लग सकता है। लेकिन जब आप अपनी प्रक्रिया को सार्वजनिक रूप से दस्तावेज़ित करते हैं तो ओपन सोर्स प्रोजेक्ट फलते-फूलते हैं। + +जब आप चीज़ें लिखते हैं, तो हर कदम पर अधिक लोग भाग ले सकते हैं। आपको किसी ऐसी चीज़ पर मदद मिल सकती है जिसके बारे में आपको पता भी नहीं था कि आपको इसकी ज़रूरत है। + +चीज़ों को लिखने का अर्थ केवल तकनीकी दस्तावेज़ीकरण से कहीं अधिक है। जब भी आपको कुछ लिखने या अपने प्रोजेक्ट पर निजी तौर पर चर्चा करने की इच्छा महसूस हो, तो अपने आप से पूछें कि क्या आप इसे सार्वजनिक कर सकते हैं। + +अपने प्रोजेक्ट के रोडमैप, आप किस प्रकार के योगदान की तलाश कर रहे हैं, योगदान की समीक्षा कैसे की जाती है, या आपने कुछ निर्णय क्यों लिए, इस बारे में पारदर्शी रहें। + +यदि आप देखते हैं कि कई उपयोगकर्ता एक ही समस्या से जूझ रहे हैं, तो उत्तरों को README में दर्ज करें। + +बैठकों के लिए, किसी प्रासंगिक मुद्दे पर अपने नोट्स या निष्कर्ष प्रकाशित करने पर विचार करें। पारदर्शिता के इस स्तर से आपको जो फीडबैक मिलेगा वह आपको आश्चर्यचकित कर सकता है। + +हर चीज़ का दस्तावेज़ीकरण आपके द्वारा किए जाने वाले काम पर भी लागू होता है। यदि आप अपने प्रोजेक्ट में पर्याप्त अपडेट पर काम कर रहे हैं, तो इसे पुल अनुरोध में डालें और इसे कार्य प्रगति पर (डब्ल्यूआईपी) के रूप में चिह्नित करें। इस तरह, अन्य लोग शुरू से ही इस प्रक्रिया में शामिल महसूस कर सकते हैं। + +### उत्तरदायी बनें + +जैसे ही आप [अपने प्रोजेक्ट का प्रचार करें](../finding-users), लोगों के पास आपके लिए प्रतिक्रिया होगी. उनके मन में यह सवाल हो सकता है कि चीज़ें कैसे काम करती हैं, या उन्हें आरंभ करने में सहायता की आवश्यकता हो सकती है। + +जब कोई व्यक्ति कोई समस्या दर्ज करता है, पुल अनुरोध सबमिट करता है, या आपके प्रोजेक्ट के बारे में कोई प्रश्न पूछता है तो प्रतिक्रियाशील बनने का प्रयास करें। जब आप तुरंत प्रतिक्रिया देते हैं, तो लोगों को लगेगा कि वे एक संवाद का हिस्सा हैं, और वे भाग लेने के लिए अधिक उत्साहित होंगे। + +भले ही आप तुरंत अनुरोध की समीक्षा नहीं कर सकते, लेकिन इसे जल्दी स्वीकार करने से जुड़ाव बढ़ाने में मदद मिलती है। यहां बताया गया है कि @tdreyno ने [मिडिलमैन](https://github.com/middleman/middleman/pull/1466) पर पुल अनुरोध का जवाब कैसे दिया: + +![बिचौलिए का अनुरोध](/assets/images/building-community/middleman_pr.png) + +[मोज़िला के एक अध्ययन में यह पाया गया](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) जिन योगदानकर्ताओं को 48 घंटों के भीतर कोड समीक्षाएँ प्राप्त हुईं, उनकी वापसी और दोहराव योगदान की दर बहुत अधिक थी। + +आपके प्रोजेक्ट के बारे में बातचीत इंटरनेट पर स्टैक ओवरफ्लो, ट्विटर या रेडिट जैसे अन्य स्थानों पर भी हो सकती है। आप इनमें से कुछ स्थानों पर सूचनाएं सेट कर सकते हैं ताकि जब कोई आपके प्रोजेक्ट का उल्लेख करे तो आप सतर्क हो जाएं। + +### अपने समुदाय को एकत्र होने के लिए जगह दें + +अपने समुदाय को एकत्रित होने के लिए जगह देने के दो कारण हैं। + +पहला कारण उनके लिए है. लोगों को एक-दूसरे को जानने में मदद करें। समान रुचि वाले लोग अनिवार्य रूप से इसके बारे में बात करने के लिए जगह चाहेंगे। और जब संचार सार्वजनिक और सुलभ होता है, तो कोई भी गति प्राप्त करने और भाग लेने के लिए पिछले अभिलेखों को पढ़ सकता है। + +दूसरा कारण आपके लिए है. यदि आप लोगों को अपने प्रोजेक्ट के बारे में बात करने के लिए सार्वजनिक स्थान नहीं देते हैं, तो वे संभवतः आपसे सीधे संपर्क करेंगे। शुरुआत में, निजी संदेशों का "सिर्फ एक बार" जवाब देना काफी आसान लग सकता है। लेकिन समय के साथ, खासकर यदि आपका प्रोजेक्ट लोकप्रिय हो जाता है, तो आप थकावट महसूस करेंगे। अपने प्रोजेक्ट के बारे में लोगों से निजी तौर पर संवाद करने के प्रलोभन से बचें। इसके बजाय, उन्हें एक निर्दिष्ट सार्वजनिक चैनल पर निर्देशित करें। + +सार्वजनिक संचार उतना ही सरल हो सकता है जितना लोगों को आपको सीधे ईमेल करने या आपके ब्लॉग पर टिप्पणी करने के बजाय किसी मुद्दे को खोलने के लिए निर्देशित करना। आप अपने प्रोजेक्ट के बारे में लोगों से बात करने के लिए एक मेलिंग सूची भी सेट कर सकते हैं, या एक ट्विटर अकाउंट, स्लैक या आईआरसी चैनल बना सकते हैं। या उपरोक्त सभी प्रयास करें! +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) समुदाय के सदस्यों की सहायता के लिए हर दूसरे सप्ताह कार्यालय समय अलग रखें: + +> कोप्स के पास समुदाय को सहायता और मार्गदर्शन प्रदान करने के लिए हर दूसरे सप्ताह का समय भी निर्धारित होता है। कोप्स अनुरक्षकों ने नवागंतुकों के साथ काम करने, पीआर के साथ मदद करने और नई सुविधाओं पर चर्चा करने के लिए विशेष रूप से समर्पित समय निर्धारित करने पर सहमति व्यक्त की है। + +सार्वजनिक संचार के उल्लेखनीय अपवाद हैं: 1. सुरक्षा मुद्दे और 2. संवेदनशील आचार संहिता का उल्लंघन। आपके पास लोगों के लिए इन मुद्दों की निजी तौर पर रिपोर्ट करने का हमेशा एक तरीका होना चाहिए। यदि आप अपने व्यक्तिगत ईमेल का उपयोग नहीं करना चाहते हैं, तो एक समर्पित ईमेल पता सेट करें। + +## अपने समुदाय को बढ़ाना + +समुदाय अत्यंत शक्तिशाली हैं. वह शक्ति वरदान या अभिशाप हो सकती है, यह इस बात पर निर्भर करता है कि आप उसका उपयोग कैसे करते हैं। जैसे-जैसे आपके प्रोजेक्ट का समुदाय बढ़ता है, उसे विनाश की नहीं बल्कि निर्माण की शक्ति बनने में मदद करने के कई तरीके हैं। + +### बुरे अभिनेताओं को बर्दाश्त न करें + +कोई भी लोकप्रिय परियोजना अनिवार्य रूप से ऐसे लोगों को आकर्षित करेगी जो आपके समुदाय को मदद करने के बजाय नुकसान पहुंचाते हैं। वे अनावश्यक बहस शुरू कर सकते हैं, छोटी-छोटी बातों पर विवाद कर सकते हैं, या दूसरों को धमका सकते हैं। + +इस प्रकार के लोगों के प्रति शून्य-सहिष्णुता की नीति अपनाने की पूरी कोशिश करें। यदि अनियंत्रित छोड़ दिया जाए, तो नकारात्मक लोग आपके समुदाय के अन्य लोगों को असहज कर देंगे। वे चले भी सकते हैं. + + + +आपके प्रोजेक्ट के तुच्छ पहलुओं पर नियमित बहस आपके सहित दूसरों को महत्वपूर्ण कार्यों पर ध्यान केंद्रित करने से विचलित करती है। आपके प्रोजेक्ट में आने वाले नए लोग इन वार्तालापों को देख सकते हैं और भाग नहीं लेना चाहेंगे। + +जब आप अपने प्रोजेक्ट पर नकारात्मक व्यवहार होते देखें, तो उसे सार्वजनिक रूप से बताएं। दयालु लेकिन दृढ़ स्वर में बताएं कि उनका व्यवहार स्वीकार्य क्यों नहीं है। यदि समस्या बनी रहती है, तो आपको इसकी आवश्यकता हो सकती है [उन्हें जाने के लिए कहो](../code-of-conduct/#अपनी-आचार-संहिता-लागू-करना). आपके [आचार संहिता](../code-of-conduct/) इन वार्तालापों के लिए एक रचनात्मक मार्गदर्शक हो सकता है। + +### योगदानकर्ताओं से वहीं मिलें जहां वे हैं + +जैसे-जैसे आपका समुदाय बढ़ता है, अच्छा दस्तावेज़ीकरण और अधिक महत्वपूर्ण हो जाता है। आकस्मिक योगदानकर्ता, जो अन्यथा आपके प्रोजेक्ट से परिचित नहीं हो सकते हैं, उन्हें जिस संदर्भ की आवश्यकता है उसे तुरंत प्राप्त करने के लिए आपके दस्तावेज़ को पढ़ें। + +अपनी योगदान फ़ाइल में, नए योगदानकर्ताओं को स्पष्ट रूप से बताएं कि शुरुआत कैसे करें। आप इस उद्देश्य के लिए एक समर्पित अनुभाग भी बनाना चाह सकते हैं। उदाहरण के लिए, [Django](https://github.com/django/django) के पास नए योगदानकर्ताओं का स्वागत करने के लिए एक विशेष लैंडिंग पृष्ठ है। + +![Django नया योगदानकर्ता पृष्ठ](/assets/images/building-community/django_new_contributors.png) + +अपनी समस्या कतार में, ऐसे बग लेबल करें जो विभिन्न प्रकार के योगदानकर्ताओं के लिए उपयुक्त हों: उदाहरण के लिए, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) आपके प्रोजेक्ट में नए व्यक्ति के लिए आपके मुद्दों को तुरंत स्कैन करना और आरंभ करना आसान बनाएं। + +अंत में, लोगों को हर कदम पर स्वागत महसूस कराने के लिए अपने दस्तावेज़ का उपयोग करें। + +आप उन अधिकांश लोगों के साथ कभी बातचीत नहीं करेंगे जो आपके प्रोजेक्ट पर आते हैं। ऐसे योगदान भी हो सकते हैं जो आपको इसलिए नहीं मिले क्योंकि कोई व्यक्ति डरा हुआ महसूस कर रहा था या नहीं जानता था कि कहां से शुरुआत करें। यहां तक ​​कि कुछ दयालु शब्द भी किसी को हताशा में आपका प्रोजेक्ट छोड़ने से रोक सकते हैं। + +उदाहरण के लिए, यहां बताया गया है कि कैसे [Rubinius](https://github.com/rubinius/rubinius/) प्रारंभ होगा [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> हम रुबिनियस का उपयोग करने के लिए आपको धन्यवाद कहकर शुरुआत करना चाहते हैं। यह परियोजना प्यार का परिश्रम है, और हम उन सभी उपयोगकर्ताओं की सराहना करते हैं जो बग पकड़ते हैं, प्रदर्शन में सुधार करते हैं और दस्तावेज़ीकरण में मदद करते हैं। प्रत्येक योगदान सार्थक है, इसलिए भाग लेने के लिए धन्यवाद। जैसा कि कहा जा रहा है, यहां कुछ दिशानिर्देश दिए गए हैं जिनका पालन करने के लिए हम आपसे कहते हैं ताकि हम आपकी समस्या का सफलतापूर्वक समाधान कर सकें। + +### अपने प्रोजेक्ट का स्वामित्व साझा करें + + + +जब लोग स्वामित्व की भावना महसूस करते हैं तो वे परियोजनाओं में योगदान देने के लिए उत्साहित होते हैं। इसका मतलब यह नहीं है कि आपको अपने प्रोजेक्ट के दृष्टिकोण को बदलना होगा या उन योगदानों को स्वीकार करना होगा जो आप नहीं चाहते हैं। लेकिन जितना अधिक आप दूसरों को श्रेय देंगे, उतना ही अधिक वे आपके साथ बने रहेंगे। + +देखें कि क्या आप अपने समुदाय के साथ स्वामित्व को यथासंभव साझा करने के तरीके ढूंढ सकते हैं। यहाँ कुछ विचार हैं: + +* **आसान (गैर-महत्वपूर्ण) बग को ठीक करने का विरोध करें।** इसके बजाय, उन्हें नए योगदानकर्ताओं को भर्ती करने के अवसर के रूप में उपयोग करें, या किसी ऐसे व्यक्ति का मार्गदर्शन करें जो योगदान देना चाहता है। यह पहली बार में अस्वाभाविक लग सकता है, लेकिन आपका निवेश समय के साथ फल देगा। उदाहरण के लिए, @michaeljoseph ने एक योगदानकर्ता से इसे स्वयं ठीक करने के बजाय नीचे दिए गए [कुकीकटर](https://github.com/audreyr/cookiecutter) मुद्दे पर एक पुल अनुरोध सबमिट करने के लिए कहा। + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **अपने प्रोजेक्ट में एक योगदानकर्ता या लेखक फ़ाइल प्रारंभ करें** जिसमें आपके प्रोजेक्ट में योगदान देने वाले सभी लोगों की सूची हो, जैसे [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) +करता है. + +* यदि आपके पास एक बड़ा समुदाय है, तो **एक समाचार पत्र भेजें या एक ब्लॉग पोस्ट लिखें** योगदानकर्ताओं को धन्यवाद दें। जंग का [This Week in Rust](https://this-week-in-rust.org/) और हुडीज़ [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) दो अच्छे उदाहरण हैं. + +* **प्रत्येक योगदानकर्ता को पहुंच प्रदान करें** @felixge ने पाया कि इसने लोगों को बनाया है [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), और उन्हें उन परियोजनाओं के लिए नए अनुरक्षक भी मिल गए जिन पर उन्होंने कुछ समय से काम नहीं किया था। + +* यदि आपका प्रोजेक्ट GitHub पर है, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** और कम से कम एक बैकअप व्यवस्थापक जोड़ें. संगठन बाहरी सहयोगियों के साथ परियोजनाओं पर काम करना आसान बनाते हैं। + +हकीकत तो यही है [most projects only have](https://peerj.com/preprints/1233/) एक या दो अनुरक्षक जो अधिकांश कार्य करते हैं। आपका प्रोजेक्ट जितना बड़ा होगा, और आपका समुदाय जितना बड़ा होगा, सहायता पाना उतना ही आसान होगा। + +हालाँकि आपको कॉल का उत्तर देने के लिए हमेशा कोई नहीं मिल सकता है, लेकिन वहाँ सिग्नल लगाने से अन्य लोगों के कॉल करने की संभावना बढ़ जाती है। और आप जितनी जल्दी शुरुआत करेंगे, उतनी जल्दी लोग मदद कर सकते हैं। + + + +## विवादों का समाधान + +आपके प्रोजेक्ट के शुरुआती चरणों में, बड़े निर्णय लेना आसान होता है। जब आप कुछ करना चाहते हैं, तो आप बस उसे करते हैं। + +जैसे-जैसे आपका प्रोजेक्ट अधिक लोकप्रिय होगा, अधिक लोग आपके निर्णयों में रुचि लेंगे। भले ही आपके पास योगदानकर्ताओं का एक बड़ा समुदाय न हो, यदि आपके प्रोजेक्ट में बहुत सारे उपयोगकर्ता हैं, तो आप पाएंगे कि लोग निर्णयों पर विचार कर रहे हैं या अपने स्वयं के मुद्दे उठा रहे हैं। + +अधिकांश भाग के लिए, यदि आपने एक मैत्रीपूर्ण, सम्मानजनक समुदाय विकसित किया है और अपनी प्रक्रियाओं को खुले तौर पर प्रलेखित किया है, तो आपका समुदाय समाधान खोजने में सक्षम होना चाहिए। लेकिन कभी-कभी आप ऐसे मुद्दे में फंस जाते हैं जिसका समाधान करना थोड़ा कठिन होता है। + +### दयालुता का स्तर निर्धारित करें + +जब आपका समुदाय किसी कठिन मुद्दे से जूझ रहा हो, तो गुस्सा बढ़ सकता है। लोग क्रोधित या निराश हो सकते हैं और इसे एक-दूसरे पर या आप पर निकाल सकते हैं। + +एक अनुरक्षक के रूप में आपका काम इन स्थितियों को बढ़ने से रोकना है। भले ही विषय पर आपकी राय मजबूत हो, लड़ाई में कूदने और अपने विचारों को आगे बढ़ाने के बजाय एक मॉडरेटर या फैसिलिटेटर की स्थिति लेने का प्रयास करें। यदि कोई निर्दयी हो रहा है या बातचीत पर एकाधिकार जमा रहा है, [तुरंत कार्रवाई करें](../building-community/#बुरे-अभिनेताओं-को-बर्दाश्त-न-करें) +चर्चाओं को सभ्य और उत्पादक बनाए रखना। + + + +अन्य लोग मार्गदर्शन के लिए आपकी ओर देख रहे हैं। अच्छा उदाहरण स्थापित करो। आप अभी भी निराशा, नाखुशी या चिंता व्यक्त कर सकते हैं, लेकिन ऐसा शांति से करें। + +खुद को शांत रखना आसान नहीं है, लेकिन नेतृत्व प्रदर्शित करने से आपके समुदाय के स्वास्थ्य में सुधार होता है। इंटरनेट आपका धन्यवाद करता है. + +### अपने README को एक संविधान मानें + +आपका README है [निर्देशों के एक संग्रह से कहीं अधिक](../starting-a-project/#एक-रीडमी-लिखना). यह आपके लक्ष्यों, उत्पाद दृष्टिकोण और रोडमैप के बारे में बात करने का भी स्थान है। यदि लोग किसी विशेष सुविधा की योग्यता पर बहस करने पर अत्यधिक ध्यान केंद्रित कर रहे हैं, तो यह आपके README पर दोबारा गौर करने और आपके प्रोजेक्ट की उच्च दृष्टि के बारे में बात करने में मदद कर सकता है। अपने README पर ध्यान केंद्रित करने से बातचीत भी अवैयक्तिक हो जाती है, जिससे आप रचनात्मक चर्चा कर सकते हैं। + +### यात्रा पर ध्यान दें, मंजिल पर नहीं + +कुछ परियोजनाएँ प्रमुख निर्णय लेने के लिए मतदान प्रक्रिया का उपयोग करती हैं। पहली नज़र में समझदार होते हुए भी, मतदान एक-दूसरे की चिंताओं को सुनने और संबोधित करने के बजाय "उत्तर" पाने पर जोर देता है। + +मतदान राजनीतिक हो सकता है, जहां समुदाय के सदस्य एक-दूसरे का पक्ष लेने या एक निश्चित तरीके से मतदान करने के लिए दबाव महसूस करते हैं। चाहे वह कोई भी हो, हर कोई वोट नहीं देता [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) आपके समुदाय में, या वर्तमान उपयोगकर्ताओं को, जिन्हें नहीं पता था कि वोट हो रहा है। + +कभी-कभी, मतदान एक आवश्यक टाईब्रेकर होता है। हालाँकि, जितना आप सक्षम हैं, आम सहमति के बजाय ["आम सहमति की तलाश"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) पर जोर दें। + +सर्वसम्मति प्राप्त करने की प्रक्रिया के तहत, समुदाय के सदस्य प्रमुख चिंताओं पर तब तक चर्चा करते हैं जब तक उन्हें नहीं लगता कि उन्हें पर्याप्त रूप से सुना गया है। जब केवल छोटी-मोटी चिंताएँ बची रहती हैं, तो समुदाय आगे बढ़ता है। "आम सहमति की मांग" यह स्वीकार करती है कि एक समुदाय एक सटीक उत्तर तक पहुंचने में सक्षम नहीं हो सकता है। इसके बजाय, यह सुनने और चर्चा को प्राथमिकता देता है। + + + +भले ही आप वास्तव में सर्वसम्मति प्राप्त करने की प्रक्रिया नहीं अपनाते हों, एक परियोजना अनुरक्षक के रूप में, यह महत्वपूर्ण है कि लोग जानें कि आप सुन रहे हैं। अन्य लोगों को यह महसूस कराना कि उनकी बात सुनी जा रही है, और उनकी चिंताओं को हल करने के लिए प्रतिबद्ध होना, संवेदनशील स्थितियों को दूर करने में काफी मदद करता है। फिर, अपने शब्दों को कार्यों के साथ जारी रखें। + +किसी संकल्प के लिए निर्णय लेने में जल्दबाजी न करें। सुनिश्चित करें कि हर कोई यह महसूस करे कि समाधान की ओर बढ़ने से पहले सभी जानकारी सार्वजनिक कर दी गई है। + +### बातचीत को कार्रवाई पर केंद्रित रखें + +चर्चा महत्वपूर्ण है, लेकिन उत्पादक और अनुत्पादक बातचीत में अंतर है। + +चर्चा को तब तक प्रोत्साहित करें जब तक यह सक्रिय रूप से समाधान की ओर बढ़ रही हो। यदि यह स्पष्ट है कि बातचीत धीमी हो रही है या विषय से भटक रही है, तीखी नोकझोंक व्यक्तिगत होती जा रही है, या लोग छोटी-छोटी बातों को लेकर झगड़ रहे हैं, तो इसे बंद करने का समय आ गया है। + +इन वार्तालापों को जारी रखने की अनुमति देना न केवल मौजूदा मुद्दे के लिए बुरा है, बल्कि आपके समुदाय के स्वास्थ्य के लिए भी बुरा है। यह एक संदेश भेजता है कि इस प्रकार की बातचीत की अनुमति है या इसे प्रोत्साहित भी किया जाता है, और यह लोगों को भविष्य के मुद्दों को उठाने या हल करने से हतोत्साहित कर सकता है। + +आपके द्वारा या दूसरों द्वारा उठाए गए प्रत्येक बिंदु पर, अपने आप से पूछें, _"यह हमें किसी समाधान के करीब कैसे लाता है?"_ + +यदि बातचीत सुलझने लगी है, तो बातचीत पर फिर से ध्यान केंद्रित करने के लिए समूह से पूछें, _"हमें आगे कौन सा कदम उठाना चाहिए?"_ + +यदि बातचीत स्पष्ट रूप से कहीं नहीं जा रही है, कोई स्पष्ट कार्रवाई नहीं की जानी है, या उचित कार्रवाई पहले ही की जा चुकी है, तो मुद्दे को बंद करें और बताएं कि आपने इसे क्यों बंद किया। + + + +### अपनी लड़ाइयाँ बुद्धिमानी से चुनें + +प्रसंग महत्वपूर्ण है. विचार करें कि चर्चा में कौन शामिल है और वे शेष समुदाय का प्रतिनिधित्व कैसे करते हैं। + +क्या समुदाय में हर कोई इस मुद्दे से परेशान है, या इससे जुड़ा भी है? या एक अकेला उपद्रवी है? केवल सक्रिय आवाज़ों पर ही नहीं, बल्कि अपने मूक समुदाय के सदस्यों पर भी विचार करना न भूलें। + +यदि मुद्दा आपके समुदाय की व्यापक आवश्यकताओं का प्रतिनिधित्व नहीं करता है, तो आपको बस कुछ लोगों की चिंताओं को स्वीकार करने की आवश्यकता हो सकती है। यदि यह बिना किसी स्पष्ट समाधान के बार-बार आने वाला मुद्दा है, तो उन्हें विषय पर पिछली चर्चाओं की ओर इंगित करें और थ्रेड बंद कर दें। + +### एक सामुदायिक टाईब्रेकर की पहचान करें + +अच्छे रवैये और स्पष्ट संचार के साथ, अधिकांश कठिन परिस्थितियाँ हल हो सकती हैं। हालाँकि, एक सार्थक बातचीत में भी, कैसे आगे बढ़ना है, इस पर राय में अंतर हो सकता है। इन मामलों में, ऐसे व्यक्ति या लोगों के समूह की पहचान करें जो टाईब्रेकर के रूप में काम कर सकते हैं। + +एक टाईब्रेकर परियोजना का प्राथमिक अनुरक्षक हो सकता है, या यह लोगों का एक छोटा समूह हो सकता है जो मतदान के आधार पर निर्णय लेता है। आदर्श रूप से, आपने गवर्नेंस फ़ाइल का उपयोग करने से पहले उसमें एक टाईब्रेकर और संबंधित प्रक्रिया की पहचान कर ली है। + +आपका टाईब्रेकर अंतिम उपाय होना चाहिए। विभाजनकारी मुद्दे आपके समुदाय के लिए बढ़ने और सीखने का एक अवसर हैं। इन अवसरों को स्वीकार करें और जहां भी संभव हो समाधान की ओर बढ़ने के लिए सहयोगात्मक प्रक्रिया का उपयोग करें। + +## समुदाय खुले स्रोत का ❤️ है + +स्वस्थ, संपन्न समुदाय हर सप्ताह खुले स्रोत में खर्च किए गए हजारों घंटों को ऊर्जा प्रदान करते हैं। कई योगदानकर्ता खुले स्रोत पर काम करने - या काम न करने - का कारण अन्य लोगों को बताते हैं। रचनात्मक रूप से उस शक्ति का उपयोग करना सीखकर, आप किसी को अविस्मरणीय ओपन सोर्स अनुभव प्राप्त करने में मदद करेंगे। diff --git a/_articles/hi/code-of-conduct.md b/_articles/hi/code-of-conduct.md new file mode 100644 index 00000000000..cf0d9f21042 --- /dev/null +++ b/_articles/hi/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: hi +title: आपकी आचार संहिता +description: आचार संहिता को अपनाकर और लागू करके स्वस्थ और रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाना। +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## मुझे आचार संहिता की आवश्यकता क्यों है? + +आचार संहिता एक दस्तावेज है जो आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार की अपेक्षाएं स्थापित करता है। आचार संहिता को अपनाने और लागू करने से आपके समुदाय के लिए एक सकारात्मक सामाजिक माहौल बनाने में मदद मिल सकती है। + +आचार संहिता न केवल आपके प्रतिभागियों को, बल्कि स्वयं को भी सुरक्षित रखने में मदद करती है। यदि आप किसी प्रोजेक्ट को बनाए रखते हैं, तो आप पा सकते हैं कि अन्य प्रतिभागियों का अनुत्पादक रवैया आपको समय के साथ अपने काम के बारे में थका हुआ या नाखुश महसूस करा सकता है। + +आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार को सुविधाजनक बनाने के लिए सशक्त बनाती है। सक्रिय रहने से यह संभावना कम हो जाती है कि आप या अन्य लोग अपने प्रोजेक्ट से थक जाएंगे, और जब कोई ऐसा कुछ करता है जिससे आप सहमत नहीं हैं तो आपको कार्रवाई करने में मदद मिलती है। + +## आचार संहिता स्थापित करना + +यथाशीघ्र एक आचार संहिता स्थापित करने का प्रयास करें: आदर्श रूप से, जब आप पहली बार अपना प्रोजेक्ट बनाते हैं। + +आपकी अपेक्षाओं को संप्रेषित करने के अलावा, आचार संहिता निम्नलिखित का वर्णन करती है: + +* जहां आचार संहिता प्रभावी होती है _(केवल मुद्दों और पुल अनुरोधों, या घटनाओं जैसी सामुदायिक गतिविधियों पर?)_ +* आचार संहिता किस पर लागू होती है _(समुदाय के सदस्यों और अनुरक्षकों पर, लेकिन प्रायोजकों के बारे में क्या?)_ +* यदि कोई आचार संहिता का उल्लंघन करता है तो क्या होगा +* कोई कैसे उल्लंघन की रिपोर्ट कर सकता है + +जहां भी आप कर सकें, पूर्व कला का उपयोग करें। [योगदानकर्ता अनुबंध](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग कुबेरनेट्स, रेल्स और स्विफ्ट सहित 40,000 से अधिक ओपन सोर्स परियोजनाओं द्वारा किया जाता है। + +The [Django आचार संहिता](https://www.djangoproject.com/conduct/) और यह [नागरिक आचार संहिता](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) आचार संहिता के दो अच्छे उदाहरण भी हैं। + +एक CODE_OF_CONDUCT फ़ाइल अपने प्रोजेक्ट की रूट डायरेक्टरी में फ़ाइल में रखें, और इसे अपने समुदाय से जोड़कर इसे अपने समुदाय के लिए दृश्यमान बनाएं CONTRIBUTING या README फ़ाइल. + +## यह निर्णय लेना कि आप अपनी आचार संहिता को कैसे लागू करेंगे + + + +उल्लंघन होने से **_पहले_** आपको स्पष्ट करना चाहिए कि आपकी आचार संहिता कैसे लागू की जाएगी। ऐसा करने के कई कारण हैं: + +* यह दर्शाता है कि आप जरूरत पड़ने पर कार्रवाई करने को लेकर गंभीर हैं। + +* आपका समुदाय अधिक आश्वस्त महसूस करेगा कि शिकायतों की वास्तव में समीक्षा की जाती है। + +* आप अपने समुदाय को आश्वस्त करेंगे कि समीक्षा प्रक्रिया निष्पक्ष और पारदर्शी है, क्या उन्हें कभी भी उल्लंघन के लिए जांच में पाया जाएगा। + +आपको लोगों को आचार संहिता के उल्लंघन की रिपोर्ट करने का एक निजी तरीका (जैसे ईमेल पता) देना चाहिए और यह बताना चाहिए कि वह रिपोर्ट कौन प्राप्त करता है। यह एक अनुरक्षक, अनुरक्षकों का समूह या आचार संहिता कार्य समूह हो सकता है। + +यह मत भूलिए कि हो सकता है कि कोई व्यक्ति उस व्यक्ति के बारे में उल्लंघन की रिपोर्ट करना चाहता हो जो उन रिपोर्टों को प्राप्त करता है। इस मामले में, उन्हें किसी अन्य को उल्लंघन की रिपोर्ट करने का विकल्प दें। उदाहरण के लिए,@ctb and @mr-c [उनके प्रोजेक्ट पर स्पष्टीकरण दें](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> अपमानजनक, परेशान करने वाले, या अन्यथा अस्वीकार्य व्यवहार के मामलों की रिपोर्ट **khmer-project@idyll.org** पर ईमेल करके की जा सकती है, जो केवल सी. टाइटस ब्राउन और माइकल आर. क्रूसो को जाती है। उनमें से किसी एक से जुड़े मुद्दे की रिपोर्ट करने के लिए कृपया विज्ञान और प्रौद्योगिकी के लिए एक एनएसएफ केंद्र, बीकॉन सेंटर फॉर द स्टडी ऑफ इवोल्यूशन इन एक्शन में विविधता निदेशक **जूडी ब्राउन क्लार्क, पीएच.डी.** को ईमेल करें।* + +प्रेरणा के लिए, Django का [प्रवर्तन मैनुअल](https://www.djangoproject.com/conduct/enforcement-manual/) देखें (हालाँकि, आपके प्रोजेक्ट के आकार के आधार पर, आपको इतनी व्यापक चीज़ की आवश्यकता नहीं हो सकती है). + +## अपनी आचार संहिता लागू करना + +कभी-कभी, आपके सर्वोत्तम प्रयासों के बावजूद, कोई ऐसा कार्य करेगा जो इस संहिता का उल्लंघन करता है। नकारात्मक या हानिकारक व्यवहार सामने आने पर उससे निपटने के कई तरीके हैं। + +### स्थिति के बारे में जानकारी इकट्ठा करें + +समुदाय के प्रत्येक सदस्य की आवाज़ को अपनी आवाज़ के समान महत्वपूर्ण मानें। यदि आपको कोई रिपोर्ट मिलती है कि किसी ने आचार संहिता का उल्लंघन किया है, तो इसे गंभीरता से लें और मामले की जांच करें, भले ही वह उस व्यक्ति के साथ आपके अपने अनुभव से मेल न खाता हो। ऐसा करना आपके समुदाय को संकेत देता है कि आप उनके दृष्टिकोण को महत्व देते हैं और उनके निर्णय पर भरोसा करते हैं। + +विचाराधीन समुदाय का सदस्य बार-बार अपराधी हो सकता है जो लगातार दूसरों को असहज महसूस कराता है, या हो सकता है कि उसने केवल एक बार ही कुछ कहा या किया हो। संदर्भ के आधार पर दोनों ही कार्रवाई करने के आधार हो सकते हैं। + +प्रतिक्रिया देने से पहले, स्वयं को यह समझने का समय दें कि क्या हुआ था। यह बेहतर ढंग से समझने के लिए कि वे कौन हैं और उन्होंने ऐसा व्यवहार क्यों किया होगा, उस व्यक्ति की पिछली टिप्पणियों और बातचीत को पढ़ें। इस व्यक्ति और उनके व्यवहार के बारे में अपने अलावा अन्य दृष्टिकोण इकट्ठा करने का प्रयास करें। + + + +### उचित कार्रवाई करें + +पर्याप्त जानकारी एकत्र करने और संसाधित करने के बाद, आपको यह निर्णय लेना होगा कि क्या करना है। जब आप अपने अगले कदमों पर विचार करें, तो याद रखें कि एक मॉडरेटर के रूप में आपका लक्ष्य एक सुरक्षित, सम्मानजनक और सहयोगात्मक वातावरण को बढ़ावा देना है। न केवल इस बात पर विचार करें कि संबंधित स्थिति से कैसे निपटा जाए, बल्कि यह भी कि आपकी प्रतिक्रिया आपके समुदाय के बाकी व्यवहार और अपेक्षाओं को कैसे प्रभावित करेगी। + +जब कोई आचार संहिता के उल्लंघन की रिपोर्ट करता है, तो इसे संभालना उनका नहीं, आपका काम है। कभी-कभी, रिपोर्टर अपने करियर, प्रतिष्ठा या शारीरिक सुरक्षा को बहुत जोखिम में डालकर जानकारी का खुलासा कर रहा है। उन्हें अपने उत्पीड़क का सामना करने के लिए मजबूर करना रिपोर्टर को समझौतावादी स्थिति में डाल सकता है। आपको संबंधित व्यक्ति के साथ सीधा संवाद संभालना चाहिए, जब तक कि रिपोर्टर स्पष्ट रूप से अन्यथा अनुरोध न करे। + +ऐसे कुछ तरीके हैं जिनसे आप आचार संहिता के उल्लंघन पर प्रतिक्रिया दे सकते हैं: + +* **संबंधित व्यक्ति को सार्वजनिक चेतावनी दें** और बताएं कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला, अधिमानतः उस चैनल में जहां यह हुआ। जहां संभव हो, सार्वजनिक संचार शेष समुदाय को बताता है कि आप आचार संहिता को गंभीरता से लेते हैं। दयालु बनें, लेकिन अपने संचार में दृढ़ रहें। + +* **व्यक्तिगत रूप से उस व्यक्ति तक पहुंचें**यह समझाने के लिए कि उनके व्यवहार ने दूसरों पर कैसे नकारात्मक प्रभाव डाला। यदि स्थिति में संवेदनशील व्यक्तिगत जानकारी शामिल है तो आप निजी संचार चैनल का उपयोग करना चाह सकते हैं। यदि आप किसी के साथ निजी तौर पर संवाद करते हैं, तो उन लोगों को सीसी देना एक अच्छा विचार है जिन्होंने सबसे पहले स्थिति की सूचना दी थी, ताकि वे जान सकें कि आपने कार्रवाई की है। सीसी देने से पहले रिपोर्टिंग व्यक्ति से सहमति मांगें। + +कभी-कभी, किसी समाधान तक नहीं पहुंचा जा सकता. सामना किए जाने पर संबंधित व्यक्ति आक्रामक या शत्रुतापूर्ण हो सकता है या अपना व्यवहार नहीं बदलता है। इस स्थिति में, आप कड़ी कार्रवाई करने पर विचार कर सकते हैं। उदाहरण के लिए: + +* **परियोजना के किसी भी पहलू में भाग लेने पर अस्थायी प्रतिबंध के माध्यम से लागू, परियोजना से संबंधित व्यक्ति को निलंबित करें** + +* **प्रोजेक्ट से व्यक्ति को स्थायी रूप से प्रतिबंधित** करें + +सदस्यों पर प्रतिबंध लगाना हल्के में नहीं लिया जाना चाहिए और यह दृष्टिकोण में स्थायी और अपूरणीय अंतर का प्रतिनिधित्व करता है। आपको ये उपाय केवल तभी करना चाहिए जब यह स्पष्ट हो कि किसी समाधान पर नहीं पहुंचा जा सकता। + +## एक अनुरक्षक के रूप में आपकी जिम्मेदारियाँ + +आचार संहिता कोई ऐसा कानून नहीं है जिसे मनमाने ढंग से लागू किया जाए। आप आचार संहिता के प्रवर्तक हैं और आचार संहिता द्वारा स्थापित नियमों का पालन करना आपकी जिम्मेदारी है। + +एक अनुरक्षक के रूप में आप अपने समुदाय के लिए दिशानिर्देश स्थापित करते हैं और उन दिशानिर्देशों को अपनी आचार संहिता में निर्धारित नियमों के अनुसार लागू करते हैं। इसका अर्थ है आचार संहिता उल्लंघन की किसी भी रिपोर्ट को गंभीरता से लेना। रिपोर्टर को उनकी शिकायत की गहन और निष्पक्ष समीक्षा करनी चाहिए। यदि आप यह निर्धारित करते हैं कि जिस व्यवहार की उन्होंने रिपोर्ट की है वह उल्लंघन नहीं है, तो उन्हें स्पष्ट रूप से बताएं और बताएं कि आप इस पर कार्रवाई क्यों नहीं करने जा रहे हैं। वे इसके साथ क्या करते हैं यह उन पर निर्भर है: उस व्यवहार को सहन करें जिससे उन्हें कोई समस्या थी, या समुदाय में भाग लेना बंद कर दें। + +व्यवहार की एक रिपोर्ट जो तकनीकी रूप से आचार संहिता का उल्लंघन नहीं करती है, फिर भी यह संकेत दे सकती है कि आपके समुदाय में कोई समस्या है, और आपको इस संभावित समस्या की जांच करनी चाहिए और तदनुसार कार्य करना चाहिए। इसमें स्वीकार्य व्यवहार को स्पष्ट करने के लिए अपनी आचार संहिता को संशोधित करना और/या उस व्यक्ति से बात करना शामिल हो सकता है जिसके व्यवहार की रिपोर्ट की गई थी और उन्हें यह बताना कि हालांकि उन्होंने आचार संहिता का उल्लंघन नहीं किया है, वे जो अपेक्षित है उससे किनारा कर रहे हैं और निश्चित कर रहे हैं। प्रतिभागी असहज महसूस करते हैं। + +अंत में, एक अनुरक्षक के रूप में, आप स्वीकार्य व्यवहार के लिए मानक निर्धारित और लागू करते हैं। आपके पास परियोजना के सामुदायिक मूल्यों को आकार देने की क्षमता है, और प्रतिभागी आपसे उन मूल्यों को निष्पक्ष और समान तरीके से लागू करने की उम्मीद करते हैं। + +## उस व्यवहार को प्रोत्साहित करें जो आप दुनिया में देखना चाहते हैं 🌎 + +जब कोई परियोजना शत्रुतापूर्ण या अप्रिय लगती है, भले ही वह सिर्फ एक व्यक्ति हो जिसका व्यवहार दूसरों द्वारा सहन किया जाता है, तो आप कई और योगदानकर्ताओं को खोने का जोखिम उठाते हैं, जिनमें से कुछ से आप कभी भी नहीं मिल सकते हैं। आचार संहिता को अपनाना या लागू करना हमेशा आसान नहीं होता है, लेकिन स्वागत योग्य माहौल को बढ़ावा देने से आपके समुदाय को बढ़ने में मदद मिलेगी। diff --git a/_articles/hi/finding-users.md b/_articles/hi/finding-users.md new file mode 100644 index 00000000000..e0cd0fd6ec7 --- /dev/null +++ b/_articles/hi/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: hi +title: अपने प्रोजेक्ट के लिए उपयोगकर्ता ढूँढना +description: अपने ओपन सोर्स प्रोजेक्ट को खुश उपयोगकर्ताओं के हाथों में पहुंचाकर उसे बढ़ने में मदद करें। +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## बातों का प्रसार + +ऐसा कोई नियम नहीं है जो कहता हो कि लॉन्च करते समय आपको एक ओपन सोर्स प्रोजेक्ट का प्रचार करना होगा। ओपन सोर्स में काम करने के कई संतोषजनक कारण हैं जिनका लोकप्रियता से कोई लेना-देना नहीं है। यह आशा करने के बजाय कि अन्य लोग आपके ओपन सोर्स प्रोजेक्ट को ढूंढेंगे और उसका उपयोग करेंगे, आपको अपनी कड़ी मेहनत के बारे में प्रचार करना होगा! + +## अपने संदेश का पता लगाएं + +इससे पहले कि आप अपने प्रोजेक्ट को बढ़ावा देने का वास्तविक काम शुरू करें, आपको यह समझाने में सक्षम होना चाहिए कि यह क्या करता है और यह क्यों मायने रखता है। + +आपके प्रोजेक्ट को क्या अलग या दिलचस्प बनाता है? आपने इसे क्यों बनाया? इन प्रश्नों का स्वयं उत्तर देने से आपको अपने प्रोजेक्ट के महत्व के बारे में बताने में मदद मिलेगी। + +याद रखें कि लोग उपयोगकर्ता के रूप में शामिल होते हैं, और अंततः योगदानकर्ता बन जाते हैं, क्योंकि आपका प्रोजेक्ट उनके लिए एक समस्या का समाधान करता है। जब आप अपने प्रोजेक्ट के संदेश और मूल्य के बारे में सोचते हैं, तो उन्हें इस नजरिए से देखने का प्रयास करें कि उपयोगकर्ता और योगदानकर्ता क्या चाहते हैं। + +उदाहरण के लिए, @robb अपने प्रोजेक्ट को स्पष्ट रूप से बताने के लिए कोड उदाहरणों का उपयोग करता है, [Cartography](https://github.com/robb/Cartography), उपयोगी है: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +मैसेजिंग के बारे में गहराई से जानने के लिए मोज़िला देखें ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) उपयोगकर्ता व्यक्तित्व विकसित करने के लिए व्यायाम। + +## अपने प्रोजेक्ट को ढूंढने और उसका अनुसरण करने में लोगों की सहायता करें + + + +लोगों को एक ही नामस्थान की ओर इंगित करके अपना प्रोजेक्ट ढूंढने और याद रखने में सहायता करें। + +**अपने काम को बढ़ावा देने के लिए एक स्पष्ट हैंडल रखें।** एक ट्विटर हैंडल, GitHub URL, या IRC चैनल लोगों को आपके प्रोजेक्ट की ओर इंगित करने का एक आसान तरीका है। ये आउटलेट आपके प्रोजेक्ट के बढ़ते समुदाय को एकत्रित होने की जगह भी देते हैं। + +यदि आप अभी तक अपने प्रोजेक्ट के लिए आउटलेट स्थापित नहीं करना चाहते हैं, तो अपने हर काम में अपने स्वयं के ट्विटर या GitHub हैंडल को बढ़ावा दें। आपके ट्विटर या 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/) हैं [a few examples](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/). वे चैनल ढूंढें जहां आपको लगता है कि लोगों को आपके काम से सबसे अधिक लाभ होगा या वे आपके काम के बारे में उत्साहित होंगे। + + + +देखें कि क्या आप अपने प्रोजेक्ट को प्रासंगिक तरीकों से साझा करने के तरीके ढूंढ सकते हैं: + +* **प्रासंगिक ओपन सोर्स प्रोजेक्ट्स और समुदायों को जानें।** कभी-कभी, आपको सीधे अपने प्रोजेक्ट का प्रचार करने की ज़रूरत नहीं होती है। यदि आपका प्रोजेक्ट पायथन का उपयोग करने वाले डेटा वैज्ञानिकों के लिए एकदम सही है, तो पायथन डेटा विज्ञान समुदाय को जानें। जैसे-जैसे लोग आपको जानने लगेंगे, आपके काम के बारे में बात करने और साझा करने के स्वाभाविक अवसर पैदा होंगे। +* **उन लोगों को ढूंढें जो उस समस्या का अनुभव कर रहे हैं जिसे आपका प्रोजेक्ट हल करता है।** उन लोगों के लिए संबंधित मंचों के माध्यम से खोजें जो आपके प्रोजेक्ट के लक्षित दर्शकों में आते हैं। उनके प्रश्न का उत्तर दें और समाधान के रूप में अपनी परियोजना का सुझाव देने के लिए, जब उचित हो, एक चतुराईपूर्ण तरीका खोजें। +* **प्रतिक्रिया के लिए पूछें।** ऐसे दर्शकों के सामने अपना और अपने काम का परिचय दें जिन्हें यह प्रासंगिक और दिलचस्प लगे। इस बारे में स्पष्ट रहें कि आपको क्या लगता है कि आपके प्रोजेक्ट से किसे लाभ होगा। वाक्य को पूरा करने का प्रयास करें: _"मुझे लगता है कि मेरा प्रोजेक्ट वास्तव में एक्स की मदद करेगा, जो Y_ करने की कोशिश कर रहे हैं"। केवल अपने काम का प्रचार करने के बजाय दूसरों की प्रतिक्रिया सुनें और उसका जवाब दें। + +सामान्यतया, बदले में चीज़ें मांगने से पहले दूसरों की मदद करने पर ध्यान केंद्रित करें। क्योंकि कोई भी किसी प्रोजेक्ट को आसानी से ऑनलाइन प्रमोट कर सकता है, इसलिए बहुत शोर होगा। भीड़ से अलग दिखने के लिए, लोगों को यह संदर्भ दें कि आप कौन हैं, न कि केवल वह जो आप चाहते हैं। + +यदि कोई आपकी आरंभिक पहुंच पर ध्यान नहीं देता है या प्रतिक्रिया नहीं देता है, तो निराश न हों! अधिकांश प्रोजेक्ट लॉन्च एक पुनरावृत्तीय प्रक्रिया है जिसमें महीनों या वर्षों का समय लग सकता है। यदि आपको पहली बार कोई प्रतिक्रिया नहीं मिलती है, तो एक अलग रणनीति आज़माएं, या पहले दूसरों के काम में मूल्य जोड़ने के तरीकों की तलाश करें। अपने प्रोजेक्ट को प्रचारित करने और लॉन्च करने में समय और समर्पण लगता है। + +## वहां जाएं जहां आपके प्रोजेक्ट के दर्शक हैं (ऑफ़लाइन) + +![सार्वजनिक रूप से बोलना](/assets/images/finding-users/public_speaking.jpg) + +ऑफ़लाइन कार्यक्रम दर्शकों के बीच नई परियोजनाओं को बढ़ावा देने का एक लोकप्रिय तरीका है। वे व्यस्त दर्शकों तक पहुंचने और गहरे मानवीय संबंध बनाने का एक शानदार तरीका हैं, खासकर यदि आप डेवलपर्स तक पहुंचने में रुचि रखते हैं। + +यदि आप [सार्वजनिक भाषण में नए](https://peaking.io/) हैं, तो एक स्थानीय बैठक ढूंढ़कर शुरुआत करें जो आपके प्रोजेक्ट की भाषा या पारिस्थितिकी तंत्र से संबंधित हो। + + + +यदि आपने पहले कभी किसी कार्यक्रम में बात नहीं की है, तो घबराहट महसूस होना बिल्कुल सामान्य है! याद रखें कि आपके दर्शक वहां हैं क्योंकि वे वास्तव में आपके काम के बारे में सुनना चाहते हैं। + +जब आप अपनी बात लिखते हैं, तो इस बात पर ध्यान केंद्रित करें कि आपके दर्शकों को क्या दिलचस्प लगेगा और उन्हें क्या लाभ मिलेगा। अपनी भाषा मित्रतापूर्ण एवं सुगम्य रखें। मुस्कुराएं, सांस लें और आनंद लें। + + + +जब आप तैयार महसूस करें, तो अपने प्रोजेक्ट को बढ़ावा देने के लिए एक सम्मेलन में बोलने पर विचार करें। सम्मेलन आपको अधिक लोगों तक पहुँचने में मदद कर सकते हैं, कभी-कभी दुनिया भर से। + +ऐसे सम्मेलनों की तलाश करें जो आपकी भाषा या पारिस्थितिकी तंत्र के लिए विशिष्ट हों। अपना भाषण प्रस्तुत करने से पहले, उपस्थित लोगों के लिए अपनी बात तैयार करने के लिए सम्मेलन पर शोध करें और सम्मेलन में बोलने के लिए स्वीकार किए जाने की संभावना बढ़ाएं। आप अक्सर सम्मेलन के वक्ताओं को देखकर अपने दर्शकों के बारे में अंदाजा लगा सकते हैं। + + + +## प्रतिष्ठा बनायें + +ऊपर उल्लिखित रणनीतियों के अलावा, लोगों को अपने प्रोजेक्ट में साझा करने और योगदान करने के लिए आमंत्रित करने का सबसे अच्छा तरीका उनकी परियोजनाओं को साझा करना और योगदान देना है। + +नए लोगों की मदद करना, संसाधन साझा करना और दूसरों की परियोजनाओं में विचारशील योगदान देना आपको सकारात्मक प्रतिष्ठा बनाने में मदद करेगा। ओपन सोर्स समुदाय में एक सक्रिय सदस्य होने से लोगों को आपके काम के संदर्भ में मदद मिलेगी और आपके प्रोजेक्ट पर ध्यान देने और साझा करने की अधिक संभावना होगी। अन्य ओपन सोर्स परियोजनाओं के साथ संबंध विकसित करने से आधिकारिक साझेदारी भी हो सकती है। + + + +अपनी प्रतिष्ठा बनाना शुरू करने के लिए कभी भी बहुत जल्दी या बहुत देर नहीं होती है। भले ही आपने अपना खुद का प्रोजेक्ट पहले ही लॉन्च कर दिया हो, दूसरों की मदद करने के तरीकों की तलाश जारी रखें। + +दर्शक वर्ग बनाने का कोई रातोरात समाधान नहीं है। दूसरों का विश्वास और सम्मान हासिल करने में समय लगता है, और आपकी प्रतिष्ठा बनाना कभी ख़त्म नहीं होता। + +## बने रहिए! + +लोगों को आपके ओपन सोर्स प्रोजेक्ट पर ध्यान देने में काफी समय लग सकता है। वह ठीक है! आज की कुछ सबसे लोकप्रिय परियोजनाओं को गतिविधि के उच्च स्तर तक पहुंचने में वर्षों लग गए। यह आशा करने के बजाय कि आपका प्रोजेक्ट अनायास लोकप्रियता हासिल कर लेगा, संबंध बनाने पर ध्यान केंद्रित करें। धैर्य रखें और अपना काम उन लोगों के साथ साझा करते रहें जो इसकी सराहना करते हैं। diff --git a/_articles/hi/getting-paid.md b/_articles/hi/getting-paid.md new file mode 100644 index 00000000000..f0937243586 --- /dev/null +++ b/_articles/hi/getting-paid.md @@ -0,0 +1,179 @@ +--- +lang: hi +title: ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना +description: अपने समय या अपने प्रोजेक्ट के लिए वित्तीय सहायता प्राप्त करके अपने काम को खुले स्रोत में बनाए रखें। +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## कुछ लोग वित्तीय सहायता क्यों चाहते हैं? + +ओपन सोर्स का अधिकांश कार्य स्वैच्छिक है। उदाहरण के लिए, हो सकता है कि किसी को अपने द्वारा उपयोग किए जा रहे किसी प्रोजेक्ट में बग का सामना करना पड़े और वह त्वरित समाधान सबमिट कर दे, या हो सकता है कि वे अपने खाली समय में किसी ओपन सोर्स प्रोजेक्ट के साथ छेड़छाड़ करने का आनंद लें। + + + +ऐसे कई कारण हैं जिनकी वजह से कोई व्यक्ति अपने ओपन सोर्स कार्य के लिए भुगतान नहीं करना चाहेगा। + +* **उनके पास पहले से ही एक पूर्णकालिक नौकरी हो सकती है जो उन्हें पसंद है,** जो उन्हें अपने खाली समय में ओपन सोर्स में योगदान करने में सक्षम बनाती है। +* **वे ओपन सोर्स को एक शौक** या रचनात्मक पलायन के रूप में सोचने का आनंद लेते हैं और अपनी परियोजनाओं पर काम करने के लिए वित्तीय रूप से बाध्य महसूस नहीं करना चाहते हैं। +* **उन्हें ओपन सोर्स में योगदान करने से अन्य लाभ मिलते हैं,** जैसे कि उनकी प्रतिष्ठा या पोर्टफोलियो बनाना, एक नया कौशल सीखना, या किसी समुदाय के करीब महसूस करना। + + + +दूसरों के लिए, विशेष रूप से जब योगदान जारी है या महत्वपूर्ण समय की आवश्यकता है, तो ओपन सोर्स में योगदान करने के लिए भुगतान प्राप्त करना ही एकमात्र तरीका है जिससे वे भाग ले सकते हैं, या तो क्योंकि परियोजना को इसकी आवश्यकता है, या व्यक्तिगत कारणों से। + +लोकप्रिय परियोजनाओं को बनाए रखना एक महत्वपूर्ण जिम्मेदारी हो सकती है, जिसमें प्रति माह कुछ घंटों के बजाय प्रति सप्ताह 10 या 20 घंटे लगते हैं। + + + +भुगतान किया गया कार्य जीवन के विभिन्न क्षेत्रों के लोगों को सार्थक योगदान देने में भी सक्षम बनाता है। कुछ लोग अपनी वर्तमान वित्तीय स्थिति, ऋण, या परिवार या अन्य देखभाल संबंधी दायित्वों के आधार पर, ओपन सोर्स परियोजनाओं पर अवैतनिक समय बिताने का जोखिम नहीं उठा सकते हैं। इसका मतलब है कि दुनिया कभी भी उन प्रतिभाशाली लोगों के योगदान को नहीं देखती है जो स्वेच्छा से अपना समय नहीं दे सकते। इसके नैतिक निहितार्थ हैं, जैसा कि @ashedryden [ने वर्णन किया है](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), क्योंकि जो काम किया गया है वह है उन लोगों के पक्ष में पक्षपातपूर्ण जिनके पास पहले से ही जीवन में लाभ हैं, जो बाद में अपने स्वैच्छिक योगदान के आधार पर अतिरिक्त लाभ प्राप्त करते हैं, जबकि अन्य जो स्वयंसेवा करने में सक्षम नहीं होते हैं उन्हें बाद में अवसर नहीं मिलते हैं, जो खुले स्रोत में विविधता की वर्तमान कमी को मजबूत करता है समुदाय। + + + +यदि आप वित्तीय सहायता की तलाश में हैं, तो विचार करने के लिए दो रास्ते हैं। आप एक योगदानकर्ता के रूप में अपने समय का वित्तपोषण कर सकते हैं, या आप परियोजना के लिए संगठनात्मक वित्तपोषण पा सकते हैं। + +## अपने समय का वित्तपोषण करना + +आज, कई लोगों को ओपन सोर्स पर अंशकालिक या पूर्णकालिक काम करने के लिए भुगतान मिलता है। अपने समय के लिए भुगतान पाने का सबसे आम तरीका अपने नियोक्ता से बात करना है। + +यदि आपका नियोक्ता वास्तव में परियोजना का उपयोग करता है, तो ओपन सोर्स कार्य के लिए मामला बनाना आसान है, लेकिन अपनी पिच के साथ रचनात्मक बनें। हो सकता है कि आपका नियोक्ता प्रोजेक्ट का उपयोग नहीं करता हो, लेकिन वे पायथन का उपयोग करते हैं, और एक लोकप्रिय पायथन प्रोजेक्ट को बनाए रखने से नए पायथन डेवलपर्स को आकर्षित करने में मदद मिलती है। शायद यह आपके नियोक्ता को सामान्य रूप से अधिक डेवलपर-अनुकूल बनाता है। + +यदि आपके पास कोई मौजूदा ओपन सोर्स प्रोजेक्ट नहीं है जिस पर आप काम करना चाहेंगे, बल्कि चाहेंगे कि आपका वर्तमान कार्य आउटपुट ओपन सोर्स हो, तो अपने नियोक्ता के लिए उनके कुछ आंतरिक सॉफ़्टवेयर को ओपन सोर्स करने का मामला बनाएं। + +कई कंपनियां अपना ब्रांड बनाने और गुणवत्तापूर्ण प्रतिभाओं की भर्ती के लिए ओपन सोर्स प्रोग्राम विकसित कर रही हैं। + +उदाहरण के लिए, @hueniverse ने पाया कि औचित्य सिद्ध करने के लिए वित्तीय कारण थे [ओपन सोर्स में वॉलमार्ट का निवेश](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). और @jamesgpearce ने पाया वह फेसबुक का ओपन सोर्स प्रोग्राम है [make a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) +भर्ती में: + +> यह हमारी हैकर संस्कृति और हमारे संगठन को कैसे समझा जाता है, के साथ निकटता से जुड़ा हुआ है। हमने अपने कर्मचारियों से पूछा, "क्या आप फेसबुक के ओपन सोर्स सॉफ़्टवेयर प्रोग्राम के बारे में जानते थे?" दो-तिहाई ने कहा "हाँ"। एक-आधे ने कहा कि कार्यक्रम ने हमारे लिए काम करने के उनके निर्णय में सकारात्मक योगदान दिया। ये सीमांत संख्याएं नहीं हैं, और मुझे आशा है कि यह प्रवृत्ति जारी रहेगी। + +यदि आपकी कंपनी इस मार्ग पर चलती है, तो समुदाय और कॉर्पोरेट गतिविधि के बीच की सीमाओं को स्पष्ट रखना महत्वपूर्ण है। अंततः, ओपन सोर्स दुनिया भर के लोगों के योगदान के माध्यम से खुद को कायम रखता है, और यह किसी एक कंपनी या स्थान से बड़ा है। + + + +यदि आप अपने वर्तमान नियोक्ता को ओपन सोर्स कार्य को प्राथमिकता देने के लिए मना नहीं सकते हैं, तो एक नया नियोक्ता ढूंढने पर विचार करें जो ओपन सोर्स में कर्मचारी योगदान को प्रोत्साहित करता हो। ऐसी कंपनियों की तलाश करें जो ओपन सोर्स कार्य के प्रति अपना समर्पण स्पष्ट करती हों। उदाहरण के लिए: + +* कुछ कंपनियाँ, जैसे [Netflix](https://netflix.github.io/), के पास ऐसी वेबसाइटें हैं जो ओपन सोर्स में उनकी भागीदारी को उजागर करती हैं। + +ऐसी परियोजनाएँ जो किसी बड़ी कंपनी में उत्पन्न हुईं, जैसे [Go](https://github.com/golang) या [React](https://github.com/facebook/react), ओपन सोर्स पर काम करने के लिए लोगों को नियोजित करने की भी संभावना है। + +अपनी व्यक्तिगत परिस्थितियों के आधार पर, आप अपने ओपन सोर्स कार्य के वित्तपोषण के लिए स्वतंत्र रूप से धन जुटाने का प्रयास कर सकते हैं। उदाहरण के लिए: + +* @Homebrew (और [कई अन्य अनुरक्षक और संगठन](https://github.com/sponsors/community)) [GitHub Sponsors](https://github.com/sponsors) के माध्यम से उनके काम को वित्तपोषित करें +* @gaearon उसके काम को वित्त पोषित किया [Redux](https://github.com/reactjs/redux) पर, और [Patreon crowdfunding campaign](https://redux.js.org/) के जरिए +* @andrewgodwin स्कीमा माइग्रेशन पर वित्त पोषित कार्य [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +अंत में, कभी-कभी ओपन सोर्स प्रोजेक्ट उन मुद्दों पर इनाम देते हैं जिनमें आप मदद करने पर विचार कर सकते हैं। + +* @ConnorChristie भुगतान पाने में सक्षम था [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol अपनी JavaScript लाइब्रेरी पर काम करता है [gitcoin पर इनाम के माध्यम से](https://gitcoin.co/). +* @mamiM ने इसके बाद @MetaMask का जापानी अनुवाद किया [इस मुद्दे को बाउंटीज़ नेटवर्क पर वित्त पोषित किया गया था](https://explorer.bounties.network/bounty/134). + +## अपने प्रोजेक्ट के लिए फंडिंग ढूँढना + +व्यक्तिगत योगदानकर्ताओं के लिए व्यवस्था से परे, कभी-कभी परियोजनाएं चल रहे काम को निधि देने के लिए कंपनियों, व्यक्तियों या अन्य लोगों से धन जुटाती हैं। + +संगठनात्मक फंडिंग वर्तमान योगदानकर्ताओं को भुगतान करने, परियोजना चलाने की लागत (जैसे होस्टिंग शुल्क) को कवर करने, या नई सुविधाओं या विचारों में निवेश करने में जा सकती है। + +जैसे-जैसे ओपन सोर्स की लोकप्रियता बढ़ती है, परियोजनाओं के लिए फंडिंग ढूंढना अभी भी प्रयोगात्मक है, लेकिन कुछ सामान्य विकल्प उपलब्ध हैं। + +### क्राउडफंडिंग अभियानों या प्रायोजन के माध्यम से अपने काम के लिए धन जुटाएं + +यदि आपके पास पहले से ही एक मजबूत दर्शक वर्ग या प्रतिष्ठा है, या आपका प्रोजेक्ट बहुत लोकप्रिय है, तो प्रायोजन ढूँढना अच्छा काम करता है। +प्रायोजित परियोजनाओं के कुछ उदाहरणों में शामिल हैं: + +* **[webpack](https://github.com/webpack)** कंपनियों और व्यक्तियों से धन जुटाता है [through OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** एक गैर-लाभकारी संगठन जो काम के लिए भुगतान करता है [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects + +### एक राजस्व धारा बनाएँ + +आपके प्रोजेक्ट के आधार पर, आप व्यावसायिक सहायता, होस्ट किए गए विकल्पों या अतिरिक्त सुविधाओं के लिए शुल्क लेने में सक्षम हो सकते हैं। कुछ उदाहरणों में शामिल हैं: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** अतिरिक्त सहायता के लिए सशुल्क संस्करण प्रदान करता है +* **[Travis CI](https://github.com/travis-ci)** अपने उत्पाद के सशुल्क संस्करण प्रदान करता है +* **[Ghost](https://github.com/TryGhost/Ghost)** सशुल्क प्रबंधित सेवा वाला एक गैर-लाभकारी संगठन है + +कुछ लोकप्रिय परियोजनाएँ, जैसे [npm](https://github.com/npm/cli) और [Docker](https://github.com/docker/docker), यहां तक ​​कि अपने व्यवसाय के विकास को समर्थन देने के लिए उद्यम पूंजी भी जुटाते हैं। + +### अनुदान निधि के लिए आवेदन करें + +कुछ सॉफ़्टवेयर फ़ाउंडेशन और कंपनियाँ ओपन सोर्स कार्य के लिए अनुदान प्रदान करती हैं। कभी-कभी, परियोजना के लिए कानूनी इकाई स्थापित किए बिना व्यक्तियों को अनुदान का भुगतान किया जा सकता है। + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** को [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) से अनुदान प्राप्त हुआ। +* **[OpenMRS](https://github.com/openmrs)** कार्य द्वारा वित्त पोषित किया गया था [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** को [Sloan Foundation](https://sloan.org/programs/digital-technology) से अनुदान प्राप्त हुआ। +* **[Python Software Foundation](https://www.python.org/psf/grants/)** पायथन से संबंधित कार्यों के लिए अनुदान प्रदान करता है। + +अधिक विस्तृत विकल्पों और केस अध्ययन के लिए, @nayafia [एक गाइड लिखा](https://github.com/nayafia/lemonade-stand) +ओपन सोर्स कार्य के लिए भुगतान प्राप्त करना। विभिन्न प्रकार की फंडिंग के लिए अलग-अलग कौशल की आवश्यकता होती है, इसलिए यह पता लगाने के लिए अपनी ताकत पर विचार करें कि कौन सा विकल्प आपके लिए सबसे अच्छा काम करता है। + +## वित्तीय सहायता के लिए मामला बनाना + +चाहे आपका प्रोजेक्ट एक नया विचार हो, या वर्षों से चला आ रहा हो, आपको अपने लक्षित फंडर की पहचान करने और एक सम्मोहक मामला बनाने में महत्वपूर्ण विचार करने की उम्मीद करनी चाहिए। + +चाहे आप अपने समय के लिए भुगतान करना चाह रहे हों, या किसी परियोजना के लिए धन जुटाना चाह रहे हों, आपको निम्नलिखित प्रश्नों का उत्तर देने में सक्षम होना चाहिए। + +### प्रभाव + +यह प्रोजेक्ट उपयोगी क्यों है? आपके उपयोगकर्ता, या संभावित उपयोगकर्ता, इसे इतना पसंद क्यों करते हैं? पांच साल में यह कहां होगा? + +### संकर्षण + +सबूत इकट्ठा करने की कोशिश करें कि आपका प्रोजेक्ट मायने रखता है, चाहे वह मेट्रिक्स, उपाख्यान या प्रशंसापत्र हो। क्या अभी कोई कंपनी या उल्लेखनीय लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं? यदि नहीं, तो क्या किसी प्रमुख व्यक्ति ने इसका समर्थन किया है? + +### फंड देने वाले के लिए मूल्य + +फंडर्स, चाहे आपका नियोक्ता हो या अनुदान देने वाला फाउंडेशन, अक्सर अवसरों के साथ संपर्क किया जाता है। उन्हें किसी अन्य अवसर की अपेक्षा आपके प्रोजेक्ट का समर्थन क्यों करना चाहिए? वे व्यक्तिगत रूप से कैसे लाभान्वित होते हैं? + +### धन का उपयोग + +प्रस्तावित फंडिंग से आप वास्तव में क्या हासिल करेंगे? वेतन देने के बजाय परियोजना की उपलब्धियों या परिणामों पर ध्यान दें। + +### आपको धनराशि कैसे प्राप्त होगी + +क्या फंडर को संवितरण से संबंधित कोई आवश्यकता है? उदाहरण के लिए, आपको एक गैर-लाभकारी संस्था होने या एक गैर-लाभकारी वित्तीय प्रायोजक होने की आवश्यकता हो सकती है। या शायद धनराशि किसी संगठन के बजाय किसी व्यक्तिगत ठेकेदार को दी जानी चाहिए। ये आवश्यकताएं फंडर्स के बीच अलग-अलग होती हैं, इसलिए पहले से ही अपना शोध करना सुनिश्चित करें। + + + +## प्रयोग करो और हार मत मानो + +पैसा जुटाना आसान नहीं है, चाहे आप एक ओपन सोर्स प्रोजेक्ट हों, एक गैर-लाभकारी संस्था हों, या एक सॉफ्टवेयर स्टार्टअप हों, और ज्यादातर मामलों में आपको रचनात्मक होने की आवश्यकता होती है। यह पहचानना कि आप भुगतान कैसे प्राप्त करना चाहते हैं, अपना शोध करना, और अपने आप को अपने फंडर के स्थान पर रखना आपको फंडिंग के लिए एक ठोस मामला बनाने में मदद करेगा। diff --git a/_articles/hi/how-to-contribute.md b/_articles/hi/how-to-contribute.md new file mode 100644 index 00000000000..ad6e4fdbbc6 --- /dev/null +++ b/_articles/hi/how-to-contribute.md @@ -0,0 +1,521 @@ +--- +lang: hi +title: ओपन सोर्स में कैसे योगदान करें +description: क्या आप ओपन सोर्स में योगदान देना चाहते हैं? पहली बार और अनुभवी लोगों के लिए ओपन सोर्स योगदान करने के लिए एक मार्गदर्शिका। +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## ओपन सोर्स में योगदान क्यों करें? + + + +ओपन सोर्स में योगदान करना किसी भी ऐसे कौशल में सीखने, सिखाने और अनुभव बनाने का एक फायदेमंद तरीका हो सकता है जिसकी आप कल्पना कर सकते हैं। + +लोग ओपन सोर्स में योगदान क्यों देते हैं? बहुत सारे कारण! + +### जिस सॉफ़्टवेयर पर आप भरोसा करते हैं उसे सुधारें + +बहुत से ओपन सोर्स योगदानकर्ता उस सॉफ़्टवेयर के उपयोगकर्ता बनकर शुरुआत करते हैं जिसमें वे योगदान करते हैं। जब आप अपने द्वारा उपयोग किए जाने वाले ओपन सोर्स सॉफ़्टवेयर में कोई बग पाते हैं, तो आप यह देखने के लिए स्रोत को देखना चाहेंगे कि क्या आप इसे स्वयं ठीक कर सकते हैं। यदि ऐसा मामला है, तो पैच बैक में योगदान करना यह सुनिश्चित करने का सबसे अच्छा तरीका है कि आपके मित्र (और जब आप अगली रिलीज़ के लिए अपडेट करते हैं तो आप स्वयं) इससे लाभ उठा सकेंगे। + +### मौजूदा कौशल में सुधार करें + +चाहे वह कोडिंग हो, यूजर इंटरफ़ेस डिज़ाइन हो, ग्राफ़िक डिज़ाइन हो, लेखन हो, या आयोजन हो, यदि आप अभ्यास की तलाश में हैं, तो ओपन सोर्स प्रोजेक्ट पर आपके लिए एक कार्य है। + +### ऐसे लोगों से मिलें जो समान चीज़ों में रुचि रखते हैं + +गर्मजोशी से स्वागत करने वाले समुदायों के साथ ओपन सोर्स परियोजनाएं लोगों को वर्षों तक वापस लाती हैं। बहुत से लोग खुले स्रोत में अपनी भागीदारी के माध्यम से आजीवन मित्रता बनाते हैं, चाहे वह सम्मेलनों में एक-दूसरे से मिलना हो या बरिटो के बारे में देर रात तक ऑनलाइन चैट करना हो। + +### मार्गदर्शक खोजें और दूसरों को सिखाएं + +किसी साझा प्रोजेक्ट पर दूसरों के साथ काम करने का मतलब है कि आपको यह बताना होगा कि आप काम कैसे करते हैं, साथ ही अन्य लोगों से मदद भी मांगनी होगी। सीखने और सिखाने के कार्य इसमें शामिल सभी लोगों के लिए एक संतुष्टिदायक गतिविधि हो सकते हैं। + +### सार्वजनिक कलाकृतियों का निर्माण करें जो आपको प्रतिष्ठा (और करियर) बढ़ाने में मदद करें + +परिभाषा के अनुसार, आपके सभी ओपन सोर्स कार्य सार्वजनिक हैं, जिसका अर्थ है कि आप जो भी कर सकते हैं उसे प्रदर्शित करने के लिए आपको कहीं भी ले जाने के लिए निःशुल्क उदाहरण मिलते हैं। + +### लोगों के कौशल सीखें + +ओपन सोर्स नेतृत्व और प्रबंधन कौशल का अभ्यास करने के अवसर प्रदान करता है, जैसे संघर्षों को हल करना, लोगों की टीमों को संगठित करना और काम को प्राथमिकता देना। + +### परिवर्तन करने में सक्षम होना सशक्त है, यहां तक कि छोटे परिवर्तन भी + +ओपन सोर्स में भाग लेने का आनंद लेने के लिए आपको आजीवन योगदानकर्ता बनने की आवश्यकता नहीं है। क्या आपने कभी किसी वेबसाइट पर कोई टाइपो त्रुटि देखी है और सोचा है कि कोई इसे ठीक कर देगा? किसी ओपन सोर्स प्रोजेक्ट पर, आप बस यही कर सकते हैं। ओपन सोर्स लोगों को उनके जीवन और वे दुनिया का अनुभव कैसे करते हैं, इस पर एजेंसी महसूस करने में मदद करता है, और यह अपने आप में संतुष्टिदायक है। + +## योगदान देने का क्या मतलब है + +यदि आप एक नए ओपन सोर्स योगदानकर्ता हैं, तो प्रक्रिया डराने वाली हो सकती है। आपको सही प्रोजेक्ट कैसे मिलता है? यदि आप नहीं जानते कि कोडिंग कैसे की जाती है तो क्या होगा? क्या हो यदि कुछ गलत हो जाए? + +कोइ चिंता नहीं! किसी ओपन सोर्स प्रोजेक्ट में शामिल होने के सभी प्रकार के तरीके हैं, और कुछ युक्तियाँ आपको अपने अनुभव से अधिकतम लाभ उठाने में मदद करेंगी। + +### आपको कोड योगदान करने की आवश्यकता नहीं है + +ओपन सोर्स में योगदान देने के बारे में एक आम ग़लतफ़हमी यह है कि आपको कोड का योगदान करने की आवश्यकता है। वास्तव में, यह अक्सर किसी परियोजना के अन्य भाग होते हैं जिन्हें [सबसे अधिक उपेक्षित या अनदेखा](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 ने कैटलॉग के लिए किया](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* पूछें कि क्या आप एक नई सुविधा लिखने में मदद कर सकते हैं +* स्वचालित प्रोजेक्ट सेटअप +* टूलींग और परीक्षण में सुधार करें + +### क्या आपको लोगों की मदद करना पसंद है? + +* प्रोजेक्ट के बारे में प्रश्नों के उत्तर दें, उदाहरण के लिए, स्टैक ओवरफ्लो ([इस पोस्टग्रेज उदाहरण की तरह](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) या रेडिट +* खुले मुद्दों पर लोगों के सवालों के जवाब दें +* चर्चा बोर्डों या वार्तालाप चैनलों को मॉडरेट करने में सहायता करें + +### क्या आपको दूसरों की कोड में मदद करना पसंद है? + +* अन्य लोगों के सबमिशन पर कोड की समीक्षा करें +* किसी प्रोजेक्ट का उपयोग कैसे किया जा सकता है, इसके लिए ट्यूटोरियल लिखें +* किसी अन्य योगदानकर्ता को सलाह देने की पेशकश, [जैसे @ereichert ने Rust पर @bronzdoc के लिए किया](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### आपको सिर्फ सॉफ्टवेयर प्रोजेक्ट पर काम नहीं करना है! + +जबकि "ओपन सोर्स" अक्सर सॉफ़्टवेयर को संदर्भित करता है, आप किसी भी चीज़ पर सहयोग कर सकते हैं। ऐसी किताबें, रेसिपी, सूचियाँ और कक्षाएं हैं जिन्हें ओपन सोर्स प्रोजेक्ट के रूप में विकसित किया जाता है। + +उदाहरण के लिए: + +* @sindresorhus एक ["भयानक" सूचियों की सूची तैयार करता है](https://github.com/sindresorhus/awesome) +* @h5bp फ्रंट-एंड डेवलपर उम्मीदवारों के लिए [संभावित साक्षात्कार प्रश्नों की सूची] (https://github.com/h5bp/Front-end-Developer-Interview-Questions) रखता है +* @stuartlynn और @nicole-a-tesla ने [पफिन्स के बारे में मजेदार तथ्यों का संग्रह](https://github.com/stuartlynn/puffin_facts) बनाया। + +भले ही आप एक सॉफ़्टवेयर डेवलपर हों, दस्तावेज़ीकरण प्रोजेक्ट पर काम करने से आपको ओपन सोर्स में शुरुआत करने में मदद मिल सकती है। उन परियोजनाओं पर काम करना अक्सर कम डराने वाला होता है जिनमें कोड शामिल नहीं होता है, और सहयोग की प्रक्रिया आपके आत्मविश्वास और अनुभव का निर्माण करेगी। + +## अपने आप को एक नई परियोजना की ओर उन्मुख करना + + + +टाइपो फिक्स से अधिक किसी भी चीज़ के लिए, ओपन सोर्स में योगदान करना किसी पार्टी में अजनबियों के समूह के पास जाने जैसा है। यदि आप लामाओं के बारे में बात करना शुरू करते हैं, जबकि वे सुनहरी मछली के बारे में गहन चर्चा में थे, तो वे शायद आपको थोड़ा अजीब तरीके से देखेंगे। + +अपने स्वयं के सुझावों पर आँख मूँद कर कूदने से पहले, कमरे को पढ़ना सीखना शुरू करें। ऐसा करने से संभावना बढ़ जाती है कि आपके विचारों पर ध्यान दिया जाएगा और सुना जाएगा। + +### एक ओपन सोर्स प्रोजेक्ट का एनाटॉमी + +प्रत्येक खुला स्रोत समुदाय अलग है। + +एक ओपन सोर्स प्रोजेक्ट पर वर्षों बिताने का मतलब है कि आपको एक ओपन सोर्स प्रोजेक्ट के बारे में पता चल गया है। एक अलग प्रोजेक्ट पर जाएँ, और आप पाएंगे कि शब्दावली, मानदंड और संचार शैलियाँ पूरी तरह से अलग हैं। + +जैसा कि कहा गया है, कई ओपन सोर्स प्रोजेक्ट समान संगठनात्मक संरचना का पालन करते हैं। विभिन्न सामुदायिक भूमिकाओं और समग्र प्रक्रिया को समझने से आपको किसी भी नई परियोजना के प्रति शीघ्रता से उन्मुख होने में मदद मिलेगी। + +एक विशिष्ट ओपन सोर्स प्रोजेक्ट में निम्नलिखित प्रकार के लोग होते हैं: + +* **लेखक:** वह व्यक्ति/संगठन जिसने प्रोजेक्ट बनाया है +* **स्वामी:** वह व्यक्ति/व्यक्ति जिनके पास संगठन या भंडार पर प्रशासनिक स्वामित्व है (हमेशा मूल लेखक के समान नहीं) +* **रखरखावकर्ता:** योगदानकर्ता जो परियोजना के दृष्टिकोण को आगे बढ़ाने और संगठनात्मक पहलुओं को प्रबंधित करने के लिए जिम्मेदार हैं (वे परियोजना के लेखक या मालिक भी हो सकते हैं।) +* **योगदानकर्ता:** हर कोई जिसने परियोजना में कुछ न कुछ योगदान दिया है +* **समुदाय सदस्य:** वे लोग जो परियोजना का उपयोग करते हैं। वे बातचीत में सक्रिय हो सकते हैं या परियोजना की दिशा पर अपनी राय व्यक्त कर सकते हैं + +बड़ी परियोजनाओं में उपसमितियां या कार्य समूह भी हो सकते हैं जो टूलींग, ट्राइएज, सामुदायिक मॉडरेशन और इवेंट आयोजन जैसे विभिन्न कार्यों पर केंद्रित हो सकते हैं। इस जानकारी को पाने के लिए किसी प्रोजेक्ट की वेबसाइट पर "टीम" पृष्ठ, या शासन दस्तावेज़ के भंडार में देखें। + +एक प्रोजेक्ट में दस्तावेज़ीकरण भी होता है. ये फ़ाइलें आमतौर पर रिपॉजिटरी के शीर्ष स्तर पर सूचीबद्ध होती हैं। + +* **लाइसेंस:** परिभाषा के अनुसार, प्रत्येक ओपन सोर्स प्रोजेक्ट के पास एक [ओपन सोर्स लाइसेंस](https://choosealicense.com) होना चाहिए। यदि प्रोजेक्ट के पास लाइसेंस नहीं है, तो यह खुला स्रोत नहीं है। +* **रीडमी:** रीडमी एक निर्देश पुस्तिका है जो परियोजना में नए समुदाय के सदस्यों का स्वागत करती है। यह बताता है कि परियोजना क्यों उपयोगी है और इसे कैसे शुरू किया जाए। +* **योगदान:** जबकि READMEs लोगों को परियोजना का उपयोग करने में मदद करते हैं, योगदान करने वाले दस्तावेज़ लोगों को परियोजना में योगदान देने में मदद करते हैं। यह बताता है कि किस प्रकार के योगदान की आवश्यकता है और प्रक्रिया कैसे काम करती है। हालाँकि हर परियोजना में योगदान फ़ाइल नहीं होती है, इसकी उपस्थिति संकेत देती है कि यह योगदान करने के लिए एक स्वागत योग्य परियोजना है। +* **आचार संहिता:** आचार संहिता प्रतिभागियों के व्यवहार से संबंधित बुनियादी नियम निर्धारित करती है और एक मैत्रीपूर्ण, स्वागत योग्य वातावरण बनाने में मदद करती है। हालाँकि हर परियोजना में एक Code_OF_CONDUCT फ़ाइल नहीं होती है, लेकिन इसकी उपस्थिति संकेत देती है कि यह योगदान देने के लिए एक स्वागत योग्य परियोजना है। +* **अन्य दस्तावेज़:** अतिरिक्त दस्तावेज़ हो सकते हैं, जैसे ट्यूटोरियल, वॉकथ्रू, या शासन नीतियां, विशेष रूप से बड़ी परियोजनाओं पर। + +अंत में, ओपन सोर्स प्रोजेक्ट चर्चा को व्यवस्थित करने के लिए निम्नलिखित टूल का उपयोग करते हैं। अभिलेखों को पढ़ने से आपको एक अच्छी तस्वीर मिलेगी कि समुदाय कैसे सोचता है और कैसे काम करता है। + +* **समस्या ट्रैकर:** जहां लोग परियोजना से संबंधित मुद्दों पर चर्चा करते हैं। +* **पुल रीकवेस्ट:** जहां लोग प्रगति पर चल रहे परिवर्तनों पर चर्चा और समीक्षा करते हैं। +* **चर्चा फ़ोरम या मेलिंग सूचियाँ:** कुछ परियोजनाएँ इन चैनलों का उपयोग वार्तालाप विषयों के लिए कर सकती हैं (उदाहरण के लिए, _"मैं कैसे करूँ..."_ या _"आप किस बारे में सोचते हैं..."_ बग के बजाय रिपोर्ट या सुविधा अनुरोध)। अन्य सभी वार्तालापों के लिए समस्या ट्रैकर का उपयोग करते हैं। +* **सिंक्रोनस चैट चैनल:** कुछ प्रोजेक्ट आकस्मिक बातचीत, सहयोग और त्वरित आदान-प्रदान के लिए चैट चैनल (जैसे स्लैक या आईआरसी) का उपयोग करते हैं। + +## योगदान देने के लिए एक परियोजना ढूँढना + +अब जब आपको पता चल गया है कि ओपन सोर्स प्रोजेक्ट कैसे काम करते हैं, तो योगदान देने के लिए एक प्रोजेक्ट ढूंढने का समय आ गया है! + +यदि आपने पहले कभी भी ओपन सोर्स में योगदान नहीं दिया है, तो अमेरिकी राष्ट्रपति जॉन एफ कैनेडी से कुछ सलाह लें, जिन्होंने एक बार कहा था, _"यह मत पूछो कि आपका देश आपके लिए क्या कर सकता है - यह पूछें कि आप अपने देश के लिए क्या कर सकते हैं।"_ + +ओपन सोर्स में योगदान सभी स्तरों पर, सभी परियोजनाओं में होता है। आपको यह ज़्यादा सोचने की ज़रूरत नहीं है कि वास्तव में आपका पहला योगदान क्या होगा, या यह कैसा दिखेगा। + +इसके बजाय, उन परियोजनाओं के बारे में सोचकर शुरुआत करें जिनका आप पहले से उपयोग कर रहे हैं, या जिनका उपयोग करना चाहते हैं। जिन परियोजनाओं में आप सक्रिय रूप से योगदान देंगे, उन्हीं परियोजनाओं में आप स्वयं को वापस आते हुए पाएंगे। + +उन परियोजनाओं के भीतर, जब भी आप खुद को यह सोचते हुए पाते हैं कि कुछ बेहतर या अलग हो सकता है, तो अपनी प्रवृत्ति पर कार्य करें। + +ओपन सोर्स कोई विशेष क्लब नहीं है; यह आप जैसे ही लोगों द्वारा बनाया गया है। "ओपन सोर्स" दुनिया की समस्याओं को ठीक करने योग्य मानने के लिए सिर्फ एक फैंसी शब्द है। + +आप 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 समन्वेषण](https://github.com/explore/) +* [Open Source शुक्रवार](https://opensourcefriday.com) +* [पहली बार आने वाले](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### योगदान देने से पहले एक चेकलिस्ट + +जब आपको कोई ऐसा प्रोजेक्ट मिल जाए जिसमें आप योगदान करना चाहते हैं, तो यह सुनिश्चित करने के लिए त्वरित स्कैन करें कि प्रोजेक्ट योगदान स्वीकार करने के लिए उपयुक्त है। वरना आपकी मेहनत को कभी जवाब नहीं मिल पाएगा. + +यह मूल्यांकन करने के लिए एक आसान चेकलिस्ट है कि कोई प्रोजेक्ट नए योगदानकर्ताओं के लिए अच्छा है या नहीं। + +**ओपन सोर्स की परिभाषा को पूरा करता है** + +
+ + +
+ +**परियोजना सक्रिय रूप से योगदान स्वीकार करती है** + +Main branch पर commit प्रतिबद्ध को देखें। GitHub पर, आप इस जानकारी को रिपॉजिटरी के होमपेज पर देख सकते हैं। + +
+ + +
+ +
+ + +
+ +
+ + +
+ +इसके बाद, परियोजना के मुद्दों को देखें। + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +अब प्रोजेक्ट के पुल रीकवेस्ट के लिए भी ऐसा ही करें। + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**परियोजना स्वागतयोग्य है** + +एक परियोजना जो मैत्रीपूर्ण और स्वागत योग्य है, यह संकेत देती है कि वे नए योगदानकर्ताओं के प्रति ग्रहणशील होंगे। + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## योगदान कैसे जमा करें + +आपको अपनी पसंद का एक प्रोजेक्ट मिल गया है और आप योगदान देने के लिए तैयार हैं। अंत में! यहां बताया गया है कि अपना योगदान सही तरीके से कैसे प्राप्त करें। + +### प्रभावी ढंग से संचार करना + +चाहे आप एक बार के योगदानकर्ता हों या किसी समुदाय में शामिल होने का प्रयास कर रहे हों, दूसरों के साथ काम करना सबसे महत्वपूर्ण कौशलों में से एक है जिसे आप ओपन सोर्स में विकसित करेंगे। + + + +इससे पहले कि आप कोई मुद्दा खोलें या अनुरोध खींचें, या चैट में कोई प्रश्न पूछें, अपने विचारों को प्रभावी ढंग से सामने लाने में मदद के लिए इन बिंदुओं को ध्यान में रखें। + +**संदर्भ दें।** दूसरों को तेजी से आगे बढ़ने में मदद करें। यदि आप किसी त्रुटि का सामना कर रहे हैं, तो बताएं कि आप क्या करने का प्रयास कर रहे हैं और इसे कैसे पुन: उत्पन्न करना है। यदि आप कोई नया विचार सुझा रहे हैं, तो स्पष्ट करें कि आप क्यों सोचते हैं कि यह परियोजना के लिए उपयोगी होगा (केवल आपके लिए नहीं!)। + +> 😇 _"जब मैं यह करता हूं तो वह नहीं होता"_ +> +> 😢 _"यह टूट गया है! कृपया इसे ठीक करें।"_ + +**कृपया अपना होमवर्क पहले से कर लें।** चीजों को न जानना ठीक है, लेकिन दिखाएं कि आपने प्रयास किया। मदद मांगने से पहले, किसी प्रोजेक्ट की रीडमी, दस्तावेज़ीकरण, मुद्दे (खुले या बंद), मेलिंग सूची की जांच करना और उत्तर के लिए इंटरनेट पर खोजना सुनिश्चित करें। जब आप प्रदर्शित करेंगे कि आप सीखने का प्रयास कर रहे हैं तो लोग इसकी सराहना करेंगे। + +> 😇 _"मुझे नहीं पता कि ईस को कैसे लागू किया जाए। मैंने सहायता दस्तावेजों की जांच की और कोई उल्लेख नहीं मिला।"_ +> +> 😢 _"मैं कैसे यह करूं?"_ + +**अनुरोधों को संक्षिप्त और सीधा रखें।** ईमेल भेजने की तरह, हर योगदान, चाहे कितना भी सरल या उपयोगी क्यों न हो, किसी और की समीक्षा की आवश्यकता होती है। कई परियोजनाओं में मदद के लिए उपलब्ध लोगों की तुलना में अधिक अनुरोध आ रहे हैं। संक्षिप्त रखें। आपको इस बात की संभावना बढ़ जाएगी कि कोई आपकी मदद कर पाएगा। + +> 😇 _"मैं एक एपीआई ट्यूटोरियल लिखना चाहूंगा।"_ +> +> 😢 _"मैं पिछले दिन राजमार्ग पर गाड़ी चला रहा था और गैस के लिए रुका, और तभी मेरे मन में यह अद्भुत विचार आया कि हमें क्या करना चाहिए, लेकिन इससे पहले कि मैं यह समझाऊं, मैं आपको दिखाता हूं..."_ + +**सभी संचार सार्वजनिक रखें।** हालांकि यह आकर्षक है, जब तक आपको संवेदनशील जानकारी (जैसे कोई सुरक्षा मुद्दा या गंभीर आचरण उल्लंघन) साझा करने की आवश्यकता न हो, निजी तौर पर अनुरक्षकों तक न पहुंचें। जब आप बातचीत को सार्वजनिक रखते हैं, तो अधिक लोग आपके आदान-प्रदान से सीख सकते हैं और लाभ उठा सकते हैं। चर्चाएँ, अपने आप में, योगदान हो सकती हैं। + +> 😇 _(एक टिप्पणी के रूप में) "@-maintainer नमस्ते! हमें इस PR पर कैसे आगे बढ़ना चाहिए?"_ +> +> 😢_(एक ईमेल के रूप में) "अरे, ईमेल पर आपको परेशान करने के लिए खेद है, लेकिन मैं सोच रहा था कि क्या आपको मेरे PR की समीक्षा करने का मौका मिला है"_ + +**प्रश्न पूछना ठीक है (लेकिन धैर्य रखें!)** हर कोई किसी न किसी समय परियोजना में नया था, और यहां तक ​​कि अनुभवी योगदानकर्ताओं को भी जब वे किसी नई परियोजना को देखते हैं तो उन्हें तेजी लाने की जरूरत होती है। इसी तरह, लंबे समय तक अनुरक्षक भी हमेशा परियोजना के हर हिस्से से परिचित नहीं होते हैं। उन्हें वही धैर्य दिखाएं जो आप चाहते हैं कि वे आपके प्रति दिखाएं। + +> 😇 _"इस त्रुटि पर ध्यान देने के लिए धन्यवाद। मैंने आपके सुझावों का पालन किया। यहां आउटपुट है।"_ +> +> 😢 _"आप मेरी समस्या का समाधान क्यों नहीं कर सकते? क्या यह आपका प्रोजेक्ट नहीं है?"_ + +**सामुदायिक निर्णयों का सम्मान करें।** आपके विचार समुदाय की प्राथमिकताओं या दृष्टिकोण से भिन्न हो सकते हैं। वे प्रतिक्रिया दे सकते हैं या आपके विचार को आगे न बढ़ाने का निर्णय ले सकते हैं। जबकि आपको चर्चा करनी चाहिए और समझौते की तलाश करनी चाहिए, लेकिन अनुरक्षकों को आपके निर्णय के साथ आपकी इच्छा से अधिक समय तक रहना होगा। यदि आप उनकी दिशा से असहमत हैं, तो आप हमेशा अपने स्वयं के कांटे पर काम कर सकते हैं या अपना स्वयं का प्रोजेक्ट शुरू कर सकते हैं। + +> 😇 _"मुझे निराशा है कि आप मेरे उपयोग के मामले का समर्थन नहीं कर सकते, लेकिन जैसा कि आपने समझाया है कि यह केवल उपयोगकर्ताओं के एक छोटे हिस्से को प्रभावित करता है, मैं समझता हूं क्यों। सुनने के लिए धन्यवाद।"_ +> +> 😢 _"आप मेरे उपयोग के मामले का समर्थन क्यों नहीं करेंगे? यह अस्वीकार्य है!"_ + +**सबसे बढ़कर, इसे उत्तम दर्जे का रखें।** ओपन सोर्स दुनिया भर के सहयोगियों से बना है। भाषाओं, संस्कृतियों, भूगोलों और समय क्षेत्रों में संदर्भ खो जाता है। इसके अलावा, लिखित संचार से स्वर या मनोदशा को व्यक्त करना कठिन हो जाता है। इन वार्तालापों में अच्छे इरादे मानें। किसी विचार पर विनम्रतापूर्वक ज़ोर देना, अधिक संदर्भ मांगना, या अपनी स्थिति को और स्पष्ट करना ठीक है। बस इंटरनेट को उस समय से बेहतर जगह छोड़ने का प्रयास करें जब यह आपको मिला था। + +### संदर्भ एकत्रित करना + +कुछ भी करने से पहले, यह सुनिश्चित करने के लिए त्वरित जांच करें कि आपके विचार की चर्चा कहीं और नहीं की गई है। प्रोजेक्ट के README, मुद्दे (खुले और बंद), मेलिंग सूची और स्टैक ओवरफ़्लो को स्किम करें। आपको हर चीज़ को पढ़ने में घंटों खर्च करने की ज़रूरत नहीं है, लेकिन कुछ प्रमुख शब्दों की त्वरित खोज बहुत काम आती है। + +यदि आपको अपना विचार कहीं और नहीं मिल रहा है, तो आप एक कदम उठाने के लिए तैयार हैं। यदि प्रोजेक्ट GitHub पर है, तो आप संभवतः कोई समस्या खोलकर या अनुरोध खींचकर संवाद करेंगे: + +* **ईशूस** बातचीत या चर्चा शुरू करने जैसा है +* **पुल रीकवेस्ट** समाधान पर काम शुरू करने के लिए हैं +* **हल्के संचार के लिए,** जैसे कि स्पष्टीकरण या कैसे-कैसे प्रश्न करें, स्टैक ओवरफ़्लो, IRS, स्लैक, या अन्य चैट चैनलों पर पूछने का प्रयास करें, यदि प्रोजेक्ट में कोई है + +किसी मुद्दे को खोलने या अनुरोध खींचने से पहले, यह देखने के लिए कि क्या आपको कुछ विशिष्ट शामिल करने की आवश्यकता है, प्रोजेक्ट के योगदान दस्तावेज़ (आमतौर पर CONTRIBUTING या README में एक फ़ाइल) की जाँच करें। उदाहरण के लिए, वे आपसे एक टेम्पलेट का पालन करने के लिए कह सकते हैं, या आपसे परीक्षण का उपयोग करने के लिए कह सकते हैं। + +यदि आप कोई महत्वपूर्ण योगदान देना चाहते हैं, तो उस पर काम करने से पहले पूछने के लिए एक मुद्दा खोलें। प्रोजेक्ट को कुछ समय के लिए देखना उपयोगी है (GitHub पर, [आप "watch" पर क्लिक कर सकते हैं)](https://help.github.com/articles/watching-repositories/) सभी वार्तालापों की सूचना प्राप्त करने के लिए), और वह काम करने से पहले समुदाय के सदस्यों को जानें जिन्हें स्वीकार नहीं किया जा सकता है। + + + +### एक मुद्दा खुल रहा है + +आपको आमतौर पर निम्नलिखित स्थितियों में कोई मुद्दा खोलना चाहिए: + +* उस त्रुटि की रिपोर्ट करें जिसे आप स्वयं हल नहीं कर सकते +* किसी उच्च-स्तरीय विषय या विचार पर चर्चा करें (उदाहरण के लिए, समुदाय, दृष्टिकोण या नीतियां) +* एक नई सुविधा या अन्य परियोजना विचार का प्रस्ताव रखें + +मुद्दों पर संवाद करने के लिए युक्तियाँ: + +* **यदि आप कोई खुला मुद्दा देखते हैं जिससे आप निपटना चाहते हैं,** लोगों को यह बताने के लिए कि आप इस मुद्दे पर हैं, उस मुद्दे पर टिप्पणी करें। इस तरह, लोगों द्वारा आपके काम की नकल करने की संभावना कम होगी। +* **यदि कोई मुद्दा कुछ समय पहले खोला गया था,** यह संभव है कि इसे कहीं और संबोधित किया जा रहा है, या पहले ही हल किया जा चुका है, इसलिए काम शुरू करने से पहले पुष्टि के लिए टिप्पणी करें। +* **यदि आपने कोई मुद्दा खोला है, लेकिन बाद में आपको स्वयं उत्तर मिल गया है,** लोगों को बताने के लिए मुद्दे पर टिप्पणी करें, फिर मुद्दे को बंद कर दें। यहां तक कि उस परिणाम का दस्तावेज़ीकरण भी परियोजना में एक योगदान है। + +### पुल रीकवेस्ट खोलना + +आपको आमतौर पर निम्नलिखित स्थितियों में पुल अनुरोध खोलना चाहिए: + +* मामूली सुधार सबमिट करें (उदाहरण के लिए, एक टाइपो, एक टूटा हुआ लिंक या एक स्पष्ट त्रुटि) +* उस योगदान पर काम शुरू करें जो पहले से ही मांगा गया था, या जिस पर आप पहले ही किसी मुद्दे पर चर्चा कर चुके हैंn + +पुल अनुरोध को समाप्त कार्य का प्रतिनिधित्व करने की आवश्यकता नहीं है। आमतौर पर पुल अनुरोध को जल्दी खोलना बेहतर होता है, ताकि अन्य लोग आपकी प्रगति को देख सकें या उस पर प्रतिक्रिया दे सकें। बस इसे "ड्राफ्ट" के रूप में खोलें या विषय पंक्ति में "डब्ल्यूआईपी" (कार्य प्रगति पर) के रूप में चिह्नित करें। आप बाद में कभी भी और कमिट जोड़ सकते हैं। + +यदि प्रोजेक्ट GitHub पर है, तो पुल अनुरोध सबमिट करने का तरीका यहां दिया गया है: + +* **[रेपासटरी को फोर्क करें](https://guides.github.com/activities/forking/)** और इसे स्थानीय रूप से क्लोन करें। अपने लोकल को रिमोट के रूप में जोड़कर मूल "अपस्ट्रीम" रिपॉजिटरी से कनेक्ट करें। "अपस्ट्रीम" से परिवर्तन अक्सर खींचें ताकि आप अद्यतित रहें ताकि जब आप अपना पुल अनुरोध सबमिट करें, तो मर्ज विवादों की संभावना कम हो जाएगी। (अधिक विस्तृत निर्देश देखें [यहाँ](https://help.github.com/articles/syncing-a-fork/).) +* **[एक ब्रेनच बनाएँ](https://guides.github.com/introduction/flow/)** आपके संपादनों के लिए. +* **अपने पीआर में किसी भी प्रासंगिक मुद्दे** या सहायक दस्तावेज़ का संदर्भ लें (उदाहरण के लिए, " #37 बंद होता है।") +* **यदि आपके परिवर्तनों में HTML/CSS में अंतर शामिल है तो पहले और बाद के स्क्रीनशॉट शामिल करें**। छवियों को अपने पुल अनुरोध के मुख्य भाग में खींचें और छोड़ें। +* **अपने परिवर्तनों का परीक्षण करें!** यदि कोई मौजूदा परीक्षण मौजूद है तो उसके विरुद्ध अपने परिवर्तन चलाएँ और आवश्यकता पड़ने पर नए बनाएँ। परीक्षण मौजूद हैं या नहीं, सुनिश्चित करें कि आपके परिवर्तन मौजूदा प्रोजेक्ट को बाधित नहीं करते हैं। +* **परियोजना की शैली में अपनी सर्वोत्तम क्षमता से योगदान दें**। इसका मतलब यह हो सकता है कि इंडेंट, सेमी-कोलन या टिप्पणियों का उपयोग आप अपने स्वयं के भंडार से अलग तरीके से करेंगे, लेकिन इससे अनुरक्षक के लिए विलय करना, दूसरों के लिए समझना और भविष्य में बनाए रखना आसान हो जाता है। + +यदि यह आपका पहला पुल अनुरोध है, तो [मेक अ पुल रिक्वेस्ट](http://makeapullrequest.com/) देखें, जिसे @kentcdodds ने वॉकथ्रू वीडियो ट्यूटोरियल के रूप में बनाया है। आप @Roshanjossey द्वारा बनाए गए [प्रथम योगदान](https://github.com/Roshanjossey/first-contributions) रिपॉजिटरी में पुल अनुरोध करने का अभ्यास भी कर सकते हैं। + +## आपके योगदान जमा करने के बाद क्या होता है + +तुमने यह किया! ओपन सोर्स योगदानकर्ता बनने पर बधाई। हमें उम्मीद है कि यह कई में से पहला है। + +आपके द्वारा योगदान जमा करने के बाद, निम्नलिखित में से एक होगा: + +### 😭 आपको कोई प्रतिक्रिया नहीं मिलती। + +उम्मीद है कि आपने [गतिविधि के संकेतों के लिए परियोजना की जाँच की](#योगदान-देने-से-पहले-एक-चेकलिस्ट) योगदान देने से पहले. हालाँकि, किसी सक्रिय प्रोजेक्ट पर भी, यह संभव है कि आपके योगदान को प्रतिक्रिया नहीं मिलेगी। + +यदि आपको एक सप्ताह से अधिक समय में कोई प्रतिक्रिया नहीं मिली है, तो किसी से समीक्षा के लिए पूछते हुए, उसी थ्रेड में विनम्रतापूर्वक प्रतिक्रिया देना उचित है। यदि आप अपने योगदान की समीक्षा करने के लिए सही व्यक्ति का नाम जानते हैं, तो आप उस थ्रेड में उनका @-mention कर सकते हैं। + +**उस व्यक्ति तक निजी तौर पर संपर्क न करें; याद रखें कि ओपन सोर्स परियोजनाओं के लिए सार्वजनिक संचार महत्वपूर्ण है। + +यदि आप विनम्रतापूर्वक बात करते हैं और फिर भी कोई प्रतिक्रिया नहीं देता है, तो यह संभव है कि कोई भी कभी भी प्रतिक्रिया नहीं देगा। यह कोई बढ़िया एहसास नहीं है, लेकिन इससे आपको हतोत्साहित न होने दें। यह हर किसी के साथ हुआ है! आपको प्रतिक्रिया न मिलने के कई संभावित कारण हो सकते हैं, जिनमें व्यक्तिगत परिस्थितियाँ भी शामिल हैं जो आपके नियंत्रण से बाहर हो सकती हैं। योगदान देने के लिए कोई अन्य प्रोजेक्ट या तरीका खोजने का प्रयास करें। यदि कुछ भी हो, तो यह एक अच्छा कारण है कि समुदाय के अन्य सदस्यों के शामिल होने और प्रतिक्रिया देने से पहले योगदान देने में बहुत अधिक समय न लगाया जाए। + +### 🚧 कोई आपके योगदान में परिवर्तन का अनुरोध करता है। + +यह सामान्य बात है कि आपसे आपके योगदान में परिवर्तन करने के लिए कहा जाएगा, चाहे वह आपके विचार के दायरे पर प्रतिक्रिया हो, या आपके कोड में परिवर्तन हो। + +जब कोई परिवर्तन का अनुरोध करता है, तो उत्तरदायी बनें। उन्होंने आपके योगदान की समीक्षा करने के लिए समय लिया है। पीआर खोलना और चले जाना बुरी आदत है। यदि आप नहीं जानते कि परिवर्तन कैसे करें, तो समस्या पर शोध करें और यदि आपको सहायता की आवश्यकता हो तो सहायता माँगें। + +यदि आपके पास अब इस मुद्दे पर काम करने का समय नहीं है (उदाहरण के लिए, यदि बातचीत महीनों से चल रही है, और आपकी परिस्थितियाँ बदल गई हैं), तो अनुरक्षक को बताएं ताकि वे प्रतिक्रिया की उम्मीद न करें। कोई अन्य व्यक्ति कार्यभार संभालने में प्रसन्न हो सकता है। + +### 👎 आपका योगदान स्वीकार नहीं किया जाता। + +आपका योगदान अंततः स्वीकार किया भी जा सकता है और नहीं भी। उम्मीद है कि आपने पहले से ही इसमें बहुत अधिक काम नहीं किया होगा। यदि आप निश्चित नहीं हैं कि इसे क्यों स्वीकार नहीं किया गया, तो अनुरक्षक से फीडबैक और स्पष्टीकरण मांगना बिल्कुल उचित है। हालाँकि, अंततः, आपको इसका सम्मान करना होगा कि यह उनका निर्णय है। बहस न करें या शत्रुतापूर्ण न बनें। यदि आप असहमत हैं तो फोर्क और अपने संस्करण पर काम करने के लिए आपका हमेशा स्वागत है! + +### 🎉 आपका योगदान स्वीकार किया जाता है। + +हुर्रे! आपने सफलतापूर्वक ओपन सोर्स योगदान दे दिया है! + +## तुमने यह किया! + +चाहे आपने अभी अपना पहला ओपन सोर्स योगदान दिया हो, या आप योगदान करने के नए तरीकों की तलाश कर रहे हों, हमें उम्मीद है कि आप कार्रवाई करने के लिए प्रेरित होंगे। भले ही आपका योगदान स्वीकार नहीं किया गया हो, जब कोई अनुरक्षक आपकी मदद करने का प्रयास करे तो धन्यवाद कहना न भूलें। ओपन सोर्स आपके जैसे लोगों द्वारा बनाया गया है: एक समय में एक मुद्दा, पुल अनुरोध, टिप्पणी, या हाई-फाइव। diff --git a/_articles/hi/index.html b/_articles/hi/index.html new file mode 100644 index 00000000000..454d05a6705 --- /dev/null +++ b/_articles/hi/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: ओपन सोर्स गाइड +lang: hi +permalink: /hi/ +--- diff --git a/_articles/hi/leadership-and-governance.md b/_articles/hi/leadership-and-governance.md new file mode 100644 index 00000000000..aa191f5f602 --- /dev/null +++ b/_articles/hi/leadership-and-governance.md @@ -0,0 +1,157 @@ +--- +lang: hi +title: नेतृत्व और शासन +description: निर्णय लेने के लिए औपचारिक नियमों से बढ़ते ओपन सोर्स प्रोजेक्ट्स को फायदा हो सकता है। +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## अपने बढ़ते प्रोजेक्ट के लिए प्रशासन को समझना + +आपका प्रोजेक्ट बढ़ रहा है, लोग इसमें लगे हुए हैं और आप इस चीज़ को जारी रखने के लिए प्रतिबद्ध हैं। इस स्तर पर, आप सोच रहे होंगे कि नियमित परियोजना योगदानकर्ताओं को अपने वर्कफ़्लो में कैसे शामिल किया जाए, चाहे वह किसी को प्रतिबद्ध पहुंच प्रदान करना हो या सामुदायिक बहस को हल करना हो। यदि आपके कोई प्रश्न हैं, तो हमें उत्तर मिल गए हैं। + +## ओपन सोर्स प्रोजेक्ट्स में उपयोग की जाने वाली औपचारिक भूमिकाओं के उदाहरण क्या हैं? + +कई परियोजनाएँ योगदानकर्ता भूमिकाओं और मान्यता के लिए समान संरचना का पालन करती हैं। + +हालाँकि, इन भूमिकाओं का वास्तव में क्या मतलब है, यह पूरी तरह आप पर निर्भर है। यहां कुछ प्रकार की भूमिकाएं दी गई हैं जिन्हें आप पहचान सकते हैं: + +* **रखरखाव** +* **योगदान देने वाला** +* **कमिटर** + +**कुछ परियोजनाओं के लिए, "रखरखावकर्ता"** किसी परियोजना में प्रतिबद्ध पहुंच वाले एकमात्र लोग होते हैं। अन्य परियोजनाओं में, वे केवल वे लोग हैं जो रीडमी में अनुरक्षक के रूप में सूचीबद्ध हैं। + +एक अनुरक्षक आवश्यक रूप से ऐसा व्यक्ति नहीं है जो आपके प्रोजेक्ट के लिए कोड लिखता हो। यह कोई ऐसा व्यक्ति हो सकता है जिसने आपके प्रोजेक्ट को प्रचारित करने के लिए बहुत काम किया हो, या लिखित दस्तावेज़ीकरण किया हो जिसने प्रोजेक्ट को दूसरों के लिए अधिक सुलभ बना दिया हो। चाहे वे दिन-प्रतिदिन कुछ भी करें, एक अनुरक्षक संभवतः वह व्यक्ति होता है जो परियोजना की दिशा में ज़िम्मेदारी महसूस करता है और इसे सुधारने के लिए प्रतिबद्ध है। + +**एक "योगदानकर्ता" कोई भी हो सकता है** जो किसी मुद्दे या पुल अनुरोध पर टिप्पणी करता है, जो लोग परियोजना में मूल्य जोड़ते हैं (चाहे वह मुद्दों का परीक्षण करना हो, कोड लिखना हो, या घटनाओं का आयोजन करना हो), या मर्ज किए गए पुल अनुरोध वाला कोई भी व्यक्ति (शायद योगदानकर्ता की सबसे संकीर्ण परिभाषा।) + + + +**शब्द "कमिटर"** का उपयोग कमिट एक्सेस, जो एक विशिष्ट प्रकार की जिम्मेदारी है, को योगदान के अन्य रूपों से अलग करने के लिए किया जा सकता है। + +हालाँकि आप अपनी परियोजना भूमिकाओं को अपनी इच्छानुसार किसी भी तरह परिभाषित कर सकते हैं, [व्यापक परिभाषाओं का उपयोग करने पर विचार करें](../how-to-contribute/#योगदान-देने-का-क्या-मतलब-है) योगदान के और अधिक रूपों को प्रोत्साहित करना। आप उन लोगों को औपचारिक रूप से पहचानने के लिए नेतृत्व की भूमिकाओं का उपयोग कर सकते हैं जिन्होंने आपके प्रोजेक्ट में उत्कृष्ट योगदान दिया है, भले ही उनके तकनीकी कौशल कुछ भी हों। + + + +## मैं इन नेतृत्व भूमिकाओं को कैसे औपचारिक बनाऊं? + +अपनी नेतृत्व भूमिकाओं को औपचारिक बनाने से लोगों को स्वामित्व महसूस करने में मदद मिलती है और समुदाय के अन्य सदस्यों को पता चलता है कि मदद के लिए किससे संपर्क करना चाहिए। + +एक छोटी परियोजना के लिए, नेताओं को नामित करना आपके README या CONTRIBUTORS टेक्स्ट फ़ाइल में उनके नाम जोड़ने जितना आसान हो सकता है। + +किसी बड़े प्रोजेक्ट के लिए, यदि आपके पास कोई वेबसाइट है, तो एक टीम पेज बनाएं या वहां अपने प्रोजेक्ट लीडरों की सूची बनाएं। उदाहरण के लिए, [Postgres](https://github.com/postgres/postgres/) के पास एक [comprehensive team page](https://www.postgresql.org/community/contributors/) प्रत्येक योगदानकर्ता के लिए संक्षिप्त प्रोफ़ाइल के साथ। + +यदि आपके प्रोजेक्ट में बहुत सक्रिय योगदानकर्ता समुदाय है, तो आप अनुरक्षकों की एक "कोर टीम" बना सकते हैं, या ऐसे लोगों की उपसमितियां भी बना सकते हैं जो विभिन्न मुद्दे क्षेत्रों (उदाहरण के लिए, सुरक्षा, समस्या निवारण, या सामुदायिक आचरण) का स्वामित्व लेते हैं। लोगों को वे भूमिकाएँ सौंपने के बजाय स्वयं संगठित होने दें और उनके लिए स्वेच्छा से काम करने दें जिनके बारे में वे सबसे अधिक उत्साहित हैं। + + + +नेतृत्व दल एक निर्दिष्ट चैनल बनाना चाह सकते हैं (जैसे आईआरसी पर) या परियोजना पर चर्चा करने के लिए नियमित रूप से मिलना चाहते हैं (जैसे गिटर या गूगल हैंगआउट पर)। आप उन बैठकों को सार्वजनिक भी कर सकते हैं ताकि अन्य लोग सुन सकें। [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), उदाहरण के लिए, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +एक बार जब आप नेतृत्व की भूमिकाएँ स्थापित कर लें, तो यह दस्तावेज करना न भूलें कि लोग उन्हें कैसे प्राप्त कर सकते हैं! कोई आपके प्रोजेक्ट में अनुरक्षक कैसे बन सकता है या उपसमिति में कैसे शामिल हो सकता है, इसके लिए एक स्पष्ट प्रक्रिया स्थापित करें और इसे अपने में लिखें GOVERNANCE.md. + +उपकरण जैसे [Vossibility](https://github.com/icecrime/vossibility-stack) आपको सार्वजनिक रूप से ट्रैक करने में मदद मिल सकती है कि प्रोजेक्ट में कौन योगदान दे रहा है (या नहीं दे रहा है)। इस जानकारी का दस्तावेजीकरण करने से समुदाय की इस धारणा से बचा जा सकता है कि रखरखाव करने वाले एक समूह हैं जो निजी तौर पर अपने निर्णय लेते हैं। + +अंत में, यदि आपका प्रोजेक्ट GitHub पर है, तो अपने प्रोजेक्ट को अपने व्यक्तिगत खाते से किसी संगठन में ले जाने और कम से कम एक बैकअप व्यवस्थापक जोड़ने पर विचार करें। [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) अनुमतियों और एकाधिक रिपॉजिटरी को प्रबंधित करना और अपने प्रोजेक्ट की विरासत को सुरक्षित रखना आसान बनाएं [shared ownership](../building-community/#अपने-प्रोजेक्ट-का-स्वामित्व-साझा-करें). + +## मुझे किसी को प्रतिबद्ध पहुंच कब देनी चाहिए? + +कुछ लोग सोचते हैं कि आपको योगदान देने वाले हर व्यक्ति को प्रतिबद्ध पहुंच देनी चाहिए। ऐसा करने से अधिक लोग आपके प्रोजेक्ट पर स्वामित्व महसूस करने के लिए प्रोत्साहित हो सकते हैं। + +दूसरी ओर, विशेष रूप से बड़ी, अधिक जटिल परियोजनाओं के लिए, आप केवल उन लोगों को प्रतिबद्ध पहुंच देना चाह सकते हैं जिन्होंने अपनी प्रतिबद्धता प्रदर्शित की है। इसे करने का कोई एक सही तरीका नहीं है - वही करें जो आपको सबसे अधिक आरामदायक लगे! + +यदि आपका प्रोजेक्ट GitHub पर है, तो आप इसका उपयोग कर सकते हैं [protected branches](https://help.github.com/articles/about-protected-branches/) यह प्रबंधित करना कि कौन किसी विशेष शाखा में जा सकता है, और किन परिस्थितियों में। + + + +## ओपन सोर्स परियोजनाओं के लिए कुछ सामान्य शासन संरचनाएँ क्या हैं? + +ओपन सोर्स परियोजनाओं से जुड़ी तीन सामान्य शासन संरचनाएँ हैं। + +* **बीडीएफएल:** बीडीएफएल का अर्थ है "जीवन के लिए परोपकारी तानाशाह"। इस संरचना के तहत, सभी प्रमुख परियोजना निर्णयों पर एक व्यक्ति (आमतौर पर परियोजना का प्रारंभिक लेखक) का अंतिम अधिकार होता है। [Python](https://github.com/python) एक उत्कृष्ट उदाहरण है. छोटी परियोजनाएँ संभवतः डिफ़ॉल्ट रूप से बीडीएफएल हैं, क्योंकि केवल एक या दो अनुरक्षक होते हैं। किसी कंपनी में शुरू हुआ प्रोजेक्ट भी बीडीएफएल श्रेणी में आ सकता है। + +* **मेरिटोक्रेसी:** **(नोट: शब्द "मेरिटोक्रेसी" कुछ समुदायों के लिए नकारात्मक अर्थ रखता है और इसका एक नकारात्मक प्रभाव है[complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** योग्यतातंत्र के तहत, सक्रिय परियोजना योगदानकर्ताओं (जो "योग्यता" प्रदर्शित करते हैं) को औपचारिक निर्णय लेने की भूमिका दी जाती है। निर्णय आम तौर पर शुद्ध मतदान सर्वसम्मति के आधार पर किए जाते हैं। योग्यतातंत्र की अवधारणा का सूत्रपात किसके द्वारा किया गया था? [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) +योग्यतातंत्र हैं. योगदान केवल अपना प्रतिनिधित्व करने वाले व्यक्तियों द्वारा ही किया जा सकता है, किसी कंपनी द्वारा नहीं। + +* **उदार योगदान:** उदार योगदान मॉडल के तहत, जो लोग सबसे अधिक काम करते हैं उन्हें सबसे प्रभावशाली माना जाता है, लेकिन यह वर्तमान कार्य पर आधारित है न कि ऐतिहासिक योगदान पर। प्रमुख परियोजना निर्णय शुद्ध वोट के बजाय सर्वसम्मति प्राप्त करने की प्रक्रिया (प्रमुख शिकायतों पर चर्चा) के आधार पर किए जाते हैं, और यथासंभव अधिक से अधिक सामुदायिक दृष्टिकोणों को शामिल करने का प्रयास किया जाता है। उदार योगदान मॉडल का उपयोग करने वाली परियोजनाओं के लोकप्रिय उदाहरणों में शामिल हैं [Node.js](https://foundation.nodejs.org/) और [Rust](https://www.rust-lang.org/). + +आपको किसका उपयोग करना चाहिए? यह आप पर निर्भर करता है! हर मॉडल के फायदे और फायदे हैं। और यद्यपि वे पहली बार में काफी भिन्न लग सकते हैं, तीनों मॉडलों में जितना वे दिखते हैं उससे कहीं अधिक समानता है। यदि आप इनमें से किसी एक मॉडल को अपनाने में रुचि रखते हैं, तो इन टेम्पलेट्स को देखें: + +* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## क्या मुझे अपना प्रोजेक्ट लॉन्च करते समय शासन दस्तावेज़ों की आवश्यकता होगी? + +आपके प्रोजेक्ट के प्रशासन को लिखने का कोई सही समय नहीं है, लेकिन एक बार जब आप अपने समुदाय की गतिशीलता को देख लेंगे तो इसे परिभाषित करना बहुत आसान हो जाएगा। ओपन सोर्स गवर्नेंस के बारे में सबसे अच्छी (और सबसे कठिन) बात यह है कि इसे समुदाय द्वारा आकार दिया जाता है! + +हालाँकि, कुछ शुरुआती दस्तावेज़ अनिवार्य रूप से आपके प्रोजेक्ट के प्रशासन में योगदान देंगे, इसलिए आप जो कर सकते हैं उसे लिखना शुरू कर दें। उदाहरण के लिए, आप व्यवहार के लिए स्पष्ट अपेक्षाओं को परिभाषित कर सकते हैं, या आपके प्रोजेक्ट के लॉन्च पर भी आपकी योगदानकर्ता प्रक्रिया कैसे काम करती है। + +यदि आप एक ओपन सोर्स प्रोजेक्ट लॉन्च करने वाली कंपनी का हिस्सा हैं, तो लॉन्च से पहले इस बारे में आंतरिक चर्चा करना उचित है कि आपकी कंपनी प्रोजेक्ट को आगे बढ़ाने के बारे में कैसे बनाए रखने और निर्णय लेने की उम्मीद करती है। हो सकता है कि आप सार्वजनिक रूप से यह स्पष्ट करना चाहें कि आपकी कंपनी इस परियोजना में कैसे शामिल होगी (या नहीं करेगी!)। + + + +## यदि कॉर्पोरेट कर्मचारी अंशदान जमा करना शुरू कर दें तो क्या होगा? + +सफल ओपन सोर्स परियोजनाओं का उपयोग कई लोगों और कंपनियों द्वारा किया जाता है, और कुछ कंपनियों के पास अंततः राजस्व धाराएं परियोजना से जुड़ी हो सकती हैं। उदाहरण के लिए, कोई कंपनी किसी वाणिज्यिक सेवा पेशकश में परियोजना के कोड को एक घटक के रूप में उपयोग कर सकती है। + +जैसे-जैसे परियोजना अधिक व्यापक रूप से उपयोग की जाती है, इसमें विशेषज्ञता रखने वाले लोगों की मांग अधिक हो जाती है - आप उनमें से एक हो सकते हैं! - और कभी-कभी उन्हें प्रोजेक्ट में किए गए काम के लिए भुगतान मिलेगा। + +व्यावसायिक गतिविधि को सामान्य और विकास ऊर्जा के एक अन्य स्रोत के रूप में मानना ​​महत्वपूर्ण है। निःसंदेह, भुगतान किए गए डेवलपर्स को अवैतनिक डेवलपर्स की तुलना में विशेष व्यवहार नहीं मिलना चाहिए; प्रत्येक योगदान का मूल्यांकन उसकी तकनीकी खूबियों के आधार पर किया जाना चाहिए। हालाँकि, लोगों को व्यावसायिक गतिविधि में शामिल होने में सहज महसूस करना चाहिए, और किसी विशेष वृद्धि या सुविधा के पक्ष में बहस करते समय अपने उपयोग के मामलों को बताने में सहज महसूस करना चाहिए। + +"वाणिज्यिक" "ओपन सोर्स" के साथ पूरी तरह से संगत है। "वाणिज्यिक" का सीधा सा मतलब है कि इसमें कहीं न कहीं पैसा शामिल है - कि सॉफ्टवेयर का उपयोग वाणिज्य में किया जाता है, जो कि एक परियोजना के अपनाने के रूप में तेजी से संभव है। (जब ओपन सोर्स सॉफ़्टवेयर का उपयोग गैर-ओपन-सोर्स उत्पाद के हिस्से के रूप में किया जाता है, तो समग्र उत्पाद अभी भी "मालिकाना" सॉफ़्टवेयर होता है, हालांकि, ओपन सोर्स की तरह, इसका उपयोग वाणिज्यिक या गैर-व्यावसायिक उद्देश्यों के लिए किया जा सकता है।) + +किसी भी अन्य की तरह, व्यावसायिक रूप से प्रेरित डेवलपर्स अपने योगदान की गुणवत्ता और मात्रा के माध्यम से परियोजना में प्रभाव प्राप्त करते हैं। जाहिर है, एक डेवलपर जिसे उसके समय के लिए भुगतान किया जाता है, वह उस व्यक्ति से अधिक काम करने में सक्षम हो सकता है जिसे भुगतान नहीं किया जाता है, लेकिन यह ठीक है: भुगतान कई संभावित कारकों में से एक है जो किसी के काम को प्रभावित कर सकता है। अपनी परियोजना चर्चाओं को योगदानों पर केंद्रित रखें, न कि उन बाहरी कारकों पर जो लोगों को योगदान देने में सक्षम बनाते हैं। + +## क्या मुझे अपने प्रोजेक्ट का समर्थन करने के लिए एक कानूनी इकाई की आवश्यकता है? + +जब तक आप पैसे का प्रबंधन नहीं कर रहे हों, आपको अपने ओपन सोर्स प्रोजेक्ट का समर्थन करने के लिए किसी कानूनी इकाई की आवश्यकता नहीं है। + +उदाहरण के लिए, यदि आप एक वाणिज्यिक व्यवसाय बनाना चाहते हैं, तो आप एक सी कॉर्प या एलएलसी स्थापित करना चाहेंगे (यदि आप अमेरिका में स्थित हैं)। यदि आप केवल अपने ओपन सोर्स प्रोजेक्ट से संबंधित अनुबंध कार्य कर रहे हैं, तो आप एकमात्र मालिक के रूप में धन स्वीकार कर सकते हैं, या एलएलसी स्थापित कर सकते हैं (यदि आप अमेरिका में स्थित हैं)। + +यदि आप अपने ओपन सोर्स प्रोजेक्ट के लिए दान स्वीकार करना चाहते हैं, तो आप एक दान बटन सेट कर सकते हैं (उदाहरण के लिए पेपैल या स्ट्राइप का उपयोग करके), लेकिन पैसा तब तक कर-कटौती योग्य नहीं होगा जब तक कि आप एक योग्य गैर-लाभकारी संस्था (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/) का, एक नोड-आधारित ढांचा। diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md new file mode 100644 index 00000000000..7ad3b9bdf9a --- /dev/null +++ b/_articles/hi/legal.md @@ -0,0 +1,162 @@ +--- +lang: hi +title: ओपन सोर्स का कानूनी पक्ष +description: ओपन सोर्स के कानूनी पक्ष के बारे में आपने जो कुछ भी सोचा है, और कुछ चीजें जो आपने नहीं सोची हैं। +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## ओपन सोर्स के कानूनी निहितार्थ को समझना + +अपने रचनात्मक कार्य को दुनिया के साथ साझा करना एक रोमांचक और पुरस्कृत अनुभव हो सकता है। इसका मतलब यह भी हो सकता है कि कई कानूनी चीजें जिनके बारे में आप नहीं जानते कि आपको चिंता करने की ज़रूरत है। शुक्र है, आपको शून्य से शुरुआत करने की ज़रूरत नहीं है। हमने आपकी कानूनी ज़रूरतें पूरी कर ली हैं। (इससे पहले कि आप गहराई से जानें, हमारा पढ़ना सुनिश्चित करें [disclaimer](/notices/).) + +## लोग ओपन सोर्स के कानूनी पक्ष की इतनी परवाह क्यों करते हैं? + +ख़ुशी है कि आपने पूछा! जब आप कोई रचनात्मक कार्य (जैसे लेखन, ग्राफ़िक्स, या कोड) करते हैं, तो वह कार्य डिफ़ॉल्ट रूप से विशेष कॉपीराइट के अंतर्गत होता है। यानी, कानून मानता है कि आपके काम के लेखक के रूप में, आपको यह कहने का अधिकार है कि दूसरे इसके साथ क्या कर सकते हैं। + +सामान्य तौर पर, इसका मतलब यह है कि कोई भी अन्य व्यक्ति टेक-डाउन, शेक-डाउन या मुकदमेबाजी के जोखिम के बिना आपके काम का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है। + +हालाँकि, ओपन सोर्स एक असामान्य परिस्थिति है, क्योंकि लेखक को उम्मीद है कि अन्य लोग काम का उपयोग, संशोधन और साझा करेंगे। लेकिन चूँकि कानूनी डिफ़ॉल्ट अभी भी अनन्य कॉपीराइट है, इसलिए आपको एक ऐसे लाइसेंस की आवश्यकता है जो इन अनुमतियों को स्पष्ट रूप से बताता हो। + +यदि आप ओपन सोर्स लाइसेंस लागू नहीं करते हैं, तो आपके प्रोजेक्ट में योगदान देने वाला प्रत्येक व्यक्ति भी अपने काम का विशेष कॉपीराइट धारक बन जाता है। इसका मतलब है कि कोई भी उनके योगदान का उपयोग, प्रतिलिपि, वितरण या संशोधन नहीं कर सकता है - और उस "कोई भी" में आप शामिल नहीं हैं। + +अंततः, आपके प्रोजेक्ट में लाइसेंस आवश्यकताओं वाली निर्भरताएँ हो सकती हैं जिनके बारे में आपको जानकारी नहीं थी। आपके प्रोजेक्ट के समुदाय, या आपके नियोक्ता की नीतियों के लिए, आपके प्रोजेक्ट को विशिष्ट ओपन सोर्स लाइसेंस का उपयोग करने की भी आवश्यकता हो सकती है। हम नीचे इन स्थितियों को कवर करेंगे। + +## क्या सार्वजनिक GitHub परियोजनाएँ खुला स्रोत हैं? + +जब आप GitHub पर [एक नया प्रोजेक्ट बनाते हैं](https://help.github.com/articles/creating-a-new-repository/), तो आपके पास रिपॉजिटरी को **private** या **public** बनाने का विकल्प होता है। + +![Create repository](/assets/images/legal/repo-create-name.png) + +**अपने GitHub प्रोजेक्ट को सार्वजनिक बनाना आपके प्रोजेक्ट को लाइसेंस देने के समान नहीं है।** सार्वजनिक परियोजनाएँ इसके अंतर्गत आती हैं [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), जो दूसरों को आपके प्रोजेक्ट को देखने और फोर्क करने की अनुमति देता है, लेकिन अन्यथा आपका काम बिना किसी अनुमति के आता है। + +यदि आप चाहते हैं कि अन्य लोग आपके प्रोजेक्ट का उपयोग, वितरण, संशोधन या योगदान करें, तो आपको एक ओपन सोर्स लाइसेंस शामिल करना होगा। उदाहरण के लिए, कोई व्यक्ति आपके GitHub प्रोजेक्ट के किसी भी हिस्से को अपने कोड में कानूनी रूप से उपयोग नहीं कर सकता, भले ही वह सार्वजनिक हो, जब तक कि आप स्पष्ट रूप से उन्हें ऐसा करने का अधिकार नहीं देते। + +## बस मुझे टीएल;डीआर दें कि मुझे अपने प्रोजेक्ट की सुरक्षा के लिए क्या चाहिए। + +आप भाग्यशाली हैं, क्योंकि आज, ओपन सोर्स लाइसेंस मानकीकृत और उपयोग में आसान हैं। आप किसी मौजूदा लाइसेंस को सीधे अपने प्रोजेक्ट में कॉपी-पेस्ट कर सकते हैं। + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) +सबसे लोकप्रिय ओपन सोर्स लाइसेंस हैं, लेकिन चुनने के लिए अन्य विकल्प भी हैं। आप इन लाइसेंसों का पूरा पाठ और उनका उपयोग करने के तरीके के बारे में निर्देश यहां पा सकते हैं[choosealicense.com](https://choosealicense.com/). + +जब आप GitHub पर एक नया प्रोजेक्ट बनाएंगे, तो आप होंगे [लाइसेंस जोड़ने के लिए कहा गया](https://help.github.com/articles/open-source-licensing/). + + + +## मेरे प्रोजेक्ट के लिए कौन सा ओपन सोर्स लाइसेंस उपयुक्त है? + +यदि आप कोरी स्लेट से शुरुआत कर रहे हैं, तो इसमें गलत होना कठिन है [MIT License](https://choosealicense.com/licenses/mit/). यह संक्षिप्त है, समझने में बहुत आसान है, और किसी को भी कुछ भी करने की अनुमति देता है जब तक कि वे आपके कॉपीराइट नोटिस सहित लाइसेंस की एक प्रति अपने पास रखते हैं। यदि आपको कभी आवश्यकता होगी तो आप प्रोजेक्ट को एक अलग लाइसेंस के तहत जारी करने में सक्षम होंगे। + +अन्यथा, आपके प्रोजेक्ट के लिए सही ओपन सोर्स लाइसेंस चुनना आपके उद्देश्यों पर निर्भर करता है। + +आपके प्रोजेक्ट की बहुत संभावना है (या होगी) **dependencies**. उदाहरण के लिए, यदि आप Node.js प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं, तो आप संभवतः नोड पैकेज मैनेजर (npm) से लाइब्रेरी का उपयोग करेंगे। आप जिन पुस्तकालयों पर निर्भर हैं उनमें से प्रत्येक के पास अपना स्वयं का ओपन सोर्स लाइसेंस होगा। यदि उनका प्रत्येक लाइसेंस "अनुमोदनात्मक" है (डाउनस्ट्रीम लाइसेंसिंग के लिए बिना किसी शर्त के जनता को उपयोग, संशोधन और साझा करने की अनुमति देता है), तो आप अपने इच्छित किसी भी लाइसेंस का उपयोग कर सकते हैं। सामान्य अनुमेय लाइसेंस में एमआईटी, अपाचे 2.0, आईएससी और बीएसडी शामिल हैं। + +दूसरी ओर, यदि आपकी किसी निर्भरता का लाइसेंस "मजबूत कॉपीलेफ्ट" है (सार्वजनिक रूप से समान अनुमतियाँ देता है, समान लाइसेंस डाउनस्ट्रीम का उपयोग करने की शर्त के अधीन), तो आपके प्रोजेक्ट को उसी लाइसेंस का उपयोग करना होगा। सामान्य मजबूत कॉपीलेफ़्ट लाइसेंस में GPLv2, GPLv3, और AGPLv3 शामिल हैं। + +आप शायद उन **communities** पर भी विचार करना चाहेंगे जिनका आप उपयोग करेंगे और आपके प्रोजेक्ट में योगदान देंगे: + +* **क्या आप चाहते हैं कि आपकी परियोजना का उपयोग अन्य परियोजनाओं द्वारा निर्भरता के रूप में किया जाए?** संभवतः आपके प्रासंगिक समुदाय में सबसे लोकप्रिय लाइसेंस का उपयोग करना सबसे अच्छा है। उदाहरण के लिए, [MIT](https://choosealicense.com/licenses/mit/) +के लिए सबसे लोकप्रिय लाइसेंस है [npm libraries](https://libraries.io/search?platforms=NPM). +* **क्या आप चाहते हैं कि आपका प्रोजेक्ट बड़े व्यवसायों को पसंद आए?** एक बड़ा व्यवसाय संभवतः सभी योगदानकर्ताओं से एक एक्सप्रेस पेटेंट लाइसेंस चाहेगा। इस मामले में, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. +* **क्या आप चाहते हैं कि आपका प्रोजेक्ट उन योगदानकर्ताओं को आकर्षित करे जो नहीं चाहते कि उनके योगदान का उपयोग बंद स्रोत सॉफ़्टवेयर में किया जाए?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) या (यदि वे भी बंद स्रोत सेवाओं में योगदान नहीं करना चाहते हैं) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) +अच्छा चलेगा। + +आपकी **कंपनी** को अपने ओपन सोर्स प्रोजेक्ट्स के लिए विशिष्ट लाइसेंसिंग आवश्यकताएं हो सकती हैं। उदाहरण के लिए, इसके लिए एक अनुमेय लाइसेंस की आवश्यकता हो सकती है ताकि कंपनी आपके प्रोजेक्ट का उपयोग कंपनी के बंद स्रोत उत्पाद में कर सके। या आपकी कंपनी को एक मजबूत कॉपीलेफ्ट लाइसेंस और एक अतिरिक्त योगदानकर्ता समझौते (नीचे देखें) की आवश्यकता हो सकती है ताकि केवल आपकी कंपनी, और कोई नहीं, बंद स्रोत सॉफ़्टवेयर में आपके प्रोजेक्ट का उपयोग कर सके। या आपकी कंपनी को मानकों, सामाजिक जिम्मेदारी, या पारदर्शिता से संबंधित कुछ ज़रूरतें हो सकती हैं, जिनमें से किसी के लिए एक विशेष लाइसेंसिंग रणनीति की आवश्यकता हो सकती है। आप अपने [कंपनी का कानूनी विभाग](#मेरी-कंपनी-की-कानूनी-टीम-को-क्या-जानना-आवश्यक-है) से बातें करें। + +जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ऊपर उल्लिखित लाइसेंसों में से एक को शामिल करने से आपका GitHub प्रोजेक्ट खुला स्रोत बन जाएगा। यदि आप अन्य विकल्प देखना चाहते हैं, तो देखें [choosealicense.com](https://choosealicense.com) अपने प्रोजेक्ट के लिए सही लाइसेंस ढूँढ़ने के लिए, भले ही वह हो [isn't software](https://choosealicense.com/non-software/). + +## यदि मैं अपने प्रोजेक्ट का लाइसेंस बदलना चाहूँ तो क्या होगा? + +अधिकांश परियोजनाओं को कभी भी लाइसेंस बदलने की आवश्यकता नहीं होती है। लेकिन कभी-कभी हालात बदल जाते हैं. + +उदाहरण के लिए, जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, इसमें निर्भरताएँ या उपयोगकर्ता जुड़ते हैं, या आपकी कंपनी रणनीतियाँ बदलती है, जिनमें से किसी को भी अलग लाइसेंस की आवश्यकता हो सकती है या चाहिए। साथ ही, यदि आपने शुरू से ही अपने प्रोजेक्ट को लाइसेंस देने की उपेक्षा की है, तो लाइसेंस जोड़ना प्रभावी रूप से लाइसेंस बदलने के समान है। अपने प्रोजेक्ट का लाइसेंस जोड़ते या बदलते समय विचार करने योग्य तीन मूलभूत बातें हैं: + +**यह जटिल है।** लाइसेंस अनुकूलता और अनुपालन का निर्धारण करना और कॉपीराइट किसके पास है, यह बहुत जल्दी जटिल और भ्रमित करने वाला हो सकता है। नई रिलीज़ और योगदान के लिए नए लेकिन संगत लाइसेंस पर स्विच करना सभी मौजूदा योगदानों को दोबारा लाइसेंस देने से अलग है। लाइसेंस बदलने की इच्छा के पहले संकेत पर अपनी कानूनी टीम को शामिल करें। भले ही आपके पास लाइसेंस परिवर्तन के लिए अपने प्रोजेक्ट के कॉपीराइट धारकों से अनुमति है या आप प्राप्त कर सकते हैं, फिर भी अपने प्रोजेक्ट के अन्य उपयोगकर्ताओं और योगदानकर्ताओं पर परिवर्तन के प्रभाव पर विचार करें। अपने प्रोजेक्ट के लिए लाइसेंस परिवर्तन को एक "गवर्नेंस इवेंट" के रूप में सोचें, जो आपके प्रोजेक्ट के हितधारकों के साथ स्पष्ट संचार और परामर्श के साथ आसानी से चलेगा। शुरुआत से ही अपने प्रोजेक्ट के लिए उपयुक्त लाइसेंस चुनने और उसका उपयोग करने का और भी अधिक कारण! + +**आपके प्रोजेक्ट का मौजूदा लाइसेंस।** यदि आपके प्रोजेक्ट का मौजूदा लाइसेंस उस लाइसेंस के अनुकूल है जिसे आप बदलना चाहते हैं, तो आप नए लाइसेंस का उपयोग शुरू कर सकते हैं। ऐसा इसलिए है क्योंकि यदि लाइसेंस ए लाइसेंस बी के साथ संगत है, तो आप बी की शर्तों का अनुपालन करते समय ए की शर्तों का अनुपालन करेंगे (लेकिन जरूरी नहीं कि इसका विपरीत भी हो)। इसलिए यदि आप वर्तमान में एक अनुमेय लाइसेंस (उदाहरण के लिए, एमआईटी) का उपयोग कर रहे हैं, तो आप अधिक शर्तों वाले लाइसेंस में बदल सकते हैं, जब तक कि आप एमआईटी लाइसेंस और किसी भी संबंधित कॉपीराइट नोटिस की एक प्रति अपने पास रखते हैं (यानी, इसका अनुपालन करना जारी रखते हैं। एमआईटी लाइसेंस की न्यूनतम शर्तें)। लेकिन यदि आपका वर्तमान लाइसेंस अनुमेय नहीं है (उदाहरण के लिए, कॉपीलेफ्ट, या आपके पास लाइसेंस नहीं है) और आप एकमात्र कॉपीराइट धारक नहीं हैं, तो आप अपने प्रोजेक्ट के लाइसेंस को एमआईटी में नहीं बदल सकते। मूलतः, अनुमेय लाइसेंस के साथ परियोजना के कॉपीराइट धारकों ने लाइसेंस बदलने की अग्रिम अनुमति दे दी है। + +**आपके प्रोजेक्ट के मौजूदा कॉपीराइट धारक।** यदि आप अपने प्रोजेक्ट में एकमात्र योगदानकर्ता हैं तो या तो आप या आपकी कंपनी प्रोजेक्ट के एकमात्र कॉपीराइट धारक हैं। आप या आपकी कंपनी जो भी लाइसेंस जोड़ना या बदलना चाहती है, आप उसे जोड़ या बदल सकते हैं। अन्यथा ऐसे अन्य कॉपीराइट धारक भी हो सकते हैं जिनसे लाइसेंस बदलने के लिए आपको सहमति की आवश्यकता होगी। कौन हैं वे? जिन लोगों की आपके प्रोजेक्ट में प्रतिबद्धता है, वे शुरुआत करने के लिए एक अच्छी जगह हैं। लेकिन कुछ मामलों में कॉपीराइट उन लोगों के नियोक्ताओं के पास होगा। कुछ मामलों में लोगों ने केवल न्यूनतम योगदान दिया होगा, लेकिन ऐसा कोई सख्त नियम नहीं है कि कोड की कुछ पंक्तियों के तहत योगदान कॉपीराइट के अधीन नहीं है। क्या करें? निर्भर करता है। अपेक्षाकृत छोटी और युवा परियोजना के लिए, सभी मौजूदा योगदानकर्ताओं को किसी मुद्दे या पुल अनुरोध में लाइसेंस परिवर्तन के लिए सहमत करना संभव हो सकता है। बड़ी और लंबे समय तक चलने वाली परियोजनाओं के लिए, आपको कई योगदानकर्ताओं और यहां तक ​​कि उनके उत्तराधिकारियों की तलाश करनी पड़ सकती है। मोज़िला को फ़ायरफ़ॉक्स, थंडरबर्ड और संबंधित सॉफ़्टवेयर को पुनः लाइसेंस देने में वर्षों (2001-2006) लग गए। + +वैकल्पिक रूप से, आप अपने मौजूदा ओपन सोर्स लाइसेंस द्वारा अनुमत शर्तों से परे, कुछ शर्तों के तहत कुछ लाइसेंस परिवर्तनों के लिए योगदानकर्ताओं को पहले से सहमत कर सकते हैं (एक अतिरिक्त योगदानकर्ता समझौते के माध्यम से - नीचे देखें)। इससे लाइसेंस बदलने की जटिलता कुछ हद तक बदल जाती है। आपको पहले से ही अपने वकीलों से अधिक सहायता की आवश्यकता होगी, और लाइसेंस परिवर्तन निष्पादित करते समय आप अभी भी अपने प्रोजेक्ट के हितधारकों के साथ स्पष्ट रूप से संवाद करना चाहेंगे। + +## क्या मेरे प्रोजेक्ट को अतिरिक्त योगदानकर्ता समझौते की आवश्यकता है? + +शायद नहीं। अधिकांश ओपन सोर्स परियोजनाओं के लिए, एक ओपन सोर्स लाइसेंस अंतर्निहित रूप से इनबाउंड (योगदानकर्ताओं से) और आउटबाउंड (अन्य योगदानकर्ताओं और उपयोगकर्ताओं के लिए) लाइसेंस दोनों के रूप में कार्य करता है।यदि आपका प्रोजेक्ट GitHub पर है, तो GitHub सेवा की शर्तें "इनबाउंड = आउटबाउंड" बनाती हैं [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +एक अतिरिक्त योगदानकर्ता समझौता - जिसे अक्सर Contributor License Agreement (CLA) कहा जाता है - परियोजना अनुरक्षकों के लिए प्रशासनिक कार्य बना सकता है। एक समझौता कितना काम जोड़ता है यह परियोजना और कार्यान्वयन पर निर्भर करता है। एक साधारण समझौते के लिए आवश्यक हो सकता है कि योगदानकर्ता एक क्लिक के साथ पुष्टि करें कि उनके पास प्रोजेक्ट ओपन सोर्स लाइसेंस के तहत योगदान करने के लिए आवश्यक अधिकार हैं। अधिक जटिल समझौते के लिए कानूनी समीक्षा और योगदानकर्ताओं के नियोक्ताओं से हस्ताक्षर की आवश्यकता हो सकती है। + +साथ ही, "कागजी कार्रवाई" जोड़कर, जो कुछ लोगों का मानना ​​है कि अनावश्यक, समझने में कठिन या अनुचित है (जब समझौते के प्राप्तकर्ता को परियोजना के ओपन सोर्स लाइसेंस के माध्यम से योगदानकर्ताओं या जनता की तुलना में अधिक अधिकार मिलते हैं), एक अतिरिक्त योगदानकर्ता समझौते को अमित्र माना जा सकता है परियोजना के समुदाय के लिए। + + + +कुछ स्थितियाँ जहाँ आप अपने प्रोजेक्ट के लिए अतिरिक्त योगदानकर्ता समझौते पर विचार करना चाह सकते हैं उनमें शामिल हैं: + +* आपके वकील चाहते हैं कि सभी योगदानकर्ता स्पष्ट रूप से (_साइन_, ऑनलाइन या ऑफलाइन) योगदान शर्तों को स्वीकार करें, शायद इसलिए क्योंकि उन्हें लगता है कि ओपन सोर्स लाइसेंस ही पर्याप्त नहीं है (भले ही यह है!)। यदि यह एकमात्र चिंता का विषय है, तो एक योगदानकर्ता समझौता जो परियोजना के ओपन सोर्स लाइसेंस की पुष्टि करता है, पर्याप्त होना चाहिए। [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) हल्के अतिरिक्त योगदानकर्ता समझौते का एक अच्छा उदाहरण है। +* आप या आपके वकील चाहते हैं कि डेवलपर्स यह प्रतिनिधित्व करें कि उनकी प्रत्येक प्रतिबद्धता अधिकृत है. [Developer Certificate of Origin](https://developercertificate.org/) आवश्यकता यह है कि कितनी परियोजनाएँ इसे प्राप्त करती हैं। उदाहरण के लिए, Node.js समुदाय [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) उनके पूर्व CLI का। आपके भंडार पर डीसीओ के प्रवर्तन को स्वचालित करने का एक सरल विकल्प है [DCO Probot](https://github.com/probot/dco). +*आपका प्रोजेक्ट एक ओपन सोर्स लाइसेंस का उपयोग करता है जिसमें एक्सप्रेस पेटेंट अनुदान (जैसे एमआईटी) शामिल नहीं है, और आपको सभी योगदानकर्ताओं से पेटेंट अनुदान की आवश्यकता है, जिनमें से कुछ बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के लिए काम कर सकते हैं जिनका उपयोग आपको लक्षित करने के लिए किया जा सकता है या परियोजना के अन्य योगदानकर्ता और उपयोगकर्ता। The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) आमतौर पर इस्तेमाल किया जाने वाला अतिरिक्त योगदानकर्ता समझौता है जिसमें अपाचे लाइसेंस 2.0 में पाए गए पेटेंट अनुदान को प्रतिबिंबित किया गया है। +* आपका प्रोजेक्ट कॉपीलेफ्ट लाइसेंस के अंतर्गत है, लेकिन आपको प्रोजेक्ट का मालिकाना संस्करण भी वितरित करने की आवश्यकता है। आपको प्रत्येक योगदानकर्ता से आपको कॉपीराइट सौंपने या आपको (लेकिन जनता को नहीं) अनुमेय लाइसेंस देने की आवश्यकता होगी। [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) इस प्रकार के समझौते का एक उदाहरण है. +* आपको लगता है कि आपके प्रोजेक्ट को अपने जीवनकाल में लाइसेंस बदलने की आवश्यकता हो सकती है और आप चाहते हैं कि योगदानकर्ता ऐसे परिवर्तनों के लिए पहले से सहमत हों। + +यदि आपको अपने प्रोजेक्ट के साथ एक अतिरिक्त योगदानकर्ता समझौते का उपयोग करने की आवश्यकता है, तो एक एकीकरण का उपयोग करने पर विचार करें [CLA assistant](https://github.com/cla-assistant/cla-assistant) योगदानकर्ता व्याकुलता को कम करने के लिए। + +## मेरी कंपनी की कानूनी टीम को क्या जानना आवश्यक है? + +यदि आप एक कंपनी कर्मचारी के रूप में एक ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो सबसे पहले, आपकी कानूनी टीम को पता होना चाहिए कि आप एक प्रोजेक्ट को ओपन सोर्स कर रहे हैं। + +बेहतर या बदतर के लिए, उन्हें बताने पर विचार करें, भले ही यह एक व्यक्तिगत परियोजना हो। संभवत: आपके पास अपनी कंपनी के साथ एक "कर्मचारी आईपी समझौता" है जो उन्हें आपकी परियोजनाओं पर कुछ नियंत्रण देता है, खासकर यदि वे कंपनी के व्यवसाय से संबंधित हैं या आप परियोजना को विकसित करने के लिए किसी कंपनी के संसाधनों का उपयोग करते हैं। आपकी कंपनी को आपको आसानी से अनुमति देनी चाहिए, और शायद पहले से ही एक कर्मचारी-अनुकूल आईपी समझौते या कंपनी नीति के माध्यम से अनुमति दे दी है। यदि नहीं, तो आप बातचीत कर सकते हैं (उदाहरण के लिए, समझाएं कि आपका प्रोजेक्ट आपके लिए कंपनी के पेशेवर शिक्षण और विकास उद्देश्यों को पूरा करता है), या जब तक आपको एक बेहतर कंपनी नहीं मिल जाती, तब तक अपने प्रोजेक्ट पर काम करने से बचें। + +**यदि आप अपनी कंपनी के लिए किसी प्रोजेक्ट की ओपन सोर्सिंग कर रहे हैं,** तो उन्हें अवश्य बताएं। आपकी कानूनी टीम के पास संभवतः पहले से ही नीतियां हैं कि कंपनी की व्यावसायिक आवश्यकताओं और विशेषज्ञता के आधार पर किस ओपन सोर्स लाइसेंस (और शायद अतिरिक्त योगदानकर्ता समझौते) का उपयोग किया जाए ताकि यह सुनिश्चित हो सके कि आपका प्रोजेक्ट उसकी निर्भरता के लाइसेंस का अनुपालन करता है। यदि नहीं, तो आप और वे भाग्यशाली हैं! आपकी कानूनी टीम को इस चीज़ का पता लगाने के लिए आपके साथ काम करने के लिए उत्सुक होना चाहिए। सोचने लायक कुछ बातें: + +* **तृतीय पक्ष सामग्री:** क्या आपके प्रोजेक्ट में दूसरों द्वारा बनाई गई निर्भरताएँ हैं या अन्यथा दूसरों के कोड को शामिल या उपयोग करते हैं? यदि ये ओपन सोर्स हैं, तो आपको सामग्रियों के ओपन सोर्स लाइसेंस का अनुपालन करना होगा। इसकी शुरुआत एक ऐसे लाइसेंस को चुनने से होती है जो तीसरे पक्ष के ओपन सोर्स लाइसेंस के साथ काम करता है (ऊपर देखें)। यदि आपका प्रोजेक्ट तृतीय पक्ष ओपन सोर्स सामग्री को संशोधित या वितरित करता है, तो आपकी कानूनी टीम यह भी जानना चाहेगी कि आप तृतीय पक्ष ओपन सोर्स लाइसेंस की अन्य शर्तों को पूरा कर रहे हैं जैसे कि कॉपीराइट नोटिस बनाए रखना। यदि आपका प्रोजेक्ट दूसरों के कोड का उपयोग करता है जिसके पास ओपन सोर्स लाइसेंस नहीं है, तो आपको संभवतः तीसरे पक्ष के अनुरक्षकों से पूछना होगा [एक ओपन सोर्स लाइसेंस जोड़ें](https://choosealicense.com/no-license/#for-users), और यदि आपको कोई नहीं मिल सकता है, तो अपने प्रोजेक्ट में उनके कोड का उपयोग करना बंद कर दें। + +* **व्यापार रहस्य:** विचार करें कि क्या परियोजना में ऐसा कुछ है जिसे कंपनी आम जनता के लिए उपलब्ध नहीं कराना चाहती है। यदि ऐसा है, तो जिस सामग्री को आप निजी रखना चाहते हैं, उसे निकालने के बाद आप अपने प्रोजेक्ट के बाकी हिस्से को ओपन सोर्स कर सकते हैं। + +* **पेटेंट:** क्या आपकी कंपनी किसी ऐसे पेटेंट के लिए आवेदन कर रही है जिसके ओपन सोर्सिंग से आपका प्रोजेक्ट [सार्वजनिक प्रकटीकरण](https://en.wikipedia.org/wiki/Public_disclosure) बनेगा? अफसोस की बात है, आपको प्रतीक्षा करने के लिए कहा जा सकता है (या हो सकता है कि कंपनी आवेदन की समझदारी पर पुनर्विचार करेगी)। यदि आप बड़े पेटेंट पोर्टफोलियो वाली कंपनियों के कर्मचारियों से अपने प्रोजेक्ट में योगदान की उम्मीद कर रहे हैं, तो आपकी कानूनी टीम चाहती है कि आप योगदानकर्ताओं (जैसे अपाचे 2.0 या जीपीएलवी 3) से एक्सप्रेस पेटेंट अनुदान के साथ लाइसेंस का उपयोग करें, या एक अतिरिक्त योगदानकर्ता अनुबंध ( ऊपर देखें)। + +* **ट्रेडमार्क:** दोबारा जांचें कि आपके प्रोजेक्ट का नाम [किसी भी मौजूदा ट्रेडमार्क के साथ टकराव नहीं करता है](../starting-a-project/#नाम-टकराव-से-बचना)। यदि आप प्रोजेक्ट में अपनी कंपनी के ट्रेडमार्क का उपयोग करते हैं, तो जांच लें कि इससे कोई टकराव न हो। [FOSSmarks](http://fossmarks.org/) मुक्त और मुक्त स्रोत परियोजनाओं के संदर्भ में ट्रेडमार्क को समझने के लिए एक व्यावहारिक मार्गदर्शिका है। + +* **गोपनीयता:** क्या आपका प्रोजेक्ट उपयोगकर्ताओं पर डेटा एकत्र करता है? कंपनी सर्वर के लिए "फ़ोन होम"? आपकी कानूनी टीम कंपनी की नीतियों और बाहरी नियमों का अनुपालन करने में आपकी सहायता कर सकती है। + +यदि आप अपनी कंपनी का पहला ओपन सोर्स प्रोजेक्ट जारी कर रहे हैं, तो उपरोक्त पूरा करने के लिए पर्याप्त से अधिक है (लेकिन चिंता न करें, अधिकांश परियोजनाओं को कोई बड़ी चिंता नहीं उठानी चाहिए)। + +लंबी अवधि में, आपकी कानूनी टीम कंपनी को ओपन सोर्स में अपनी भागीदारी से अधिक लाभ प्राप्त करने और सुरक्षित रहने में मदद करने के लिए और अधिक प्रयास कर सकती है: + +* **कर्मचारी योगदान नीतियां:** एक कॉर्पोरेट नीति विकसित करने पर विचार करें जो निर्दिष्ट करती है कि आपके कर्मचारी ओपन सोर्स परियोजनाओं में कैसे योगदान करते हैं। एक स्पष्ट नीति आपके कर्मचारियों के बीच भ्रम को कम करेगी और उन्हें कंपनी के सर्वोत्तम हित में ओपन सोर्स परियोजनाओं में योगदान करने में मदद करेगी, चाहे वह उनकी नौकरी के हिस्से के रूप में हो या उनके खाली समय में। एक अच्छा उदाहरण रैकस्पेस की [मॉडल आईपी और ओपन सोर्स योगदान नीति](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) है। + + + +* **क्या जारी करें:** [(लगभग) सब कुछ?](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/hi/maintaining-balance-for-open-source-maintainers.md b/_articles/hi/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..64b41be1b52 --- /dev/null +++ b/_articles/hi/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,219 @@ +--- +lang: hi +title: ओपन सोर्स अनुरक्षकों के लिए संतुलन बनाए रखना +description: एक अनुचर के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ। +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +जैसे-जैसे एक ओपन सोर्स प्रोजेक्ट की लोकप्रियता बढ़ती है, आपको लंबे समय तक तरोताजा और उत्पादक बने रहने के लिए संतुलन बनाए रखने में मदद करने के लिए स्पष्ट सीमाएँ निर्धारित करना महत्वपूर्ण हो जाता है। + +संतुलन खोजने के लिए अनुरक्षकों के अनुभवों और उनकी रणनीतियों के बारे में जानकारी प्राप्त करने के लिए, हमने मेंटेनर समुदाय के 40 सदस्यों के साथ एक कार्यशाला चलाई, जिससे हमें अनुमति मिली खुले स्रोत में बर्नआउट के साथ उनके प्रत्यक्ष अनुभवों और उन प्रथाओं से सीखना जिन्होंने उन्हें अपने काम में संतुलन बनाए रखने में मदद की है। यहीं पर व्यक्तिगत पारिस्थितिकी की अवधारणा काम आती है। + +तो, व्यक्तिगत पारिस्थितिकी क्या है? जैसा रॉकवुड लीडरशिप इंस्टीट्यूट द्वारा वर्णित, इसमें "संतुलन बनाए रखना, गति बनाए रखना और शामिल है जीवन भर हमारी ऊर्जा को बनाए रखने की दक्षता।" इसने हमारी बातचीत को तैयार किया, जिससे अनुरक्षकों को समय के साथ विकसित होने वाले एक बड़े पारिस्थितिकी तंत्र के हिस्से के रूप में अपने कार्यों और योगदान को पहचानने में मदद मिली। बर्नआउट, क्रोनिक कार्यस्थल तनाव से उत्पन्न एक सिंड्रोम जैसा कि [डब्ल्यूएचओ द्वारा परिभाषित](https://icd.who.int/browse/2025-01/foundation/en#129180281), अनुरक्षकों के बीच असामान्य नहीं है। इससे अक्सर प्रेरणा की हानि, ध्यान केंद्रित करने में असमर्थता और उन योगदानकर्ताओं और समुदाय के लिए सहानुभूति की कमी हो जाती है जिनके साथ आप काम करते हैं। + + + +व्यक्तिगत पारिस्थितिकी की अवधारणा को अपनाकर, अनुरक्षक सक्रिय रूप से बर्नआउट से बच सकते हैं, आत्म-देखभाल को प्राथमिकता दे सकते हैं और अपना सर्वश्रेष्ठ कार्य करने के लिए संतुलन की भावना बनाए रख सकते हैं। + +## एक अनुरक्षक के रूप में स्वयं की देखभाल और बर्नआउट से बचने के लिए युक्तियाँ: + +### ओपन सोर्स में काम करने के लिए अपनी प्रेरणाओं को पहचानें + +इस बात पर विचार करने के लिए समय निकालें कि ओपन सोर्स रखरखाव के कौन से हिस्से आपको ऊर्जावान बनाते हैं। अपनी प्रेरणाओं को समझने से आपको काम को इस तरह से प्राथमिकता देने में मदद मिल सकती है जिससे आप व्यस्त रहेंगे और नई चुनौतियों के लिए तैयार रहेंगे। चाहे वह उपयोगकर्ताओं से सकारात्मक प्रतिक्रिया हो, समुदाय के साथ सहयोग और मेलजोल की खुशी हो, या कोड में गोता लगाने की संतुष्टि हो, अपनी प्रेरणाओं को पहचानने से आपका ध्यान केंद्रित करने में मदद मिल सकती है। + +### इस बात पर विचार करें कि किन कारणों से आप असंतुलित हो जाते हैं और तनावग्रस्त हो जाते हैं + +यह समझना महत्वपूर्ण है कि किन कारणों से हम थक जाते हैं। यहां कुछ सामान्य विषय हैं जो हमने ओपन सोर्स अनुरक्षकों के बीच देखे हैं: + +* **सकारात्मक प्रतिक्रिया का अभाव:** उपयोगकर्ताओं के पास शिकायत होने पर संपर्क करने की बहुत अधिक संभावना होती है। यदि सब कुछ बढ़िया चलता है, तो वे चुप रहना पसंद करते हैं। सकारात्मक प्रतिक्रिया के बिना मुद्दों की बढ़ती सूची को देखना हतोत्साहित करने वाला हो सकता है, जिसमें दिखाया गया हो कि आपके योगदान से कैसे फर्क पड़ रहा है। + + + +* **'नहीं' नहीं कहना:** किसी ओपन सोर्स प्रोजेक्ट पर अपनी अपेक्षा से अधिक ज़िम्मेदारियाँ लेना आसान हो सकता है। चाहे यह उपयोगकर्ताओं, योगदानकर्ताओं, या अन्य अनुरक्षकों से हो - हम हमेशा उनकी अपेक्षाओं पर खरे नहीं उतर सकते। + + + +* **अकेले काम करना:** एक अनुरक्षक बनना अविश्वसनीय रूप से अकेला हो सकता है। भले ही आप अनुरक्षकों के एक समूह के साथ काम करते हैं, पिछले कुछ वर्षों में वितरित टीमों को व्यक्तिगत रूप से बुलाना कठिन रहा है। + + + +* **पर्याप्त समय या संसाधन नहीं:** यह स्वयंसेवक अनुरक्षकों के लिए विशेष रूप से सच है, जिन्हें किसी परियोजना पर काम करने के लिए अपने खाली समय का त्याग करना पड़ता है। + + + +* **परस्पर विरोधी मांगें:** खुला स्रोत विभिन्न प्रेरणाओं वाले समूहों से भरा है, जिन्हें नेविगेट करना मुश्किल हो सकता है। यदि आपको ओपन सोर्स करने के लिए भुगतान किया जाता है, तो आपके नियोक्ता के हित कभी-कभी समुदाय के विपरीत हो सकते हैं। + + + +### बर्नआउट के लक्षणों से सावधान रहें + +क्या आप 10 सप्ताह तक अपनी गति बनाए रख सकते हैं? दस महीने? 10 वर्ष? + +उपकरण जैसे [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) [@shaunagm](https://github.com/shaunagm) से और मोज़िला का इससे आपको अपनी वर्तमान गति पर विचार करने और यह देखने में मदद मिल सकती है कि क्या आप कोई समायोजन कर सकते हैं। कुछ अनुरक्षक नींद की गुणवत्ता और हृदय गति परिवर्तनशीलता (दोनों तनाव से जुड़े हुए हैं) जैसे मेट्रिक्स को ट्रैक करने के लिए पहनने योग्य तकनीक का भी उपयोग करते हैं। + + + +### आपको अपना और अपने समुदाय का भरण-पोषण जारी रखने के लिए क्या चाहिए होगा? + +यह प्रत्येक अनुरक्षक के लिए अलग दिखेगा, और आपके जीवन के चरण और अन्य बाहरी कारकों के आधार पर बदल जाएगा। लेकिन यहां कुछ विषय हैं जो हमने सुने हैं: + +* **समुदाय पर निर्भर रहें:** प्रतिनिधिमंडल और योगदानकर्ताओं को ढूंढने से काम का बोझ कम हो सकता है। किसी प्रोजेक्ट के लिए संपर्क के कई बिंदु होने से आपको बिना किसी चिंता के ब्रेक लेने में मदद मिल सकती है। [मेंटेनर कम्युनिटी](http://maintainers.github.com/) जैसे समूहों में अन्य अनुरक्षकों और व्यापक समुदाय से जुड़ें। साथियों के समर्थन और सीखने के लिए यह एक बेहतरीन संसाधन हो सकता है। + + आप उपयोगकर्ता समुदाय के साथ जुड़ने के तरीकों की भी तलाश कर सकते हैं, ताकि आप नियमित रूप से फीडबैक सुन सकें और अपने ओपन सोर्स कार्य के प्रभाव को समझ सकें। + +* **फंडिंग का अन्वेषण करें:** चाहे आप कुछ पिज़्ज़ा मनी की तलाश में हों, या पूर्णकालिक ओपन सोर्स पर जाने की कोशिश कर रहे हों, मदद के लिए कई संसाधन मौजूद हैं! पहले कदम के रूप में, दूसरों को आपके ओपन सोर्स कार्य को प्रायोजित करने की अनुमति देने के लिए [GitHub प्रायोजक](https://github.com/sponsors) को चालू करने पर विचार करें। यदि आप पूर्णकालिक बनने के बारे में सोच रहे हैं, तो [GitHub Accelerator](http://accelerator.github.com/) के अगले दौर के लिए आवेदन करें। + + + +* **टूल्स का उपयोग करें:** सांसारिक कार्यों को स्वचालित करने के लिए [GitHub 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 में यह सूचीबद्ध करना कि आप क्या करने में रुचि रखते हैं और क्या नहीं करने में। उदाहरण के लिए, आप कह सकते हैं: "मैं केवल उन पीआर का विलय करता हूं जिनमें स्पष्ट रूप से उन कारणों को सूचीबद्ध किया गया है कि उन्हें क्यों बनाया गया है," या, "मैं केवल वैकल्पिक गुरुवार को शाम 6 से 7 बजे तक मुद्दों की समीक्षा करता हूं।" यह दूसरों के लिए अपेक्षाएं निर्धारित करता है, और आपको कुछ देता है अपने समय पर योगदानकर्ताओं या उपयोगकर्ताओं की मांगों को कम करने में मदद करने के लिए अन्य समय पर इंगित करना। + + + + विषाक्त व्यवहार और नकारात्मक बातचीत को बंद करने में दृढ़ रहना सीखें। उन चीज़ों को ऊर्जा न देना ठीक है जिनकी आपको परवाह नहीं है। + + + + + +याद रखें, व्यक्तिगत पारिस्थितिकी एक सतत अभ्यास है जो आपकी ओपन सोर्स यात्रा में प्रगति के साथ विकसित होगी। आत्म-देखभाल को प्राथमिकता देकर और संतुलन की भावना बनाए रखकर, आप प्रभावी ढंग से और स्थायी रूप से ओपन सोर्स समुदाय में योगदान कर सकते हैं, जिससे आपकी भलाई और लंबे समय तक आपकी परियोजनाओं की सफलता दोनों सुनिश्चित हो सकती है। + +## अतिरिक्त संसाधन + +* [मेंटेनर समुदाय](http://maintainers.github.com/) +* [ओपन सोर्स का सामाजिक अनुबंध](https://snarky.ca/the-social-contract-of-open-source/), ब्रेट कैनन +* [अनकर्लड](https://daniel.haxx.se/uncurled/), डेनियल स्टेनबर्ग +* [जहरीले लोगों से कैसे निपटें](https://www.youtube.com/watch?v=7lIpP3GEyXs), जीना हाउजगे +* [सस्टेनओएसएस](https://sustainoss.org/) +* [नेतृत्व की रॉकवुड कला](https://rockwoodleadership.org/art-of-leadership/) +* [नहीं कहना](https://mikemcquaid.com/saying-no/), माइक मैकक्यूएड +* [गवर्निंग ओपन](https://governingopen.com/) +* कार्यशाला के एजेंडे को रीमिक्स किया गया था [घर से मोज़िला की मूवमेंट बिल्डिंग](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) शृंखला + +## योगदानकर्ताओं + +इस गाइड के लिए अपने अनुभव और सुझाव हमारे साथ साझा करने वाले सभी अनुरक्षकों को बहुत धन्यवाद! + +यह मार्गदर्शिका [@abbycabs](https://github.com/abbycabs) द्वारा इनके योगदान के साथ लिखी गई थी: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/hi/metrics.md b/_articles/hi/metrics.md new file mode 100644 index 00000000000..5f4de85f9ba --- /dev/null +++ b/_articles/hi/metrics.md @@ -0,0 +1,128 @@ +--- +lang: hi +title: ओपन सोर्स मेट्रिक्स +description: अपने ओपन सोर्स प्रोजेक्ट की सफलता को मापने और ट्रैक करके उसे फलने-फूलने में मदद करने के लिए सोच-समझकर निर्णय लें। +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## किसी भी चीज़ को क्यों मापें? + +डेटा, जब बुद्धिमानी से उपयोग किया जाता है, तो आपको ओपन सोर्स अनुरक्षक के रूप में बेहतर निर्णय लेने में मदद मिल सकती है। + +अधिक जानकारी के साथ, आप यह कर सकते हैं: + +* समझें कि उपयोगकर्ता किसी नई सुविधा पर कैसे प्रतिक्रिया देते हैं +* पता लगाएं कि नए उपयोगकर्ता कहां से आते हैं +* बाहरी उपयोग के मामले या कार्यक्षमता को पहचानें और निर्णय लें कि इसका समर्थन करना है या नहीं +* अपने प्रोजेक्ट की लोकप्रियता का आकलन करें +* समझें कि आपके प्रोजेक्ट का उपयोग कैसे किया जाता है +* प्रायोजन और अनुदान के माध्यम से धन जुटाएं + +उदाहरण के लिए, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) ने पाया कि Google Analytics उन्हें काम को प्राथमिकता देने में मदद करता है: + +> होमब्रू निःशुल्क प्रदान किया जाता है और इसे पूरी तरह से स्वयंसेवकों द्वारा अपने खाली समय में चलाया जाता है। परिणामस्वरूप, हमारे पास भविष्य की सुविधाओं को सर्वोत्तम तरीके से डिज़ाइन करने और वर्तमान कार्य को प्राथमिकता देने के तरीके पर निर्णय लेने के लिए होमब्रू उपयोगकर्ताओं का विस्तृत उपयोगकर्ता अध्ययन करने के लिए संसाधन नहीं हैं। अनाम समग्र उपयोगकर्ता विश्लेषण हमें लोग होमब्रू का उपयोग कैसे, कहां और कब करते हैं, इसके आधार पर सुधारों और सुविधाओं को प्राथमिकता देने की अनुमति देते हैं। + +लोकप्रियता ही सब कुछ नहीं है. हर कोई अलग-अलग कारणों से खुले स्रोत में आ जाता है। यदि एक ओपन सोर्स अनुरक्षक के रूप में आपका लक्ष्य अपना काम दिखाना है, अपने कोड के बारे में पारदर्शी होना है, या सिर्फ मनोरंजन करना है, तो मेट्रिक्स आपके लिए महत्वपूर्ण नहीं हो सकते हैं। + +यदि आप अपने प्रोजेक्ट को गहराई से समझने में रुचि रखते हैं, तो अपने प्रोजेक्ट की गतिविधि का विश्लेषण करने के तरीकों के लिए आगे पढ़ें। + +## खोज + +इससे पहले कि कोई भी आपके प्रोजेक्ट का उपयोग कर सके या उसमें योगदान कर सके, उन्हें यह जानना होगा कि यह मौजूद है। अपने आप से पूछें: _क्या लोगों को यह प्रोजेक्ट मिल रहा है?_ + +![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +यदि आपका प्रोजेक्ट GitHub पर होस्ट किया गया है, [आप देख सकते हैं](https://help.github.com/articles/about-repository-graphs/#traffic) आपके प्रोजेक्ट पर कितने लोग आते हैं और वे कहाँ से आते हैं। अपने प्रोजेक्ट के पेज से, "इनसाइट्स" पर क्लिक करें, फिर "ट्रैफ़िक" पर क्लिक करें। इस पृष्ठ पर, आप देख सकते हैं: + +* **कुल पृष्ठ दृश्य:** आपको बताता है कि आपका प्रोजेक्ट कितनी बार देखा गया + +* **कुल अद्वितीय विज़िटर:** आपको बताता है कि कितने लोगों ने आपका प्रोजेक्ट देखा + +* **रेफ़रिंग साइटें:** आपको बताती हैं कि विज़िटर कहाँ से आए। यह मीट्रिक आपको यह पता लगाने में मदद कर सकता है कि आपको अपने दर्शकों तक कहां पहुंचना है और क्या आपके प्रचार प्रयास काम कर रहे हैं। + +* **लोकप्रिय सामग्री:** आपको बताती है कि विज़िटर आपके प्रोजेक्ट पर कहां जाते हैं, पृष्ठ दृश्य और अद्वितीय विज़िटर के आधार पर। + +[गिटहब सितारे](https://help.github.com/articles/about-stars/) लोकप्रियता का आधारभूत माप प्रदान करने में भी मदद मिल सकती है। हालाँकि GitHub सितारे आवश्यक रूप से डाउनलोड और उपयोग से संबंधित नहीं हैं, वे आपको बता सकते हैं कि कितने लोग आपके काम पर ध्यान दे रहे हैं। + +आप भी चाहते होंगे [tविशिष्ट स्थानों में रैक खोज योग्यता](https://opensource.com/business/16/6/pirate-metrics): उदाहरण के लिए, Google पेजरैंक, आपके प्रोजेक्ट की वेबसाइट से रेफरल ट्रैफ़िक, या अन्य ओपन सोर्स प्रोजेक्ट या वेबसाइट से रेफरल। + +## उपयोग + +लोग आपके प्रोजेक्ट को इस जंगली और पागलपन वाली चीज़ पर ढूंढ रहे हैं जिसे हम इंटरनेट कहते हैं। आदर्श रूप से, जब वे आपका प्रोजेक्ट देखेंगे, तो वे कुछ करने के लिए मजबूर महसूस करेंगे। दूसरा प्रश्न जो आप पूछना चाहेंगे वह है: _क्या लोग इस परियोजना का उपयोग कर रहे हैं?_ + +यदि आप अपने प्रोजेक्ट को वितरित करने के लिए npm या RubyGems.org जैसे पैकेज मैनेजर का उपयोग करते हैं, तो आप अपने प्रोजेक्ट के डाउनलोड को ट्रैक करने में सक्षम हो सकते हैं। + +प्रत्येक पैकेज प्रबंधक "डाउनलोड" की थोड़ी अलग परिभाषा का उपयोग कर सकता है, और डाउनलोड आवश्यक रूप से इंस्टॉल या उपयोग से संबंधित नहीं है, लेकिन यह तुलना के लिए कुछ आधार रेखा प्रदान करता है। कई लोकप्रिय पैकेज प्रबंधकों में उपयोग के आंकड़ों को ट्रैक करने के लिए [Libraries.io](https://libraries.io/) का उपयोग करने का प्रयास करें। + +यदि आपका प्रोजेक्ट GitHub पर है, तो "ट्रैफ़िक" पृष्ठ पर फिर से नेविगेट करें। आप यह देखने के लिए [क्लोन ग्राफ](https://github.com/blog/1873-clone-graphs) का उपयोग कर सकते हैं कि आपके प्रोजेक्ट को किसी दिए गए दिन में कितनी बार क्लोन किया गया है, कुल क्लोन और अद्वितीय क्लोनर्स द्वारा विभाजित किया गया है। + +![क्लोन ग्राफ़](/assets/images/metrics/clone_graph.png) + +यदि आपके प्रोजेक्ट को खोजने वाले लोगों की संख्या की तुलना में उपयोग कम है, तो विचार करने के लिए दो मुद्दे हैं। दोनों में से एक: + +* आपका प्रोजेक्ट आपके दर्शकों को सफलतापूर्वक परिवर्तित नहीं कर रहा है, या +* आप गलत दर्शकों को आकर्षित कर रहे हैं + +उदाहरण के लिए, यदि आपका प्रोजेक्ट हैकर न्यूज़ के पहले पन्ने पर आता है, तो आपको संभवतः खोज (ट्रैफ़िक) में वृद्धि दिखाई देगी, लेकिन रूपांतरण दर कम होगी, क्योंकि आप हैकर न्यूज़ पर सभी तक पहुंच रहे हैं। हालाँकि, यदि आपका रूबी प्रोजेक्ट रूबी सम्मेलन में प्रदर्शित किया गया है, तो आपको लक्षित दर्शकों से उच्च रूपांतरण दर देखने की अधिक संभावना है। + +यह पता लगाने का प्रयास करें कि आपके दर्शक कहां से आ रहे हैं और अपने प्रोजेक्ट पेज पर दूसरों से फीडबैक मांगें ताकि यह पता चल सके कि आप इन दोनों में से किस समस्या का सामना कर रहे हैं। + +एक बार जब आप जान जाते हैं कि लोग आपके प्रोजेक्ट का उपयोग कर रहे हैं, तो आप यह पता लगाने की कोशिश करना चाहेंगे कि वे इसके साथ क्या कर रहे हैं। क्या वे आपके कोड को फोर्क करके और सुविधाएँ जोड़कर इस पर निर्माण कर रहे हैं? क्या वे इसका उपयोग विज्ञान या व्यवसाय के लिए कर रहे हैं? + +## अवधारण + +लोगों को आपका प्रोजेक्ट मिल रहा है और वे इसका उपयोग कर रहे हैं। अगला प्रश्न जो आप स्वयं से पूछना चाहेंगे वह है: _क्या लोग इस परियोजना में योगदान दे रहे हैं?_ + +योगदानकर्ताओं के बारे में सोचना शुरू करना कभी भी जल्दी नहीं है। अन्य लोगों के हस्तक्षेप के बिना, आप अपने आप को एक अस्वस्थ स्थिति में डालने का जोखिम उठाते हैं जहां आपका प्रोजेक्ट लोकप्रिय है (कई लोग इसका उपयोग करते हैं) लेकिन समर्थित नहीं है (मांग को पूरा करने के लिए रखरखाव के लिए पर्याप्त समय नहीं है)। + +प्रतिधारण के लिए [नए योगदानकर्ताओं की आमद](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), की भी आवश्यकता होती है, चूँकि पहले सक्रिय योगदानकर्ता अंततः अन्य चीज़ों की ओर बढ़ेंगे। + +सामुदायिक मेट्रिक्स के उदाहरण जिन्हें आप नियमित रूप से ट्रैक करना चाहते हैं उनमें शामिल हैं: + +* **कुल योगदानकर्ता संख्या और प्रति योगदानकर्ता प्रतिबद्धताओं की संख्या:** आपको बताता है कि आपके पास कितने योगदानकर्ता हैं, और कौन कम या ज्यादा सक्रिय है। GitHub पर, आप इसे "अंतर्दृष्टि" -> "योगदानकर्ता" के अंतर्गत देख सकते हैं। अभी, यह ग्राफ़ केवल उन योगदानकर्ताओं की गणना करता है जिन्होंने रिपॉजिटरी की डिफ़ॉल्ट शाखा के लिए प्रतिबद्ध किया है। + +![योगदानकर्ता ग्राफ](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **पहली बार, आकस्मिक और बार-बार योगदान देने वाले:** आपको यह ट्रैक करने में मदद करता है कि क्या आपको नए योगदानकर्ता मिल रहे हैं, और क्या वे वापस आते हैं। (आकस्मिक योगदानकर्ता कम संख्या में कमिट वाले योगदानकर्ता होते हैं। चाहे वह एक कमिट हो, पांच से कम कमिट हो, या कुछ और यह आप पर निर्भर है।) नए योगदानकर्ताओं के बिना, आपके प्रोजेक्ट का समुदाय स्थिर हो सकता है। + +* **खुले मुद्दों और खुले पुल अनुरोधों की संख्या:** यदि ये संख्या बहुत अधिक हो जाती है, तो आपको समस्या परीक्षण और कोड समीक्षा में मदद की आवश्यकता हो सकती है। + +* **_खुले हुए_ मुद्दों और _खुले_पुल अनुरोधों की संख्या:** खुले हुए मुद्दों का मतलब है कि किसी को आपके प्रोजेक्ट की इतनी परवाह है कि वह किसी मुद्दे को खोल सके। यदि वह संख्या समय के साथ बढ़ती है, तो यह दर्शाता है कि लोग आपके प्रोजेक्ट में रुचि रखते हैं। + +* **योगदान के प्रकार:** उदाहरण के लिए, कमिट करना, टाइपो या बग को ठीक करना, या किसी मुद्दे पर टिप्पणी करना। + + + +## अनुरक्षक गतिविधि + +अंत में, आप यह सुनिश्चित करके लूप को बंद करना चाहेंगे कि आपके प्रोजेक्ट के अनुरक्षक प्राप्त योगदान की मात्रा को संभालने में सक्षम हैं। आखिरी सवाल जो आप खुद से पूछना चाहेंगे वह है: _क्या मैं (या हम) अपने समुदाय को जवाब दे रहे हैं?_ + +अनुत्तरदायी अनुरक्षक खुले स्रोत परियोजनाओं के लिए एक बाधा बन जाते हैं। यदि कोई योगदान जमा करता है लेकिन रखरखावकर्ता से कभी जवाब नहीं मिलता है, तो वे निराश महसूस कर सकते हैं और छोड़ सकते हैं। + +[मोज़िला से अनुसंधान](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) सुझाव देता है कि बार-बार योगदान को प्रोत्साहित करने में अनुरक्षक प्रतिक्रिया एक महत्वपूर्ण कारक है। + +विचार करना [यह ट्रैक करना कि आपको (या किसी अन्य अनुरक्षक को) योगदान का जवाब देने में कितना समय लगता है](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), चाहे कोई समस्या हो या पुल अनुरोध। प्रतिक्रिया देने के लिए कार्रवाई की आवश्यकता नहीं है. यह कहने जितना सरल हो सकता है: _"आपके सबमिशन के लिए धन्यवाद! मैं अगले सप्ताह के भीतर इसकी समीक्षा करूंगा।"_ + +आप योगदान प्रक्रिया के चरणों के बीच लगने वाले समय को भी माप सकते हैं, जैसे: + +* किसी अंक के खुले रहने का औसत समय +* क्या मुद्दे पीआर द्वारा बंद कर दिए जाते हैं +* क्या बासी मुद्दे बंद हो जाते हैं +* पुल अनुरोध को मर्ज करने का औसत समय + +## लोगों के बारे में जानने के लिए 📊 का प्रयोग करें + +मेट्रिक्स को समझने से आपको एक सक्रिय, बढ़ता हुआ ओपन सोर्स प्रोजेक्ट बनाने में मदद मिलेगी। भले ही आप डैशबोर्ड पर प्रत्येक मीट्रिक को ट्रैक नहीं करते हैं, फिर भी अपना ध्यान उस प्रकार के व्यवहार पर केंद्रित करने के लिए उपरोक्त ढांचे का उपयोग करें जो आपके प्रोजेक्ट को आगे बढ़ाने में मदद करेगा। + +[CHAOSS](https://chaoss.community/) एक स्वागतयोग्य, खुला स्रोत समुदाय है जो सामुदायिक स्वास्थ्य के लिए एनालिटिक्स, मेट्रिक्स और सॉफ्टवेयर पर केंद्रित है। diff --git a/_articles/hi/security-best-practices-for-your-project.md b/_articles/hi/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..713f36c1bb0 --- /dev/null +++ b/_articles/hi/security-best-practices-for-your-project.md @@ -0,0 +1,158 @@ +--- +lang: hi +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/hi/starting-a-project.md b/_articles/hi/starting-a-project.md new file mode 100644 index 00000000000..fc320784b03 --- /dev/null +++ b/_articles/hi/starting-a-project.md @@ -0,0 +1,356 @@ +--- +lang: hi +title: एक ओपन सोर्स प्रोजेक्ट शुरू करना +description: ओपन सोर्स की दुनिया के बारे में और जानें और अपना खुद का प्रोजेक्ट लॉन्च करने के लिए तैयार हो जाएं। +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## खुले स्रोत का "क्या" और "क्यों"। + +तो क्या आप ओपन सोर्स के साथ शुरुआत करने के बारे में सोच रहे हैं? बधाई हो! दुनिया आपके योगदान की सराहना करती है. आइए बात करें कि ओपन सोर्स क्या है और लोग ऐसा क्यों करते हैं। + +### "ओपन सोर्स" का क्या मतलब है? + +जब कोई प्रोजेक्ट ओपन सोर्स होता है, तो इसका मतलब है कि **कोई भी किसी भी उद्देश्य के लिए आपके प्रोजेक्ट का उपयोग, अध्ययन, संशोधन और वितरण करने के लिए स्वतंत्र है।** ये अनुमतियाँ [एक ओपन सोर्स लाइसेंस](https://opensource.org/licenses) के माध्यम से लागू की जाती हैं। + +खुला स्रोत शक्तिशाली है क्योंकि यह अपनाने और सहयोग की बाधाओं को कम करता है, जिससे लोगों को परियोजनाओं को तेजी से फैलाने और सुधारने की अनुमति मिलती है। इसके अलावा, क्योंकि यह उपयोगकर्ताओं को बंद स्रोत के सापेक्ष, अपने स्वयं के कंप्यूटिंग को नियंत्रित करने की क्षमता देता है। उदाहरण के लिए, ओपन सोर्स सॉफ़्टवेयर का उपयोग करने वाले व्यवसाय के पास किसी बंद स्रोत विक्रेता के उत्पाद निर्णयों पर विशेष रूप से निर्भर रहने के बजाय सॉफ़्टवेयर में कस्टम सुधार करने के लिए किसी को नियुक्त करने का विकल्प होता है। + +_मुफ़्त सॉफ़्टवेयर_ परियोजनाओं के उसी सेट को संदर्भित करता है जो _ओपन सोर्स_ है। कभी-कभी आप [इन शर्तों](https://en.wikipedia.org/wiki/Free_and_open-source_software) को "फ्री और ओपन सोर्स सॉफ्टवेयर" (FOSS) या "फ्री, लिब्रे और ओपन सोर्स सॉफ्टवेयर" के रूप में भी देखेंगे। (दाँत साफ करने का धागा)। _मुक्त_ और _मुक्ति_ का तात्पर्य स्वतंत्रता से है, [कीमत से नहीं](#क्या-ओपन-सोर्स-का-मतलब-निःशुल्क-है)। + +### लोग अपना काम ओपन सोर्स क्यों करते हैं? + + + +[इसके कई कारण हैं](https://ben.balter.com/2015/11/23/why-open-source/) कोई व्यक्ति या संगठन किसी प्रोजेक्ट को ओपन सोर्स क्यों करना चाहेगा। कुछ उदाहरणों में शामिल हैं: + +* **सहयोग:** ओपन सोर्स प्रोजेक्ट दुनिया में किसी से भी बदलाव स्वीकार कर सकते हैं। [व्यायाम](https://github.com/exercism/), उदाहरण के लिए, 350 से अधिक योगदानकर्ताओं वाला एक प्रोग्रामिंग अभ्यास मंच है। + +* **अडॉप्टेशन और रीमिक्सिंग:** ओपन सोर्स प्रोजेक्ट्स का उपयोग कोई भी लगभग किसी भी उद्देश्य के लिए कर सकता है। लोग इसका उपयोग अन्य चीजें बनाने में भी कर सकते हैं। [WordPress](https://github.com/WordPress), उदाहरण के लिए, किसी मौजूदा प्रोजेक्ट के फोर्क के रूप में शुरू किया गया, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md)। + +* **पारदर्शिता:** त्रुटियों या विसंगतियों के लिए कोई भी ओपन सोर्स प्रोजेक्ट का निरीक्षण कर सकता है। पारदर्शिता [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) या [United States](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) जैसी सरकारों, बैंकिंग या स्वास्थ्य देखभाल जैसे विनियमित उद्योगों और [Let's Encrypt](https://github.com/letsencrypt), जैसे सुरक्षा सॉफ़्टवेयर के लिए मायने रखती है। + +ओपन सोर्स सिर्फ सॉफ्टवेयर के लिए ही नहीं है। आप डेटा सेट से लेकर किताबों तक सब कुछ ओपन सोर्स कर सकते हैं। आप और क्या स्रोत खोल सकते हैं, इस बारे में विचारों के लिए [गिटहब एक्सप्लोर](https://github.com/explore) देखें। + +### क्या ओपन सोर्स का मतलब "निःशुल्क" है? + +ओपन सोर्स का सबसे बड़ा आकर्षण यह है कि इसमें पैसा खर्च नहीं होता है। हालाँकि, "निःशुल्क", खुले स्रोत के समग्र मूल्य का एक उपोत्पाद है। + +क्योंकि [एक ओपन सोर्स लाइसेंस के लिए आवश्यक है](https://opensource.org/osd-annotated) कि कोई भी आपके प्रोजेक्ट को लगभग किसी भी उद्देश्य के लिए उपयोग, संशोधित और साझा कर सकता है, प्रोजेक्ट स्वयं निःशुल्क होते हैं। यदि प्रोजेक्ट के उपयोग में पैसे खर्च होते हैं, तो कोई भी कानूनी तौर पर इसकी प्रतिलिपि बना सकता है और इसके बजाय मुफ़्त संस्करण का उपयोग कर सकता है। + +परिणामस्वरूप, अधिकांश ओपन सोर्स प्रोजेक्ट मुफ़्त हैं, लेकिन "निःशुल्क" ओपन सोर्स परिभाषा का हिस्सा नहीं है। ओपन सोर्स की आधिकारिक परिभाषा का अनुपालन करते हुए, दोहरे लाइसेंसिंग या सीमित सुविधाओं के माध्यम से अप्रत्यक्ष रूप से ओपन सोर्स परियोजनाओं के लिए शुल्क लेने के कई तरीके हैं। + +## क्या मुझे अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना चाहिए? + +संक्षिप्त उत्तर हां है, क्योंकि परिणाम चाहे जो भी हो, अपना खुद का प्रोजेक्ट लॉन्च करना यह सीखने का एक शानदार तरीका है कि ओपन सोर्स कैसे काम करता है। + +यदि आपने पहले कभी कोई प्रोजेक्ट ओपन सोर्स नहीं किया है, तो आप इस बात से घबरा सकते हैं कि लोग क्या कहेंगे, या कोई नोटिस करेगा या नहीं। यदि यह आपके जैसा लगता है, तो आप अकेले नहीं हैं! + +ओपन सोर्स कार्य किसी भी अन्य रचनात्मक गतिविधि की तरह है, चाहे वह लेखन हो या पेंटिंग। अपने काम को दुनिया के साथ साझा करना डरावना लग सकता है, लेकिन बेहतर होने का एकमात्र तरीका अभ्यास करना है - भले ही आपके पास दर्शक न हों। + +यदि आप अभी तक आश्वस्त नहीं हैं, तो एक क्षण रुककर सोचें कि आपके लक्ष्य क्या हो सकते हैं। + +### अपने लक्ष्य निर्धारित करना + +लक्ष्य आपको यह पता लगाने में मदद कर सकते हैं कि किस पर काम करना है, किस चीज़ को ना कहना है और आपको कहाँ दूसरों से मदद की ज़रूरत है। अपने आप से यह पूछकर शुरुआत करें, _मैं इस प्रोजेक्ट का ओपन सोर्सिंग क्यों कर रहा हूँ?_ + +इस प्रश्न का कोई भी सही उत्तर नहीं है। आपके पास एक ही प्रोजेक्ट के लिए कई लक्ष्य हो सकते हैं, या अलग-अलग लक्ष्यों वाली अलग-अलग परियोजनाएँ हो सकती हैं। + +यदि आपका एकमात्र लक्ष्य अपना काम दिखाना है, तो हो सकता है कि आप योगदान भी न चाहें, और अपने README में ऐसा कहें भी नहीं। दूसरी ओर, यदि आप योगदानकर्ता चाहते हैं, तो आप स्पष्ट दस्तावेज़ीकरण और नए लोगों का स्वागत महसूस कराने में समय लगाएंगे। + + + +जैसे-जैसे आपका प्रोजेक्ट बढ़ता है, आपके समुदाय को आपसे कोड के अलावा और भी बहुत कुछ की आवश्यकता हो सकती है। मुद्दों पर प्रतिक्रिया देना, कोड की समीक्षा करना और अपने प्रोजेक्ट का प्रचार-प्रसार करना एक ओपन सोर्स प्रोजेक्ट में सभी महत्वपूर्ण कार्य हैं। + +जबकि आप गैर-कोडिंग कार्यों पर कितना समय बिताएंगे, यह आपके प्रोजेक्ट के आकार और दायरे पर निर्भर करेगा, आपको उन्हें स्वयं संबोधित करने या आपकी सहायता के लिए किसी को ढूंढने के लिए एक अनुरक्षक के रूप में तैयार रहना चाहिए। + +**यदि आप किसी प्रोजेक्ट की ओपन सोर्सिंग करने वाली कंपनी का हिस्सा हैं,**सुनिश्चित करें कि आपके प्रोजेक्ट के पास आंतरिक संसाधन हैं जो उसे आगे बढ़ाने के लिए आवश्यक हैं। आप यह पहचानना चाहेंगे कि लॉन्च के बाद प्रोजेक्ट को बनाए रखने के लिए कौन ज़िम्मेदार है, और आप उन कार्यों को अपने समुदाय के साथ कैसे साझा करेंगे। + +यदि आपको परियोजना के प्रचार, संचालन और रखरखाव के लिए समर्पित बजट या स्टाफिंग की आवश्यकता है, तो बातचीत जल्दी शुरू करें। + + + +### अन्य परियोजनाओं में योगदान देना + +यदि आपका लक्ष्य यह सीखना है कि दूसरों के साथ कैसे सहयोग करें या यह समझें कि ओपन सोर्स कैसे काम करता है, तो किसी मौजूदा प्रोजेक्ट में योगदान देने पर विचार करें। उस प्रोजेक्ट से शुरुआत करें जिसे आप पहले से ही उपयोग करते हैं और पसंद करते हैं। किसी प्रोजेक्ट में योगदान देना टाइप की त्रुटियों को ठीक करने या दस्तावेज़ीकरण को अपडेट करने जितना आसान हो सकता है। + +यदि आप निश्चित नहीं हैं कि योगदानकर्ता के रूप में शुरुआत कैसे करें, तो हमारी जाँच करें [ओपन सोर्स गाइड में योगदान कैसे करें](../how-to-contribute/). + +## अपना स्वयं का ओपन सोर्स प्रोजेक्ट लॉन्च करना + +अपने काम का स्रोत खोलने का कोई सही समय नहीं है। आप किसी विचार का स्रोत खोल सकते हैं, कोई कार्य प्रगति पर है, या वर्षों तक बंद स्रोत रहने के बाद। + +आम तौर पर कहें तो, आपको अपने प्रोजेक्ट को तब ओपन सोर्स करना चाहिए जब आप दूसरों को अपने काम को देखने और उस पर फीडबैक देने में सहज महसूस करें। + +इससे कोई फर्क नहीं पड़ता कि आप अपने प्रोजेक्ट को किस चरण में खोलने का निर्णय लेते हैं, प्रत्येक प्रोजेक्ट में निम्नलिखित दस्तावेज़ शामिल होने चाहिए: + +* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Code of conduct](../code-of-conduct/) + +एक अनुरक्षक के रूप में, ये घटक आपको अपेक्षाओं को संप्रेषित करने, योगदान प्रबंधित करने और सभी के कानूनी अधिकारों (आपके अपने अधिकारों सहित) की रक्षा करने में मदद करेंगे। वे आपके सकारात्मक अनुभव प्राप्त करने की संभावनाओं को उल्लेखनीय रूप से बढ़ा देते हैं। + +यदि आपका प्रोजेक्ट GitHub पर है, तो इन फ़ाइलों को अनुशंसित फ़ाइल नामों के साथ अपनी रूट निर्देशिका में डालने से GitHub को उन्हें पहचानने और स्वचालित रूप से आपके पाठकों के सामने लाने में मदद मिलेगी। + +### लाइसेंस चुनना + +एक ओपन सोर्स लाइसेंस यह गारंटी देता है कि अन्य लोग बिना किसी प्रभाव के आपके प्रोजेक्ट का उपयोग, प्रतिलिपि, संशोधन और योगदान कर सकते हैं। यह आपको जटिल कानूनी स्थितियों से भी बचाता है। **ओपन सोर्स प्रोजेक्ट लॉन्च करते समय आपको एक लाइसेंस शामिल करना होगा।** + +क़ानूनी काम कोई मज़ेदार नहीं है. अच्छी खबर यह है कि आप मौजूदा लाइसेंस को कॉपी करके अपने रिपॉजिटरी में पेस्ट कर सकते हैं। आपकी मेहनत की रक्षा करने में केवल एक मिनट लगेगा। + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), और [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) सबसे लोकप्रिय ओपन सोर्स लाइसेंस हैं, लेकिन [अन्य विकल्प भी हैं](https://choosealicense.com). + +जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ओपन सोर्स लाइसेंस शामिल करने से आपका GitHub प्रोजेक्ट ओपन सोर्स बन जाएगा। + +![एक लाइसेंस चुनें](/assets/images/starting-a-project/repository-license-picker.png) + +यदि आपके पास ओपन सोर्स प्रोजेक्ट के प्रबंधन के कानूनी पहलुओं के बारे में अन्य प्रश्न या चिंताएं हैं, [हमने आपका ध्यान रखा है](../legal/). + +### एक रीडमी लिखना + +READMEs आपके प्रोजेक्ट का उपयोग कैसे करें यह समझाने के अलावा और भी बहुत कुछ करते हैं। वे यह भी बताते हैं कि आपका प्रोजेक्ट क्यों मायने रखता है, और आपके उपयोगकर्ता इसके साथ क्या कर सकते हैं। + +अपने README में निम्नलिखित प्रश्नों के उत्तर देने का प्रयास करें: + +* यह प्रोजेक्ट क्या करता है? +* यह प्रोजेक्ट उपयोगी क्यों है? +* मैं कैसे शुरू करूँ? +* यदि मुझे आवश्यकता हो तो मुझे और सहायता कहां से मिल सकती है? + +आप अपने README का उपयोग अन्य प्रश्नों के उत्तर देने के लिए कर सकते हैं, जैसे कि आप योगदान कैसे संभालते हैं, परियोजना के लक्ष्य क्या हैं, और लाइसेंस और एट्रिब्यूशन के बारे में जानकारी। यदि आप योगदान स्वीकार नहीं करना चाहते हैं, या आपका प्रोजेक्ट अभी तक उत्पादन के लिए तैयार नहीं है, तो इस जानकारी को लिख लें। + + + +कभी-कभी, लोग README लिखने से बचते हैं क्योंकि उन्हें लगता है कि परियोजना अधूरी है, या वे योगदान नहीं चाहते हैं। इसे लिखने के ये सभी बहुत अच्छे कारण हैं। + +अधिक प्रेरणा के लिए, @dguo's का ["एक README बनाएं" मार्गदर्शिका](https://www.makeareadme.com/) उपयोग करने का प्रयास करें या @PurpleBooth's [README टेम्पलेट](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) संपूर्ण README लिखने के लिए। + +जब आप रूट डायरेक्टरी में एक README फ़ाइल शामिल करते हैं, तो GitHub स्वचालित रूप से इसे रिपॉजिटरी होमपेज पर प्रदर्शित करेगा। + +### अपने योगदान संबंधी दिशानिर्देश लिखना + +एक योगदान फ़ाइल आपके दर्शकों को बताती है कि आपके प्रोजेक्ट में कैसे भाग लेना है। उदाहरण के लिए, आप निम्न पर जानकारी शामिल कर सकते हैं: + +* बग रिपोर्ट कैसे दर्ज करें ([इश्यू और पुल रिक्वेस्ट टेम्प्लेट्स का उपयोग](https://github.com/blog/2111-issue-and-pull-request-templates)) करने का प्रयास करें। +* नई सुविधा का सुझाव कैसे दें +* अपना वातावरण कैसे स्थापित करें और परीक्षण कैसे चलाएं + +तकनीकी विवरण के अलावा, योगदान फ़ाइल योगदान के लिए आपकी अपेक्षाओं को संप्रेषित करने का एक अवसर है, जैसे: + +* आप जिस प्रकार के योगदान की तलाश कर रहे हैं +* परियोजना के लिए आपका रोडमैप या विज़न +* योगदानकर्ताओं को आपसे कैसे संपर्क करना चाहिए (या नहीं करना चाहिए)। + +गर्मजोशीपूर्ण, मैत्रीपूर्ण लहजे का उपयोग करना और योगदान के लिए विशिष्ट सुझाव देना (जैसे दस्तावेज़ लिखना, या वेबसाइट बनाना) नवागंतुकों को भाग लेने के लिए स्वागत और उत्साहित महसूस कराने में काफी मदद कर सकता है। + +उदाहरण के लिए, [सक्रिय व्यवस्थापक](https://github.com/activeadmin/activeadmin/) प्रारंभ होता है [इसकी योगदान मार्गदर्शिका](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) के साथ: + +> सबसे पहले, सक्रिय व्यवस्थापक में योगदान देने पर विचार करने के लिए धन्यवाद। यह आप जैसे लोग ही हैं जो एक्टिव एडमिन को इतना बढ़िया टूल बनाते हैं। + +आपके प्रोजेक्ट के शुरुआती चरणों में, आपकी CONTRIBUTING फ़ाइल सरल हो सकती है। योगदान देने के लिए आपको हमेशा यह समझाना चाहिए कि बग या फ़ाइल समस्याओं की रिपोर्ट कैसे करें, और कोई तकनीकी आवश्यकताएं (जैसे परीक्षण) कैसे करें। + +समय के साथ, आप अपनी योगदान फ़ाइल में अन्य अक्सर पूछे जाने वाले प्रश्न जोड़ सकते हैं। इस जानकारी को लिखने का मतलब है कि कम लोग आपसे वही प्रश्न बार-बार पूछेंगे। + +अपनी CONTRIBUTING फ़ाइल लिखने में अधिक सहायता के लिए, देखें @nayafia's [contributing गाइड टेम्पलेट](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) या @mozilla's ["CONTRIBUTING.md कैसे बनाएं।"](https://mozillascience.github.io/working-open-workshop/contributing/). + +अपनी CONTRIBUTING फ़ाइल को अपने README से लिंक करें, ताकि अधिक लोग इसे देख सकें। यदि आप [CONTRIBUTING फ़ाइल को अपने प्रोजेक्ट के भंडार में रखते हैं](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), जब कोई योगदानकर्ता कोई समस्या उत्पन्न करता है या पुल अनुरोध खोलता है तो GitHub स्वचालित रूप से आपकी फ़ाइल से लिंक हो जाएगा। + +![योगदान दिशानिर्देश](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### आचार संहिता की स्थापना + + + +अंत में, एक आचार संहिता आपके प्रोजेक्ट के प्रतिभागियों के लिए व्यवहार के लिए बुनियादी नियम निर्धारित करने में मदद करती है। यह विशेष रूप से मूल्यवान है यदि आप किसी समुदाय या कंपनी के लिए एक ओपन सोर्स प्रोजेक्ट लॉन्च कर रहे हैं। आचार संहिता आपको स्वस्थ, रचनात्मक सामुदायिक व्यवहार की सुविधा प्रदान करने का अधिकार देती है, जो एक अनुरक्षक के रूप में आपके तनाव को कम करेगा। + +अधिक जानकारी के लिए, हमारी जाँच करें [आचार संहिता मार्गदर्शिका](../code-of-conduct/). + +यह बताने के अलावा कि आप प्रतिभागियों से कैसे व्यवहार करने की अपेक्षा करते हैं, आचार संहिता यह भी बताती है कि ये अपेक्षाएं किस पर लागू होती हैं, कब लागू होती हैं और उल्लंघन होने पर क्या करना चाहिए। + +ओपन सोर्स लाइसेंस की तरह, आचार संहिता के लिए भी उभरते मानक हैं, इसलिए आपको अपना खुद का लिखने की ज़रूरत नहीं है। [योगदानकर्ता वाचा](https://contributor-covenant.org/) एक ड्रॉप-इन आचार संहिता है जिसका उपयोग [40,000 से अधिक ओपन सोर्स प्रोजेक्ट्स](https://www.contributor-covenant.org/adopters) द्वारा किया जाता है। कुबेरनेट्स, रेल्स और स्विफ्ट सहित। इससे कोई फर्क नहीं पड़ता कि आप किस पाठ का उपयोग करते हैं, आपको आवश्यकता पड़ने पर अपनी आचार संहिता लागू करने के लिए तैयार रहना चाहिए। + +टेक्स्ट को सीधे अपने रिपॉजिटरी में एक Code_OF_CONDUCT फ़ाइल में पेस्ट करें। फ़ाइल को अपने प्रोजेक्ट की रूट डायरेक्टरी में रखें ताकि इसे ढूंढना आसान हो, और इसे अपने README से लिंक करें। + +## अपने प्रोजेक्ट का नामकरण और ब्रांडिंग करना + +ब्रांडिंग एक आकर्षक लोगो या आकर्षक प्रोजेक्ट नाम से कहीं अधिक है। यह इस बारे में है कि आप अपने प्रोजेक्ट के बारे में कैसे बात करते हैं, और आप अपना संदेश किस तक पहुंचाते हैं। + +### सही नाम चुनना + +ऐसा नाम चुनें जो याद रखने में आसान हो और, आदर्श रूप से, प्रोजेक्ट क्या करता है, इसका कुछ अंदाज़ा देता हो। उदाहरण के लिए: + +* [Sentry](https://github.com/getsentry/sentry) क्रैश रिपोर्टिंग के लिए ऐप्स पर नज़र रखता है +* [Thin](https://github.com/macournoyer/thin) एक तेज़ और सरल रूबी वेब सर्वर है + +यदि आप किसी मौजूदा प्रोजेक्ट पर निर्माण कर रहे हैं, तो उपसर्ग के रूप में उनके नाम का उपयोग करने से यह स्पष्ट करने में मदद मिल सकती है कि आपका प्रोजेक्ट क्या करता है (उदाहरण के लिए, [node-fetch](https://github.com/bitinn/node-fetch) window.fetch` को Node.js पर लाता है)। + +स्पष्टता को सर्वोपरि मानें। चुटकुले मजेदार हैं, लेकिन याद रखें कि कुछ चुटकुले अन्य संस्कृतियों या आपसे अलग अनुभव वाले लोगों पर लागू नहीं हो सकते हैं। आपके कुछ संभावित उपयोगकर्ता कंपनी के कर्मचारी हो सकते हैं: जब उन्हें कार्यस्थल पर आपके प्रोजेक्ट के बारे में बताना हो तो आप उन्हें असहज नहीं करना चाहेंगे! + +### नाम टकराव से बचना + +[समान नाम वाले ओपन सोर्स प्रोजेक्ट की जांच करें](http://ivantomic.com/projects/ospnc/), खासकर यदि आप एक ही भाषा या पारिस्थितिकी तंत्र साझा करते हैं। यदि आपका नाम किसी लोकप्रिय मौजूदा प्रोजेक्ट से मेल खाता है, तो आप अपने दर्शकों को भ्रमित कर सकते हैं। + +यदि आप अपने प्रोजेक्ट का प्रतिनिधित्व करने के लिए एक वेबसाइट, ट्विटर हैंडल या अन्य संपत्तियां चाहते हैं, तो सुनिश्चित करें कि आपको अपने इच्छित नाम मिल सकें। आदर्श रूप से, मन की शांति के लिए [अभी उन नामों को आरक्षित करें](https://instantdomainsearch.com/), भले ही आप अभी उनका उपयोग करने का इरादा नहीं रखते हों। + +सुनिश्चित करें कि आपके प्रोजेक्ट का नाम किसी भी ट्रेडमार्क का उल्लंघन नहीं करता है। कोई कंपनी बाद में आपसे अपना प्रोजेक्ट वापस लेने के लिए कह सकती है, या आपके खिलाफ कानूनी कार्रवाई भी कर सकती है। यह जोखिम के लायक ही नहीं है। + +आप ट्रेडमार्क विवादों के लिए [WIPO ग्लोबल ब्रांड डेटाबेस](http://www.wipo.int/branddb/en/) की जांच कर सकते हैं। यदि आप किसी कंपनी में हैं, तो यह उन चीजों में से एक है जिसमें आपकी [कानूनी टीम आपकी मदद कर सकती है।](../legal/) + +अंत में, अपने प्रोजेक्ट के नाम के लिए त्वरित Google खोज करें। क्या लोग आपका प्रोजेक्ट आसानी से ढूंढ पाएंगे? क्या खोज परिणामों में कुछ और दिखाई देता है जो आप नहीं चाहेंगे कि वे देखें? + +### आप कैसे लिखते हैं (और कोड) आपके ब्रांड को भी प्रभावित करता है! + +अपने प्रोजेक्ट के पूरे जीवनकाल में, आप बहुत सारा लेखन करेंगे: रीडमी, ट्यूटोरियल, सामुदायिक दस्तावेज़, मुद्दों पर प्रतिक्रिया देना, शायद न्यूज़लेटर और मेलिंग सूचियाँ भी। + +चाहे वह आधिकारिक दस्तावेज हो या कोई आकस्मिक ईमेल, आपकी लेखन शैली आपके प्रोजेक्ट के ब्रांड का हिस्सा है। इस बात पर विचार करें कि आप अपने दर्शकों के सामने कैसे आ सकते हैं और क्या आप यही लहजा बताना चाहते हैं। + + + +गर्मजोशीपूर्ण, समावेशी भाषा (जैसे कि "उन्हें", यहां तक ​​कि जब एक व्यक्ति का जिक्र हो) का उपयोग करना आपके प्रोजेक्ट को नए योगदानकर्ताओं का स्वागत करने में काफी मदद कर सकता है। सरल भाषा पर कायम रहें, क्योंकि हो सकता है कि आपके कई पाठक मूल अंग्रेजी बोलने वाले न हों। + +शब्दों को लिखने के तरीके के अलावा, आपकी कोडिंग शैली भी आपके प्रोजेक्ट के ब्रांड का हिस्सा बन सकती है। [Angular](https://angular.io/guide/styleguide) और [jQuery](https://contribute.jquery.org/style-guide/js/) कठोर कोडिंग शैलियों और दिशानिर्देशों वाली परियोजनाओं के दो उदाहरण हैं। + +जब आप अभी शुरुआत कर रहे हों तो अपने प्रोजेक्ट के लिए स्टाइल गाइड लिखना आवश्यक नहीं है, और आप पाएंगे कि आप वैसे भी अपने प्रोजेक्ट में विभिन्न कोडिंग शैलियों को शामिल करने का आनंद लेते हैं। लेकिन आपको यह अनुमान लगाना चाहिए कि आपकी लेखन और कोडिंग शैली विभिन्न प्रकार के लोगों को कैसे आकर्षित या हतोत्साहित कर सकती है। आपके प्रोजेक्ट के शुरुआती चरण आपके लिए वह मिसाल कायम करने का अवसर हैं जो आप देखना चाहते हैं। + +## आपकी प्री-लॉन्च चेकलिस्ट + +क्या आप अपना प्रोजेक्ट ओपन सोर्स करने के लिए तैयार हैं? मदद के लिए यहां एक चेकलिस्ट दी गई है। सभी बक्सों की जाँच करें? आप जाने के लिए तैयार हैं! ["प्रकाशित करें" पर क्लिक करें](https://help.github.com/articles/making-a-private-repository-public/) और अपनी पीठ थपथपाएं। + +**दस्तावेज़ीकरण** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Code** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**लोग** + +यदि आप एक व्यक्ति हैं: + +
+ + +
+ +यदि आप एक कंपनी या संगठन हैं: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## तुमने यह किया! + +आपके पहले प्रोजेक्ट की ओपन सोर्सिंग के लिए बधाई। परिणाम चाहे जो भी हो, सार्वजनिक रूप से काम करना समुदाय के लिए एक उपहार है। प्रत्येक प्रतिबद्धता, टिप्पणी और अनुरोध के साथ, आप अपने लिए और दूसरों के लिए सीखने और बढ़ने के अवसर पैदा कर रहे हैं। diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md index 35ad736ae69..97b32ca9e41 100644 --- a/_articles/how-to-contribute.md +++ b/_articles/how-to-contribute.md @@ -1,15 +1,8 @@ --- lang: en title: How to Contribute to Open Source -description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans. +description: Want to contribute to open source? A guide to making open source contributions, for first-timers and veterans. class: contribute -toc: - why-contribute-to-open-source: "Why contribute to open source?" - what-it-means-to-contribute: "What it means to contribute" - orienting-yourself-to-a-new-project: "Orienting yourself to a new project" - finding-a-project-to-contribute-to: "Finding a project to contribute to" - how-to-submit-a-contribution: "How to submit a contribution" - what-happens-after-you-submit-a-contribution: "What happens after you submit a contribution" order: 1 image: /assets/images/cards/contribute.png related: @@ -21,9 +14,9 @@ related: @@ -31,13 +24,17 @@ Contributing to open source can be a rewarding way to learn, teach, and build ex Why do people contribute to open source? Plenty of reasons! +### Improve software you rely on + +Lots of open source contributors start by being users of software they contribute to. When you find a bug in open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it. + ### Improve existing skills Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. ### Meet people who are interested in similar things -Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos. +Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late-night online chats about burritos. ### Find mentors and teach others @@ -51,7 +48,7 @@ By definition, all of your open source work is public, which means you get free Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work. -### It's empowering to be able to make changes, even small ones +### It's empowering to make changes, even small ones You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying. @@ -69,20 +66,12 @@ A common misconception about contributing to open source is that you need to con avatar I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.

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

Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project. - - ### Do you like planning events? * Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) @@ -98,15 +87,15 @@ Even if you like to write code, other types of contributions are a great way to ### Do you like to write? -* Write and improve the project's documentation +* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151) * Curate a folder of examples showing how the project is used -* Start a newsletter for the project, or curate highlights from the mailing list -* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194) -* Write a translation for the project's documentation +* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/) +* Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/) +* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) @@ -389,9 +390,9 @@ Whether you're a one-time contributor or trying to join a community, working wit @@ -403,7 +404,7 @@ Before you open an issue or pull request, or ask a question in chat, keep these > > 😢 _"X is broken! Please fix it."_ -**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn. +**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn. > 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ > @@ -439,11 +440,11 @@ Before you open an issue or pull request, or ask a question in chat, keep these Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. -If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request: +If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following: -* **Issues** are like starting a conversation or discussion -* **Pull requests** are for starting work on a solution -* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one +* **Raising an Issue:** These are like starting a conversation or discussion +* **Pull requests** are for starting work on a solution. +* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution. Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. @@ -475,10 +476,10 @@ Tips for communicating on issues: You should usually open a pull request in the following situations: -* Submit trivial fixes (for example, a typo, a broken link or an obvious error) -* Start work on a contribution that was already asked for, or that you've already discussed, in an issue +* Submit small fixes such as a typo, a broken link or an obvious error. +* Start work on a contribution that was already asked for, or that you've already discussed, in an issue. -A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later. +A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later. If the project is on GitHub, here's how to submit a pull request: @@ -486,43 +487,41 @@ If the project is on GitHub, here's how to submit a pull request: * **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. * **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.") * **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. -* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project. +* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project. * **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. -## What happens after you submit a contribution - -You did it! Congratulations on becoming an open source contributor. We hope it's the first of many. +## What happens after you submit your contribution -After you submit a contribution, one of the following will happen: +Before we start celebrating, one of the following will happen after you submit your contribution: -### 😭 You don't get a response. +### 😭 You don't get a response Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread. -**Don't** reach out to that person privately; remember that public communication is vital to open source projects. +**Don't reach out to that person privately**; remember that public communication is vital to open source projects. -If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. +If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. -### 🚧 Someone requests changes to your contribution. +### 🚧 Someone requests changes to your contribution It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. -When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. +When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). -If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over. +If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). -### 👎 Your contribution doesn't get accepted. +### 👎 Your contribution doesn't get accepted Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! -### 🎉 Your contribution gets accepted. +### 🎉 Your contribution gets accepted Hooray! You've successfully made an open source contribution! -## You did it! +## You did it! 🎉 Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time. diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md new file mode 100644 index 00000000000..c4c9ecd2d31 --- /dev/null +++ b/_articles/hu/best-practices.md @@ -0,0 +1,280 @@ +--- +lang: hu +title: Bevált gyakorlatok karbantartók részére +description: Nyílt forráskódú karbantartóként tedd az életed könnyebbé a folyamatok dokumentálásától kezdve a közösség erejének a kiaknázásáig. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Mit jelent karbantartónak lenni? + +Ha olyan nyílt forráskódú projektet tartasz fenn, amelyet sok ember használ, akkor valószínűleg észrevetted, hogy kevesebbet kódolsz, és többet válaszolsz a problémákra. + +A projekt korai szakaszában új ötletekkel kísérletezel és alapvető döntéseket hozol az alapján, hogy mit szeretnél. Ahogy a projekted népszerűsége növekszik, azon veszed észre magad, hogy egyre többet dolgozol együtt a felhasználókkal és a közreműködőkkel. + +Egy projektet fenntartani többet jelent, mint csak kódolni. Ezek a feladatok gyakran váratlanok, de ugyanolyan fontosak egy fejlődő projektben. Összegyűjtöttünk néhány módszert az életünk megkönnyítésére, a folyamatok dokumentálásától kezdve a közösség erejének a kiaknázásáig. + +## A folyamatok dokumentálása + +A dolgok leírása az egyik legfontosabb dolog, amelyet karbantartóként megtehetsz. + +A dokumentáció nem csak a saját gondolkodásod letisztulását segíti, hanem azt is, hogy más is megértse a szándékodat anélkül, hogy kérdezni kellene. + +A dolgok leírása könnyebbé teszi azt, hogy nemet tudj mondani olyan dolgokra, amelyek nem illeszkednek a projekt hatókörébe. Ezenkívül megkönnyíti az embereknek a belépését és segítését. Sohasem tudhatod, hogy ki olvassa vagy használja a projektet. + +Még ha nem is fejted ki a teljes mondanivalód, akkor is jobb legalább felsoroláspontokban röviden összeszedni azt, mintha nem írnál semmit sem. + +Ne felejtsd el naprakészen tartani a dokumentációt. Ha nem vagy képes ezt mindig megtenni, töröld az elavult dokumentációt, vagy jelezd azt, hogy elavult, így a közreműködők tudják, hogy szívesen várod a frissítéseket ezekre. + +### Írd le a projekt vízióját + +Kezd azzal, hogy leírod a projekt célját. Írd le a README-ben, vagy hozz létre egy különálló VISION fájlt. Ha van bármi más ami segít, mint például egy projekt roadmap, akkor tedd elérhetővé azt is. + +A tiszta, jól dokumentált elképzelés segít fókuszálni és elkerülni azt, hogy más hozzájárulók felesleges vagy oda nem illő dolgokkal járuljanak hozzá. + +Például @lord észrevette, hogy a projekt vízió segített neki abban, hogy eldöntse, hogy melyik kéréssel töltse az idejét. Új karbantartóként sajnálta, hogy nem ragaszkodott a projektjének hatóköréhez, amikor megkapta az első, funkcióra irányuló kérést a [Slate-hez](https://github.com/lord/slate). + + + +### Kommunikáld az elvárásaid + +A szabályok leírása idegesítő lehet. Időnként úgy érzed, mintha más emberek viselkedését szabályoznád, vagy mintha kiölnél minden szórakoztató dolgot a projektből. + +Ugyanakkor megfelelően leírva és jól végrehajtva, a jó szabályok támogatják a karbantartókat. Megakadályozzák, hogy olyan dolgokba menj bele, amelyekbe nem akarsz. + +A legtöbb ember, aki a projekttel találkozik, semmit sem tud rólad vagy a körülményeidről. Feltételezhetik, hogy fizetést kapsz a munkádért, különösen, ha rendszeresen használják, és függnek a projekttől Lehet, hogy egy ideig sok időt töltesz a projekttel, de az is lehet, hogy most egy új munkával, vagy épp a családdal foglalkozol. + +Mindez teljesen rendben van! Csak legyél biztos abban, hogy mások is tudnak erről. + +Ha a projekt fenntartása részmunkaidős vagy tisztán önkéntes, akkor legyél őszinte abban, hogy mennyi időd van rá. Ez nem egyezik meg azzal, hogy szerinted mennyi időt igényelne a projekt, vagy azzal, hogy mennyi időt várnak el mások tőled. + +Néhány szabály, amelyeket érdemes leírni: + +* Hogyan vizsgálod meg és fogadod el a hozzájárulást (_Meg vannak követelve a tesztek? Van az issue-khoz sablon?_) +* A hozzájárulások típusai, amelyeket elfogadsz (_Csak egy bizonyos részéhez fogadsz el hozzájárulást a kódnak?_) +* Mikor helyénvaló ismét figyelmeztetni (_például: "7 napon belül várhatsz választ a karbantartótól. Ha ez alatt még sincs visszajelzés, nyugodtan pingeld meg a szálat."_) +* Mennyi időt fogsz a projektre fordítani (_például: "Csak kb. 5 órát foglalkozunk a hetente ezzel a projekttel."_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), és a [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) mellett számos példa van a karbantartók és közreműködők alapszabályairól rendelkező projektekre. + +### Legyen a kommunikáció nyilvános + +Ne felejtsd el dokumentálni az interakciókat is. Ahol csak lehet, tartsd nyilvánosan a projekttel kapcsolatos kommunikációt. Ha valaki megpróbál privát kapcsolaton keresztül kommunikálni egy funkciókérést vagy támogatási igényt akkor, udvariasan irányítsd egy nyilvános kommunikációs csatornára, például egy levelezőlistára vagy a hibakövető rendszerre. + +Ha személyesen találkozol más karbantartókkal, vagy ha zártkörű döntés születik, akkor is nyilvánosan dokumentáld ezeket a beszélgetéseket, még akkor is, ha csak jegyzeteket írsz. + +Így bárki, aki csatlakozik a közösséghez, ugyanazt az információt éri el, mint az, aki már évek óta tagja a közösségnek. + +## Meg kell tanulni nemet mondani + +Leírtad a dolgokat. Ideális esetben mindenki elolvassa a dokumentációt, de a valóságban ez nem mindig van így, ezért figyelmeztetned kell majd másokat arra, hogy ez a tudás létezik. + +Ha mindent leírsz, az segít megszüntetni azokat a helyzeteket, amikor szükség van a szabályok érvényesítésére. + +Nemet mondani nem kellemes, de a _"Hozzájárulásod nem felel meg a projekt kritériumoknak"_ kevésbé személyeskedő, mint a _"Nem tetszik ez a hozzájárulásod"_. + +Sok helyzetben kell majd nemet mondanod, amelyekkel karbantartóként találkozol: olyan funkciókérések, amelyek nem felelnek meg az alkalmazási körnek, valaki félrevisz egy beszélgetést, amellyel felesleges munkát generál másoknak. + +### Legyen barátságos a beszélgetés + +A legfontosabb helyek, ahol gyakorolni fogod a nemet mondást, azok az issue-k és a beolvasztási kérelmek. Projekt karbantartóként elkerülhetetlen lesz az a helyzet, amikor olyan javaslatokat kapsz, amelyeket nem akarsz elfogadni. + +Lehet, hogy a hozzájárulás megváltoztatja a projekt célját, vagy nem felel meg a jövőképének. Talán az ötlet jó, de a megvalósítás rossz. + +Az indoktól függetlenül lehetséges tapintatosan kezelni azokat a hozzájárulásokat, amelyek nem felelnek meg a projekt normáinak. + +Ha olyan hozzájárulást kapsz, amelyet nem akarsz elfogadni, akkor az első reakciód lehet hogy az, hogy figyelmen kívül hagyod, vagy úgy teszel, mintha nem látnád. Ha így teszel, akkor a másik személy érzéseit megsértheted, vagy akár más, lehetséges hozzájárulók kedvét is elveszed a részvételtől. + + + +Ne hagyj nyitva nem kívánt hozzájárulást, csak azért, mert bűntudatot éreznél attól, hogy lezárod. Az idő múlásával a megválaszolatlan kérdések és a nem kívánt beolvasztási kérelmek sokkal stresszesebbé és elrettentőbbé teszik a projekttel való munkát. + +Sokkal jobb, ha azonnal lezárod a hozzájárulást, ha nem akarod elfogadni. Ha a projekted már eleve nagy feladatlistával rendelkezik, akkor itt van @steveklabnik javaslata arra, hogy [hogyan priorizáld hatékonyan az issue-kat](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +Ugyanakkor a hozzájárulások rendszeres figyelmen kívül hagyása negatív jelet küldhet a közösségnek. A projekthez való hozzájárulás elrettentő is lehet, különösen, ha valaki először próbálja. Még ha nem is fogadod el az általa benyújtott hozzájárulást, becsüld meg azt a személyt aki benyújtotta, és mondj köszönetet az érdeklődése iránt, ez nagy dicséret! + +Ha nem akarsz elfogadni egy hozzájárulást: + +* **Köszönd meg neki** a hozzájárulást +* **Magyarázd el, miért nem illik bele a projekt kritériumokba,** vagy ha lehetséges, javasolj egyértelmű dolgokat a javításra. Legyél határozott, de kedves. +* **Linkeld be a releváns dokumentációkat,** ha vannak. Ha arra leszel figyelmes, hogy rendszeresen kapsz olyan kéréseket, amelyeket nem akarsz elfogadni, akkor add hozzá a dokumentációhoz, ezzel elkerülheted, hogy mindig magadat ismételd. +* **Zárd le a kérést** + +Nem kell több a válaszba mint 1-2 mondat. Például a [celery](https://github.com/celery/celery/) felhasználója jelentett egy Windows-hoz kapcsolódó hibát, erre @berkerpeksag [így válaszolt](https://github.com/celery/celery/issues/3383): + +![Celery screenshot](/assets/images/best-practices/celery.png) + +Ha megijeszt a nemet mondás, ne aggódj, nem vagy egyedül, lásd @jessfraz [írását erről](https://blog.jessfraz.com/post/the-art-of-closing/): + +> Számos, különböző nyílt forráskódú projektekből beszéltem karbantartókkal – Mesos, Kubernetes, Chromium –, és abban mindannyian egyetértettek, hogy a legkeményebb rész a "Nem"-et mondás egy olyan javításra, amelyet nem akarsz. + +Ne érezd bűntudatot azért, mert nem fogadsz el egy hozzájárulást. Az első szabálya a nyílt forráskódnak @shykes [szerint](https://twitter.com/solomonstre/status/715277134978113536): _"A nem az átmeneti, az igen az örökös."_ Bár jó érzés a másik ember lelkesedését látni, a hozzájárulás elutasítása nem jelenti a mögötte álló személy elutasítását. + +Végül, ha a hozzájárulás nem elég jó, akkor nem vagy köteles elfogadni azt. Légy kedves és közreműködő, ha az emberek hozzájárulnak a projekthez, de csak azokat a változásokat fogadd el, amelyektől valóban azt hiszed, hogy a projekt jobbá válik. Minél gyakrabban gyakorolod a nemet mondást, annál könnyebbé válik. + +### Legyél pro-aktív + +A nemkívánatos hozzájárulások mennyiségének csökkentése érdekében mindenekelőtt mutasd be a hozzájárulási útmutatóban a projekt hozzájárulások benyújtásának és elfogadásának folyamatát. + +Ha túl sok gyenge színvonalú hozzájárulást kapsz, kérd meg a közreműködőket, hogy végezzenek el előtte egy kis munkát, például: + +* Töltsék ki a hibához, vagy beolvasztási kérelemhez rendelt űrlapot, vagy ellenőrző listát +* Nyissanak egy issue-t, mielőtt beolvasztási kérelmet adnak fel + +Ha nem követik a szabályokat, akkor azonnal zárd le a jelzést és hivatkozd meg a dokumentációt. + +Noha ez a megközelítés kezdetben kellemetlennek tűnik, a pro-aktív fellépés mindkét fél számára jó. Csökkenti annak az esélyét, hogy valaki sok elpazarolt órát fordítson egy beolvasztási kérelemre, amelyet nem fogsz elfogadni. Emellett a Te munkaterhelésed is könnyebben kezelhetővé válik. + + + +Időnként, amikor nemet mondsz, a potenciális közreműködőt felháboríthatja a döntés vagy kritizálhatja azt. Ha a viselkedése ellenségessé válik, akkor [tegyél lépéseket a helyzet enyhítésére](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) vagy akár el is távolíthatod a közösségből a személyt, ha meg sem próbál konstruktívan együttműködni. + +### Erősítsd a mentorálást + +Lehet, hogy valaki a közösségedben rendszeresen nyújt be olyan hozzájárulásokat, amelyek nem felelnek meg a projekt normáinak. Mindkét fél számára frusztráló lehet az ismételt visszautasítás. + +Ha azt látod, hogy valaki lelkesedik a projekted iránt, de egy kis segítségre van szüksége, légy türelmes. Mindig magyarázd el világosan, hogy miért nem felelnek meg a hozzájárulások a projekt elvárásainak. Próbálj ajánlani egy könnyebb vagy kevésbé bonyolult feladatot, például egy feladatot a _"good first issue"_ jelöléssel, hogy a megtegye az első lépéseket. Ha van időd, akkor fontold meg a mentorálásukat az első hozzájárulásuk alkalmával, vagy keress meg valaki mást a közösségében, aki hajlandó mentorálni őket. + +## Használd ki a közösség erejét + +Nem kell mindent egymagad csinálni. A projekt közösség okkal létezik! Ha még nincs aktív közreműködő közösség, de már sokan vannak benne, akkor is próbáld munkára fogni őket. + +### Oszd el a munkaterhelést + +Ha szeretnél másokat bevonni, akkor kérdezz körbe. + +Az új közreműködők megszerzésének egyik módja az, hogy kifejezetten [olyan issue-kat nevezel meg, amelyek elég egyszerűek a kezdők számára](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). A GitHub segíti ezen issue-k kiemelésén és láthatóvá tételét. + +Amikor azt látod, hogy az új résztvevők rendszeresen hozzájárulnak a projekthez, akkor ismerd el a munkájukat azzal, hogy nagyobb felelősséget adsz számukra. Dokumentáld le, hogy hogyan válhat valaki a projekt irányító tagjává, ha azt szeretné. + +Ösztönözz másokat arra, hogy [részt vegyenek a projekt irányításában](../building-community/#a-projekt-tulajdonjogának-megosztása) ezzel jelentősen csökkented a saját terhelésed, mint ahogy @lmccart észrevette ezt a saját projektjénél, [p5.js](https://github.com/processing/p5.js). + + + +Ha a projektet magára kell hagynod rövid vagy akár hosszabb időre, akkor nincs semmi szégyelleni való abban, ha megkérsz mást, hogy vegye át a helyed. + +Ha mások is lelkesek a projekt irányát illetően, akkor add meg nekik a hozzáférést, vagy formálisan is add át az irányítást. Ha valaki forkolta a projektet, és máshol aktívan fenntartja azt, fontold meg az eredeti projekt csatlakozását ehhez. Nagyszerű, ha sok ember akarja azt, hogy a projekt tovább éljen! + +@progrium [úgy találta](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) hogy a projekt vízió dokumentálása a [Dokku](https://github.com/dokku/dokku) esetén, segített abban, hogy a célok tovább éljenek még akkor is, amikor ő már nem vesz részt a projektben: + +> Egy wiki oldalon leírtam, hogy mit és miért akartam. Valami oknál fogva meglepetésnek számított nekem, hogy a karbantartók elkezdték vinni a projektet ebbe az irányba! Hogy pontosan úgy történt ez, ahogy én csináltam volna? Nem mindig. De mégis közelebb hozta a projektet ahhoz, amit leírtam. + +### Hagyd, hogy mások építsék ki a számukra szükséges megoldásokat + +Ha egy potenciális közreműködő eltérő véleményen van arról, hogy mit kellene a projektben megvalósítani, akkor érdemes udvariasan ösztönözni őt, hogy saját forkon dolgozzon. + +A projekt forkolása (elágaztatása) nem jelent rossz dolgot. A projekt lemásolása és módosítása a legjobb része a nyílt forráskódnak. A közösség tagjainak ösztönzése arra, hogy saját forkon dolgozzanak alkalmas arra, hogy saját kreativitásukat kiélhessék anélkül, hogy ez ütközne a projekted eredeti víziójával. + + + +Ugyanez a megoldás jó akkor is, ha valaki komolyan akarna egy megoldást a projektben valamire, de erre neked már nincs kapacitásod. API-k és testre szabható hook-ok biztosítása lehetővé teszi mások számára, hogy anélkül elégítsék ki a szükségleteiket, hogy a projektet módosítani kellene közvetlenül. @orta [szerint](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) a CocoaPods plugin megjelenése vezetett "néhány nagyon érdekes ötlethez": + +> Szinte elkerülhetetlen, hogy ha egy projekt nagyméretűvé válik, a karbantartóknak sokkal konzervatívabbá kell válniuk az új kódok bevezetése terén. Az rendben van, ha tudod mondani a "nem" szót, de sok embernek van valódi, jogos igénye. Emiatt a megoldást végül platformmá alakítod át. + +## Használj robotokat + +Ahogy vannak olyan feladatok, amelyekben mások segítenek, úgy vannak olyan feladatok is, amelyeket nem embereknek kell csinálnia. A robotok a barátaid. Használd őket, hogy megkönnyítsd az életét karbantartóknak. + +### Szükség van tesztekre és egyéb ellenőrzésekre a kód minőségének javítása érdekében + +A projekt automatizálásának egyik legfontosabb módja a tesztek hozzáadása. + +A tesztek segítenek a közreműködőknek, hogy biztosak legyenek abban, hogy semmit sem rontanak el. Ezenkívül megkönnyítik az észrevételek gyors áttekintését és elfogadását. Minél jobban és gyorsabban reagálsz, annál elkötelezettebbé válhat a közösség. + +Állíts be automatikus teszteket, amelyek az összes bejövő hozzájárulásra futnak, és győződj meg arról, hogy a teszteket a közreműködők könnyen, a saját gépeiken is futtathatják. Mielőtt beküldenék a hozzájárulásokat, követeld meg, hogy az összes kódminőségi követelményt teljesítse, minden teszten átmenjen. Itt egy segítség a minimális minőségi követelmények megkövetelésére: [Kötelező ellenőrzések](https://help.github.com/articles/about-required-status-checks/), a GitHub segít abban, hogy ellenőrzés nélkül a hozzájárulás ne kerüljön beolvasztásra. + +Ha teszteket adsz hozzá, akkor bizonyosodj meg arról, hogy elmagyaráztad azt a CONTRIBUTING.md fájlban, hogy hogyan működnek. + + + +### Használj eszközöket az alapvető karbantartási feladatok automatizálásához + +A jó hír egy népszerű projekt fenntartásához az, hogy más karbantartók valószínűleg hasonló problémákkal már szembesültek és megoldást találtak rá. + +[Számos eszköz elérhető](https://github.com/showcases/tools-for-open-source) amelyek a karbantartók munkájának különböző részeit automatizálják. Néhány példa: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automatizálja a release-elést +* [mention-bot](https://github.com/facebook/mention-bot) a beolvasztási kérelemben megemlíti automatikusan a lehetséges embereket, akik a kódot majd átnézik (kód review) +* [Danger](https://github.com/danger/danger) segít automatizálni a kód review-t +* [no-response](https://github.com/probot/no-response) lezárja azokat az issue-kat, amelyekben az issue szerzője nem válaszolt a további információkérésre +* [dependabot](https://github.com/dependabot) minden nap ellenőrzi a függőségeket, ha talál frissebb verziót, akkor automatikusan beolvasztási kérelmet készít az új verzió számmal + +A hiba jelzésekhez és más általános hozzájárulásokhoz a GitHub biztosít egy [hiba jelzés és beolvasztási kérelem formanyomtatványt](https://github.com/blog/2111-issue-and-pull-request-templates), amellyel egyszerűsíteni és egységesíteni tudod ezek beadását. @TalAter készített egy [Választásos Kalandjátékot](https://www.talater.com/open-source-templates/#/) hogy segítse ezen formanyomtatványok elkészítését. + +Az email értesítések kezeléséhez be tudod állítani az [email szűrőket](https://github.com/blog/2203-email-updates-about-your-own-activity) amellyel a prioritás megadható. + +Ha még jobban akarod csinálni, akkor a stílus útmutatók és linterek segítenek abban, hogy a hozzájárulások könnyebben áttekinthetőbbek és beolvaszthatók legyenek. + +Ellenben, ha a szabályok túl komplikáltak, akkor akadályozzák a hozzájárulást a projekthez. Figyelj arra, hogy annyi szabályt adj hozzá, amely feltétlenül szükséges ahhoz, hogy mindenkinek könnyebb legyen az élete. + +Ha nem vagy biztos abban milyen eszközt kellene használnod, akkor nézz meg más, ismert projekteket, különösen a te ökoszisztémádhoz tartozók közül. Például megnézheted, hogy hogyan néz ki egy hozzájárulási folyamat más Node modulok esetén? Hasonló eszközök és megközelítések alkalmazása segít abban, hogy a folyamatod a hozzájárulók számára már ismert legyen. + +## Teljesen rendben van, ha szünetet tartasz + +Eddig a nyílt forráskódú munka örömet okozott neked, de lehet hogy most már túlterhel téged, ami miatt kerülöd, és emiatt bűntudatod van. + +Lehet, hogy túlterheltnek érzed magad, vagy szorongást okoz, amikor a projektjeidre gondolsz, és mindeközben a hibajelzések és a beolvasztási kérelmek felhalmozódnak. + +A kiégés létező és széles körben ismert probléma a nyílt forráskódú munkákban, különösen a karbantartók körében. Karbantartóként a megelégedettséged megkérdőjelezhetetlen követelmény a nyílt forráskódú projekted fennmaradásához. + +Magától értetődik, hogy szükség van pihenésre! Nem szabad elodázni a pihenést addig, amíg kiégsz. Például @brettcannon, a Python fejlesztője úgy döntött, hogy [egy hónapos vakációt vesz ki](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) 14 éve folyamatosan tartó, önkéntes OSS munka után. + +Mint minden más munka esetén a rendszeres pihenők tartása felfrissít, boldogabbá teszt és fokozza a munkád iránti vágyadat. + + + +Gyakran úgy érzed nehéz pihenőt tartani, mert mindenki téged akar. Vannak akik bűntudatot éreznek, ha pihenni mennek. + +Próbáld kialakítani azt, hogy a legjobb legyen a felhasználóknak és a közösségnek, amikor távol vagy a projekttől. Ha nem találod meg a támogatást ehhez, akkor is tarts szünetet. Határozottan és biztosan kommunikáld azt, amikor nem vagy elérhető, nehogy az emberek összekeverjék azzal, hogy nem szándékosan válaszolsz nekik, vagy nem vagy reszponzív. + +A szünetek nemcsak a vakációk idejére vonatkoznak. Ha nem akarsz hétvégén, vagy munkaidőben nyílt forráskódú munkát végezni, kommunikáld ezt mások felé, így tudni fogják, hogy ne zavarjanak ezen idő alatt téged. + +## Legfontosabb, hogy vigyázz magadra! + +A népszerű projekt fenntartása más készségeket igényel később, mint a projekt elején. Karbantartóként vezetői és személyes készségeket gyakorolsz majd olyan szinten, amelyet kevés ember tapasztal meg. Noha ezt nem mindig könnyű kezelni, az egyértelmű határok meghatározása, és csak olyan dolgok elvégzése ami számodra is elfogadható, segítenek abban, hogy boldog, kipihent és produktív maradj. diff --git a/_articles/hu/building-community.md b/_articles/hu/building-community.md new file mode 100644 index 00000000000..e771c1f5641 --- /dev/null +++ b/_articles/hu/building-community.md @@ -0,0 +1,276 @@ +--- +lang: hu +title: Építs befogadó közösséget +description: Közösség építése, amely bátorítja az embereket a használatra, a részvételre és a projekt hírnevének terjesztésére. +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Sikeres projekt összeállítása + +Elindítottad a projektet, próbálod ismertté tenni, és az emberek érdeklődnek iránta. Fantasztikus! De hogy fogod őket megtartani? + +A befogadó közösség egy befektetés a projekt jövőjébe és megítélésébe. Ha a projekt éppen most kezdi el fogadni az első hozzájárulásokat, akkor kezd azzal, hogy az első közreműködők pozitív tapasztalatokat kapjanak, és könnyítsd meg nekik, hogy rendszeresen visszatérjenek. + +### Érezzék az emberek, hogy szívesen látod őket + +Gondolj a projekt közösségére például úgy, ahogyan @MikeMcQuaid amit ő [résztvevői tölcsérnek](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) nevezett el: + +![Résztvevői tölcsér](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +A közösség felépítése során fontold meg, hogy a tölcsér tetejéről valaki (potenciális felhasználó) hogyan tud eljutni a tölcsér aljára (aktív karbantartó). Cél, hogy minden résztvevő tapasztalatát a projektről javítsd ezeken a szakaszokon. Amikor az emberek könnyen érnek el eredményt, az ösztönözni fogja őket, hogy még többet tegyenek. + +Kezd a dokumentációkkal: + +* **Tedd egyszerűvé, hogy valaki könnyen használhassa a projektedet!** [Egy barátságos README](../starting-a-project/#readme-írása) és tiszta kód példák mindenkit hozzásegítenek ahhoz, hogy könnyen el tudjanak indulni. +* **Tisztán és érthetően magyarázd el, hogy hogyan lehet hozzájárulni**, használd a [CONTRIBUTING fájlodat](../starting-a-project/#részvételi-irányelvek-leírása) és a hibajelzéseket tartsd naprakészen. +* **Good first issues**: Az új hozzájárulókat segíti az, ha egyértelműen [jelezve van címkével az issue, amely kezdőknek ajánlott](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). A GitHub kiemeli ezeket az issue-kat, és ezzel segíti a hasznos hozzájárulásokat úgy, hogy a hozzájáruló szintjének megfelelő hibát ajánl megoldásra. + +[A GitHub 2017. évi nyílt forráskódú felmérése](http://opensourcesurvey.org/2017/) azt mutatta ki, hogy a félkész és zavaros dokumentáció a legnagyobb probléma a felhasználók számára. A jó dokumentáció beszippantja az embereket a projektbe: egyszer csak valaki nyit egy hibajelzést, vagy beküld egy beolvasztási kérelmet. Használd ki ezeket a lehetőségeket, hogy az emberek tovább mozogjanak lefelé a _résztvevői tölcséren_. + +* **Ha valaki újként jelenik meg a projektben, akkor köszönd meg neki az érdeklődését!** Egyetlen egy negatív tapasztalat is elég ahhoz, hogy valaki ne jöjjön vissza többé a projekthez. +* **Legyél reszponzív!** Ha hónapokig nem válaszol a problémájára valakinek, nagy esély van rá, hogy elfelejti a projektedet. +* **Légy nyitott gondolkodású az új hozzájárulások elfogadásakor!** Sok hozzájáruló hibák jelzésével vagy apró javításokkal kezdi. [Számos módja van a hozzájárulásoknak](../how-to-contribute/#mit-jelent-a-hozzájárulás) a projekthez. Hagy segítsenek az emberek úgy, ahogy ők szeretnének. +* **Ha van olyan hozzájárulás, amivel nem értesz egyet,** akkor köszönd meg az ötletet, és [magyarázd el miért](../best-practices/#meg-kell-tanulni-nemet-mondani) nem felel meg a projekt víziónak, és csatold a hivatkozásokat a dokumentációra. + + + +A nyílt forráskódú közreműködők többsége "alkalmi közreműködő": olyan emberek, akik csak alkalmanként járulnak hozzá a projekthez. Előfordulhat, hogy egy alkalmi közreműködőnek nincs ideje teljes mértékben felkészülni a projektre, ezért az a feladatod, hogy megkönnyítsd számukra a hozzájárulást ilyen esetekben is. + +Más közreműködők ösztönzése számodra is hasznos befektetés. Ha támogatod a projekt legnagyobb rajongóit abban, hogy azon dolgozzanak amin szeretnének, akkor kevesebb lesz a nyomás rajtad, hogy mindent te csinálj. + +### Dokumentálj mindent + + + +Amikor új projektet indítasz, először természetesnek tűnhet, hogy a munkádat nem publikálod. De a nyílt forráskódú projektek akkor sikeresek, ha a folyamatait is nyilvánosan dokumentálod. + +Amikor leírod a dolgokat, több ember vehet részt a projekt minden lépésében. Segíthet akár olyan dolgokban is, amelyekre még nem is gondoltad, hogy szükséged van. + +A dolgok leírása nem csupán a műszaki dokumentációt jelent. Bármikor, amikor azt érzed, hogy le kell írni valamit, vagy egy magánbeszélgetést folytattál a projektről, gondolkozz el arról, hogy nyilvánosságra tudod-e hozni azt. + +Legyen átlátható a projekt ütemterve, a várt hozzájárulások típusai, vagy azok áttekintésének módja és akár az is, hogy miért hoztál meg bizonyos döntéseket. + +Ha több felhasználó jelzi ugyanazt a problémát, akkor dokumentáld a válaszokat a README részben. + +Találkozók alkalmával fontold meg a megjegyzések, vagy döntések közzétételét az adott kérdésben. Az ilyen szintű átláthatóság miatt kapott visszajelzések lehet meg fognak majd lepni. + +Mindennek a dokumentálása az te általad végzett munkára is vonatkozik. Ha a projekt lényeges frissítésén dolgozol, akkor add fel beolvasztási kérelemként és jelöld meg folyamatban lévő munkaként (WIP). Ily módon más emberek, már korán bekapcsolódhatnak a folyamatba és így maguknak érzik azt. + +### Legyél reszponzív + +Amint [ismertté próbálod tenni a projektet](../finding-users), az emberek visszajelzéseket fognak küldeni neked. Lesznek kérdéseik a működéséről, vagy épp segítségre lehet szükségük az induláshoz. + +Próbálj azonnal reagálni, ha valaki hibajegyet vagy beolvasztási kérelmet nyújt be, vagy kérdést tesz fel a projekttel kapcsolatban. Ha gyorsan reagálsz, az emberek úgy érzik, hogy részesei a párbeszédnek, és lelkesebben fognak részt venni. + +Még ha a kérelmet nem is tudod azonnal átvizsgálni, a korai befogadás segít növelni az elkötelezettséget. Így válaszolt @tdreyno a [Middleman](https://github.com/middleman/middleman/pull/1466) egyik beolvasztási kérelmére: + +![Middleman beolvasztási kérelem](/assets/images/building-community/middleman_pr.png) + +[Egy Mozilla tanulmány szerint](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) azoknak a válaszadóknak, akik 48 órán belül megkapták a kód review eredményét, sokkal magasabb volt a visszatérési aránya a projekthez, és a hozzájárulásuk ahhoz. + +A projekttel kapcsolatos beszélgetések az internet más részein is zajlanak, például a StackOverflow, a Twitter vagy a Reddit oldalain. Ezen helyek egy részén értesítéseket állíthatsz be, így figyelmeztetést kapsz, ha valaki megemlíti a projektedet. + +### Biztosíts egy helyet a közösségednek + +Két oka is van, hogy miért kell a közösségnek egy állandó helyet biztosítani, ahol összejöhetnek. + +Az első ok ők maguk. Segíts az embereknek megismerni egymást. A közös érdeklődésű emberek szeretnének egy helyet, ahol lehet beszélgetni. És amikor a kommunikáció nyilvános és hozzáférhető, bárki elolvashatja a múltbeli archívumokat, hogy felvegye a ritmust, és hogy részt vegyen a párbeszédben. + +A másik ok te vagy. Ha nem biztosítasz egy nyilvános helyet az embereknek, ahol a projektjéről lehet beszélni, akkor valószínűleg közvetlenül téged keresnek meg. A kezdetben ez könnyűnek tűnhet, hiszen a magánüzenetekre csípőből válaszolunk. De az idő múlásával, különösen, ha a projekt népszerűvé válik, kimerülten fogod magad érezni. Állj ellen annak a kísértésnek, hogy privát módon kommunikálj az emberekkel a projekttel kapcsolatosan. Ehelyett irányítsd őket egy kijelölt, és nyilvános csatornára. + +A nyilvános kommunikáció egyszerű, ha arra kéred az embereket, hogy nyissanak egy hibajegyet, ahelyett, hogy közvetlenül e-mailen küldnének azt, vagy megjegyzést fűznének a blogodhoz. Beállíthatsz egy levelezőlistát, vagy létrehozhatsz egy Twitter fiókot, Slack vagy akár egy IRC csatornát arra, hogy az emberek beszéljenek a projektedről. De akár próbálkozhatsz mindegyikkel! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) minden második héten biztosít időt arra, hogy segítse a közösség tagjait: + +> Kopsnak minden második héten van elkülönített ideje arra, hogy segítséget és útmutatást nyújtson a közösség számára. A Kops fenntartói megállapodtak abban, hogy külön időt fordítanak az újonnan érkezőkkel való együttműködésre, a PR-ekkel kapcsolatos segítségnyújtásra és az új funkciók megvitatására. + +A nyilvános kommunikáció alól kivételt képeznek: a 1) biztonsági kérdések és a 2) magatartási kódex megsértése. Az embereknek mindig képesnek kell lenniük arra, hogy ezeket a kérdéseket privát módon jelentsék be. Ha nem akarod használni a személyes e-mail címed, akkor állíts be egy külön e-mail címet erre a célra. + +## Növeld a közösséget + +A közösség rendkívül erős dolog. Ez a hatalom áldás vagy átok lehet, attól függően, hogy hogyan kezeled. Ahogy a projekt közössége növekszik, vannak olyan módok, amelyek segítenek abban, hogy ez az erő az építés, és ne pusztítás erejévé váljon. + +### Ne tűrd el a helytelen viselkedést + +Bármely népszerű projekt elkerülhetetlenül vonzza azokat az embereket, akik ahelyett, hogy segítséget nyújtanának a közösségnek inkább ártanak neki. Lehet, hogy felesleges vitákat indítanak, felkavaró kritikákat fogalmaznak meg alapvető funkciókról, vagy másokat piszkálnak. + +Tegyél meg mindent, hogy zéró toleranciát tanúsíts az ilyen típusú emberekkel szemben. Ha figyelmen kívül hagyod ezt, akkor a negatív emberek kellemetlenné teszik a közösség többi tagjának részvételét a projektben, akik akár emiatt még távozhatnak is. + + + +A projekt alapvető céljairól folytatott rendszeres vita zavarhat másokat, köztük téged is, és elvonja a figyelmet a fontos feladatokról. A projektbe érkező új emberek láthatják ezeket a beszélgetéseket, és emiatt lehet nem akarnak részt venni majd benne. + +Ha negatív viselkedést látsz a projektben, azt hozd nyilvánosságra. Magyarázd el kedvesen, de határozott hangon, hogy miért nem fogadható el ez a viselkedés. Ha a probléma továbbra is fennáll, akkor lehet, hogy [fel kell kérned az érintettet a távozásra](../code-of-conduct/#a-magatartási-kódex-érvényesítése). A [Magatartási kódexed](../code-of-conduct/) konstruktív útmutatást jelenthet az ilyen jellegű beszélgetésekhez. + +### Maradj kapcsolatban + +A jó dokumentáció akkor válik fontosabbá, ha közösséged növekszik. Az alkalmi közreműködők, akik esetleg egyébként nem ismerik a projektet, azért olvassák el a dokumentációt, hogy gyorsan megértsék azt a környezetet, amire szükségük van. + +A CONTRIBUTING fájljában kifejezetten mond el az új közreműködőknek az elindulás módját. Érdemes lehet erre a célra egy külön fejezetet létrehozni. Például a [Django](https://github.com/django/django) projektnek van egy speciális nyitóoldallal, amelyen az új közreműködőket fogadják. + +![Django új közreműködő oldala](/assets/images/building-community/django_new_contributors.png) + +A hibalistában azon hibákat címkézd meg, amelyek különböző hozzájárulás típusokat igényelnek, például: [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, vagy _"documentation"_. [Ezek a címkék](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) segítik az újonnan érkezőket abban, hogy gyorsan átnézzék a listát és el tudják kezdeni a munkát. + +Végül, de nem utolsó sorban a dokumentáció alapján érezzék az emberek, hogy szívesen látod őket bármely folyamatában a projektnek. + +Általában nem fogsz közvetlenül minden emberrel kommunikálni, aki megfordul a projekten. Lehet, hogy lesznek olyan hozzájárulások, amelyeket azért nem kapsz meg, mert valaki elrettent a projekttől, vagy nem tudta, hogy hol kezdje. Akár néhány kedves szó is elég lehet ahhoz, hogy megakadályozd, hogy valaki csalódottan hagyja el a projektet. + +Itt egy példa, hogy hogyan kezdj a [Rubinius](https://github.com/rubinius/rubinius/) projektben, [a CONTRIBUTING útmutatójuk](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> Mindenekelőtt azzal szeretnénk kezdeni, hogy köszönjük azt, hogy használod a Rubinius-t. Ez a projekt szeretetteljes munkát jelent, és nagyra értékeljük az összes felhasználót, aki hibákat észlel, javít a teljesítményben és segítséget nyújt a dokumentációban. Minden hozzájárulás hasznos, ezért köszönjük a részvételed. Kérjük néhány iránymutatást tarts be, hogy sikeresen meg tudjuk oldani a problémádat. + +### A projekt tulajdonjogának megosztása + + + +Az emberek örömmel járulnak hozzá a projektekhez, ha maguknak érzik azt. Ez nem azt jelenti, hogy át kell szabni a projekt víziódat, vagy el kell fogadni a nem kívánt hozzájárulásokat. De minél többet adsz ebből másoknak, annál jobban magukénak fogják érezni. + +Nézd meg, hogyan találhatod meg a módját, hogy a lehető legnagyobb mértékben megoszd a tulajdont a közösséggel. Íme néhány ötlet: + +* **Állj ellen az egyszerű (nem kritikus) hibák javításának.** Ehelyett használd ezeket a hibákat arra, hogy új segítőket toborozz toborzására, vagy mentorálj valakit, aki szeretne hozzájárulni. Bár furcsának tűnhet, de ez a befektetés idővel megtérül. Például a @michaeljoseph megkérte az egyik közreműködőt, hogy nyújtson be beolvasztási kérelmet egy alábbi, [Cookiecutter] (https://github.com/audreyr/cookiecutter) hibával kapcsolatosan, ahelyett, hogy saját maga javította volna ki. + +![Cookiecutter hiba](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Állíts össze egy CONTRIBUTORS vagy AUTHORS fájlt a projektben,** amely listáz mindenkit aki hozzájárul a projekthez. Például ahogy a [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) csinálja. + +* Ha széles közösséged van, **akkor küldj ki hírlevelet vagy vezess blogot** amelyen megköszönöd a hozzájárulásokat. A Rust-nak a [Heti Rust](https://this-week-in-rust.org/) és a Hoodie-nak a [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) két jó példa erre. + +* **Minden közreműködő kapjon commit jogot.** @felixge szerint az emberek [sokkal aprólékosabban kidolgozzák a hozzájárulásukat](https://felixge.de/2013/03/11/the-pull-request-hack.html), és még több karbantartót lehet bevonni, akik esetleg korábban passzívak voltak. + +* Ha a projekted a GitHub-on van, **akkor mozgasd a projektet át a személyes fiókod alól a [Szervezeti Fiók](https://help.github.com/articles/creating-a-new-organization-account/)** alá és adj hozzá legalább egy admint még biztonság esetére. Az Szervezeti Fiók alkalmasabb külső résztvevők bevonására. + +A valóságban [a legtöbb projektnek](https://peerj.com/preprints/1233/) csak egy, két karbantartója van. Minél nagyobb a projekted, és a közösséged, annál könnyebb segítséget találni. + +Bár nem mindig válaszolnak a felhívásodra, de egy jelzés kiküldése növeli az esélyét, hogy valaki reagál majd rá. És minél előbb megteszed ezt, annál hamarabb segíthetnek az emberek. + + + +## Konfliktusok megoldása + +A projekt korai szakaszában a fontos döntések meghozatala egyszerű. Ha akarsz csinálni valamit, akkor csak megcsinálod. + +Ahogy a projekt népszerűbbé válik, egyre több embert érdekelnek majd az általad meghozott döntések. Még ha nem is rendelkezel nagy közreműködő közösséggel, de a projektnek már sok felhasználója van, akkor találni fogsz olyan embereket, akik a döntéseket mérlegelni fogják, vagy a saját kifogásaikat megfogalmazzák. + +Nagyrészt barátságos és tiszteletteljes közösség esetén és nyíltan dokumentált folyamat esetén találni fogsz megoldást. De néha olyan helyzetbe kerülhetsz, amit kicsit nehezebb lesz megoldani. + +### Viselkedéseddel mutass példát + +Ha a közösség egy nehéz kérdéssel kerül szembe, akkor emelkedetté válhat a hangulat. Az emberek dühösek vagy csalódottak lehetnek, és ezt egymáson vagy épp rajtad vezethetik le. + +Mint karbantartó az a feladatod, hogy ezt a szituációt ne engedd eszkalálódni. Még ha határozott véleményed is van az adott témában, próbáld felvenni a moderátor és az egyeztető szerepet inkább ahelyett, hogy fejest ugranál a csatározásba, és a nézetedet erőltetnéd. Ha valaki barátságtalan, vagy kisajátítja a beszélgetést, akkor [azonnal cselekedj](../building-community/#ne-tűrd-el-a-helytelen-viselkedést), hogy a beszélgetés udvarias és produktív maradjon. + + + +Mások útmutatást kérnek tőled, mutass jó példát. Bátran kifejezheted a csalódottságod, szomorúságod vagy aggodalmadat, de ezt mindig nyugodtan tedd. + +A nyugalom megtartása nem könnyű, de ennek demonstrálása a projekt vezetés által javítja a közösséget. Az internet meg fogja köszönni. + +### A README-t alkotmányként kezeld + +A README fájlod [több mint utasítások összessége](../starting-a-project/#readme-írása). Ez egy olyan hely, ahol beszélhetsz a céljaidról, a termék jövőképéről és az ütemtervről. Ha az emberek túlzottan arra koncentrálnak, hogy megvitatják egy adott funkció értékességét, akkor előfordulhat, hogy át kell értékelned a README-t és még pontosabban kell definiálnod a projekt vízióját. A README szem előtt tartása személytelenebbé teszi a beszélgetést, így az konstruktív maradhat. + +### Az útra figyelj, ne a végcélra + +Egyes projektek szavazási folyamatot használnak a nagyobb döntések meghozatalához. Bár a szavazás első pillantásra ésszerű, a szavazás inkább a "válasz" elérésére helyezi a hangsúlyt, ahelyett, hogy meghallgatná és kezelné a véleményeket. + +A szavazás politikai jellegűvé válhat, amikor a közösség tagjai nyomást gyakorolnak egymásra, hogy egymást előnyben részesítsék, vagy bizonyos módon szavazzanak. Nem mindenki szavaz, függetlenül attól, hogy a [néma többségről](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users), vagy a jelenlegi felhasználókról van szó, akik épp nem tudták, hogy szavazás zajlik. + +Időnként a szavazással történik a szükséges döntéshozás. Mindazonáltal, amennyire képes vagy, hangsúlyozd a ["konszenzus keresését"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) a létrehozott konszenzus helyett. + +Konszenzuskeresési folyamat keretében a közösség tagjai megbeszélik a legfontosabb problémákat, amíg úgy nem érzik, hogy mindenkit meg nem hallgattak. Amikor csak apró észrevételek maradnak már csak, akkor a közösség tovább haladhat. A "konszenzuskeresés" elismeri azt, hogy a közösség nem biztos, hogy képes megtalálni a tökéletes választ. Ehelyett egymás meghallgatását, és a beszélgetést részesíti előnyben. + + + +Ha karbantartóként nem használod a konszenzuskeresési folyamatot, akkor is fontos, hogy az emberek tudják, hogy figyelsz rájuk. Érezzék, hogy meghallgatod őket, és elkötelezed magad a problémáik megoldása mellett, ez a tartós módja annak, hogy elkerüld a komolyabb, kiterjedt problémákat. A szavak után lépj a tettek mezejére. + +Ne siess a döntéssel annak érdekében, hogy megold. Mielőtt állást foglalnál egy kérdésben, győződj meg arról, hogy mindenki úgy érzi-e, hogy meghallgatták és hogy minden információ ezzel kapcsolatban nyilvánosságra került. + +### A cselekvés legyen a fókuszban + +A beszélgetés fontos, de különbség van a produktív és a nem produktív beszélgetések között. + +Támogassa a párbeszédet mindaddig, amíg az a megoldást szolgálja. Ha a párbeszéd egyértelműen tárgytalanná, személyeskedővé válik, vagy félrecsúszik, esetleg az emberek lényegtelen, apró részletekkel kezdenek el foglalkozni, akkor ideje leállítani a megbeszélést. + +Ezen beszélgetések továbbengedése nem csak a jelenlegi probléma kezelésére, hanem a közösség egészségére is káros lehet. Azt üzeni, hogy az ilyen típusú beszélgetések megengedettek vagy akár bátoríthatók, ennek következménye, hogy ez visszatarthatja az embereket a jövőbeli kérdések felvetésétől vagy megoldásától. + +Ha már mások minden észrevételét meghallgattad, akkor kérdezd meg magadtól: _"Hogyan visz ez minket közelebb a megoldáshoz?"_ + +Ha a beszélgetés kezd letisztulni, akkor kérdezd meg a csoportot: _"Mi legyen a következő lépés?"_, ezzel továbbra is fókuszálva tartod a beszélgetést. + +Ha egy beszélgetés nyilvánvalóan nem vezet sehova, vagy nincs egyértelmű intézkedés amit végre kell hajtani, vagy az már meg is megtörtént, akkor zárd le a problémát, és indokold meg, miért zártad le. + + + +### Válassz okosan csatát + +Fontos a környezet. Gondold át, hogy kik vesznek részt a vitában, és hogyan képviselik a közösség többi részét. + +A közösség minden tagja ideges, vagy éppen elragadtatott a kérdéssel kapcsolatban? Vagy egy magányos bajkeverő műve az egész? Ne felejts el figyelni a közösség csendes tagjait, nem csak a hangoskodókat halld meg. + +Ha a téma nem a közösség szélesebb körű igényeit képviseli, akkor el kell fogadni az aggódó hangokat. Ha ez egy rendszeresen visszatérő probléma, egyértelmű megoldás nélkül, akkor mutass rá a témával kapcsolatos korábbi megbeszélésekre, és zárd be a szálat. + +### Keress döntéshozókat a közösségben + +Jó hozzáállással, és egyértelmű kommunikációval a legnehezebb helyzetek is megoldhatók. De még egy eredményes beszélgetés után is eltérhet a vélemény arról, hogy hogyan kell folytatni. Ezekre az esetekre keress egy embert vagy embercsoportot, akik döntéshozóként szolgálnak. + +A döntéshozó lehet a projekt karbantartója, vagy akár egy kis embercsoport, akik szavazás alapján hoznak döntést. Ideális az ha, a döntéshozókat és a kapcsolódó folyamatot egy GOVERNANCE fájlban részletezed. + +A döntéshozódnak az utolsó lehetőségnek kell lennie. A megosztó kérdések a közösség növekedésének és tanulásának a lehetőségét jelentik. Ragadd meg ezeket a lehetőségeket, és használd az együttműködési folyamatot a megoldáshoz, amikor csak lehetséges. + +## A nyílt forráskód ❤️ a közösséget + +Az egészséges, virágzó közösségek heti több ezer órát fordítanak a nyílt forráskódra. Számos résztvevő másokra hivatkozik, hogy miért dolgozik – vagy éppen miért nem dolgozik –, a nyílt forráskódon. Ha megtanulod kreatívan használni a közösség erejét, akkor hozzásegítesz valakit majd ahhoz, hogy felejthetetlen élményeket szerezzen a nyílt forráskódban. diff --git a/_articles/hu/code-of-conduct.md b/_articles/hu/code-of-conduct.md new file mode 100644 index 00000000000..e6418c8bc83 --- /dev/null +++ b/_articles/hu/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: hu +title: Magatartási kódex +description: Az egészséges és konstruktív közösség építéséhez a magatartási kódex elfogadásával és érvényesítésével lehet hozzájárulni. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Miért kell magatartási kódex? + +A magatartási kódex egy olyan dokumentum, amelyben a viselkedéssel kapcsolatos elvárásokat fogalmazzák meg a projekt tagjai számára. A magatartási kódex elfogadásával és betartásával segítheted a közösség egészséges szociális légkörének kialakítását és megtartását. + +A magatartási kódex nem csak a résztvevőket, téged is meg tud védeni. Karbantartóként találkozhatsz olyan lehangoló résztvevőkkel, akik a negatív hozzáállásukkal elkedvetlenítenek és elszívják az energiáidat. + +A magatartási kódex lehetőséget ad arra, hogy az egészséges és konstruktív közösségi viselkedést megtarthasd. A pro-aktív viselkedésed segíthet abban, hogy te vagy a közösség tagjai elfásuljanak a projekteden, és fel tudsz lépni azok ellen, akik a kódex szabályait megsértik. + +## A magatartási kódex létrehozása + +Próbáld létrehozni a magatartási kódexet olyan korán amennyire csak lehet, ideális esetben a projekt indulásakor. + +Az elvárásaid mellett a magatartási kódex az alábbiakat írja még le: + +* Mire érvényes a magatartási kódex? _(csak a hibakövető rendszerre és beolvasztási kérelmekre, vagy más közösségi eseményekre, mint például rendezvények?)_ +* Kikre vonatkozik a magatartási kódex? _(karbantartókra és közösségi tagokra, de vajon vonatkozik-e a szponzorokra?)_ +* Mi történik, ha valaki vét a szabályok ellen? +* Hogyan kell jelenteni, ha szabálysértést tapasztal valaki? + +Lehetőség szerint használj már létező, publikus dokumentumot. A [Contributor Covenant](https://contributor-covenant.org/) egy azonnal használható magatartási kódex, amelyet már több mint 40,000 nyílt forráskódú projekt használ, mint például a Kubernetes, Rails, és a Swift. + +A [Django Code of Conduct](https://www.djangoproject.com/conduct/) és a [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) szintén nagyon jó minták. + +Helyezd el a CODE_OF_CONDUCT állomány a projekt gyökérkönyvtárában, és hivatkozd meg őket a CONTRIBUTING és README állományokból, hogy mindenkinek látható legyen. + +## Dönts arról, hogy fogod betartatni a szabályzatot + + + +Magyarázd el részletesen, hogy a magatartási kódexnek hogyan szerzel érvényt, **mielőtt** még szabályszegés történne. Ez több szempontból előnyös: + +* Megmutatja, hogy komolyan gondolod, hogy szükség esetén cselekszel. + +* A közösség nyugodtabbnak fogja érezni magát, mert a panaszok ténylegesen felülvizsgálatra kerülnek. + +* Meggyőzi a közösséget arról, hogy a felülvizsgálati folyamat tisztességes és átlátható, ha esetleg valakit felelősségre kell vonni a szabálysértés miatt. + +Praktikus biztosítani egy privát csatornát (pl. e-mail cím), amin a magatartási kódex megsértését jelenteni tudják. Add meg azt is, hogy ki vagy kik kapják a jelentést. Ez lehet egy vagy több karbantartó, esetleg egy külön testület. + +Ne feledd, előfordulhat, hogy épp olyan személyre vonatkozóan érkezik kifogás aki szintén kapja a jelentést. Ebben az esetben adj lehetőséget arra, hogy más személy részére jelentsék a szabálysértést. Például, @ctb és @mr-c [kifejtik ezt a projektjükben](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> A zaklató, erőszakos vagy egyéb elfogadhatatlan viselkedést emailben lehet jelenteni **khmer-project@idyll.org** címre, amelyet csak C. Titus Brown és Michael R. Crusoe kap meg. Ha bármelyikük érintett a szabálysértésben, akkor **Judi Brown Clarke, Ph.D.** Sokszínűségért Felelős Igazgató legyen a címzett.* + +További inspirációért nézd meg a Django magatartás kódexét [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (nem biztos hogy, ennyire részletes kódexre van szükséged, ez a projekt méretétől függ). + +## A magatartási kódex érvényesítése + +Annak ellenére, hogy mindent megtettél, néha előfordul, hogy valaki vét a szabályok ellen. Ekkor számos módja van a negatív vagy káros viselkedés kezelésének. + +### Gyűjts információt a helyzetről + +A közösség minden tagjának hangja ugyanolyan fontos, mint a tiéd. Ha olyan jelentést kapsz, hogy valaki megsértette a magatartási kódexet, akkor vedd komolyan és vizsgáld meg az ügyet, még akkor is, ha nem feltételezel ilyet az adott személyről. Ezzel jelzed a közösségnek, hogy értékeled a szempontjaikat és bízol az ítélőképességükben. + +A szóban forgó illető lehet ismétlődő elkövető, aki rendszeresen kényelmetlen helyzetbe hoz másokat, vagy csak egyszer mondott vagy tett valamit. Mindkettő indok lehet a cselekvésre a témától függően. + +Mielőtt válaszolnál, adj magadnak időt, hogy megértsd, mi történt. Olvasd el a személy múltbeli észrevételeit és beszélgetéseit, hogy jobban megértsd, ki ő és miért cselekedett ilyen módon. Próbáld meg más emberek véleményét kikérni az adott emberről és viselkedéséről. + + + +### Tedd meg a megfelelő lépéseket + +A szükséges információk összegyűjtése és feldolgozása után el kell döntened, hogy mit teszel. Miközben megteszed a szükséges lépéseket, ne feledd, hogy a moderátor célja az, hogy biztonságos, tiszteletteljes és együttműködő környezetet teremtsen. Ne csak arra gondolj, hogy hogyan kell kezelni a szóban forgó helyzetet, hanem arra is, hogy a válasz hogyan befolyásolja a közösség további viselkedését és elvárásait. + +Amikor valaki bejelenti a magatartási kódex megsértését, akkor annak kezelése a te feladatod és nem az övé. Néha a bejelentő olyan információkat tár fel, amelyek nagy kockázatot jelenthetnek karrierjük, hírnevük vagy fizikai biztonságuk szempontjából. Ha arra kényszeríted őket, hogy szálljanak szembe a szabálysértővel, azzal kompromittálod őket. A közvetlen kommunikációt neked kell lefolytatnod ebben az ügyben, kivéve, ha a bejelentő mást kér. + +Számos lehetőséged van arra, hogy eljárj a szabálysértőkkel szemben: + +* **Publikusan figyelmeztesd a kérdéses személyt** és magyarázd el, hogy a viselkedése negatívan hatott másokra, lehetőleg azon a csatornán, ahol történt. A nyilvános kommunikáció, ahol lehetséges, azt közvetíti a közösség többi tagja felé, hogy komolyan veszed a magatartási kódexet. Légy kedves, de szilárd a kommunikációban. + +* **Privát módon lépj kapcsolatba a kérdéses személlyel** és magyarázd el, hogy a viselkedése negatívan hatott másokra. Szenzitív információk esetén privát csatornákat használj. Ha valakivel privát levelezést folytatsz, akkor jó ötlet CC mezőben értesíteni a bejelentőt, így értesül róla, hogy megtetted a szükséges lépéseket. Mindenképpen kérd a bejelentő hozzájárulását mielőtt a CC mezőbe teszed. + +Néha a fentiek nem érnek célt. A kérdéses személy agresszív vagy ellenséges lesz és nem változtatja meg a viselkedését. Ebben a helyzetben meg kell fontolnod keményebb intézkedéseket is, mint például: + +* **A kérdéses személyt felfüggeszted** a projekten, átmenetileg megtiltva neki, hogy a projektben bármilyen módon részt vegyen. + +* **A kérdéses személyt véglegesen kizárod** a projektből. + +A felfüggesztés és kizárás súlyos büntetés, és azt mutatja, hogy valaki összeegyeztethetetlen a projekttel és szabályaival. Csak akkor alkalmazd ezeket, ha biztos vagy benne, hogy nem lehet megoldani a problémát. + +## A felelősséged karbantartóként + +A magatartási kódex nem tetszőlegesen betartatott törvény. Te vagy a kódex végrehajtója és a te felelősséged, hogy az abban megállapított szabályok be legyenek tartva. + +Karbantartóként te állapítod meg a közösségére vonatkozó iránymutatásokat, és ezeket neked kell betartatni a magatartási kódexben meghatározott szabályok szerint. Ez azt jelenti, hogy a magatartási kódex bármilyen megsértését komolyan kell venned. A bejelentők felé kötelességgel tartozol a panaszok alapos és tisztességes felülvizsgálatával. Ha úgy ítéled meg, hogy az általuk jelentett magatartás nem sérti a kódexet, azt kommunikáld egyértelműen feléjük és magyarázd meg, miért nem teszel lépéseket. Ezután már rájuk van bízva, hogy a mit tesznek: eltűrik a magatartást, amelyet bejelentettek, vagy abbahagyják a közösségben való részvételt. + +Az olyan viselkedésről szóló jelentés, amely _technikailag_ nem sérti a magatartási kódexet, még mindig jelezheti azt, hogy probléma van a közösségben. Ilyenkor meg kell vizsgálnod ezt, mint lehetséges problémát és szükség esetén cselekedned is kell. Lehet, hogy felül kell vizsgálnod a magatartási kódexet, hogy tisztázódjon, mi az elfogadható viselkedés. Esetleg beszélned kell a viselkedési problémában érintett személyekkel, hogy bár nem sértették meg a szabályokat, nagyon közel álltak hozzá, és ezzel másokat kellemetlen helyzetbe hoztak. + +Végeredményben, karbantartóként te vagy az, aki lefekteti és betartatja az elfogadható viselkedés szabályait. Megvan a lehetőséged, hogy alakítsd a projekt közösségi értékeit és a résztvevők elvárják, hogy ezeket az értékeket tisztességesen és következetesen képviseld. + +## Erősítsd azt a viselkedést amit látni akarsz a világban 🌎 + +Ha egy projekt ellenségesnek vagy nem befogadónak tűnik – akkor is, ha csak egyetlen ember az oka, akinek a viselkedését mások tolerálják –, azt kockáztatod, hogy rengeteg közreműködőt elveszítesz. Ezek között olyanokat is, akikkel akár soha többé nem találkozhatsz. Nem mindig könnyű a magatartási kódex elfogadása vagy érvényesítése, de a barátságos környezet elősegítése segít a közösség növekedésében. diff --git a/_articles/hu/finding-users.md b/_articles/hu/finding-users.md new file mode 100644 index 00000000000..e582fc904e1 --- /dev/null +++ b/_articles/hu/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: hu +title: A projekt felhasználók megtalálása +description: Segítsd a projekted fejlődését azzal, hogy elégedett felhasználókat találsz. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Az ige terjesztése + +Nincs olyan szabály, ami kimondja, hogy egy nyílt forráskódú projektet ismertté kell tenni az induláskor. Számos valós ok lehet arra, hogy olyan nyílt forráskódú munkát végezz, amelynek semmi köze a népszerűséghez. Ahelyett, hogy abban reménykednél, hogy mások majd megtalálják és felhasználják a nyílt forráskódú projektedet, kezdd el megismertetni a világot a kemény munkád eredményével! + +## Fogalmazd meg az üzenetet + +Mielőtt elindítanád a projekted népszerűsítési munkáját, meg kell tudnod fogalmazni, hogy az mit csinál, és miért fontos. + +Mitől más, mint a többi, vagy miért különleges a projekt? Miért hoztad létre? Ha megválaszolod ezeket a kérdéseket, segít kommunikálni a projekt lényegét. + +Ne feledd, hogy az emberek először _felhasználóként_ vesznek részt, majd idővel _résztvevőkké_ válnak, mert a projekt megold számukra egy problémát. Amikor a projekt üzenetéről és értékéről gondolkodsz, próbáld objektíven, a _felhasználók és résztvevők_ szemszögéből nézni ezeket. + +Például, @robb példa programkódokat használt a projektje népszerűsítésére, [Cartography](https://github.com/robb/Cartography), hogy bizonyítsa mennyire hasznos: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +Kicsit mélyebb üzenetért, nézd meg a Mozilla ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) felhasználói személyiség fejlesztéséről szóló útmutatóját. + +## Segítsd az embereket abban, hogy megtalálják és kövessék a projektedet + + + +Segíts az embereknek megjegyezni a projektedet azáltal, hogy egyetlen pontra, helyre irányítod őket. + +**Legyen egyértelmű, hogy hol népszerűsíted a munkád.** Ez lehet Twitter vagy IRC csatorna, vagy GitHub URL, amely könnyen elérhető mindenkinek. Ezek a helyek a projekt növekvő közösségének is helyet biztosítanak. + +Ha még nem szeretnél projekthez köthető kommunikációs csatornákat kiépíteni, akkor a saját Twitter vagy GitHub helyeiden is meg tudod azt tenni. A Twitter vagy GitHub azonosító alapján a felhasználók tudni fogják hogyan érjenek el téged és a projektet. Ha eseményen vagy szakmai találkozókon adsz elő, akkor bizonyosodj meg róla, hogy ezeket a elérhetőségeket feltüntetted az előadásodban. + + + +**Fontold meg webhely létrehozását a projektedhez.** A weboldal barátságosabbá teszi a projektet és könnyebbé teszi a keresést, főleg ha ez áttekinthető dokumentációval és útmutatókkal párosul. Egy weboldal azt sugallja, hogy a projekt aktív, így az emberek bátrabban fogják használni. Mutass példákat arra, hogy a felhasználók hogyan tudják használni a munkádat. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), a Django társalapítója mondta egyszer a weboldalról, hogy _"messze a legjobb dolog volt, amit csinálhattunk a Django indulásakor"_. + +Ha a projekted a GitHub-on van, akkor használhatod a [GitHub Pages](https://pages.github.com/) funkciót arra, hogy a weboldalt könnyedén létrehozd. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), és [Middleman](https://middlemanapp.com/) [és még számos példa](https://github.com/showcases/github-pages-examples) a nagyszerű, áttekinthető weboldalakra. + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +Most, hogy van a projektednek üzenete és van egy könnyű módja annak, hogy az emberek megtalálják a projektedet, vágjunk bele, és beszéljünk az emberekkel. + +## Ott kell lenni, ahol a hallgatóság van (online) + +Az online tájékoztatás nagyszerű módja annak, hogy gyorsan megoszthasd és terjeszd az információt. Az online csatornák használatával lehetőséged van nagyon széles közönség elérésére. + +Használd ki a meglévő online közösségeket és platformokat, hogy elérd a saját közönségedet. Ha a nyílt forráskódú projekted szoftver projekt, akkor közönségedet megtalálhatod a [StackOverflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), vagy [Quora](https://www.quora.com/) oldalakon. Találd meg azokat a csatornákat, ahol olyan emberek vannak, akik a legtöbbet profitálhatnak a munkádból, vagy a leginkább kíváncsiak lehetnek rá. + + + +Nézzük, hogyan lehet megtalálni a lényeges helyeket, ahol megoszthatod a projekted: + +* **Ismerd meg a kapcsolódó nyílt forráskódú projekteket és közösségeket.** Néha nem kell közvetlenül hirdetni a projekted. Ha a projekt tökéletes a Python-t használó adathalmaz kutatók számára, ismerkedj meg a Python adatkutató közösséggel. Amint az emberek megismernek, természetes lehetőség adódik a beszélgetésre és arra, hogy megoszd velük a munkád eredményét. +* **Találd meg azokat az embereket, akiknek a problémájára megoldást kínál a projekted.** Nézd át a kapcsolódó fórumokat, hogy megtaláld azokat az embereket, akik a projekted közönségét alkothatják. Válaszold meg a kérdéseiket és ha lehetséges, tapintatosan ajánld fel a projektedet megoldásként. +* **Kérj visszajelzést.** Mutasd be magadat és a munkádat egy olyan közösségnek, amelyik érdekesnek találhatja azt. Legyél konkrét abban, hogy szerinted kinek hasznos a projekted. Próbáld így befejezni a mondatod: _"Úgy gondolom, hogy a projektem tényleg nagyon hasznos X csoportnak, akik az Y problémát akarják megoldani_". Hallgasd meg és válaszolj mások észrevételére, ne csak bemutató előadás legyen a projektedről. + +Általánosságban: fókuszálj mások megsegítésére mielőtt bármit is kérsz. Mivel bárki képes online egy projektet bemutatni, ezért sok lesz a zaj. Ahhoz, hogy kitűnj a tömegből, az embereknek meg kell érteniük, hogy ki is vagy és nem csak azt, hogy mit akarsz. + +Ha senki sem figyel fel vagy válaszol az első kísérletedre, ne add fel! A legtöbb projekt iteratív folyamat, amely hónapokig vagy akár évekig tart. Ha elsőre nem kapsz visszajelzést, akkor próbálj más taktikát vagy keress olyan lehetőséget, hogy mások munkájához hozzájárulj valami hasznossal. A projekt hírének megalapozása és elindítása időt és kitartást igényel. + +## Ott kell lenni, ahol a hallgatóság van (off-line) + +![Előadás](/assets/images/finding-users/public_speaking.jpg) + +A projektek népszerűsítésének gyakori módja, ha egy off-line eseményen mutatod be őket. Ez nagyszerű módja annak, hogy elérjed az elkötelezett közönséget, és mélyebb emberi kapcsolatokat építs ki különösen, ha érdekelt vagy a fejlesztők elérésében. + +Ha teljesen [új vagy az előadásban](https://speaking.io/), keress egy helyi szakmai találkozót (meetup) amely kapcsolódik a projekted témájához vagy programnyelvéhez. + + + +Ha még soha nem beszéltél egy eseményen, teljesen normális, hogy feszültnek érzed magad. Ne feledd, hogy a közönség azért van ott, mert valóban szeretne hallani a munkádról. + +A beszéd írásakor összpontosíts arra, amit szerinted a közönség érdekesnek talál és mutasd meg az értéket a munkádban. Barátságos, elfogadható nyelvezetet használj. Mosolyogj, lélegezz és érezd jól magad! + + + +Amikor késznek érzed magad, gondolkozz el, hogy hol, milyen konferenciákon tudnád bemutatni a projektedet. A konferenciák segítenek abban, hogy több embert elérj, gyakran a világ minden részéről. + +Keress olyan konferenciát, amely erősen kapcsolódik a te fejlesztési nyelvedhez, ökoszisztémádhoz. Mielőtt az előadásoddal jelentkezel, nézz utána a konferenciának, és szabd kicsit hozzá az előadásodat, ezzel növelve az esélyét, hogy elfogadják az anyagodat. Gyakran a többi előadó alapján is fel tudod mérni, hogy milyen az adott konferencia közönsége. + + + +## Alapozd meg a hírnevet + +A fent vázolt stratégiák mellett a legjobb módja annak, hogy részvételre buzdítsd az embereket a projektedre az, hogy te is részt veszel az ő projektjeikben. + +Új résztvevők segítése, információ megosztása és átgondolt részvétel mások projektjeiben segít, hogy pozitív kép alakuljon ki rólad. Aktív nyílt forráskódú közösségi tagként az emberek felfigyelnek rád és könnyebben befogadják a projektedet. A más projektekkel kialakított kapcsolat akár hivatalos partnerséghez is vezethet. + + + +Soha sincs túl késő vagy túl korán a hírnév építéséhez. Még ha el is indítottad a saját projektedet, folyamatosan keresd a lehetőséget arra, hogy másoknak segíts. + +Nem létezik olyan módszer, amivel hirtelen közönséget és hírnevet tudsz szerezni. A bizalom és tisztelet megszerzéséhez idő kell, és a hírnév építése sohasem érhet véget. + +## Tarts ki! + +Lehet, hogy sokáig fog tartani, mire az emberek felfigyelnek a projektedre, de ezzel nincs semmi probléma! Számos olyan projektnek, amely ma a leghíresebbek között van, évekig tartott, mire elérte a jelenlegi ismertségét és aktivitását. A lényeg a kapcsolatépítésen legyen, ne abban reménykedj, hogy egyszer magától fog növekedni a hírneve. Légy türelmes, és működj együtt azokkal, akik értékelik a munkádat. diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md new file mode 100644 index 00000000000..843a061f5e7 --- /dev/null +++ b/_articles/hu/getting-paid.md @@ -0,0 +1,181 @@ +--- +lang: hu +title: Fizetés a nyílt forráskódú munkaért +description: Tartsd fenn a nyílt forráskódú projektedet azáltal, hogy pénzügyi támogatókat szerzel. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Miért keresünk pénzügyi támogatást? + +A legtöbb nyílt forráskódú munka önkéntes. Például, ha valaki találkozik egy hibával egy projektben amelyet használ, akkor gyors javítást nyújt be, vagy szabadidejében a nyílt forráskódú projektet javítgatja. + + + +Számos oka lehet annak, hogy valaki nem akar fizetést a nyílt forráskódú munkájáért. + +* **Lehet, hogy már főállásban dolgozik, amit szeret,** és ami lehetővé teszi, hogy szabadidejében nyílt forráskódon is dolgozhasson. +* **Hobbiként tekint a nyílt forráskódú fejlesztésre** vagy a kreatív szabadság kiteljesedéseként és nem akarja magát korlátozni. +* **Más előnye származik a nyílt forráskódú munkájából,** például a hírnév vagy portfólió építés, tanulás, vagy a közösségi munka öröme. + + + +Mások számára, különösen, ha a hozzájárulásuk folyamatosak vagy jelentős időre van szükségük, a nyílt forráskódban való munkájuk megfizetése az egyetlen módja annak, hogy részt vehessenek benne, akár a projekt igényei, akár személyes okok miatt. + +A népszerű projektek fenntartása jelentős felelősséggel járhat, havi néhány óra helyett akár heti 10 vagy 20 órát is igénybe vehet. + + + +A fizetett munka az élet különböző területein élő emberek számára is lehetővé teszi, hogy érdemi hozzájárulást nyújtsanak a projekthez. Egyesek nem engedhetik meg maguknak, hogy fizetetlen időt töltsenek a nyílt forráskódú projekteken a jelenlegi pénzügyi helyzetük, adósságuk, családi vagy egyéb gondoskodási kötelezettségeik miatt. Ez azt jelenti, soha nem jutnak el a világba azoknak a tehetséges embereknek a hozzájárulásai, akik nem engedhetik meg maguknak, hogy ingyen dolgozzanak. Ennek etikai következményei vannak, ahogy @ashedryden [írta](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), azoknak akiknek nincs szüksége pénzügyi támogatásra könnyebben végezhetnek nyílt forráskódú munkát, így azzal további előnyöket szerezhetnek, míg aki nem tud pénzügyi okokból ilyen munkát végezni, ezt az előnyt értelemszerűen nem is szerezheti meg, ezzel tovább erősítve a sokszínűség hiányát a nyílt forráskódú közösségben. + + + +Ha pénzügyi támogatást keresel, akkor két irány lehet. Résztvevőként finanszírozhatod a saját idődet vagy találsz egy szervezetet, aki támogatja a projektet. + +## Saját időnk finanszírozása + +Ma sok embernek fizetnek részmunkaidőben vagy teljes munkaidőben nyílt forráskódú munkáért. A leggyakoribb módja annak, hogy fizessenek az idődért az, hogy megbeszéled a saját munkáltatóddal. + +Egyszerűbb elérni ezt, ha az adott nyílt forráskódú projektet a munkaadód is használja. Lehet, hogy a munkaadód nem használja a projektet, de használja a Python-t, és egy népszerű Python projekt fenntartása segíti, hogy új Python fejlesztőket találjon a munkaadód. Ezzel a munkaadód még fejlesztő-barátabbnak tűnik. + +Ha még nincs nyílt forráskódú projekted, amin dolgoznál, de szeretnéd, ha munkád eredménye nyílt forrású lenne, győzd meg a munkaadódat, hogy valamelyik belső projekt forráskódját tegye nyílttá. + +Számos cég fejleszt nyílt forráskódú programokat azért, hogy az imázsukat javítsák és a tehetséges fejlesztőket megszerezzék. + +@hueniverse, például úgy találta, hogy a pénzügyi okok miatt kezdett a [Walmart a nyílt forráskódba fektetni](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). És @jamesgpearce szerint a Facebook nyílt forráskódú programja [változtatott a munkaerő toborzáson](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon): + +> Ez szorosan illeszkedik a fejlesztői kultúránkhoz és a szervezetünk megítéléséhez. Megkérdeztük a kollégáinkat, "Tudtad-e, hogy a Facebooknak vannak nyílt forráskódú projektjei?". Kétharmad válaszolt igennel. A megkérdezettek fele mondta azt, hogy ez jelentősen hozzájárult a döntésükhöz, hogy nálunk dolgozzanak! Ezek nem elhanyagolható számok, és remélem, hogy ez a trend folytatódik. + +Ha a vállalatod ezt az utat választja, fontos, hogy a közösségi és a vállalati tevékenység jól elhatárolódjon. Végső soron a nyílt forráskód fenntartja saját magát a világ minden tájáról érkező emberek hozzájárulásaival, és ez jóval nagyobb, mint bármelyik vállalat vagy hely. + + + +Ha nem tudod meggyőzni a jelenlegi munkáltatót a nyílt forráskódú munka fontosságáról, fontold meg, hogy keresel egy új munkaadót, aki ösztönzi a munkavállalók hozzájárulását a nyílt forráskódhoz. Keress olyan cégeket, amelyek kifejezetten a nyílt forráskódú munkát támogatják. Például: + +* Néhány cégnek, mint a [Netflix](https://netflix.github.io/), külön weboldala van, amin a nyílt forráskódú munkát támogatják + +A nagy cégektől származó projektek, mint a [Go](https://github.com/golang) vagy a [React](https://github.com/facebook/react), szintén nagy valószínűséggel foglalkoztatnak embereket, hogy nyílt forráskódon dolgozzanak. + +A személyes körülményeidtől függően megpróbálhatsz önállóan pénzt gyűjteni a nyílt forráskódú munkád finanszírozásához. Például: + +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) +* @gaearon a [Redux](https://github.com/reactjs/redux) projektet egy [Patreon crowdfunding kampányon](https://redux.js.org/) keresztül finanszírozta (önkéntes támogatás) +* @andrewgodwin a Django schema migrációkat [egy Kickstarter kampányon keresztül](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) finanszírozta. + +Végül, néha a nyílt forráskódú projektek díjakat tűznek ki a hibák megoldására, amelyekkel kapcsolatban akár érdemes lehet segítséget nyújtani. + +* @ConnorChristie fizetséget kapott azért, mert [segített](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol -nak a JavaScript könyvtár fejlesztésében, mindezt a [gitcoin rendszeren keresztül](https://gitcoin.co/). +* @mamiM elvégezte a japán nyelvi fordítást @MetaMask részére, melyet [a Bounties Network-ön keresztül finanszíroztak](https://explorer.bounties.network/bounty/134). + +## Találd meg a projekt finanszírozását + +Az egyéni közreműködőkkel történő megállapodásokon túl, a projektek néha pénzt szereznek vállalatoktól, magánszemélyektől vagy másoktól a folyamatban lévő munka finanszírozásához. + +A szervezeti finanszírozás elkölthető a résztvevők támogatására, a projekt működtetésére (például a tárhely díjakra, hosztingra), illetve új funkciók vagy ötletek megvalósítására. + +Miközben a nyílt forráskód népszerűsége növekszik, a projektek finanszírozásának megtalálása még mindig kísérleti jellegű, de azért van pár elterjedt lehetőség. + +### Szerezz pénzt a munkádhoz közösségi finanszírozási kampányok vagy szponzorálás révén + +Könnyű szponzorokat találni, ha már erős közönséged vagy jó hírneved van, vagy ha nagyon népszerű a projekted. + +Néhány példa: + +* **[webpack](https://github.com/webpack)** magánszemélyektől és cégektől is támogatáshoz jut [az OpenCollective-en keresztül](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** egy non-profit szervezet, amely támogatja a [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), és egyéb Ruby infrastruktúra projekteket + +### Hozz létre bevételi forrást + +A projektedtől függően kérhetsz támogatást szupportért, új funkcióért, vagy szolgáltatásért. Néhány példa: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** kínál fizetős verziót támogatásért cserébe +* **[Travis CI](https://github.com/travis-ci)** kínál fizetős verziót privát használatra +* **[Ghost](https://github.com/TryGhost/Ghost)** alapvetően non-profit, de a felügyelt szolgáltatásért fizetni kell + +Néhány híres projekt, mint az [npm](https://github.com/npm/cli) és a [Docker](https://github.com/docker/docker), még kockázati tőkét is bevontak a növekedés finanszírozásához. + +### Jelentkezz pályázatokra + +Egyes szoftveralapítványok és cégek támogatást nyújtanak a nyílt forráskódú munkákhoz. Előfordul, hogy a támogatásokat magánszemélyek is megkaphatják anélkül, hogy jogi személyt hoznának létre a projekthez. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** támogatást kapott a [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)-tól +* **[OpenMRS](https://github.com/openmrs)** támogatásban részesült a [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) által +* **[Libraries.io](https://github.com/librariesio)** támogatást kapott a [Sloan Foundation](https://sloan.org/programs/digital-technology)-től +* A **[Python Software Foundation](https://www.python.org/psf/grants/)** támogatást kínál a Python-hoz kapcsolódó projekteknek + +Ha érdekelnek a lehetőségek vagy esettanulmányok részletesebben, @nayafia [írt egy útmutatót](https://github.com/nayafia/lemonade-stand), hogy hogyan juthatunk pénzhez a nyílt forráskódú munkával. +A különböző finanszírozási lehetőségek különböző képességeket igényelnek, a választásnál vedd figyelembe az erősségeidet. + +## Pénzügyi támogatás kiépítése + +Függetlenül attól, hogy a projekted új ötlet-e, vagy már évek óta létezik, készülj arra, hogy jelentős figyelmet kell fordítanod a lehetséges támogatók megtalálására és meggyőzésére. + +Akár a saját időd finanszírozására, akár a projekted részére gyűjtesz támogatást, meg kell tudnod válaszolni a következő kérdéseket. + +### Hatás + +Miért olyan hasznos ez a projekt? Miért szeretik a felhasználók vagy a potenciális felhasználók a projektet? Hol fog tartani öt év múlva a projekt? + +### Elfogadottság + +Próbálj meg tényeket gyűjteni arra vonatkozóan, hogy a projekt lényeges, legyenek számok, anekdoták vagy ajánlások. Vannak-e olyan cégek vagy ismert emberek, akik most is használják a projektet? Ha nincs ilyen, akkor van-e olyan prominens személy, aki pozitívan nyilatkozott róla? + +### Érték a támogató részére + +A finanszírozók, akár a munkáltatód, akár egy alapítvány, gyakran a lehetőségek irányából közelítik meg a támogatás kérdését. Miért kellene támogatniuk a projektedet a kihívások ellenére? Hogyan részesülnek a hozadékából, milyen előnyöket jelent számukra a támogatás? + +### A támogatás felhasználása + +Pontosan mit fogsz elérni a javasolt finanszírozással? Az emberek fizetése helyett inkább a projekt mérföldköveire vagy eredményeire összpontosíts. + +### Hogyan kapod meg a támogatást + +A támogatónak vannak kikötései a kifizetéssel kapcsolatosan? Például lehet, hogy non-profit vállalkozásnak kell lenned vagy rendelkezned kell egy non-profit támogatóval. Lehetséges, hogy csak magánszemélyt támogatnak, szervezeteket vagy cégeket nem. Az igények támogatónként eltérhetnek, ezért érdemes ezeket előre felderíteni. + + + +## Kísérletezz és ne add fel + +Pénzügyi támogatást kapni nem könnyű dolog, legyen szó nyílt forráskódról, non-profit szervezetről, vagy szoftver startupról, legtöbb esetben kreatívnak kell lenned. El kell döntened, hogyan szeretnéd a támogatást megkapni, kutatnod kell, és a támogató helyébe kell képzelned magad, hogy meggyőzhesd a támogatásról. + +> diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md new file mode 100644 index 00000000000..479d5712f29 --- /dev/null +++ b/_articles/hu/how-to-contribute.md @@ -0,0 +1,516 @@ +--- +lang: hu +title: Hogyan lehet hozzájárulni a nyílt forráskódhoz +description: Szeretnél hozzájárulni a nyílt forráskódhoz? Ez egy útmutató a nyílt forráskódú fejlesztésekben történő részvételhez kezdők és haladók számára. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Miért vegyél részt a Nyílt Forráskódú fejlesztésben? + + + +A nyílt forráskódhoz való hozzájárulás a tanulás, a tanítás és a tapasztalatok megszerzésének a legjobb útja bármiben, amit csak el tudsz képzelni. + +Miért járulnak hozzá az emberek a nyílt forráskódhoz? Rengeteg oka van! + +### Készségfejlesztés + +Kódolás, felhasználói felület tervezése, grafikai tervezés, írás vagy akár szervezés – ha gyakorlatot keresel, akkor találsz feladatot nyílt forráskódú projekten. + +### Találkozz hasonló érdeklődésű emberekkel + +A nyílt forráskódú projektek befogadó, barátságos közösségek, ahová évek múlva is visszatérnek az emberek. Sokan egy egész életen át tartó barátságot kötnek a nyílt forráskódú részvételük révén, függetlenül attól, hogy konferenciákon vagy késő esti online beszélgetéseken ismerkednek-e meg. + +### Keress mentorokat és taníts másokat + +Közös projekten dolgozni másokkal azt jelenti, hogy el kell magyaráznod, hogy hogyan működnek a dolgok, vagy más embereket kell megkérned, hogy segítsenek. A tanításban és tanulásban minden résztvevő ki tud teljesedni. + +### Növeld a hírnevedet és támogasd a karriered azzal, hogy közzéteszed a munkád + +Alapértelmezés szerint minden nyílt forráskódú munka publikus, amit azt jelenti, hogy bárhol megjelenhetsz a munkáiddal bemutatva azt, hogy mire vagy képes. + +### Emberi készségek fejlesztése + +A nyílt forráskód számos kihívást tartogat a vezetői és szervezői készségek gyakorlásában, úgy mint konfliktus megoldás, csapatszervezés és a feladatok priorizálása. + +### Lehetőséged van változtatni, még ha kicsit is + +Ahhoz, hogy sikerélményed legyen egy nyílt forráskódú projektben, nem kell egy életen át részt venned a munkában. Láttál már valaha egy elgépelést egy weboldalon, és kívántad már azt, hogy valaki bárcsak kijavítaná? Egy nyílt forráskódú projektben éppen ezt tudod megtenni. A nyílt forráskód segít abban, hogy az emberek a saját életüket irányítsák és azt, hogy hogyan alakítsák a világot a maguk örömére. + +## Mit jelent a hozzájárulás? + +Ha új vagy a nyílt forráskódban, akkor a folyamat először félelmetes lehet. Hogyan találd meg a jó projektet? Mi van, ha nem jól kódolsz? Mi történik, ha valami nem működik? + +Ne aggódj! Rengeteg módja van annak, hogy részt vegyél a nyílt forráskódú fejlesztésekben, és számos tipp segít abban, hogy a legtöbbet hozd ki magadból. + +### Nem kell kóddal hozzájárulnod + +Gyakori tévhit a nyílt forráskódhoz való hozzájárulásról, hogy programozni kell hozzá. Valójában gyakran a projekt többi része az, amely [elhanyagolt, vagy mellőzött](https://github.com/blog/2195-the-shape-of-open-source). Óriási segítség a projektnek, ha ilyen jellegű munkával járulsz hozzá! + + + +Még ha szeretsz is programozni, akkor is nagyszerű módja a projektben való részvételnek vagy hogy találkozz közösségi tagokkal az, hogy más jellegű hozzájárulásod van a projekthez. Ezeknek a kapcsolatoknak a kiépítése lehetőséget teremt arra, hogy a projekt egyéb részein dolgozz. + +### Szeretsz rendezvényt szervezni? + +* Szervezz gyakorlati előadásokat vagy találkozókat a projektről, [ahogy @fzamperin csinálja a NodeSchool-nál](https://github.com/nodeschool/organizers/issues/406) +* Szervezd meg a projekttel kapcsolatos konferenciát (ha van ilyen) +* Segíts a közösség tagjainak megtalálni a megfelelő rendezvényeket és írj javaslatokat az előadások témáira + +### Szereted a grafikai tervezést? + +* Alakítsd át a megjelenést, hogy a projekt jobban áttekinthető legyen +* Végezz felhasználói igényfelmérést, hogy javítsd vagy finomítsd a projekt oldal navigációját vagy menürendszerét, [például ahogy a Drupal javasolja](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Állíts össze egy stílus útmutatót ezzel segítve az egységes vizuális megjelenést +* Készíts póló terveket vagy új logót, [ahogy a hapi.js fejlesztői tették](https://github.com/hapijs/contrib/issues/68) + +### Szeretsz írni? + +* Írd és javítsd a projekt dokumentációját +* Tarts karban egy példa könyvtárat a projekt használatáról +* Indíts hírlevelet a projektről, vagy a levelező listáról készít összefoglalót +* Írj útmutatókat a projektről, [ahogy PyPA fejlesztői tették](https://packaging.python.org/) +* Fordíts le a projekt dokumentációját + + + +### Szeretsz szervezni? + +* Kapcsold össze a duplikált hibajegyeket és javasolj más címkéket, hogy jobban szervezett legyen a projekt +* Nézd át a nyitott hibajegyeket és javasold a régiek lezárását, [ahogy @nzakas csinálta az ESLint esetén](https://github.com/eslint/eslint/issues/6765) +* Tegyél fel tisztázandó kérdéseket a közelmúltban megnyitott felvetésekről, problémákról a vita előmozdítása érdekében + +### Szeretsz kódolni? + +* Keress nyitott problémákat, amelyeket megoldhatsz, [mint ahogy @dianjin csinálta a Leaflet esetén](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Kérdezd meg, hogy tudsz-e segíteni valamely új funkció kifejlesztésében +* Automatizáld a projektet +* Fejleszd az eszközöket és a teszteket + +### Szeretsz segíteni embereken? + +* Válaszolj a projekttel kapcsolatos kérdésekre, például a StackOverflow-n, ([mint ez a Postgres példa](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) vagy a Reddit-en +* Válaszold meg a kérdéseket a nyitott problémákról +* Segíts moderálni a beszélgetést a fórumokon vagy egyéb csatornákon + +### Szeretsz másoknak segíteni a kódolásban? + +* Nézd át más emberek kódját, amellyel a projekthez járulnak hozzá +* Írj útmutatót arról, hogyan kell a projektben dolgozni +* Ajánld fel a segítségedet a kódolásban résztvevőnek, légy mentor [mint ahogy @ereichert csinálta @bronzdoc esetén a Rust projektben](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Nem csak szoftver projekten tudsz dolgozni! + +Bár a "nyílt forráskód" gyakran szoftverre utal, bármi másban is részt tudsz venni. Vannak könyvek, receptek, válogatott listák és útmutatók, amelyeket nyílt forráskódú projektként fejlesztenek. + +Például: + +* @sindresorhus karbantart egy [listát a nagyszerű dolgokat listázó oldalakról](https://github.com/sindresorhus/awesome) +* @h5bp kezeli [a listát a lehetséges munkainterjú kérdésekről](https://github.com/h5bp/Front-end-Developer-Interview-Questions) a front-end fejlesztő jelölteknek +* @stuartlynn és @nicole-a-tesla készített egy [gyűjteményt az északi madarak érdekességeiről](https://github.com/stuartlynn/puffin_facts) + +Még ha szoftverfejlesztő is vagy, egy dokumentációs projekt könnyebbé teszi az elindulást a nyílt forráskód világában. Kevésbé ijesztő, ha olyan projektben veszel részt először, ami nem tartalmaz kódot és a másokkal való együttműködés folyamán alakul ki az önbizalmad és nő a tapasztalatod. + +## Kezdetek egy új projektben + + + +Bármi más dolog, mint mondjuk egy elírás javítása olyan, mintha idegenekkel állnál le beszélgetni. Ha elkezdesz a lámákról beszélni, miközben ők elmélyedt párbeszédet folytatnak az aranyhalakról, akkor lehet kicsit furán fognak rád nézni. + +Mielőtt vakon javasolnál valamit, próbálj elmélyedni a témában, hogy megértsd azt. Ha így teszel, nagyobb eséllyel figyelnek oda a véleményedre és javaslataidra. + +### Egy nyílt forráskódú projekt anatómiája + +Minden nyílt forráskódú közösség más. + +Éveket eltölteni ugyanazzal a nyílt forráskódú projekttel azt jelenti, hogy ismersz egy nyílt forráskódú projektet. Egy másik projekt esetén teljesen más fogalmakkal, viselkedési normákkal és kommunikációs módszerekkel találkozhatsz. + +Ugyanakkor számos nyílt forráskódú projekt hasonló módon működik. Az eltérő közösségi szerepek vagy folyamatok megértése segít abban, hogy gyorsan alkalmazkodni tudj bármely új projekthez. + +Egy tipikus nyílt forráskódú projekt esetén az alábbi szerepek vannak: + +* **Szerző:** Személy(ek), esetleg szervezet, aki létrehozta a projektet +* **Tulajdonos:** Személy(ek), akinek adminisztrációs joga van a szervezet vagy a nyílt forrás felett (nem mindig egyezik a Szerzővel a személye) +* **Karbantartók:** Olyan résztvevők, akiknek felelőssége a projekt irányítása, az elképzelések formába öntése. (Ők lehetnek akár a Szerzői vagy a Tulajdonosai is a projektnek.) +* **Közreműködők:** Bárki, aki hozzájárul valamivel a projekthez. +* **Közösség tagjai:** Emberek, akik használják a projektet. Aktívak lehetnek a vitákban, vagy jelezhetik észrevételeiket a projekttel kapcsolatban. + +A nagyobb projekteknek lehetnek olyan albizottságai vagy munkacsoportjai is, amelyek különböző feladatokra összpontosítanak, mint például eszközök, prioritás, közösségi moderálás és rendezvényszervezés. Ezt az információt megtalálod a projekt honlapján a "csapat" oldalon, vagy a működési szabályok dokumentációi között. + +A projektnek dokumentációja is van. Ezek a fájlok általában a forráskód legfelső szintjén vannak felsorolva. + +* **LICENSE:** Alapértelmezés szerint minden nyílt forráskódú projektnek kell rendelkeznie egy [nyílt forráskód licenccel](https://choosealicense.com). Ha a projektnek nincs ilyen licence, akkor az nem nyílt forráskód. +* **README:** A README egy használati útmutató a közösség új tagjainak. Elmagyarázza, hogy miért hasznos a projekt és hogy hogyan lehet használni. +* **CONTRIBUTING:** Míg a README segíti az embereket a _használatban_, addig a CONTRIBUTING a projektben való _részvétel_ módját dokumentálja. Elmagyarázza, hogy mivel járulhatsz hozzá a projekthez és hogyan működnek a folyamatok. Bár nem minden projektnek van ilyen dokumentációja, a jelenléte azt mutatja, hogy számítanak a részvételedre és a hozzájárulásodra. +* **CODE_OF_CONDUCT:** Magatartási kódex, amely meghatározza a résztvevők magatartásának alapszabályait és elősegíti a barátságos környezet kialakítását. Bár nem minden projektnek van ilyen dokumentációja, a jelenléte azt mutatja, hogy barátságos projekt, amely számít a részvételedre. +* **Egyéb dokumentációk:** Lehetnek további dokumentációk, különösen nagyobb projektek esetén, mint például oktató anyagok, fejlesztési útmutatók, irányítási szabályok. + +A nyílt forráskódú projektek az alábbi eszközöket használják az egyeztetések szervezéséhez. A korábbi anyagok elolvasása jó képet ad arról, hogyan gondolkodik és működik a közösség. + +* **Issue tracker:** A résztvevők ennek segítségével beszélik meg a projekttel kapcsolatos problémákat. +* **Pull requests:** A résztvevők ezek segítségével vitatják meg és tekintik át a folyamatban lévő változtatásokat. +* **Internetes fórumok vagy levelező listák:** Néhány projekt használhatja ezen csatornákat is a különböző témák átbeszélésére (például, _"Hogyan tudom...?"_ vagy _"Mit gondolsz arról, hogy...?"_ című témát indít a _hiba jelentés,_ vagy _új funkció létrehozása_ helyett). Mások minden beszélgetést az _Issue tracker_-en keresztül kezelnek. +* **Csevegő csatorna:** Néhány projekt azonnali üzenetküldő (IM) csevegő csatornákat használ (mint amilyen a Slack vagy az IRC) általános beszélgetésre, együttműködésre és gyors üzenet váltásra. + +## Találd meg a projektedet! + +Most, hogy már tudod, hogy hogyan működnek a nyílt forráskódú projektek, itt az idő megtalálni azt, amelyben részt veszel! + +Ha még sohasem vettél részt nyílt forráskódú fejlesztésben korábban, akkor fogadd meg John F. Kennedy volt amerikai elnök egyik tanácsát: _"Ne azt kérdezd, hogy az ország mit tud tenni érted – kérdezd azt, hogy te mit tehetsz az országért."_ + +Hozzájárulás egy nyílt forráskódú projekthez bárhogy lehetséges, bármelyik projektben. Nem kell túlgondolni azt, hogy pontosan mi lesz az első hozzájárulásod, vagy azt, hogy az hogyan fog kinézni. + +Gondolkozz olyan projektben, amelyet már használsz, vagy használni akarsz. Azokat a projekteket, amelyekben aktívan részt veszel, szívesebben használni fogod a jövőben is. + +Ezekben a projektekben, amikor azon kapod magad, hogy gondolkozol egy jobb vagy más megoldásban, cselekedj ösztönösen! + +A nyílt forráskód nem egy zártkörű klub; ugyanolyan emberek dolgoznak rajta, mint te. A "Nyílt Forráskód" csak egy divatos kifejezés arra, hogy a világ problémáit megoldhatóként is lehet kezelni. + +Talán épp a README-t olvasod és találsz egy rossz hivatkozást, vagy egy elírást. De az is lehet, hogy új felhasználó vagy és észreveszel valami hibát, vagy egy problémát, amit dokumentálni kellene. Ahelyett, hogy nem törődsz vele és továbblépsz vagy megkérsz valakit, hogy javítsa, inkább ajánld fel a segítséged. Ez az amiről a nyílt forráskód szól! + +> [a nyílt forráskódú alkalmi hozzájárulások 28%-a](https://www.igor.pro.br/publica/papers/saner2016.pdf) a dokumentációt érinti, mint például egy elírás javítása, formázás, vagy fordítás. + +Ha szeretnél egy hibát javítani, akkor minden nyílt forráskódú projekt esetén találsz egy `/contribute` oldalt, amely segít abban, hogy kezdőként kijavítsd az első hibát. A projekt GitHub kezdőoldal URL-jét egészítsd ki a `/contribute` résszel a végén, (például [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +Az alábbiakban találsz néhány oldalt, amelyek segítenek abban, hogy felfedezd és megtaláld az új projektedet: + +* [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/) + +### Egy ellenőrző lista, mielőtt részt vennél a projektben + +Ha találtál egy projektet, amelyhez hozzájárulnál, végezz előtte egy gyors ellenőrzést. Bizonyosodj meg arról, hogy alkalmas-e a külső hozzájárulások fogadására. Máskülönben előfordulhat, hogy a kemény munkádnak nem lesz eredménye. + +Itt egy lista, aminek segítségével kiértékelheted, hogy a projekt alkalmas-e egy új résztvevőnek. + +**Megfelel a nyílt forráskód definíciójának** + +
+ + +
+ +**A projekt aktívan fogadja a hozzájárulásokat** + +Nézd meg a közösség aktivitását a _master_ ágon. A GitHub-on ezeket az információkat a projekt főoldalán eléred. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Nézd meg a projekt hibakezelőjét. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Most csináljuk meg ugyanezt a projekt kódbeolvasztási kéréseire (_pull request_). + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Barátságos projekt** + +Egy barátságos és befogadó projekt azt jelzi, hogy az új résztvevőket szívesen várják. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## Hogyan kell hozzájárulni? + +Végül megtaláltad a projekted és készen állsz a részvételre! Nézzük, hogyan tudsz valóban jól hozzájárulni! + +### Hatékony kommunikáció + +Akár csak egyszeri résztvevő vagy, vagy csatlakoznál a közösséghez, a másokkal való együttműködés az egyik legfontosabb képesség, amit a nyílt forráskódú munkád során fejleszteni tudsz. + + + +Mielőtt hibát jelzel, beolvasztást kérelmezel vagy esetleg kérdéseket teszel fel a csevegésben, tartsd szem előtt ezeket a pontokat a hatékonyabb munka érdekében. + +**Add meg a téma leírását!** Ezzel segítesz másoknak, hogy gyorsan felvegyék a téma fonalát. Ha belefutsz egy hibába, akkor magyarázd el részletesen hogyan idézted azt elő, és hogy hogyan lehet reprodukálni. Ha új ötlettel állsz elő, magyarázd el, hogy miért gondolod úgy, hogy az hasznos lesz a projektnek (és nem csak neked)? + +> 😇 _"X nem történik, ha azt csinálom, hogy Y"_ +> +> 😢 _"X hibás! Kérlek, javítsátok!"_ + +**Először végezd el a házi feladatot!** Teljesen rendben van ha nem értesz dolgokhoz, de mutasd meg azt, hogy megpróbáltad! Mielőtt segítséget kérsz, győződj meg róla, hogy átnézted a projekt README-jét, dokumentációját, nyitott és lezárt hibajelzéseit, a levelező listát és keress rá a problémára az interneten. Az emberek értékelni fogják, ha látják, hogy próbálsz tanulni. + +> 😇 _"Nem vagyok benne biztos, hogy hogyan oldjam meg az X dolgot. Átnéztem az útmutatókat, de nem találtam erről említést."_ +> +> 😢 _"Hogyan csináljam meg az X dolgot?"_ + +**Légy tömör és egyértelmű!** Hasonlóan az email küldéséhez, minden hozzájárulás esetén szükséges az – függetlenül attól, hogy mennyire egyszerű vagy mennyit segít –, hogy más is átnézze. Számos projektnek több beérkező módosítási igénye van, mint ahányan dolgoznak rajta. Ezért az észrevételeid legyenek tömörek és egyértelműek, így nagyobb eséllyel kapsz segítséget. + +> 😇 _"Szeretnék írni egy API útmutatót."_ +> +> 😢 _"Épp vezettem az autópálya lehajtón egy nap és megálltam tankolni, és ekkor egy hatalmas ötlet jutott az eszembe, amit meg kellene csinálnunk, de mielőtt elmagyaráznám, hadd meséljek a ..."_ + +**Legyen nyilvános a kommunikációd!** Bár csábító, de a karbantartókat ne privát csatornákon keresd; kivéve, ha érzékeny információt (biztonsági incidens, komoly viselkedési szabályok megsértése) kell megosztanod. Ha a kommunikáció publikus, akkor több ember tud tanulni belőle, mindenkinek hasznára válik. A publikus megbeszélések már önmagukban is hozzájárulások a projekthez. + +> 😇 _(megjegyzésként:) "@-karbantartó Szia! Mi legyen ennek a Pull Request-nek a sorsa?"_ +> +> 😢 _(emailként:) "Szia! Sajnálom, hogy a levelemmel zavarlak, de kíváncsi lennék rá, hogy van-e esély a Pull Requestem beolvasztására?"_ + +**Rendben van, hogy kérdezel, de legyél türelmes!** Mindenki volt kezdő az adott projekten, még a gyakorlott résztvevőknek is fel kell venni a tempót egy új projekt esetén. Ugyanígy, még a régebbi karbantartók sem mindig ismerik a projekt minden részét. Légy velük olyan türelmes, mint amilyet te is elvárnál tőlük. + +> 😇 _"Köszönöm, hogy megnézted ezt a hibát. Követtem az utasításaidat, itt a végeredménye:"_ +> +> 😢 _"Miért nem javítod a jelzett problémámat? Ez nem a te projekted?"_ + +**Tartsd tiszteletben a közösség döntéseit!** Az ötleteid eltérhetnek a közösség céljaitól vagy jövőképétől. Ötleteidre kaphatsz visszajelzést, vagy akár el is utasíthatják azt. Míg lényeges, hogy egyeztess és keresd a kompromisszumot, tartsd észben, hogy a karbantartóknak a hosszabb távon kell a te döntéseddel együtt élni, mint neked. Ha nem értesz egyet az iránnyal, bármikor létrehozhatod a saját elágazásodat (_fork_) a kódból, vagy akár kezdhetsz egy új projektet. + +> 😇 _"Bár szomorú vagyok, hogy nem támogatjátok az ötletemet, de ahogy elmagyaráztátok, megértettem azt, hogy ez az eset csak kevés embert érint. Köszönöm, hogy meghallgattatok!"_ +> +> 😢 _"Miért nem támogatjátok az ötletem? Ez elfogadhatatlan!"_ + +**Mindenekelőtt: ne légy ízléstelen!** A nyílt forráskódon együttműködők a világ számos részéről származnak. A kontextus gyakran elveszik a nyelvi-, kulturális-, földrajzi- és időzóna különbségek miatt. Ráadásul az írott kommunikáció megnehezíti a hangulat vagy a hozzászólás érzelmi részének közvetítését. Tételezz fel jó szándékot a beszélgetésekben. Teljesen elfogadható, ha udvariasan visszautasítasz egy ötletet, vagy megkérsz valakit, hogy adjon további információt a problémáiról. Próbáld az Internetet tisztábban ott hagyni, mint ahogy találtad. + +### Összefoglalás + +Mielőtt bármibe belekezdenél, győződjön meg róla, hogy az ötletedet nem vitatták-e már meg máshol. Nézd meg a projekt README-jét, a nyitott és lezárt hibajegyeket és kérdéseket, a levelezőlistát és a StackOverflow-t. Nem kell órákat töltened azzal, hogy átnézz mindent, de egy gyors keresés néhány kulcsszóra nem tart semeddig. + +Ha nem találod meg a felvetést sehol, akkor mehetsz tovább. Ha a projekt a GitHub-on van, akkor nyithatsz egy hibajegyet vagy létrehozhatsz egy beolvasztási kérést a módosított kód alapján: + +* **Issues** (hiba, észrevétel) olyanok mint egy párbeszéd, vagy egy megbeszélés +* **Pull requests** (beolvasztási kérelem) szolgál a munka megkezdésére +* **Egyszerű kommunikációra,** például tisztázó- vagy a "Hogyan..." kérdésekre használd a StackOverflow-t, IRC-t, Slack-et vagy egyéb rendelkezésre álló csevegő csatornát, ha van ilyen a projektben + +Mielőtt hibajegyet, észrevételt vennél fel, vagy egy beolvasztási kérelmet benyújtanál, ellenőrizd a projektben való részvételről szóló dokumentációt (ezt gyakran a CONTRIBUTING vagy a README tartalmazza), mert lehetséges, hogy mellékelned kell valamilyen specifikus információt is. Például, a projekt kérheti azt, hogy egy űrlapot tölts ki, vagy megkövetelheti a teszteket. + +Ha jelentősebb munkával akarsz részt venni, akkor nyiss egy probléma felvetést tartalmazó jegyet, ahol a kérdéseket meg lehet vitatni, mielőtt még nekikezdenél. Hasznos, ha egy darabig csak nyomon követed a projektet és a közösséget (a GitHub-on, [klikkents a "Watch" linkre](https://help.github.com/articles/watching-repositories/) hogy értesítést kapj az összes beszélgetésről), hogy megismerd a tagjait, mielőtt olyan munkát végeznél benne, amit nem fogadnak el. + + + +### Hibajegy nyitása + +Általában a következő helyzetekben kell hibajegyet (_Issue_) nyitni: + +* Hiba jelentése, amelyet nem tudsz megoldani egymagad +* Magas szintű probléma vagy téma, esetleg ötlet megbeszélése (például: közösség, vízió vagy szabályok) +* Új funkció javasolása, vagy más projekt célok, ötletek + +Tippek a jó párbeszédhez: + +* **Ha nyitsz egy hibajegyet, amit meg szeretnél oldani,** kommenteld azt, így más is tudja, hogy foglalkozol vele. Így mások nem dolgoznak ugyanezen feleslegesen. +* **Ha a hibajegy már régóta nyitott,** akkor lehetséges, hogy már máshol foglalkoznak vele, vagy már meg van oldva, így célszerű egy kommentben megkérdezni az állapotát, mielőtt elkezdesz rajta dolgozni. +* **Ha nyitottál egy hibajegyet és később magadtól rájöttél a megoldásra,** akkor kommentezz, hogy más is megismerje azt, majd zárd le a hibajegyet. Az eredmény dokumentálása is nagyon fontos a projektnek. + +### Beolvasztási kérelem megnyitása + +Általában a következő esetekben szükséges beolvasztási kérelmet nyitni: + +* Triviális javítások küldése (például egy gépelési hiba, hibás link vagy nyilvánvaló hiba) +* Olyan feladaton történő munka elkezdése, amelyet már a közösség kitárgyalt, átbeszélt és tisztáztad a kérdéseket + +A beolvasztási kérelem nem feltétlen jelent befejezett munkát. Gyakran jobb korán megnyitni ezt, így mások megfigyelhetik és visszajelzéseket adhatnak róla. Csak jelöld meg "WIP" (Work in Progress) jelzéssel a tárgy soron. Ezek után bármikor, szabadon adhatsz hozzá új kódot (commit és push). + +Ha a projekt a GitHub-on van, akkor a következőképpen kell beolvasztási kérelmet benyújtani: + +* **[Ágaztasd (fork) el a kód tározót](https://guides.github.com/activities/forking/)** és klónozd le magadhoz lokálisan. A lokális másolatodat kapcsold az eredeti tárolóhoz (original "upstream") egy _remote_ hozzáadásával. Frissítsd minél gyakrabban a változásokat az "upstream"-ről, hogy naprakész maradj. Így beolvasztás esetén kisebb eséllyel lesz ütközés a kódok összefésülésekor. (Részletes instrukciókat [itt találsz](https://help.github.com/articles/syncing-a-fork/).) +* **[Hozz létre egy új ágat (branch)](https://guides.github.com/introduction/flow/)** a módosításaidhoz. +* **Hivatkozz meg bármilyen releváns hibajegyet** vagy a dokumentációt a beolvasztási kérelmedben (például, "Closes #37.") +* **Adj hozzá a kérelmedhez "előtte" és "utána" képernyőképeket** ha HTML/CSS változás történt. Húzd be a képeket a beolvasztási kérelembe. +* **Teszteld a változtatásokat!** Mindig futtasd le a meglévő teszteket a kódodon, vagy írj újakat ha szükséges. Függetlenül a tesztektől bizonyosodj meg arról, hogy a módosításod nem rontja-e el a projektet. +* **A módosításaidnál alkalmazkodj a projekt kódolási stílusához** a legjobb tudásod szerint. Ez jelentheti azt, hogy más sorbehúzást kell használni a szövegben, lehet hogy a projekt használ pontosvesszőt, de te nem szoktál, vagy másként írják a kód kommenteket, mint ahogy te szoktad. Ha ezt betartod, a karbantartóknak könnyebb a kódot összefésülni (merge), másoknak pedig karbantartani és megérteni azt. + +Ha ez lesz az első beolvasztási kérelmed (Pull Request), akkor nézd ezt meg előtte: [Make a Pull Request](http://makeapullrequest.com/), amelyben @kentcdodds egy részletes videó anyagot készített. A beolvasztási kérelmek benyújtását a @Roshanjossey által készített [First Contributions](https://github.com/Roshanjossey/first-contributions) GitHub projekten is gyakorolhatod. + +## Mi történik miután beküldted a kész beolvasztási kérelmedet? + +Megcsináltad! Gratulálunk, a nyílt forráskód résztvevője lettél. Reméljük ezt az első lépést majd még számos követi. + +Miután beküldted a végleges hozzájárulásod a projekthez, a következők történhetnek: + +### 😭 Nem kapsz választ + +Remélhetőleg [ellenőrizted a projekt aktivitását](#egy-ellenőrző-lista-mielőtt-részt-vennél-a-projektben) mielőtt csatlakoztál hozzá. Még egy aktív projekt esetén is előfordulhat, hogy nem kap választ azonnal a résztvevő. + +Ha nem kapsz válasz egy hét alatt sem, akkor udvariasan, ugyanazon a szálon kérj meg valakit, hogy nézze át a munkádat, ez így elfogadható. Ha tudod, ki lenne ez a személy akkor meg is említheted őt a @-mention forma használatával. + +**Soha** ne követlenül, privát csatornán lépj kapcsolatba ezzel a személlyel; emlékezz, a publikus kommunikáció az egyik fontos alapja a nyílt forráskódnak. + +Ha az udvarias kérésedre sem reagált senki, akkor lehet, hogy soha nem is fog. Ez lehangoló lehet, de ne add fel, mindenkivel megtörténhet! Számos oka lehet annak, hogy nem kaptál választ, mint például olyan személyes problémák, körülmények, melyekre nincsen ráhatásod. Próbálj meg másik projektet találni, vagy más módon hozzájárulni a projekthez. Ez egy jó példa arra, hogy miért ne tegyél bele túl sok munkát, mielőtt a közösség többi tagja nem reagál az ötletedre. + +### 🚧 Valaki módosítást kér a munkádon + +Gyakran előfordul, hogy valaki módosítást kér a munkádon, amely lehet egy tisztázó kérdés, vagy egy kód módosítási igény. + +Amikor valaki ilyet kér, reagálj rá, hiszen vette a fáradtságot és időt áldozott rá, hogy a munkádat áttekintse. Nagyon rossz gyakorlat az, ha beolvasztási kérelmedet leadtad és utána nem foglalkozol már vele. Ha nem tudod, hogy a kérést hogyan teljesíthetnéd, akkor kutass, olvass és ha szükséges kérdezz vagy kérj segítséget. + +Ha már nincs többé időd, hogy a problémán dolgozz (például időközben több hónap eltelt és megváltoztak a körülményeid), akkor jelezd a karbantartók felé, hogy tudják ezt. Lehet, hogy valaki más örömmel átvenné a feladatot. + +### 👎 Nem fogadták el a munkád + +A munkádat végül vagy elfogadják, vagy nem. Remélhetőleg még nem tettél bele túl sok munkát. Ha nem vagy benne biztos, hogy miért utasították el a hozzájárulásodat, nyugodtan kérdezz és tisztázd az okokat. De végül mindig tartsd tiszteletben a döntést! Ne vitatkozz feleslegesen és ne légy ellenséges! Bármikor megteheted, hogy elágaztatod a projektet (fork) és a saját verziódon dolgozol, ha nem értesz egyet. + +### 🎉 Elfogadták a munkád + +Hurrá! Sikeresen hozzájárultál a nyílt forráskódhoz! + +## Megcsináltad! + +Legyen szó az első nyílt forráskódú munkádról, vagy arról hogy új módját keresed a hozzájárulásnak, reméljük adtunk egy kis inspirációt a cselekvéshez. Még ha nem is fogadták el a hozzájárulásodat, ne feledj el köszönetet mondani a karbantartóknak, hogy energiát szántak rád és a munkádra. A nyílt forráskódot épp olyan emberek alakítják mint te: egy hibajelzés, egy beolvasztási kérés (Pull Request), néhány komment, vagy csak egy egyszerű köszönet. diff --git a/_articles/hu/index.html b/_articles/hu/index.html new file mode 100644 index 00000000000..26bccd90955 --- /dev/null +++ b/_articles/hu/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: Nyílt forráskód útmutató +lang: hu +permalink: /hu/ +--- diff --git a/_articles/hu/leadership-and-governance.md b/_articles/hu/leadership-and-governance.md new file mode 100644 index 00000000000..94c9d2de66a --- /dev/null +++ b/_articles/hu/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: hu +title: Vezetés és irányítás +description: A nyílt forráskódú projektek részére előnyt jelent a döntéshozatal formális szabályozása. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## A növekvő projekt irányításának megértése + +A projekt egyre növekszik, az emberek elkötelezettek, és te is elkötelezted magad, hogy ezt a dolgot csinálod. Ebben a szakaszban felmerül a kérdés, hogy hogyan kell a rendszeres résztvevőket beépíteni a munkafolyamatba, függetlenül attól, hogy valaki kódot ad hozzá, vagy épp megoldja a közösségi vitákat. Ezeket a kérdéseket válaszoljuk most meg. + +## Milyen példák vannak a nyílt forráskódú projektekben használt formális szerepekre? + +Sok projekt hasonló struktúrát követ a résztvevői szerepek és a szerep azonosítása szempontjából. + +Hogy ezek a szerepek valójában mit jelentenek, teljesen rajtad múlik. Íme néhány szerepkör: + +* **Karbantartó (Maintainer)** +* **Résztvevő (Contributor)** +* **Commiter (Committer)** + +**Néhány projektnél a "karbantartók"** azok az emberek akiknek kód módosítási joguk van. Más projektekben, egyszerűen csak hétköznapi résztvevők, akik a README állományban fel vannak sorolva. + +A karbantartó nem feltétlen szükséges, hogy olyan ember legyen aki kódot ír a projektben. Lehet olyan, aki nagyon sok munkát fektet a projekt ismertté tételébe, vagy rengeteg dokumentációt ír, hogy könnyebben érthető legyen a projekt mások számára. Függetlenül attól, hogy mit csinál nap mint nap, a karbantartó valószínűleg olyan ember, aki felelősséget érez a projektért, és elkötelezett amellett, hogy jobbá tegye azt. + +**"Résztvevő" akárki lehet** aki kommentez egy hibát vagy egy beolvasztási kérelmet, vagy más értéket ad a projekthez (megold egy hibát, kódot ír, vagy eseményeket szervez), vagy bárki, akinek a módosítását beolvasztották a projektbe (talán ez a legszűkebb definíció). + + + +**A "committer" fogalma** segít abban, hogy megkülönböztethessük a kódhoz való hozzáférést, mint speciális felelősséget attól, amelyet más résztvevői típusok képviselnek. + +Bármilyen szerepkört definiálhatsz a projektedben, de [fontold meg a tágabb definíciók használatát](../how-to-contribute/#mit-jelent-a-hozzájárulás) hogy a közreműködés más formáit is ösztönözd. Használhatsz vezetői szerepeket, hogy hivatalosan elismerd azokat a személyeket, akik kiemelkedő mennyiségű munkát fektettek a projektbe, függetlenül a technikai készségeiktől. + + + +## Hogyan formalizálhatom ezeket a vezetői szerepeket? + +A vezetői szerepek formalizálása segít abban, hogy az emberek magukénak érezzék a projektet, és jelzi a többi közösségi tag számára, hogy kitől várhat segítséget. + +Kisebb projekt esetén a vezetők kijelölése annyiból áll, hogy a README vagy a CONTRIBUTORS szövegfájlba beírod a nevüket. + +Nagyobb projekt esetén, ha van weboldala, hozz létre egy csapatoldalt, ahol bemutathatod a vezetőket. Például, [Postgres](https://github.com/postgres/postgres/) projektnek van egy[átfogó csapatoldala](https://www.postgresql.org/community/contributors/) rövid bemutatkozással minden résztvevő esetén. + +Ha a projektben nagyon aktív a közreműködő közösség, akkor a "karbantartók" szűkebb köre vagy akár albizottságok alakulhatnak ki, akik a különböző problémakörök (például biztonsági, problémamegoldó vagy közösségi magatartás) kezelését vállalják. Hagyd, hogy az emberek önszerveződjenek és önkéntesek jelentkezzenek azokért a szerepekért, amelyeket a legjobban szeretnének. + + + +A vezetői csapatok egy kijelölt csatornát hozhatnak létre (például IRC) vagy találkozhatnak rendszeresen egyéb projekt megbeszéléseken (mint a Gitter vagy Google Hangout). Akár nyilvánosak is lehetnek ezek, így a többi résztvevő is láthatja. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), például, [minden héten időt biztosít erre](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +Miután létrehoztad a vezetői szerepeket, ne felejtsd el dokumentálni, hogyan érhetik el őket az emberek! Határozz meg egy világos folyamatot arra vonatkozóan, hogy valaki hogyan válhat karbantartóvá, vagy csatlakozhat egy albizottsághoz a projektben, és írd le a GOVERNANCE.md-ben. + +Az olyan eszközök, mint a [Vossibility](https://github.com/icecrime/vossibility-stack) segíthetnek nyilvánosan nyomon követni, hogy ki, mennyivel járul hozzá a projekthez. Az ilyen információk dokumentálása és publikálása megakadályozza azt, hogy a közösség úgy tekintsen a karbantartókra, mint egy szűk, zárt csoportra, akik önkényesen döntenek. + +És végül, ha a projekted a GitHub-on van, gondolkozz el azon, hogy a projektedet a személyes fiókodból egy szervezeti fiókba (_Organization account_) migrálod, legalább még egy helyettes adminisztrátor felvételével. A [GitHub szervezeti fiók](https://help.github.com/articles/creating-a-new-organization-account/) segít abban, hogy könnyebben kezeld a jogosultságokat, a kód tárolókat, és több [társtulajdonost](../building-community/#a-projekt-tulajdonjogának-megosztása) beállítva segít megőrizni a projekt örökségét. + +## Mikor kell valakinek _commit_ jogot adnom? + +Néhányan azt gondolják, hogy mindenkinek, aki hozzájárul a projekthez. Ha ezt teszed, akkor növeled az emberek felelősség érzetét a projekted iránt. + +Másrészről, különösen komplex és nagy projektek esetén, csak azoknak az embereknek célszerű ilyen jogot adni, akik bizonyították elkötelezettségüket a projekt felé. Nincs aranyszabály, hogy melyik a jobb, neked kell eldöntened, hogy számodra mi a megfelelő. + +Ha a projekt a GitHub-on van, használhatsz [védett kód ágakat (branch)](https://help.github.com/articles/about-protected-branches/), melyekkel szabályozni tudod, hogy kik és milyen feltételekkel olvaszthatnak be kódot egy kód ágra. + + + +## Melyek a nyílt forráskódú projektek közös irányítási struktúrái? + +A nyílt forráskódú projektekhez általában három közös irányítási struktúra tartozik. + +* **BDFL:** BDFL rövidítés a "Benevolent Dictator for Life" rövidítése (Jóindulatú diktátor). Ebben a struktúrában minden fontosabb döntésnél a végső szó egy emberé, általában a projekt létrehozójáé, vagy tulajdonosáé. A [Python](https://github.com/python) egy klasszikus példa. A kisebb projektek alapértelmezetten BDFL struktúrán alapulnak, mert csak egy-két karbantartó van. Azok a projektek is ebbe a kategóriába esnek, amelyeket egy cég felügyel. + +* **Meritokrácia:** **(Megjegyzendő, hogy a "meritokrácia" fogalma negatív felhangú néhány közösség vagy kultúra számára, amelynek [összetett társadalmi és politikai története van](http://geekfeminism.wikia.com/wiki/Meritocracy).)** A meritokráciában az aktív karbantartók, akikről köztudott a szakértelmük, formálisan is jogot kapnak a döntések meghozatalára. Általában a döntés ekkor is konszenzuson alapul, egyszerű többséggel. A meritokrácia úttörője az [Apache Foundation](https://www.apache.org/); [minden Apache projekt](https://www.apache.org/index.html#projects-list) meritokrácia. Csak egyének járulhatnak hozzá a kódhoz, cégek vagy cég nevében eljáró egyének nem. + +* **Liberális hozzájárulás:** A liberális hozzájárulás modellje szerint a legtöbb munkát végző embereket elismerik a legbefolyásosabbnak, de ez a jelenlegi munkán és nem a történelmi hozzájárulásokon alapul. A főbb projekt döntéseket a konszenzus-keresési folyamat jellemzi (a főbb ellentétek feloldása), nem pedig pusztán a szavazás, és arra törekszenek, hogy minél több közösségi igényt figyelembe vegyenek eközben. Ilyen projekt a [Node.js](https://foundation.nodejs.org/) és a [Rust](https://www.rust-lang.org/). + +Hogy melyiket kell használnod? Tőled függ! Mindegyik modellnek vannak előnyei és hátrányai. És bár elsőre teljesen másnak tűnhetnek, mindhárom modellben több közös vonás van. Ha érdekel valamelyiknek a használata, nézd meg ezeket a sablonokat: + +* [BDFL modell sablon](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritokrácia modell sablon](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js liberális hozzájárulás mintája](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## Szükségem van-e irányítási dokumentumokra, amikor elindítom a projektemet? + +Nincs szabály arra, hogy mikor kell a projekt irányítási dokumentumát elkészíteni. Sokkal könnyebb megalkotni, miután láttad a közösség dinamikájának működését. A nyílt forráskódú irányítás legszebb (és egyben legnehezebb) része az, hogy a közösség formálja azt! + +Néhány korai dokumentáció azonban elkerülhetetlenül hozzásegít a projekt stabil irányításához, ezért érdemes az alapokat leírnod. Például meghatározhatod a viselkedésre vonatkozó egyértelmű elvárásokat vagy a részvételi folyamat működését, akár a projekt indulásakor is. + +Mielőtt olyan nyílt forráskódú projektet indítasz, amelyet a céged kezdeményez, mindenképpen érdemes megvitatni és tisztázni a céges elvárásokat a karbantartással és döntéshozatallal kapcsolatosan, hogy a projekt gördülékenyen haladjon. Célszerű nyilvánosan elmagyarázni, hogy a vállalat hogyan (vagy épp nem) fog részt venni a projektben. + + + +## Mi történik, ha vállalati alkalmazottaktól érkezik hozzájárulás? + +A sikeres nyílt forráskódú projekteket sok ember és cég használja, és egyes vállalatok a projekthez köthető bevételi forrással is rendelkezhetnek. Például egy vállalat kereskedelmi szolgáltatásának részeként felhasználhatja egy ilyen projekt kódját. + +Ahogy a projekt egyre szélesebb körben kerül felhasználásra, a hozzáértő emberekre egyre nagyobb lesz az igény - lehet, hogy te leszel az egyik! - és néha fizetnek majd a projektben végzett munkájukért. + +Fontos, hogy az üzleti tevékenységet normálisnak tekintsük, és csak egy fejlesztést ösztönző lehetőségként kezeljük. Természetesen a fizetett fejlesztőknek nem szabad különleges bánásmódot kapniuk azokkal szemben, akinek ezért nem fizetnek; minden hozzájárulást technikai szempontból kell értékelni. Az üzletileg támogatott embereknek nem szabad kényelmetlenül érezni magukat, még akkor sem, ha a saját használati esetüket képviselik egy adott továbbfejlesztés vagy új funkció megvitatása során. + +Az "Üzlet" teljesen kompatibilis a "Nyílt Forráskóddal". Az "Üzlet" csak azt jelenti, hogy valahol megjelenik a pénz - az üzleti élet használja a kódot, ami a projekt ismertségével és elfogadottságával egyre valószínűbbé válik. (Bár amikor a nyílt forráskódú szoftvert nem-nyílt forrású termék részeként használják, az egész termék továbbra is "saját tulajdonú" szoftver marad, a nyílt forráskódú szoftverhez hasonlóan, kereskedelmi- vagy nem kereskedelmi célokra is használható.) + +Mint bárki más, az üzletileg motivált fejlesztők is a minőségi és mennyiségi hozzájáruláson keresztül érvényesülhetnek a projektben. Nyilvánvaló, hogy egy olyan fejlesztő, aki fizetést kap, többet tud tenni, mint az, aki nem kap érte fizetséget, de ezzel nincs probléma: a fizetés csak egy, a sok lehetséges tényező közül, amely befolyásolhatja, hogy valaki mennyire vesz részt a projektben. A projekt megbeszélések fókuszában a résztvevők álljanak, ne pedig azok a külső tényezők, amelyek azt befolyásolják, hogy valaki milyen közegben járult hozzá a projekthez. + +## Szükségem van egy jogi személyre a projektem támogatásához? + +Hacsak nem kezelsz pénzt, nincs szükséged jogi személyre, hogy támogasd a nyílt forráskódú projektedet. + +Ha például vállalkozást akarsz alapozni a projektedre, akkor ennek megfelelő céget kell alapítanod. Ha csak a projektedhez kapcsolódó szerződéses munkát végzel és ezért pénzt kapsz, akkor akár egyéni vállalkozóként, akár Kft-ként működsz, a helyi adó- és jogszabályoknak megfelelő módon kell eljárnod. + +Ha adományokat szeretnél kapni a nyílt forráskódú projektedért, elhelyezhetsz egy adomány gombot a weboldalon (PayPal, Stripe, stb. segítségével), de a bevétel kezelésénél ekkor is a helyi adó- és jogszabályoknak megfelelő módon kell eljárnod. + +Számos projekt nem vállalja a non-profit szervezet létrehozásával járó bonyodalmakat, ezért olyan támogatókat keresnek akik már non-profit jogi személyek. Ezek a szervezetek a te nevedben fogadhatnak el adományokat, általában némi részesedésért cserébe. A [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) és [Open Collective](https://opencollective.com/opensource) jó példák az ilyen non-profit támogató szervezetre. + + + +Ha a projekted egy adott programnyelvhez, vagy ökoszisztémához tartozik, akkor ezen területeken kell keresned a non-profit támogatókat. Például, a [Python Software Foundation](https://www.python.org/psf/) támogatja a [PyPI](https://pypi.org/), nevű Python csomagkezelőt, és a [Node.js Foundation](https://foundation.nodejs.org/) támogatja az [Express.js](https://expressjs.com/) nevű Node.js alapú webes keretrendszert. diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md new file mode 100644 index 00000000000..1b586051801 --- /dev/null +++ b/_articles/hu/legal.md @@ -0,0 +1,158 @@ +--- +lang: hu +title: A nyílt forráskód jogi oldala +description: Minden, amit valaha is gondoltál a nyílt forráskód jogi oldaláról, és néhány dolog, amit nem. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## A nyílt forráskód jogi következményeinek megértése + +A kreatív munka megosztása a világgal izgalmas élmény és egyben kifizetődő is lehet. Ez azt is jelentheti, hogy rengeteg jogi dolgot kell figyelembe venned, amiről még nem is tudsz. Szerencsére nem kell nulláról kezdened, hiszen minden megvan a jogi részek lefedéséhez. (Mielőtt részletesen belemennénk, olvasd el a [kizárási nyilatkozatot](/notices/).) + +## Miért kellene foglalkoznom a nyílt forráskód jogi oldalával? + +Örülök, hogy megkérdezted! Ha kreatív munkát végzel (például írás, grafika vagy kód), az alkotás alapértelmezés szerint kizárólagos szerzői jogi védelem alatt áll. Azaz a törvény feltételezi, hogy szerzőként beleszólhatsz, hogy mások mit tehetnek vele. + +Általában ez azt jelenti, hogy senki más nem használhatja, nem másolhatja, terjesztheti vagy módosíthatja az alkotásodat jogi következmények kockáztatása nélkül. + +A nyílt forráskód azonban nem a megszokott helyzet, mert a szerző itt azt várja, hogy mások használják, módosítsák és megosszák a munkáját. De mivel a jogi alapértelmezés még mindig a kizárólagos szerzői jog, ezért szükséged van egy licencre, amely kifejezetten kimondja ezeket az engedélyeket. + +Ha nem alkalmazol nyílt forráskódú licencet, akkor mindenki, aki hozzájárul a projekthez, a saját munkájának kizárólagos szerzői jogi tulajdonosa lesz. Ez azt jelenti, hogy senki nem tudja használni, másolni, terjeszteni vagy módosítani a hozzájárulást - és a "senki" alatt magadat is értsd. + +És végül, a projektnek lehetnek függőségei, olyan licenckövetelményekkel, amelyekről nincs tudomásod. A projekt közössége, vagy a munkáltató irányelvei szintén előírhatják, hogy a projektre konkrét, nyílt forráskódú licenceket kell használnod. Ezeket az eseteket az alábbiakban ismertetjük. + +## Nyílt forráskódúak a nyilvános GitHub projektek? + +Amikor [létrehozol egy új projektet](https://help.github.com/articles/creating-a-new-repository/) a GitHub-on, lehetőséged van megadni, hogy a projekt **private** (privát) vagy **public** (publikus) legyen. + +![Projekt létrehozása](/assets/images/legal/repo-create-name.png) + +**A GitHub projekt nyilvánossága nem azonos a projekt licencével!** A publikus projekt fogalma itt van definiálva: [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), ami engedélyezi ezek megtekintését, vagy e célból ennek elágaztatását (fork), de más egyebet nem. + +Ha azt szeretnéd, hogy mások használhassák, terjesszék, módosítsák vagy hozzájáruljanak a projekthez, meg kell nevezned egy nyílt forráskódú licencet. Például attól, hogy a projekt nyilvános, még senki sem jogosult bármely részének törvényes használatára, kivéve, ha kifejezetten feljogosítod erre a megfelelő licenccel. + +## Tömören, hogy mit kell tenned a projekted védelme érdekében + +Szerencsés helyzetben vagy, mert manapság a nyílt forráskódú licencek szabványosítottak és könnyen kezelhetők. Ezeket a licenceket bemásolhatod közvetlenül a projektedbe. + +Az [MIT](https://choosealicense.com/licenses/mit/), az [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), és a [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) a legismertebb nyílt forráskódú licencek, de vannak más lehetőségek is amikből választhatsz. Ezen licencek teljes szövegét és használatuk módját megtalálod a [choosealicense.com](https://choosealicense.com/) oldalon. + +Ha új projektet hozol létre a GitHub-on, meg kell adnod, hogy [milyen licencű a projekt](https://help.github.com/articles/open-source-licensing/). + + + +## Melyik nyílt forráskódú licenc felel meg a projektemnek? + +Ha üres lappal indulsz, akkor talán a legjobb a [MIT licenc](https://choosealicense.com/licenses/mit/). Rövid, nagyon könnyen érthető, és megengedő, amíg megtartják a licenc másolatát, beleértve a szerzői jogi nyilatkozatot is. Ha valaha szükséged lesz rá, más licenc alatt is kiadhatod később a projektedet. + +Más esetben viszont, a megfelelő nyílt forráskódú licenc kiválasztása a projekthez a célkitűzéseidtől függ. + +A projektednek vélhetően lesznek **függőségei**. Például, ha nyílt forráskódú Node.js alapú projekted van, akkor használni fogsz az npm-ről (Node.js Package Manager) származó függőségeket. Minden egyes függőségnek külön, nyílt forráskódú licence van. Ha mindegyik licenc "megengedő" (engedélyezi a publikum számára a használatot, módosítást és megosztást egyéb tovább licencelési feltételek nélkül), akkor bármilyen licencet használhatsz a projektedhez. Általánosan megengedő licencek a MIT, az Apache 2.0, az ISC és a BSD. + +Másrészről, hogy ha bármelyik függőséged licence "erős copyleft" (szintén megadja ugyanazokat a jogokat, de csak az azonos licencelés továbbvitelének feltételével), akkor a projektednek is ezt a licencet kell használnia. Ilyen "erős copyleft" licencek például a GPLv2, GPLv3, és AGPLv3. + +Azt is érdemes figyelembe venni, hogy reményeid szerint mely **közösségek** fogják használni illetve hozzájárulni a projekthez: + +* **Szeretnéd, hogy projekted más projektek függősége legyen?** Valószínűleg a legjobb, ha az adott közösségben legkedveltebb licencet használod. Például, az [MIT](https://choosealicense.com/licenses/mit/) a legnépszerűbb az [npm csomagok](https://libraries.io/search?platforms=NPM) esetén. +* **Szeretnéd, hogy a projektedet a vállalatok használják?** Egy nagyvállalat valószínűleg kifejezett szabadalmi engedélyt kér minden résztvevőtől. Ekkor az [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) lefedi mindkét fél érdekeit. +* **Szeretnéd, ha projekted vonzó legyen azon közreműködők számára, akik nem akarják, hogy zárt forráskódú szoftverekben használják fel a hozzájárulásaikat?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) vagy (ha nem kívánnak hozzájárulni még a zárt forráskódú szolgáltatásokhoz sem) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) teljességgel megfelelő. + +A **cégednek** lehetnek speciális licenc kikötései a nyílt forráskódú projektjei esetén. Például megengedő licencet vár el, hogy a saját zárt forráskódú termékeiben használhassa őket. Vagy előírhatja egy erős copyleft licenc használatát és egy további hozzájárulási megállapodást (lásd alább), hogy csak a cég és senki más ne használhassa a projektet zárt forráskódú szoftverekben. Esetleg lehetnek bizonyos igényei a szabványokkal, a társadalmi felelősséggel vagy az átláthatósággal kapcsolatban, amelyek mindegyike különleges licencelési stratégiát igényelhet. Beszélj a [céged jogi osztályával](#mit-kell-tudnia-a-cégem-jogi-osztályának). + +Amikor új projektet hozol létre a GitHub-on, lehetőséged van egy licenc kiválasztására. A fent említett licencek egyikét választva a GitHub projekted nyílt forráskódúvá válik. Ha más lehetőséget keresel, nézd át a [choosealicense.com](https://choosealicense.com) oldalt, hogy megtaláld a magadnak megfelelőt, még akkor is ha a projekted [nem szoftver projekt](https://choosealicense.com/non-software/). + +## Mi van, ha meg akarom változtatni a projekt licencét? + +A legtöbb projektnek nem szükséges licencet módosítania, de vannak körülmények, amikor mégis szükséges. + +Például, ahogy a projekt növekszik, új függőségekre vagy felhasználókra tesz szert, vagy céged megváltoztatja a stratégiáját. Ezek közül bármelyik esetén szükség lehet a licence megváltoztatására. Továbbá, ha elhanyagoltad a projekt licencelését a kezdetektől fogva, a licenc hozzáadása gyakorlatilag megegyezik a licenc megváltoztatásával. A projekt licencének hozzáadásakor vagy megváltoztatásakor három alapvető dolgot kell figyelembe venni: + +**Bonyolult.** A licenckompatibilitás és a megfelelőség meghatározása, valamint a szerzői joggal rendelkező személyek kezelése, nagyon gyorsan bonyolult és zavaros helyzetet teremthet. Az új kiadások és hozzájárulások esetén új, de kompatibilis licencre való áttérés eltér az összes meglévő hozzájárulás újralicencelésétől. Ha felmerül a licencváltás gondolata vagy igénye, azonnal vond be a jogi csapatot. Még ha rendelkezel is a licencszerződés megváltoztatásához a projekt szerzői jogtulajdonosainak engedélyével, vedd figyelembe, hogy a változás milyen hatással lesz a projekt többi felhasználójára és résztvevőjére! Gondolj egy licencváltozásra úgy, mint a projekt "irányítási eseményére", amely valószínűleg zökkenőmentesen zajlik egyértelmű kommunikációval és a projekt érdekeltjeivel folytatott konzultációval. Ez egy fontos ok arra, hogy a projekt kezdetétől megfelelő licencet válassz és használj! + +**Jelenlegi licenc.** Ha a jelenlegi licenc kompatibilis azzal, amire váltani szeretnél, akkor nyugodtan kezdd el használni az újat. Ennek az oka az, hogy ha az "A" licenc kompatibilis a "B" licenccel, akkor megfelelsz az "A" feltételeinek, miközben megfelelsz a "B" feltételeinek is (ez visszafelé nem feltétlenül igaz). Tehát, ha jelenleg megengedő licencet használsz (pl. MIT), akkor további feltételeket szabva válthatsz licencet, amennyiben megtartod a MIT licenc másolatát, és a kapcsolódó szerzői jogi megjegyzéseket (tehát továbbra is megfelelsz a MIT licenc minimális feltételeinek). Ha azonban a jelenlegi licenced nem megengedő (például "copyleft", vagy nincs licence), és nem te vagy az egyetlen szerzői jogi tulajdonos, akkor nem tudsz áttérni a MIT licencre. Alapvetően egy megengedő licenccel, a projekt szerzői előzetesen engedélyt adtak a licenc későbbi megváltoztatására. + +**A projekt meglévő szerzői jogainak tulajdonosai.** Ha egyedüli résztvevője vagy a projektnek, akkor te vagy céged a projekt szerzői jogának egyedüli birtokosa. Hozzáadhatsz új licencet vagy áttérhetsz bármilyen licencre, amire csak szeretnél. Más esetben előfordulhat, hogy a licenc megváltoztatásához más szerzői jog tulajdonosokkal is meg kell hogy egyezned. Kik ők? Célszerű azokkal kezdeni, akik commit-oltak a projektben. Néhány esetben azonban a szerzői jogokkal a hozzájáruló emberek munkáltatói rendelkeznek. Bizonyos esetekben az emberek csak minimálisan, néhány sor kóddal járulnak hozzá a projekthez, de nincs olyan szigorú és egyértelmű szabály arra vonatkozóan, hogy ilyen esetekben el lehet-e tekinteni a szerzői jogtól. Mit lehet ekkor tenni? Attól függ. Egy viszonylag kicsi és fiatal projekt esetében lehet, hogy minden meglévő résztvevő beleegyezik a licencváltozásba egy hibajegyen vagy beolvasztási kérelmen keresztül. Egy nagy és hosszú életű projekt esetében azonban sok közreműködőt és még akár az örökösöket is meg kell keresni. A Mozilla-nak évekig tartott (2001-2006) a Firefox, a Thunderbird és a kapcsolódó szoftverek újralicencelése. + +Alternatív megoldásként, a résztvevők előzetesen (egy kiegészítő hozzájárulási megállapodás alapján - lásd alább), bizonyos feltételek mellett, a meglévő nyílt forráskódú licenc változtatását is engedélyezhetik. Ez kicsit javítja a licencváltás összetettségét. Viszont előtte szükséged lesz némi segítségre az ügyvédek részéről, és továbbra is egyértelműen kommunikálnod kell a projekt érdekeltjeivel a licencváltás végrehajtásának folyamatát. + +## Szükségem van-e kiegészítő hozzájárulási megállapodásra? + +Valószínűleg nem. A nyílt forráskódú projektek túlnyomó többsége esetében a nyílt forráskódú licenc implicit módon tartalmazza egyaránt a bejövő (a résztvevőkről) és a kimenő (más hozzájárulók és felhasználók) licencet. Ha a projekt a GitHub-on van, akkor a GitHub Általános Szerződési Feltételei szerint a "bejövő = kimenő" elv [kifejezetten alapértelmezett](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +Egy kiegészítő hozzájárulási megállapodás, amelyet gyakran közreműködői licenc megállapodásnak (CLA) neveznek, adminisztratív munkát generálhat a projektgazdák számára. A projekt és a kivitelezés függvénye, hogy ez mennyi munkát jelent. Egy egyszerű megállapodás megkövetelheti, hogy a közreműködők egy kattintással megerősítsék, hogy megvan a szükséges joguk a nyílt forráskódú projekt licencének megfelelő részvételhez. Egy bonyolultabb megállapodás jogi felülvizsgálatot, és a résztvevők munkáltatójától kapott hozzájárulást is igényelhet. + +Amikor ez olyan "papírmunkát" okoz, amit egyesek szükségtelennek, nehezen érthetőnek esetleg tisztességtelennek (ha a megállapodás kedvezményezettje több jogot kap, mint amit a projekt nyílt forráskódú licence alapján a közreműködők vagy a nyilvánosság kapnak) gondolnak, egy kiegészítő hozzájárulási megállapodás barátságtalan lépésnek tűnhet a közösség számára. + + + +Egyes helyzetekben, szükséges lehet további, a projekthez kapcsolódó közreműködői megállapodást kötni: + +* A jogászok azt szeretnék, ha minden résztvevő kifejezetten elfogadná (_aláírná_, online vagy offline) a közreműködői feltételeket, talán azért, mert úgy érzik, hogy a nyílt forráskódú licenc nem elég (annak ellenére, hogy ez nem így van!). Ha csak ez az egyetlen gond, akkor elegendőnek kell lennie a nyílt forráskódú licencnek, és egy azt megerősítő közreműködői megállapodásnak. A [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) egy jó példa egy érthető, könnyen használható CLA-nak. +* Te vagy a jogászok azt szeretnék, hogy a fejlesztők minden commit-ja jogilag megállja a helyét. Ezt a projektek a [Developer Certificate of Origin](https://developercertificate.org/) segítségével érik el. Például, a Node.js közösség a saját CLA-juk helyett [inkább](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) a DCO-t [használja](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md). A DCO automatikus kikényszerítése egy Git repository-n legegyszerűbben a [DCO Probot-tal](https://github.com/probot/dco) érhető el. +* A projekt egy olyan nyílt forráskódú licencet használ, amely nem tartalmaz kifejezetten szabadalom használati engedélyt (például MIT), így szükséges egy szabadalom használati engedély nyilatkozat minden résztvevőtől, akik közül néhányan nagy szabadalom portfólióval rendelkező cégeknek dolgoznak, amelyek a szabadalmaikat felhasználva támadhatnak téged vagy a projekt többi résztvevőjét és felhasználóit. Az [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) egy elterjedten használt kiegészítő közreműködői megállapodás, ami az Apache License 2.0 licencben szereplő szabadalom használati jogosultságot tartalmazza. +* A projekted "copyleft" licencelésű, de a projektből egy szabadalmaztatott, saját verziót is terjeszteni szeretnél. Minden résztvevőnek át kell ruháznia rád a szerzői jogait, hogy megengedje neked (de nem a nyilvánosságnak) a szabad felhasználást. A [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) egy ilyen típusú megállapodás. +* Úgy gondolod, hogy a projekt élete során szükség lehet a licenc módosítására, és azt szeretnéd, hogy a közreműködők előre elfogadják az ilyen jellegű változtatásokat. + +Ha kiegészítő hozzájárulási megállapodást kell használnod, fontold meg egy olyan integrált szolgáltatás használatát, mint például a [CLA assistant](https://github.com/cla-assistant/cla-assistant), ezzel minimalizálhatod a résztvevők terhelését. + +## Mit kell tudnia a cégem jogi osztályának? + +Ha egy cég alkalmazottjaként indítasz nyílt forráskódú projektet, ezt először tudatnod kell a cég jogi csoportjával. + +Fontold ezt meg még akkor is, ha személyes projektről van szó. Valószínűleg van egy "munkavállalói szellemi tulajdon megállapodás" a cég és te közted, amely némi ellenőrzést biztosít nekik a projektjeid felett különösen, ha azok kapcsolódnak a vállalat üzleti tevékenységéhez, vagy vállalati erőforrásokat használsz a projekt fejlesztéséhez. A céged könnyedén megadhatja az engedélyt, és talán már van is alkalmazott-barát munkáltatói megállapodás, vagy vállalati irányelv. Ha nem, akkor tárgyalhatsz róla (például magyarázd el, hogy a projekt a vállalat szakmai tanulási és fejlesztési céljait szolgálja), vagy ha ez sikertelen, akkor ne dolgozz a projekten, amíg nem találsz jobb vállalatot. + +**Ha a cégednek csinálsz nyílt forráskódú projektet,** akkor mindenképpen tudjanak róla. A jogi csapat valószínűleg már rendelkezik a cég üzleti igényinek megfelelő irányelvekkel a nyílt forráskódú licencek (és esetleg további közreműködői megállapodások) használatával kapcsolatosan. Valószínűleg ahhoz is megvan a szakértelmük, hogy a projekt licencelése megfeleljen a függőségek licenceinek. Ha nem, akkor szerencsés a helyzet! A jogi csapatnak együtt kell dolgoznia veled, hogy megoldjátok ezt. Néhány dolog, amire gondolni kell: + +* **Harmadik fél anyagai:** Használ a projekted mások által létrehozott függőségeket, vagy tartalmaz illetve használ más által írt kódot? Ha ezek nyílt forráskódúak, akkor meg kell felelned azok nyílt forráskódú licencének. Első lépésként választanod kell egy licencet, ami kompatibilis a harmadik féltől származó anyagok licencével. Ha a projekt módosítja, vagy terjeszti a harmadik fél nyílt forráskódú anyagát, akkor a jogi csapat azt is szeretné tudni, hogy megfelelsz-e a harmadik fél nyílt forráskódú licenc feltételeinek, mint például a szerzői jogi megjegyzések megőrzése. Ha a projekt mások kódját használja, amely nem rendelkezik nyílt forráskódú licenccel, akkor valószínűleg fel kell kérned a harmadik felet, hogy [adjon hozzá egy nyílt forráskódú licencet](https://choosealicense.com/no-license/#for-users), ha nem kapsz ilyet, akkor abba kell hagyni ezen kód használatát. + +* **Üzleti titkok:** Vizsgáld meg, hogy van-e valami a projektben, amit a vállalat nem akar a nyilvánosság számára elérhetővé tenni. Ha igen, akkor nyisd meg a projekt többi részét, de csak miután kiszedted a privát anyagot belőle. + +* **Szabadalmak:** A céged szabadalmi kérelmet adott be, amivel kapcsolatosan a projekt forráskódjának megnyitása [nyilvánosságra hozásnak](https://en.wikipedia.org/wiki/Public_disclosure) minősül? Ez esetben sajnos felkérhetnek, arra hogy várj még (esetleg a cég újragondolhatja a szabadalmi kérelmet). Ha nagy szabadalmi portfólióval rendelkező cégek alkalmazottjaitól is számítasz hozzájárulásokra, a jogi csoport kötelezhet arra, hogy olyan licencet válassz, ami kifejezett szabadalom használati engedélyt követel meg a hozzájárulóktól (például az Apache 2.0 vagy a GPLv3), vagy egy kiegészítő hozzájárulási megállapodást vár el (lásd fent). + +* **Védjegyek:** Nézz utána alaposan, hogy a projekted neve nem ütközik [valamely védjeggyel](../starting-a-project/#kerüld-el-a-névütközést). Ha saját céged védjegyeit használod a projektben, ellenőrizd, hogy nem okoz-e ütközéseket, problémákat. A [FOSSmarks](http://fossmarks.org/) egy gyakorlati útmutató a védjegyek megértéséhez szabad és nyílt forráskódú projektek esetén. + +* **Magánélet:** Gyűjt a projekt adatokat a felhasználókról? Kommunikál vállalati szerverekkel? A jogi csoport segít neked a vállalati irányelvek és a külső szabályok betartásában. + +Ha a céged első nyílt forráskódú projektjének publikálásán dolgozol, a fentiek elégségesek ahhoz, hogy sikerüljön (de ne aggódj, a legtöbb projektben nem merül fel komoly probléma). + +Hosszabb távon a jogi csapat többet tehet azért, hogy segítsen a vállalatnak profitálni a nyílt forráskódból és közben biztonságban tudhassa magát: + +* **Munkavállalói hozzájárulás szabályozása:** Fontold meg olyan vállalati irányelv kidolgozását, amely meghatározza, hogy a munkavállalók hogyan járulnak hozzá a nyílt forráskódú projektekhez. Az egyértelmű szabályozás csökkenti a zavart az alkalmazottak körében, és segít abban, hogy a vállalat érdekeinek megfelelően járuljanak hozzá a nyílt forráskódú projektekhez, akár munkájuk részeként, akár szabadidejükben. Jó példa erre a Rackspace féle [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/). + + + +* **Mit kell kiadni:** [(Majdnem) mindent?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Ha a jogi csapat megérti és hajlandó munkát befektetni a vállalat nyílt forráskódú stratégiájába, akkor az inkább segíteni fog, mint akadályozni. +* **Megfelelés:** Még ha a céged nem is fejleszt nyílt forráskódot, biztosan használja azt. A [tudatosság és folytonosság](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) megakadályozhatja a fejfájást, a késedelmeket és a pereket. + + + +* **szabadalmak:** A céged lehet szívesen csatlakozna az [Open Invention Network-höz](https://www.openinventionnetwork.com/), ami egy védekező szabadalmi társulás, védelmet nyújt tagok számára a nagyobb, nyílt forráskódú projektek használatában, vagy megvizsgálja az [alternatív szabadalmi engedélyezés lehetőségét](https://www.eff.org/document/hacking-patent-system-2016). +* **Irányítás:** Van-e értelme, és ha igen, akkor mikor érdemes a projektet egy [cégen kívüli jogi személynek átadni](../leadership-and-governance/#szükségem-van-egy-jogi-személyre-a-projektem-támogatásához). diff --git a/_articles/hu/maintaining-balance-for-open-source-maintainers.md b/_articles/hu/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..ebf6888caa7 --- /dev/null +++ b/_articles/hu/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,219 @@ +--- +lang: hu +untranslated: true +title: Maintaining Balance for Open Source Maintainers +description: Tips for self-care and avoiding burnout as a maintainer. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. + +To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play. + +So, what is personal ecology? As described by the Rockwood Leadership Institute, it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with. + + + +By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work. + +## Tips for Self-Care and Avoiding Burnout as a Maintainer: + +### Identify your motivations for working in open source + +Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus. + +### Reflect on what causes you to get out of balance and stressed out + +It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers: + +* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference. + + + +* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations. + + + +* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person. + + + +* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project. + + + +* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community. + + + +### Watch out for signs of burnout + +Can you keep up your pace for 10 weeks? 10 months? 10 years? + +There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress). + + + +### What would you need to continue sustaining yourself and your community? + +This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard: + +* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. + + You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work. + +* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/). + + + +* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions. + + + +* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term. + + If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day. + + + +* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time. + + + +Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about. + + + + + +Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run. + +## Additional Resources + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://mikemcquaid.com/saying-no/) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series + +## Contributors + +Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/hu/metrics.md b/_articles/hu/metrics.md new file mode 100644 index 00000000000..2ee70874104 --- /dev/null +++ b/_articles/hu/metrics.md @@ -0,0 +1,126 @@ +--- +lang: hu +title: Nyílt forráskód mérőszámai +description: A nyílt forráskódú projekt sikerének titka a mérés és nyomon követés. +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Miért mérünk bármit is? + +Ha bölcsen használjuk a rendelkezésre álló adatokat, nyílt forráskódú projekt karbantartójaként jobb döntéseket tudunk hozni. + +Több információ birtokában: + +* Megértheted, hogy a felhasználók hogyan reagálnak egy új funkcióra +* Rájöhetsz arra, hogy a felhasználóid honnan érkeznek +* El tudod dönteni, hogy egy adott használati esetet, vagy új funkcionalitást támogatsz-e +* Számszerűsítheted a projekt népszerűségét +* Megértheted, hogy a felhasználók hogyan használják a munkádat +* Támogatással és szponzorálással pénzhez juthatsz + +Például, a [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) úgy találta, hogy a Google Analytics segíti őket a feladatok priorizálásában: + +> A Homebrew ingyenes, és teljességgel önkéntes munka, amit a fejlesztők a szabadidejükben végeznek. Ennek eredményeként nem rendelkezünk erőforrásokkal ahhoz, hogy részletes felhasználói tanulmányokat végezhessünk a Homebrew felhasználókról, ami alapján el tudjuk dönteni hogy, miként lehet a legjobban megtervezni a jövőbeli funkciókat és priorizálni az aktuális feladatokat. Ugyanakkor az anonim összesített felhasználói elemzés lehetővé teszi számunkra, hogy priorizáljuk a javításokat és az új funkciók fejlesztését aszerint, hogy hol, és mikor használják az emberek a Homebrew-t. + +A népszerűség nem minden. Mindenki különböző okokból kezd a nyílt forráskódba. Ha neked, mint nyílt forráskód karbantartójának az a célod, hogy megmutasd a világnak a munkád, átláthatóvá akarod tenni a kódod vagy csak élvezetből csinálod, akkor a mérőszámok nem biztos, hogy fontosak számodra. + +Ha viszont mélyebb szinten akarod megismerni a projektedet, olvass tovább, hogy megtudd, milyen módon elemezheted a projekted aktivitását. + +## Felfedezés + +Mielőtt bárki elkezdené használni a projektedet, vagy részt venne benne, tudniuk kell, hogy az létezik, és hogy hol találják. Kérdezd meg magadtól: _Az emberek megtalálják ezt a projektet?_ + +![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +Ha a munkád a GitHub-on van, [akkor láthatod](https://help.github.com/articles/about-repository-graphs/#traffic) hogy hány ember járt az oldaladon, és hogy honnan érkeztek. A projekt oldaláról, válaszd ki az "Insights", majd a "Traffic" funkciót. Ezen az oldalon a következőket láthatod: + +* **Views:** Megadja, hogy hányszor nézték meg a projekt oldalát. + +* **Unique visitors:** Megadja, hogy hány ember látogatta meg a projekt oldalát. + +* **Referring sites:** Megadja, hogy honnan érkeztek az oldalra az emberek. Ez a metrika segíthet kitalálni, hogy hol érheted el a közönséget és hogyan működnek a promóciós erőfeszítéseid. + +* **Popular content:** Megadja, hogy a projekted mely részére kíváncsiak a látogatók, lebontva oldalakra és látogatókra. + +[GitHub stars](https://help.github.com/articles/about-stars/) szintén segíthet a népszerűség mérésében. Bár a _GitHub stars_ nem szükségszerűen van kapcsolatban azzal, hogy hányan töltötték le vagy használták a projektet, mégis alkalmas arra, hogy mérje azt, hogy mennyi ember érdeklődését keltette fel a munkád. + +Érdemes lehet [egyéb helyeken is nyomon követni az elérhetőséget](https://opensource.com/business/16/6/pirate-metrics): például, Google PageRank, hivatkozások a projekt oldaladról vagy hivatkozások más nyílt forráskódú oldalról, vagy weboldalról. + +## Használat + +Az emberek megtalálják a projektet ezen a vad és őrült dolgon, amit internetnek hívunk. Ideális esetben, amikor meglátják a projektet, késztetést érezhetnek rá, hogy tegyenek valamit. A második kérdés, amit fel kell tenned magadnak: _Az emberek használják ezt a projektet?_ + +Ha a projekt terjesztéséhez csomagkezelőt (például npm vagy RubyGems.org) használsz, nyomon követheted a projekt letöltéseit. + +Mindegyik csomagkezelő kissé eltérő definíciót használhat a "letöltésre", és a letöltések nem feltétlenül korrelálnak a telepítésekkel vagy a használattal, de az összehasonlításhoz valamilyen alapot biztosítanak. Próbáld ki a [Libraries.io](https://libraries.io/) használatát, mellyel számos ismert csomagkezelő statisztikáit követheted. + +Ha a GitHub-on van a projekted, akkor a "Traffic" oldalon a [clone graph](https://github.com/blog/1873-clone-graphs) diagram használatával láthatod, egy adott napon hányszor klónozták a projektedet, lebontva összes klónozásra és egyedi látogatókra. + +![Clone graph](/assets/images/metrics/clone_graph.png) + +Ha a felhasználók száma alacsonyabb, mint a projektet felfedező emberek száma, két kérdést kell átgondolnod: + +* A projekted nem győzi meg sikeresen a célközönséget, vagy +* Rossz közönséget céloztál meg + +Például, ha a projekt a Hacker News főoldalára kerül, valószínűleg látni fogsz egy kiugrást a látogatói forgalomban, de alacsonyabb lesz a valódi felhasználók aránya, mert mindenkit elérsz a Hacker News-on. Ha Ruby projekted van, ami bemutatásra kerül egy Ruby konferencián, akkor valószínűleg nagyobb arányban lesznek felhasználók a célközönségből. + +Próbáld meg kitalálni, hogy honnan jönnek a látogatók és kérj visszajelzéseket a projekt oldalon, hogy megtudd, hogy a fenti két eset közül melyik jelent problémát. + +Ha már tudod, hogy az emberek használják a projektet, érdemes utánajárni, hogy mit csinálnak vele. Elágaztatják (fork-olják) a projektet és új funkciókat adnak hozzá? Vagy esetleg tudományos vagy üzleti célokra használják? + +## Fenntarthatóság + +Az emberek megtalálták a projektedet és használják már. A következő kérdést kell megválaszolnod magadnak: _Az emberek hozzájárulnak-e a projekthez?_ + +Soha sem túl korai elkezdeni gondolkodni a közreműködőkről. Ha nincsenek más emberek, akik részt vennének a projektben, akkor olyan egészségtelen helyzet alakulhat ki, hogy ugyan a projekt _közismert_ (sokan használják), de kevesen támogatják (a szükségeshez képest kevés a karbantartói erőforrás). + +A fenntarthatósághoz az is szükséges, hogy [folyamatosan új résztvevők érkezzenek a projektbe](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), mert előfordulhat, hogy a jelenlegi résztvevők más projektek felé fordulnak. + +Példák a közösségi metrikákra, amelyeket érdemes rendszeresen nyomon követni: + +* **Résztvevők száma és a résztvevőkre jutó kódmódosítások száma:** Megadja, hogy hány résztvevő van a projekteden, ki az, aki többet- és ki az, aki kevesebbet járul hozzá. A GitHub-on, az "Insights" -> "Contributors" alatt találod ezt meg. Jelenleg itt csak azt látod, aki az alapértelmezett fejlesztési ágon járult hozzá (commit-olt) a projekthez. + +![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **Új, alkalmi és rendszeres hozzájárulók:** Segítségével nyomon követheted, hogy jönnek-e új hozzájárulók és hogy visszatérnek-e. (Az alkalmi hozzájárulók azok, akiknek csak kevés commit-ja van. Ez jelenthet 1 vagy kevesebb, mint 5 módosítást is, rajtad múlik, hogy mi a "kevés".) Új közreműködők, hozzájárulók nélkül a projekt közössége stagnálhat. + +* **A nyitott hibajegyek és beolvasztási kérelmek száma:** Ha ezek a számok túl magasak, akkor segítségre van szükséged a hibajegyek ellenőrzéséhez és osztályozásához illetve a beolvasztandó kódok áttekintéséhez. + +* **A létrehozott hibajegyek és beolvasztási kérelmek száma:** Ez azt jelenti, hogy az embereket érdekli annyira a projekted, hogy létrehozzanak egy hibajegyet. Ha ez a szám idővel növekszik, az arra utal, hogy az emberek érdeklődnek a projekted iránt. + +* **Közreműködők típusai:** Például: kód módosítás, elírás javítás, hibajavítás, vagy kommentelés egy hibajegyhez, módosításhoz. + + + +## Karbantartói aktivitás + +És végül, meg kell bizonyosodnod arról, hogy a karbantartók képesek kezelni a beérkező hozzájárulások mennyiségét. Így utolsó kérdésként érdemes feltenned magadnak: _Képes vagyok reagálni a közösség munkájára, jelzéseire?_ + +Az inaktív karbantartók a nyílt forráskódú projektek szűk keresztmetszetévé válnak. Ha valaki hozzájárulást nyújt be, de a karbantartó soha nem reagál, az illető elkedvetlenedhet és elhagyhatja a projektet. + +[Egy kutatás a Mozillától](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) azt mutatta ki, hogy a karbantartók reakcióideje és készsége kritikus tényező a folyamatos hozzájárulások eléréséhez. + +Fontold meg annak nyomon követését, hogy mennyi időt vesz igénybe, amíg válaszolsz (te vagy másik karbantartó) a hozzájárulásokra, függetlenül attól, hogy az hibajegy vagy beolvasztási kérelem-e. A válasz nem jelenti azt, hogy cselekedni is kell. Például lehet ennyi: _"Köszönöm a hozzájárulásod! Jövő héten tudom átnézni."_ + +Meg tudod azt is mérni, hogy a hozzájárulási folyamat különböző fázisai között mennyi idő telik el, például: + +* Átlagosan mennyi ideig van nyitva egy hibajegy +* Vajon mennyi hibajegy van lezárva beolvasztási kérelemmel +* Vajon mennyi régi, már nem aktuális hibajegyet kellett lezárni +* Egy beolvasztási kérelem elfogadásának és beolvasztásának átlagos ideje + +## Használj 📊 hogy többet tudj meg a közösségről + +A metrikák megértése segít egy aktív, fejlődő nyílt forráskódú projekt létrehozásában. Még ha nem is követed nyomon az összes metrikát, használd a fenti módszereket, hogy lásd a viselkedési mintákat, amelyek segítik a projektedet. diff --git a/_articles/hu/security-best-practices-for-your-project.md b/_articles/hu/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..e754bf61e71 --- /dev/null +++ b/_articles/hu/security-best-practices-for-your-project.md @@ -0,0 +1,158 @@ +--- +lang: hu +untranslated: true +title: Security Best Practices for your Project +description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security. + +## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA) + +### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages. + +Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services. + +MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to. + +## Secure your code as part of your development workflow + +### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production. + +Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases. + +It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code. + +How to choose your SAST tool? +Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep. +Check the coverage for your language(s) + +* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them. +* Beware of False Positives! You don't want the tool to slow you down for no reason! +* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep). + +## Don't share your secrets + +### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository. + +Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes. + +To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you. + +## Check and update your dependencies + +### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task. + +Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data. + +To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. + +## Understand and manage open source license risks + +### Open source licenses come with terms and ignoring them can lead to legal and reputational risks. + +Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs. + +Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit. + +To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project. + +Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively. + +Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe. + +## Avoid unwanted changes with protected branches + +### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project. + +A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time. + +## Make it easy (and safe) to report security issues + +### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers? + +Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users. + +### Security Policy + +To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process. + +### Private Vulnerability Reporting + +On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool. + +### Define your threat model to help users and researchers understand scope + +Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions. + +A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies. + +A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context. + +If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own. + +Publishing a basic threat model alongside your security policy improves clarity for everyone. + +## Prepare a lightweight incident response process + +### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers. + +Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference. + + + +Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next? + +Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously. + +Your process doesn't have to be complex. At minimum, define: + +* Who reviews and triages security reports or alerts +* How severity is evaluated and how mitigation decisions are made +* What steps you take to prepare a fix and coordinate disclosure +* How you notify affected users, contributors, or downstream consumers + +An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust. + +For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan. + +This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident. + +## Treat security as a team effort + +### Security isn't a solo responsibility. It works best when shared across your project's community. + +While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively. + +Here are a few ways to make security a team sport: + +* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches. +* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly. +* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning). +* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook. +* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed. + +Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone. + +## Conclusion: A few steps for you, a huge improvement for your users + +These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues. + +Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface. + +## Contributors + +### Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: + +[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others! diff --git a/_articles/hu/starting-a-project.md b/_articles/hu/starting-a-project.md new file mode 100644 index 00000000000..4449eb7be6d --- /dev/null +++ b/_articles/hu/starting-a-project.md @@ -0,0 +1,357 @@ +--- +lang: hu +title: Nyílt forráskódú projekt indítása +description: Tudj meg többet a nyílt forráskód világáról, és állj készen a saját projekted elindítására. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## A nyílt forráskód "mit" és "hogyan"-ja + +Szóval arra gondoltál, hogy elkezded a nyílt forráskódú projekted. Gratulálunk! A világ nagyra fogja értékeli a részvételed. Beszéljünk kicsi arról, hogy mi is az a nyílt forráskód, és miért csinálják az emberek. + +### Mit jelent a nyílt forráskód? + +Amikor egy projekt nyílt forráskódú, az azt jelenti, hogy **bárki szabadon használhatja, tanulmányozhatja, módosíthatja és terjesztheti bármilyen céllal.** Ezt a lehetőséget [az nyílt forráskódú licenc biztosítja](https://opensource.org/licenses). + +A nyílt forráskód azért hatásos, mert elhárítja az akadályt az együttműködés és a felhasználás elől, lehetővé teszi az emberek számára a gyors fejlesztést és terjesztést. És még azért is, mert a felhasználók számára lehetővé teszi, hogy kontrolljuk legyen a saját szoftvereik felett, ellenben a zárt forráskóddal. Például egy vállalkozás, amely nyílt forráskódot használ, képes lehet arra, hogy felbérel egy olyan fejelsztőt, aki elvégzi számára a szükséges fejlesztéseket, ahelyett, hogy kizárólag a zárt forrásúkódú szoftvert fejlesztő cég termékdöntéseire támaszkodna. + +_Free software_ kifejezés ugyanazokra a projektekre vonatkozik, mint amire az _open source_. Néhol láthatod [ezen kifejezések](https://en.wikipedia.org/wiki/Free_and_open-source_software) kombinációját is, mint például "free and open source software" (FOSS) vagy "free, libre, and open source software" (FLOSS). A _Free_ és _libre_ a _szabadságra_ utal, [nem az árra](#a-nyílt-forráskódú-projekt-ingyenességet-jelent). + +### Miért vesznek részt az emberek a nyílt forráskódú projektekben? + + + +[Számos oka van](https://ben.balter.com/2015/11/23/why-open-source/) hogy valaki, vagy akár egy cég a nyílt forráskódban részt vesz. Csak néhány példa: + +* **Együttműködés:** A nyílt forráskódú projektek bárkitől elfogadnak módosítást a világ bármely részéről. [Exercism](https://github.com/exercism/), például egy programozási gyakorlást segítő projekt több, mint 350 fejlesztő részvételével. + +* **Elterjedés és újrafelhasználás:** A nyílt forráskódú projekteket bárki használhatja szinte bármilyen célra. Az emberek akár más dolgok létrehozására is felhasználhatják. A [WordPress](https://github.com/WordPress) például úgy kezdte, hogy egy létező, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) nevű projektet elágaztattak. + +* **Átláthatóság:** A nyílt forráskódú projektet bárki megvizsgálhatja, vagy hibákat kereshet benne. Az átláthatóság a kormányoknak is fontos, mint ahogy [Bulgária](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) teszi ezt, vagy ahogy az [Amerikai Egyesült Államok](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) szabályozza a bank, és egészségügy iparát, de fontos a biztonsági szoftverek esetén is, mint a [Let's Encrypt](https://github.com/letsencrypt). + +A nyílt forráskódú projekt nem csak szoftver lehet. Lehet ez adat, vagy könyv is akár, de bármi más is. Nézd meg a [GitHub Explore](https://github.com/explore) helyen, hogy mi minden lehet nyílt forráskódú projekt. + +### A nyílt forráskódú projekt ingyenességet jelent? + +A legtöbb nyílt forráskódú projekt nem kerül pénzbe. Az ingyenesség általában a nyílt forráskód következménye. + +Mivel [a nyílt forráskódú licenc előírja](https://opensource.org/osd-annotated) azt, hogy mindenki használhatja, módosíthatja és megoszthatja a projektet bármilyen célra, ezért maga a _projekt_ ingyenes. Ha a projekt úgy döntene, hogy pénzt kér tőled, akkor bárki legálisan másolatot készíthet róla és használhatja az ingyenes verziót helyette. + +Bár a nyílt forráskódú projekt önmagában ingyenes, a nyílt forráskód nem definiálja magát az ingyenességet. Van lehetőség arra, hogy pénzt kérj egy nyílt forráskódú projektért, a kettős licencelés, vagy a korlátozott funkciókon keresztül, ez még nem ütközik a nyílt forráskód definíciójával. + +## Elindíthatom a saját nyílt forráskódú projektemet? + +A rövid válasz igen, mert a saját projekten keresztül megismered a nyílt forráskódú projektek működését. + +Ha sohasem vettél részt még nyílt forráskódú projektben, akkor bátortalan lehetsz majd, ha majd az emberek reakcíója miatt, vagy ha felhívják a figyelmedet pár dologra. De emiatt ne aggódj, mert ez természetes, mással is így van! + +A nyílt forráskód egy kreatív viselkedést igénylő dolog, mint az írás vagy a festés. Lehet, először félelmetesnek tűnik, hogy megosztod a munkádat a világgal, de ez a legjobb módja annak, hogy fejlődj, hiszen nem leszel jobb, ha nem kapsz kritikákat. + +Ha még mindig nem lettél meggyőzve, akkor gondolkozz el azon, hogy mi is az igazi célod! + +### Célok kijelölése + +A célok segíthetnek abban, hogy kitaláld, min kell dolgoznod, mit kell mondanod, és hol van szükséged mások segítségére. Kérdezd meg magadtól, hogy _miért nyitom meg ezt a projektet?_ + +Nincs tökéletes válasz erre a kérdésre. Többféle célod lehet akár egy projekt esetén is, más projekteknél viszont más célok fognak vezérelni. + +Ha csak az a célod, hogy a munkádat megmutasd, akkor nem akarsz résztvevőket és ezt a README-ben le is írhatod. Másrészről, ha akarsz résztvevőket a projekteden, akkor időt kell szánnod az alapos dokumentációra, hogy az újonnan érkezők könnyen csatlakozhassanak. + + + +Ahogy a projekt növekszik, a közösségednek többre lehet szüksége, mint pusztán csak a kód. A nyílt forráskódú projektek fontos feladata a kérdések megválaszolása, a kódok áttekintése, és a projekt hírnevének terjesztése. + +A nem kódolási feladatokra fordított idő függ a projekt nagyságától és terjedelmétől, mint karbantartónak, neked is fel kell készülnöd arra, hogy találj valakit, aki segíthet ebben. + +**Ha egy olyan cég tagja van, aki nyílt forráskódú projekttel rendelkezik,** bizonyosodj meg arról, hogy vannak megfelelő belső erőforrások a projekthez. Azonosítsd azokat az embereket, akik a karbantartói feladatot fognak végezni rajta, és oszd meg a közösséggel ezeket a feladatokat. + +Ha szükséges fix költségvetés, vagy alkalmazotti kör a fejlesztéshez, vagy fenntartáshoz, akkor kezd el ezeket a egyeztetéseket minél korábban. + + + +### Hozzájárulás más projektekhez + +Ha a cél az, hogy megtanuld, hogyan működj együtt másokkal, vagy megértsd, hogyan működik a nyílt forráskód, fontold meg egy meglévő projekthez való hozzájárulást. Kezd azzal a projektel, amelyet már használsz, és szeretsz. A projekthez való hozzájárulást kezd olyan egyszerű dolgokkal, mint a helyesírási hibák javítása, vagy a dokumentáció frissítése. + +Ha nem vagy biztos abban, hogy hogyan kezdj neki, mint résztvevő, akkor nézd meg ezt: [How to Contribute to Open Source guide](../how-to-contribute/). + +## Saját nyílt forráskódú projekt indítása + +Nincs tökéletes időpont a forráskód megnyitására. Megnyithatsz egy ötletet, egy folyamatban lévő munkát, vagy akár egy olyan kódot is, ami évekig zárt volt. + +Általánosságban elmondható, hogy akkor kell a projekt forrását megnyitni, ha úgy érzed, hogy ha mások látják, és visszajelzést adnak a munkádról, az neked jó. + +Függetlenül attól, hogy melyik szakaszban döntöd el a projekt forrásának megnyitását, minden projektnek tartalmaznia kell a következő dokumentációt: + +* [Nyílt forráskódú licenc](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) +* [Résztvevőknek útmutató](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Magatartási kódex](../code-of-conduct/) + +Karbantartóként ezek az összetevők segítenek az elvárásaid közlésében, a résztvevők kezelésében és mindenki jogának a védelmében (beleértve a sajátodat is). Jelentősen növelik az esélyt arra, hogy pozitív tapasztalatokat szerezz. + +Ha a projekted a GitHub-on van, akkor ezek a fájlok a gyökérkönyvtárba kerüljenek az ajánlott fájlnevekkel, így a GitHub felismeri és automatikusan értesíti az olvasókat. + +### Licence választás + +A nyílt forráskódú licenc garantálja, hogy mások használhassák, másolhassák, módosíthassák és hozzájárulhassanak a projekthez szabadon. Emellett megvéd a kiszámíthatatlan jogi helyzetektől. **A licencet a nyílt forráskódú projekt indításával együtt kell megadni.** + +A jogi munka nem öröm. A jó hír azonban az, hogy a licencet egyszerűen elhelyezheted a projektedben, csak be kell másolni. Csak néhány percet igényel az, hogy megvédd a munkádat. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), és a [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) a leghíresebb licencek, de [van számos másik is](https://choosealicense.com) amelyből választhatsz. + +Amikor új projektet hozol létre a GitHub-on, lehetőséget kapsz licenc választásra. Nyílt forráskódú licenccel a projekted nyílt forráskódú lesz. + +![Válassz egy licencet!](/assets/images/starting-a-project/repository-license-picker.png) + +Ha egyéb kérdésed, vagy kételyed van a nyílt forráskódú projektek jogi részével kapcsolatban, akkor [bővebb információt itt találsz](../legal/). + +### README írása + +README több annál, mint hogy leírod azt, hogy hogyan kell a projektet használni. Elmagyarázza azt is, hogy miért lényeges a projekted, és hogy hogyan tud abban más is részt venni. + +A README-ben próbáld meg az alábbiakra megadni a választ: + +* Mit csinál a projekt? +* Miért hasznos a projekt? +* Hogyan lehet elkezdeni vele dolgozni? +* Hol találok további segítséget, ha szükségem van rá? + +A README meg tudja még válaszolni azt, hogy hogyan fogadsz el közreműködést, mi a projekt célja, és információkat ad a licencről és további részletekről. Ha nem fogadsz el közreműködést a projektben, vagy a projekted nincs még abban az állapotban, hogy éles működésben használható legyen, akkor szintén írd le ezeket az információkat a README-ben. + + + +Néha az emberek épp azért nem írnak README-t, mert úgy hiszik, hogy még nincs befejezve projektjük, vagy úgy gondolják hogy nem akarnak részvételt benne. Pedig éppen ezek nagyon jó okok arra, hogy a README-t megírjuk. + +Továbbiakért nézd meg @dguo ["README" útmutató készítése](https://www.makeareadme.com/) vagy @PurpleBooth [README űrlap](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) című munkáját, így jó README-t írhatsz. + +Amikor a README állományt a főkönyvtárba teszed, a GitHub automatikusan megjeleníti azt a kódtározó főoldalán. + +### Részvételi irányelvek leírása + +A CONTRIBUTING állomány közli az emberekkel, hogy hogyan lehet részt venni a projektben. Például ezeket az információkat lehet megadni: + +* Hogyan jelents egy hibát (próbáld használni a [hiba és beolvasztási kérés űrlapokat](https://github.com/blog/2111-issue-and-pull-request-templates)) +* Hogyan javasolj új funkciót +* Hogyan állítsd be a környezetedet, és futtasd a teszteket + +A műszaki adatokon kívül, a CONTRIBUTING fájl lehetőséget nyújt arra, hogy közölje a résztvevőkkel, a részvételre vonatkozó elvárásaid, például: + +* Milyen típusú résztvevőket vársz +* A roadmap-je és víziója a projektednek +* A résztvevők hogyan (vagy hogyan nem) léphetnek veled kapcsolatba + +Kedves, barátságos hang használata, és konkrét javaslatok nyújtása a hozzájárulásokhoz (például dokumentáció készítése vagy weboldal készítése) nagyban hozzájárulhat ahhoz, hogy az újonnan érkezők azt érezzék, hogy szívesen látják őket, és örüljenek a részvételnek. + +Például az [Active Admin](https://github.com/activeadmin/activeadmin/) a [saját részvételi szabályzatát](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) ezzel kezdi: + +> Legelőször is, köszönöm hogy részt kívánsz venni az Active Admin projektben. Az olyan emberek mint te, tehetik az Active Admin ilyen nagyszerű eszközzé. + +A CONTRIBUTING állomány a projekt korai fázisában egyszerű. Mindig el kell megmagyaráznod benne, hogy hogyan lehet hibát vagy egyéb problémát jelezni, a szükséges technikai igényeket, például a teszteket is le kell írni benne ahhoz, hogy valaki a projekten tudjon dolgozni. + +Idővel további gyakori kérdéseket adhatsz hozzá a CONTRIBUTING fájlhoz. Ezen információk írása azt jelenti, hogy kevesebb ember fogja újra és újra ugyanazt a kérdést feltenni. + +További segítségért a CONTRIBUTING írásához, nézd meg @nayafia [részvételi útmutató űrlapját](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) vagy a @mozilla's ["Hogyan építs CONTRIBUTING.md-t?"](https://mozillascience.github.io/working-open-workshop/contributing/). + +A CONTRIBUTING állományra hivatkozhatsz a README állományból, így az emberek azonnal látják azt. Ha [elhelyezed a CONTRIBUTING állományt a projekt alatt](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), akkor a GitHub automatikusan linkelni fogja azt, ha valaki hibát jelent, vagy beolvasztási kérést hoz létre. + +![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Magatartási kódex létrehozása + + + +A magatartási kódex segít az alapjait lefektetni a viselkedési szabályoknak a projekt résztvevők számára. Különösen értékes, ha egy nyílt forráskódú projektet indítasz egy közösség, vagy a cég számára. A magatartási kódex erősíti az egészséges, konstruktív, közösségi viselkedést, ami csökkenteni fogja a stresszt a karbantartók számára is. + +További információkért nézd meg: [Magatartási kódex útmutató](../code-of-conduct/). + +Amellett, hogy a magatartási kódex leírja, hogy hogyan kell viselkedni, azt is megadja, hogy kikre vonatkozik, mikor vonatkozik rájuk, és mi történik akkor, hogyha azt megsértik. + +Mint a nyílt forráskódú licenc esetén, itt is számos standard van a viselkedési szabály kódexre, így nem kell sajátot írnod. A [Résztvevői Megállapodás](https://contributor-covenant.org/) egy azonnal használható magatartási kódex, amelyet több mint [40,000 nyílt forráskódú projekt](https://www.contributor-covenant.org/adopters) használ, mint például a Kubernetes, Rails, vagy a Swift. Lényegtelen, hogy mit használsz ezekből, de az fontos, hogy kikényszerítsd ennek betartását. + +A kód mellé helyezd el CODE_OF_CONDUCT állományt. A főkönyvtárba tedd a README mellé, és hivatkozd meg a README állományból. + +## A projekt elnevezése és brand építés + +A brand építés több mint egy vagány logó, vagy egy megkapó projekt név. Arról szól, hogy hogyan kommunikálod a projektet, és kiket akarsz elérni vele. + +### A megfelelő név kiválasztása + +Válassz egy nevet, amelyet könnyen megjegyezhetsz, és ideális esetben sugall valamit arról, hogy mit is csinál a projekt. Például: + +* [Sentry](https://github.com/getsentry/sentry) Őrszem – monitorozza az alkalmazás hibákat +* [Thin](https://github.com/macournoyer/thin) Vékony – gyors, és egyszerű Ruby webszerver + +Ha már létező projektre alapozol, a nevét előtagként használva segít tisztázni, hogy mit csinál a projekt (például [node-fetch](https://github.com/bitinn/node-fetch) a `window.fetch` funkciót valósítja meg a Node.js alatt). + +Gondolj mindenekelőtt az egyértelműségre. A szójáték szórakoztató, de ne feledd, hogy néhány vicc érthetetlen más kultúrák, vagy emberek számára. Lehet, hogy a potenciális felhasználók egy része vállalati alkalmazott: nem akarod, hogy kényelmetlenül érezzék magukat, ha munkájuk során elő kell adniuk a projektedet! + +### Kerüld el a névütközést + +[Ellenőrizd a hasonló nevű, nyílt forráskódú projekteket](http://ivantomic.com/projects/ospnc/), különösen akkor, ha ugyanaz a fejlesztői nyelv vagy ökoszisztéma érintett. Ha a neve átfed egy népszerű, meglévő projektével, akkor az zavart okozhat. + +Ha weboldalt akarsz, vagy Twitter bejegyzéseket, vagy egyéb dolgot, amely a projektedet reprezentálja, akkor is legyél biztos a projekt nevében. Jó esetben [előre le kell foglalnod a domain nevet](https://instantdomainsearch.com/) a nyugalmad érdekében, még akkor is, ha most nem akarod használni. + +Győződj meg róla, hogy a projekt neve nem sért védjegyeket. Egy vállalat kérheti később, hogy állítsd le a projekted, vagy akár jogi lépéseket is tehet ellened. Ez nem éri meg a kockázatot. + +Ezen az oldalon [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) tudod ellenőrizni a bejegyzett kereskedelmi neveket. Ha cégnél dolgozol, akkor ezt a [cég jogi osztálya is el tudja végezni](../legal/). + +És végül, végezz egy gyors Google keresést a projekt nevével. Az emberek könnyen megtalálják majd a projektet? Van olyan dolog, ami a keresési eredményekben jelenik meg, és amit nem szeretnél ott látni? + +### Ahogyan írsz (akár kódot is) az hatással van a brand-re! + +A projekt élettartama alatt rengeteg írást készítesz: README-k, oktatóanyagok, közösségi dokumentumok, kérdésekre adott válaszok, talán még hírleveleket és levelezőlistákat is. + +Akár hivatalos dokumentáció, akár alkalmi e-mail, az írási stílusa része a projekt brand-nek. Fontold meg, hogy az a hangnem, amit szeretnél közvetíteni, befogadható-e a közösségnek akiknek szánod. + + + +A kedves, befogadó nyelv használatával jó úton jársz a projekt résztvevőinek megszerzésében és megtartásában. Használj egyszerű nyelvezetet, mivel sok olvasó nem feltétlenül angol (vagy a projekt nyelvnek megfelelő) anyanyelvű. + +A viselkedési stílusodon túl, a kód stílusa is része lehet a projekt márkájának. [Angular](https://angular.io/guide/styleguide) és a [jQuery](https://contribute.jquery.org/style-guide/js/) két példa a szigorú kódolási stílusokkal, és iránymutatásokkal rendelkező projektekre. + +Nem kell stílus útmutatót írni a projekthez, amikor éppen elkezdted, vagy ha esetleg különböző kódolási stílusokat használsz a projektben. De tisztában kell lenni azzal, hogy az írási és kódolási stílus hogyan vonzhatja, vagy riaszthatja el a különböző típusú embereket. A projekt legkorábbi szakasza lehetőséget ad arra, hogy meghatározd a kívánt mintát, amit elvársz a későbbiekben a résztvevőktől. + +## Indulás előtti ellenőrző lista + +Készen állsz a nyílt forráskódú projektre? Itt egy ellenőrzőlista, amely ebben segít. Leellenőrizted az összes pontot? Akkor készen állsz! [Válaszd a "publish" linket](https://help.github.com/articles/making-a-private-repository-public/) és indulhat a publikálás! + +**Dokumentáció** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Code** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Emberek** + +Ha magánszemély vagy, akkor: + +
+ + +
+ +Ha szervezet, vagy cég vagy, akkor: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## Megcsináltad! + +Gratulálunk, az első nyílt forráskódú projektedhez! Az eredménytől függetlenül a nyilvános munkád jelentős ajándék a közösségnek. Minden _commit_-tal, kommenttel és beolvasztási kérelemmel lehetőséget teremtettél magadnak és másoknak, hogy tanuljanak és fejlődhessenek. diff --git a/_articles/id/best-practices.md b/_articles/id/best-practices.md index 3155d15f43f..4ab11ff70c2 100644 --- a/_articles/id/best-practices.md +++ b/_articles/id/best-practices.md @@ -3,13 +3,6 @@ lang: id title: Kiat Baik untuk Pengelola description: Mempermudah hidup Anda sebagai pengelola open source, mulai dari mendokumentasikan proses hingga memberdayakan komunitas Anda. class: best-practices -toc: - apa-artinya-menjadi-pengelola: "Apa artinya menjadi pengelola?" - mendokumentasikan-proses-anda: "Mendokumentasikan proses Anda" - belajar-untuk-mengatakan-tidak: "Belajar untuk mengatakan tidak" - berdayakan-komunitas-anda: "Berdayakan komunitas Anda" - manfaatkan-robot: "Manfaatkan robot" - ok-untuk-berhenti-sejenak: "OK untuk berhenti sejenak" order: 5 image: /assets/images/cards/best-practices.png related: @@ -112,7 +105,7 @@ Jika Anda menerima kontribusi yang tidak Anda inginkan, reaksi pertama Anda mung Jangan biarkan kontribusi yang tidak diinginkan tetap terbuka karena Anda merasa bersalah atau ingin bersikap baik. Pada akhirnya, masalah yang tidak terjawab dan PR akan membuat pekerjaan proyek Anda menjadi lebih berat dan mengintimidasi Anda. -Akan lebih baik untuk langsung menutup kontribusi yang Anda tahu tidak akan diterima. Jika proyek Anda mengalami hambatan yang besar, @steveklabnik memiliki saran untuk [mengatasi laporan masalah secara efisien](http://words.steveklabnik.com/how-to-be-an-open-source-gardener). +Akan lebih baik untuk langsung menutup kontribusi yang Anda tahu tidak akan diterima. Jika proyek Anda mengalami hambatan yang besar, @steveklabnik memiliki saran untuk [mengatasi laporan masalah secara efisien](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). Kedua, mengabaikan kontribusi akan mengirimkan sinyal negatif pada komunitas Anda. Berkontribusi pada sebuah proyek bisa jadi menakutkan, apalagi untuk pertama kalinya bagi orang lain. Meskipun Anda tidak menerima kontribusi mereka, akui hasil pekerjaan mereka dan ucapkan terima kasih atas minat mereka. Itu adalah sebuah pujian yang besar! @@ -174,13 +167,13 @@ Jika Anda mencari orang lain untuk bergabung, mulailah dengan bertanya. Ketika Anda melihat kontributor baru melakukan kontribusi secara rutin, hargai pekerjaan mereka dengan menawarkan tanggung jawab yang lebih besar. Dokumentasikan bagaimana orang lain bisa menjadi seorang pemimpin. -Doronglah orang lain untuk [berbagi kepemilikan proyek](../building-community/#berbagi-kepemilikan-dari-proyek-anda) dan hal itu bisa mengurangi beban pekerjaan Anda secara drastis, seperti yang ditemukan @lmccart pada proyeknya, [p5.js](https://github.com/processing/p5.js?files=1). +Doronglah orang lain untuk [berbagi kepemilikan proyek](../building-community/#berbagi-kepemilikan-dari-proyek-anda) dan hal itu bisa mengurangi beban pekerjaan Anda secara drastis, seperti yang ditemukan @lmccart pada proyeknya, [p5.js](https://github.com/processing/p5.js). @@ -188,7 +181,7 @@ Jika Anda perlu sedikit menjauh dari proyek Anda, baik sementara atau selamanya, Jika orang lain sangat antusias dengan arah proyek Anda, berikan akses atau serahkan kendali pada orang lain. Jika seseorang melakukan _fork_ terhadap proyek Anda dan mengelolanya secara aktif di tempat lain, pertimbangkan untuk menghubungkan ke proyek tersebut melalui proyek Anda. Sangatlah hebat melihat banyak orang menginginkan proyek Anda terus hidup.! -@progrium [menemukan bahwa](http://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) dengan mendokumentasikan visi proyeknya, [Dokku](https://github.com/dokku/dokku), membantu tujuannya tetap bertahan meskipun dia sudah meninggalkan proyeknya: +@progrium [menemukan bahwa](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) dengan mendokumentasikan visi proyeknya, [Dokku](https://github.com/dokku/dokku), membantu tujuannya tetap bertahan meskipun dia sudah meninggalkan proyeknya: > Saya menuliskan sebuah halaman wiki menjelaskan tentang apa yang saya inginkan dan kenapa. Mengejutkan bagi saya karena pengelola mulai menjalankan proyek sesuai dengan arahan tersebut! Apakah ia melakukannya sesuai dengan apa yang saya kehendaki? Tidak selalu, tetapi ia membawa proyek ini semakin dekat dengan apa yang saya tuliskan. @@ -206,7 +199,7 @@ Melakukan sebuah _fork_ terhadap sebuah proyek bukan berarti sesuatu yang jelek.

-Hal yang sama juga terjadi pada pengguna yang menginginkan solusi dimana Anda tidak mampu membangunnya karena keterbatasan bandwidth. Menawarkan API dan hook bisa membantu orang lain memenuhi kebutuhan mereka, tanpa harus memodifikasi kode secara langsung. @orta [menemukan](http://artsy.github.io/blog/2016/07/03/handling-big-projects/) bahwa mendorong plugin untuk CocoaPods mengarah pada "beberapa ide menarik": +Hal yang sama juga terjadi pada pengguna yang menginginkan solusi dimana Anda tidak mampu membangunnya karena keterbatasan bandwidth. Menawarkan API dan hook bisa membantu orang lain memenuhi kebutuhan mereka, tanpa harus memodifikasi kode secara langsung. @orta [menemukan](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) bahwa mendorong plugin untuk CocoaPods mengarah pada "beberapa ide menarik": > Sangatlah susah untuk dihindari bahwa ketika sebuah proyek sudah semakin besar, pengelola harus menjadi lebih konsevatif tentang bagaimana mereka memperkenalkan kode baru. Anda menjadi lebih pandai dalam mengatakan "tidak", tetapi banyak orang memiliki kebutuhan yang pasti. Jadi, Anda akan mengubah alat Anda menjadi sebuah platform. @@ -228,7 +221,7 @@ Jika Anda menambahkan pengujian, pastikan untuk menjelaskan bagaimana mereka bek avatar Saya percaya bahwa pengujian otomatis sangat diperlukan untuk semua kode yang dikerjakan orang-orang. Jika kode tersebut benar, maka tidak diperlukan perubahan - kita hanya menuliskan kode apabila terjadi kesalahan, apakah "crash" atau "kurang fitur". Tanpa memperhatikan perubahan yang Anda lakukan, pengujian otomatis sangatlah penting untuk menangkap regresi kesalahan yang mungkin Anda timbulkan.

-— @edunham, ["Rust's Community Automation"](http://edunham.net/2016/09/27/rust_s_community_automation.html) +— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)

@@ -266,7 +259,7 @@ Sama halnya seperti pekerjaan lainnya, mengambil liburan secara berkala akan mem avatar Dalam mengelola WP-CLI, Saya menemukan bahwa saya perlu membuat diri saya bahagia terlebih dahulu, dan menentukan batas keterlibatan saya dengan jelas. Keseimbangan terbaik yang saya temukan adalah 2-5 jam per minggu sebagai bagian dari jadwal pekerjaan normal saya. Hal ini menjaga keterlibatan saya sebagai sebuah gairah. Karena saya memprioritaskan masalah-masalah yang saya kerjakan, saya bisa membuat kemajuan berkala tentang apa yang saya anggap penting.

-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/id/building-community.md b/_articles/id/building-community.md index 7a4783e1289..01235e4efda 100644 --- a/_articles/id/building-community.md +++ b/_articles/id/building-community.md @@ -3,10 +3,6 @@ lang: id title: Membangun Komunitas yang Ramah description: Membangun komunitas yang mendorong orang lain untuk menggunakan, berkontribusi, dan mempromosikan proyek Anda. class: building -toc: - mengarahkan-proyek-anda-untuk-kesuksesan: "Mengarahkan proyek Anda untuk kesuksesan" - mengembangkan-komunitas-anda: "Mengembangkan komunitas Anda" - menyelesaikan-konflik: "Menyelesaikan konflik" order: 4 image: /assets/images/cards/building.png related: @@ -22,7 +18,7 @@ Sebuah komunitas yang ramah merupakan investasi pada masa depan dan reputasi pro ### Buatlah agar orang-orang merasa diterima -Satu cara untuk memikirkan komunitas proyek Anda adalah melalui apa yang disebut @MikeMcQuaid sebagai [saluran kontributor](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel): +Satu cara untuk memikirkan komunitas proyek Anda adalah melalui apa yang disebut @MikeMcQuaid sebagai [saluran kontributor](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) @@ -58,7 +54,7 @@ Mendorong kontributor lain adalah sebuah investasi pada diri Anda juga. Ketika A avatar Apakah Anda pernah menghadiri sebuah acara dimana Anda tidak mengenal siapapun, tetapi orang lain tampak saling mengenal satu sama lain dan berbicara seperti sahabat dekat? (...) Sekarang bayangkan Anda ingin berkontribusi pada proyek open source, namun Anda tidak dapat melihat kenapa dan bagaimana ini bisa terjadi.

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

@@ -117,10 +113,10 @@ Sembarang proyek yang terkenal akan menarik orang lain untuk merusak dibandingka Lakukan yang terbaik untuk mengadopsi kebijakan tanpa toleransi terhadap orang-orang jenis ini. Jika dibiarkan, orang-orang negatif ini akan membuat orang lain menjadi tidak nyaman. Bahkan mereka bisa meninggalkan proyek Anda. @@ -136,23 +132,23 @@ Pada dokumen CONTRIBUTING, jelaskan secara eksplisit bagaimana kontributor baru ![django new contributors page](/assets/images/building-community/django_new_contributors.png) -Pada daftar laporan masalah Anda, tandai masalah yang cocok untuk setiap jenis kontributor yang berbeda: misalnya, [_"hanya pemula"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), _"laporan kesalahan pertama"_, atau _"dokumentasi"_. [Label ini](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) mempermudah orang yang baru pada proyek Anda untuk mencari daftar laporan masalah dan mulai berkontribusi. +Pada daftar laporan masalah Anda, tandai masalah yang cocok untuk setiap jenis kontributor yang berbeda: misalnya, [_"hanya pemula"_](https://kentcdodds.com/blog/first-timers-only), _"laporan kesalahan pertama"_, atau _"dokumentasi"_. [Label ini](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) mempermudah orang yang baru pada proyek Anda untuk mencari daftar laporan masalah dan mulai berkontribusi. Akhirnya, gunakan dokumentasi Anda untuk membuat orang lain nyaman pada setiap langkahnya. Anda tidak akan pernah berinteraksi dengan sebagian besar orang-orang yang hadir pada proyek Anda. Bisa jadi terdapat kontribusi yang tidak Anda dapatkan karena seseorang merasa terintimidasi atau tidak tahu bagaimana memulainya. Sebuah kata-kata sederhana bisa menjaga mereka untuk tetap bertahan dan bebas dari rasa frustasi. -Sebagai contoh, berikut bagaimana cara [Rubinius](https://github.com/rubinius/rubinius/) memulai [panduan kontribusinya](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md): +Sebagai contoh, berikut bagaimana cara [Rubinius](https://github.com/rubinius/rubinius/) memulai [panduan kontribusinya](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): > Kita ingin memulainya dengan mengucapkan terima kasih karena menggunakan Rubinius. Proyek ini merupakan hasil cinta kami, dan kami menghargai semua pengguna yang menemukan kesalahan, membuat perbaikan performa, dan membantu dengan dokumentasi. Setiap kontribusi sangat berharga, sehingga kami mengucapkan terima kasih untuk berpartisipasi. Meski demikian, berikut adalah beberapa panduan yang kami harapkan untuk bisa diikuti sehingga kami bisa menyelesaikan permasalahan Anda dengan baik. ### Berbagi kepemilikan dari proyek Anda @@ -164,15 +160,15 @@ Cari cara untuk bisa berbagi kepemilikan dengan komunitas Anda sebanyak mungkin. ![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) -* **Bualah dokumen CONTRIBUTORS atau AUTHORS pada proyek Anda** yang mendata semua orang yang berkontribusi pada proyek Anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md). +* **Bualah dokumen CONTRIBUTORS atau AUTHORS pada proyek Anda** yang mendata semua orang yang berkontribusi pada proyek Anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). * Jika Anda memiliki komunitas yang cukup besar, **kirimkan surat berita atau tuliskan blog** dan ucapkan terima kasih pada kontributor. [This Week in Rust](https://this-week-in-rust.org/) milik Rust dan [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) milik Hoodie adalah dua contoh bagus. -* **Berikan setiap kontributor akses commit.** @felixge menemukan bahwa hal ini membuat orang lain [lebih tertarik untuk memperbaiki perbaikan mereka](http://felixge.de/2013/03/11/the-pull-request-hack.html), dan dia juga menemukan pengelola baru untuk proyek yang tidak dia kelola selama beberapa waktu. +* **Berikan setiap kontributor akses commit.** @felixge menemukan bahwa hal ini membuat orang lain [lebih tertarik untuk memperbaiki perbaikan mereka](https://felixge.de/2013/03/11/the-pull-request-hack.html), dan dia juga menemukan pengelola baru untuk proyek yang tidak dia kelola selama beberapa waktu. * Jika proyek Anda berada pada GitHub, **pindahkan proyek Anda dari akun personal ke [Organisasi](https://help.github.com/articles/creating-a-new-organization-account/)** dan tambahkan paling tidak satu admin cadangan. Organisasi mempermudah pekerjaan kolaborasi dengan kolaborator eksternal. -Kenyataannya adalah [sebagian besar proyek hanya memiliki](https://peerj.com/preprints/1233.pdf) satu atau dua pengeloa yang melakukan sebagian besar pekerjaan. Semakin besar proyek Anda, dan semakin besar komunitas Anda, semakin mudah untuk menemukan bantuan. +Kenyataannya adalah [sebagian besar proyek hanya memiliki](https://peerj.com/preprints/1233/) satu atau dua pengeloa yang melakukan sebagian besar pekerjaan. Semakin besar proyek Anda, dan semakin besar komunitas Anda, semakin mudah untuk menemukan bantuan. Meskipun tidak selalu mudah untuk mendapatkan orang yang memenuhi panggilan Anda, memberikan sinyal akan meningkatkan peluang dimana orang lain akan ikut terlibat. Dan semakin cepat Anda melakukannya, semakin cepat pula orang akan datang membantu. @@ -202,7 +198,7 @@ Tugas Anda sebagai pengelola adalah menjaga situasi ini agar tidak sampai memunc avatar Sebagai pengelola proyek, sangatlah penting untuk menghargai kontributor Anda. Mereka seringkali menerima apa yang Anda sampaikan secara personal.

-— @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)

@@ -218,7 +214,7 @@ Dokumen README [lebih dari sekedar sekumpulan instruksi](../starting-a-project/# Beberapa proyek menggunakan proses pemilihan suara model voting untuk pengambilan keputusan yang besar. Meskipun masuk akal di awal, voting berfokus pada mendapatkan "jawaban", dan bukan pada mendengarkan dan menjawab kekhawatiran orang lain. -Voting bisa sangat politis, dimana anggota komunitas merasa tertekan untuk melakukannya. Tidak semua memberikan suaranya, baik sebagai [silent majority](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) pada komunitas Anda, atau pengguna yang tidak tahu bahwa terjadi voting. +Voting bisa sangat politis, dimana anggota komunitas merasa tertekan untuk melakukannya. Tidak semua memberikan suaranya, baik sebagai [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) pada komunitas Anda, atau pengguna yang tidak tahu bahwa terjadi voting. Seringkali voting memang diperlukan untuk memecah kebuntuan. Namun tekankan ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) daripada konsensus. @@ -228,7 +224,7 @@ Pada proses _consensus seeking_, anggota komunitas mendiskusikan masalah utama s avatar Salah satu alasan kenapa sistem voting tidak berlaku untuk masalah Atom adalah karena tim Atom tidak akan mengikuti sistem voting pada setiap kasusnya. Seringkali kami harus memilih apa yang kami rasa benar meskipun tidak populer. (...) Apa yang bisa saya tawarkan dan janjikan...adalah karena itu merupakan pekerjaan saya untuk mendengarkan komunitas.

-— @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

@@ -254,7 +250,7 @@ Jika sebuah diskusi tidak mengarah kemana-mana, tidak ada tindakan yang jelas ya avatar Mengarahkan sebuah diskusi pada sebuah kegunaan tanpa bersifat memaksa adalah sebuah seni. Hal ini tidak semudah untuk meminta orang-orang untuk menghabiskan waktu mereka, atau meminta mereka untuk tidak memberikan komentar kecuali mereka memiliki ide yang konstruktif. (...) Anda harus menyarankan kondisi untuk peningkatan lebih lanjut: berikan rute kepada orang, jalur yang bisa diikuti yang mengarah pada hasil yang Anda inginkan, tanpa seolah-olah Anda mengatur perilaku mereka.

-— @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/id/code-of-conduct.md b/_articles/id/code-of-conduct.md index 9388a8891d2..c6c1dce206d 100644 --- a/_articles/id/code-of-conduct.md +++ b/_articles/id/code-of-conduct.md @@ -3,11 +3,6 @@ lang: id title: Kode Etik Anda description: Fasilitasi perilaku komunitas yang sehat dan konstruktif dengan mengadopsi dan menerapkan kode etik. class: coc -toc: - kenapa-saya-perlu-menerapkan-kode-etik: "Kenapa saya perlu menerapkan kode etik?" - membuat-kode-etik: "Membuat kode etik" - menentukan-bagaimana-anda-akan-menerapkan-kode-etik: "Menentukan bagaimana Anda akan menerapkan kode etik" - menerapkan-kode-etik: "Menerapkan kode etik" order: 8 image: /assets/images/cards/coc.png related: @@ -34,9 +29,9 @@ Selain mengkomunikasikan ekspektasi Anda, kode etik juga menjelaskan beberapa ha * Apa yang terjadi jika seseorang melanggar kode etik * Bagaimana seseorang dapat melaporkan pelanggaran -Apabila dimungkinkan, gunakan yang sudah ada. [Contributor Covenant](http://contributor-covenant.org/) adalah kode etik yang bisa digunakan dan sudah digunakan oleh lebih dari 40.000 proyek open source, termasuk Kubernetes, Rails, dan Swift. +Apabila dimungkinkan, gunakan yang sudah ada. [Contributor Covenant](https://www.contributor-covenant.org/) adalah kode etik yang bisa digunakan dan sudah digunakan oleh lebih dari 40.000 proyek open source, termasuk Kubernetes, Rails, dan Swift. -[Kode etik Django](https://www.djangoproject.com/conduct/) dan [Kode etik Warga](http://citizencodeofconduct.org/) adalah dua contoh kode etik yang bagus. +[Kode etik Django](https://www.djangoproject.com/conduct/) dan [Kode etik Warga](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) adalah dua contoh kode etik yang bagus. Tempatkan dokumen CODE_OF_CONDUCT pada induk direktori proyek Anda, dan hubungkan dari dokumen README sehingga terlihat dengan jelas oleh komunitas Anda. @@ -45,7 +40,7 @@ Tempatkan dokumen CODE_OF_CONDUCT pada induk direktori proyek Anda, dan hubungka @@ -59,7 +54,7 @@ Anda harus menjelaskan bagaimana kode etik Anda akan diterapkan **_sebelum_** pe Anda harus memberikan sebuah jalan yang pribadi (seperti alamat email) untuk melaporkan pelanggaran kode etik dan menjelaskan siapa yang menerima laporan tersebut. Penerima laporan bisa jadi pengelola, sekelompok orang pengelola, atau tim kode etik. -Jangan lupa bahwa seseorang mungkin melaporkan pelanggaran terhadap orang yang akan menerima laporan tersebut. Pada kasus ini, berikan opsi untuk melaporkan pelanggaran pada orang lain. Misalnya, @ctb dan @mr-c [menjelaskan pada proyek mereka](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Jangan lupa bahwa seseorang mungkin melaporkan pelanggaran terhadap orang yang akan menerima laporan tersebut. Pada kasus ini, berikan opsi untuk melaporkan pelanggaran pada orang lain. Misalnya, @ctb dan @mr-c [menjelaskan pada proyek mereka](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Perilaku kasar, melecehkan, atau perilaku lainnya yang tidak dapat diterima dapat dilaporkan dengan mengirimkan email pada **khmer-project@idyll.org** yang akan sampai pada C. Titus Brown dan Michael R. Crusoe. Untuk melaporkan masalah pada salah satu dari mereka, kirimkan email pada **Judi Brown Clarke, Ph.D.** Direktur Diversity pada BEACON Center untuk Studi Evolusi, sebuah pusat studi NSF untuk Ilmu Pengetahuan dan Teknologi.* diff --git a/_articles/id/finding-users.md b/_articles/id/finding-users.md index 8a9aa3d3019..4244d95f423 100644 --- a/_articles/id/finding-users.md +++ b/_articles/id/finding-users.md @@ -3,13 +3,6 @@ lang: id title: Menemukan Pengguna untuk Proyek Anda description: Membantu proyek open source Anda untuk berkembang dengan cara menyampaikannya ke pengguna yang senang dengan proyek Anda class: finding -toc: - menyebarkan-kata: "Menyebarkan kata" - menentukan-pesan-anda: "Menentukan pesan Anda" - bantu-orang-lain-menemukan-dan-mengikuti-proyek-anda: "Bantu orang lain menemukan dan mengikuti proyek Anda" - ketika-pengguna-proyek-anda-online: "Ketika pengguna proyek Anda (online)" - ketika-pengguna-proyek-anda-offline: "Ketika pengguna proyek Anda (offline)" - membangun-sebuah-reputasi: "Membangun sebuah reputasi" order: 3 image: /assets/images/cards/finding.png related: @@ -33,7 +26,7 @@ Sebagai contoh, @robb menggunakan contoh kode program untuk menjelaskan kenapa p ![cartography readme](/assets/images/finding-users/cartography.jpg) -Untuk mendalami lebih dalam tentang penyampaian pesan, lihat panduan Mozilla ["Persona dan Jalur"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) untuk mengembangkan persona pengguna. +Untuk mendalami lebih dalam tentang penyampaian pesan, lihat panduan Mozilla ["Persona dan Jalur"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) untuk mengembangkan persona pengguna. ## Bantu orang lain menemukan dan mengikuti proyek Anda @@ -72,13 +65,13 @@ Ketika Anda telah memiliki pesan untuk proyek Anda dan cara mudah bagi orang lai Kegiatan outreach online merupakan cara yang bagus untuk berbagi dan menyebarkan informasi dengan cepat. Dengan menggunakan chanel online, Anda memiliki potensi untuk menjangkau jumlah pengguna yang sangat besar. -Ambil keuntungan dari komunitas dan platform online yang sudah ada untuk menjangkau pengguna Anda. Jika proyek open source Anda adalah proyek perangkat lunak, Anda mungkin bisa menjangkau proyek Anda melalui [Stack Overflow](http://stackoverflow.com/), [reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), atau [Quora](https://www.quora.com/). Temukan chanel yang Anda pikir orang-orang akan mendapatkan keuntungan dari pekerjaan Anda. +Ambil keuntungan dari komunitas dan platform online yang sudah ada untuk menjangkau pengguna Anda. Jika proyek open source Anda adalah proyek perangkat lunak, Anda mungkin bisa menjangkau proyek Anda melalui [Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), atau [Quora](https://www.quora.com/). Temukan chanel yang Anda pikir orang-orang akan mendapatkan keuntungan dari pekerjaan Anda. @@ -98,13 +91,13 @@ Jika tidak ada yang menanggapi atau merespon, jangan kecewa! Rilis proyek awal b Kegiatan _offline_ adalah cara yang populer untuk mempromosikan proyek baru. Kegiatan ini merupakan cara yang baik untuk menjangkau pengguna yang sibuk dan membangun koneksi yang lebih personal, terutama jika Anda tertarik untuk menjangkau para pengembang. -Jika Anda termasuk [awam pada komunikasi publik](http://speaking.io/), mulailah dengan mencari acara pertemuan lokal yang berhubungan dengan bahasa atau ekosistem dari proyek Anda. +Jika Anda termasuk [awam pada komunikasi publik](https://speaking.io/), mulailah dengan mencari acara pertemuan lokal yang berhubungan dengan bahasa atau ekosistem dari proyek Anda. @@ -144,7 +137,7 @@ Seringkali, hubungan ini bisa mengarah pada hubungan yang resmi dengan ekosistem avatar Satu-satunya alasan kenapa urllib3 adalah pustaka Python pihak ketiga yang paling terkenal adalah karena merupakan bagian dari requests.

-— @shazow, ["How to make your open source project thrive"](https://text.sourcegraph.com/how-to-make-your-open-source-project-thrive-with-andrey-petrov-6463b935c540#.mk31f8fgf) +— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)

@@ -152,14 +145,6 @@ Tidak pernah terlalu cepat, atau terlambat untuk membangun reputasi Anda. Meskip Tidak ada solusi cepat untuk membangun pengguna. Mendapatkan kepercayaan dan penghargaan membutuhkan waktu, dan proses membangun reputasi tidak pernah selesai. - - ## Teruslah Berjuang! Seringkali membutuhkan waktu yang sangat lama sebelum orang lain mulai memperhatikan proyek open source Anda. Tidak masalah! Sebagian dari proyek open source yang terkenal saat ini membutuhkan waktu bertahun-tahun untuk mencapai aktivitas yang tinggi seperti saat ini. Fokus pada membangun relasi dibandingkan mencari jalan pintas.Bersabarlah dan terus berbagi pekerjaan Anda dengan mereka yang menghargainya. diff --git a/_articles/id/getting-paid.md b/_articles/id/getting-paid.md index 1e5be9b73ee..cd227e3923c 100644 --- a/_articles/id/getting-paid.md +++ b/_articles/id/getting-paid.md @@ -3,11 +3,6 @@ lang: id title: Dibayar untuk Pekerjaan Open Source description: Pertahankan pekerjaan Anda pada open source dengan mendapatkan dukungan finansial untuk waktu Anda pada proyek. class: getting-paid -toc: - kenapa-beberapa-orang-mencari-dukungan-finansial: "Kenapa beberapa orang mencari dukungan finansial" - mendanai-waktu-anda-sendiri: "Mendanai waktu Anda sendiri" - mencari-pendanaan-untuk-proyek-anda: "Mencari pendanaan untuk proyek Anda" - membangun-kasus-untuk-dukungan-finansial: "Membangun kasus untuk dukungan finansial" order: 7 image: /assets/images/cards/getting-paid.png related: @@ -37,7 +32,7 @@ Terdapat banyak alasan kenapa seseorang tidak ingin dibayar untuk pekerjaan open avatar Donasi finansial memang menambahkan perasaan tanggung jawab untuk beberapa orang. (...) Merupakan sesuatu yang penting bagi kami yang hidup pada dunia yang sangat cepat dan terkoneksi secara global untuk bisa mengatakan "belum waktunya, saya merasa melakukan sesuatunya dengan cara yang berbeda".

-— @alloy, ["Why We Don't Accept Donations"](http://blog.cocoapods.org/Why-we-dont-accept-donations/) +— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)

@@ -59,7 +54,7 @@ Pekerjaan yang dibayar juga memungkinkan orang-orang dari berbagai latar belakan avatar OSS menghasilkan keuntungan yang besar pada industri teknologi, yang akan menguntungkan semua industri. (...) Namun, jika satu-satunya orang yang bisa berfokus padanya adalah orang yang beruntung dan terobsesi, maka terdapat potensi yang sangat besar.

-— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c#.ftnd5qez0) +— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)

@@ -71,14 +66,6 @@ Saat ini, banyak orang dibayar untuk bekerja secara paruh waktu atau penuh pada Akan lebih mudah untuk mendiskusikan proyek open source jika yang mempekerjakan Anda menggunakan proyek tersebut, tetapi tetap kreatiflah dalam usaha negosiasi Anda. Mungkin mereka tidak menggunakan proyek tersebut, tetapi mereka menggunakan Python, dan mengelola proyek Python yang populer akan membantu mengundang pengembang Python yang baru. Mungkin hal ini membuat perusahaan Anda lebih ramah terhadap pengembang secara umum. - - Jika Anda tidak memiliki proyek open source yang ingin Anda kerjakan, tetapi Anda berharap pekerjaan Anda saat ini dibuat dalam bentuk open source, ajukan ke perusahaan Anda untuk membuka perangkat lunak internal mereka pada open source. Banyak perusahaan mengembangkan program open source untuk membangun citra mereka dan merekrut talenta berkualitas. @@ -99,14 +86,14 @@ Jika perusahaan Anda mengikuti rute ini, merupakan hal yang penting untuk menjag Jika Anda tidak mampu meyakinkan perusahaan untuk memprioritaskan pekerjaan open source, pertimbangkan untuk mencari perusahaan lain yang mendorong kontribusi karyawan pada open source. Cari perusahaan yang mendedikasikan pada pekerjaan open source secara eksplisit. Sebagai contoh: -* Beberapa perusahaan, seperti [Netflix](https://netflix.github.io/) atau [PayPal](http://paypal.github.io/), memiliki halaman web yang menunjukan keterlibatan mereka pada open source -* [Rackspace](https://www.rackspace.com/en-us) mempublikasikan [kebijakan kontribusi open source](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/) bagi pegawai +* Beberapa perusahaan, seperti [Netflix](https://netflix.github.io/), memiliki halaman web yang menunjukan keterlibatan mereka pada open source Proyek-proyek yang berasal dari perusahaan besar, seperti [Go](https://github.com/golang) atau [React](https://github.com/facebook/react), juga akan memperkerjakan orang-orang untuk bekerja pada open source. Akhirnya, melihat dari kondisi pribadi Anda, Anda bisa mencoba mengumpulkan uang secara mandiri untuk mendanai proyek open source Anda. Sebagai contoh: -* @gaearon mendanai pekerjaannya pada [Redux](https://github.com/reactjs/redux) melalui [kampanye Patreon crowdfunding](http://redux.js.org/) +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) +* @gaearon mendanai pekerjaannya pada [Redux](https://github.com/reactjs/redux) melalui [kampanye Patreon crowdfunding](https://redux.js.org/) * @andrewgodwin mendanai pekerjaan pada migrasi skema Django [melalui kampanye Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) ## Mencari pendanaan untuk proyek Anda @@ -122,7 +109,6 @@ Seiring dengan popularitas open source, menemukan pendanaan untuk proyek masih b Mencari sponsor bisa dilakukan jika Anda memiliki pengguna atau reputasi yang kuat, atau proyek Anda sangat populer. Beberapa proyek yang disponsori meliputi: * **[webpack](https://github.com/webpack)** mendapatkan pendanaan dari perusahaan dan perseorangan [melalui OpenCollective](https://opencollective.com/webpack) -* **[Vue](https://github.com/vuejs/vue)** [didanai melalui Patreon](https://github.com/open-source/stories/yyx990803) * **[Ruby Together](https://rubytogether.org/),** organisasi nirlaba yang membayar untuk bekerja pada [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), dan proyek infrastruktur Ruby lainnya. ### Menciptakan pendapatan @@ -133,7 +119,7 @@ Anda mungkin memberikan tambahan biaya untuk dukungan komersial, opsi hosting, a * **[Travis CI](https://github.com/travis-ci)** menawarkan versi berbayar untuk produknya * **[Ghost](https://github.com/TryGhost/Ghost)** bersifat nirlaba dengan layanan pembayaran -Beberapa proyek yang populer, seperti [npm](https://github.com/npm/npm) dan [Docker](https://github.com/docker/docker), bahkan mengajukan pendanaan pada venture capital untuk mendukung pertumbuhan bisnisnya. +Beberapa proyek yang populer, seperti [npm](https://github.com/npm/cli) dan [Docker](https://github.com/docker/docker), bahkan mengajukan pendanaan pada venture capital untuk mendukung pertumbuhan bisnisnya. ### Mengajukan hibah pendanaan @@ -183,5 +169,3 @@ Apakah pemberi dana memiliki persyaratan? Misalnya Anda harus bersifat nirlaba a ## Eksperimen dan jangan menyerah Mendapatkan pendanaan tidaklah mudah, baik untuk proyek open source, nirlaba, atau startup perangkat lunak, dan pada banyak kasus, Anda harus kreatif. mengindentifikasi bagaimana Anda hendak didanai, melakukan riset, dan menempatkan diri Anda pada penyandang dana akan membantu Anda membangun kasus yang meyakinkan untuk pendanaan. - -> diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md index be9d765422e..fe576995692 100644 --- a/_articles/id/how-to-contribute.md +++ b/_articles/id/how-to-contribute.md @@ -3,13 +3,6 @@ lang: id title: Bagaimana Berkontribusi pada Open Source description: Ingin berkontribusi pada open source? Sebuah panduan untuk melakukan kontribusi open source, untuk pemula dan veteran. class: contribute -toc: - mengapa-berkontribusi-pada-open-source: "Mengapa berkontribusi pada open source?" - apa-artinya-berkontribusi: "Apa artinya berkontribusi" - berorientasi-pada-proyek-baru: "Berorientasi pada proyek baru" - menemukan-sebuah-proyek-untuk-melakukan-kontribusi: "Menemukan sebuah proyek untuk melakukan kontribusi" - bagaimana-mengajukan-kontribusi: "Bagaimana mengajukan kontribusi" - apa-yang-terjadi-setelah-anda-mengajukan-sebuah-kontribusi: "Apa yang terjadi setelah Anda mengajukan sebuah kontribusi" order: 1 image: /assets/images/cards/contribute.png related: @@ -69,20 +62,12 @@ Kesalahpahaman yang sering terjadi tentang berkontribusi pada open source adalah avatar Saya menjadi terkenal karena pekerjaan saya pada CocoaPods, tetapi banyak orang tidak tahu bahwa saya tidak melakukan pekerjaan yang berarti pada perangkat CocoaPods itu sendiri. Waktu saya pada proyek lebih banyak dihabiskan untuk melakukan kegiatan seperti dokumentasi dan pencitraan.

-— @orta, ["Moving to OSS by default"](https://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/)

Meskipun Anda suka untuk menulis kode program, kontribusi jenis lain merupakan cara yang baik untuk bisa berpartisipasi pada proyek dan bertemu dengan anggota komunitas lainnya. Membangun hubungan tersebut akan memberikan Anda kesempatan untuk bekerja pada bagian lain dari proyek. - - ### Apakah Anda suka merencanakan kegiatan? * Mengelola workshop atau acara pertemuan tentang proyek, [seperti yang dilakukan @fzamperin untuk NodeSchool](https://github.com/nodeschool/organizers/issues/406) @@ -127,7 +112,7 @@ Meskipun Anda suka untuk menulis kode program, kontribusi jenis lain merupakan c ### Apakah Anda suka membantu orang lain? -* Menjawab pertanyaan tentang proyek, pada (misalnya) Stack Overflow ([seperti contoh Postgres ini](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) atau reddit +* Menjawab pertanyaan tentang proyek, pada (misalnya) Stack Overflow ([seperti contoh Postgres ini](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) atau reddit * Menjawab pertanyaan pada permasalahaan terbuka * Membantu memoderasi halaman diskusi atau chanel diskusi @@ -155,7 +140,7 @@ Meskipun Anda seorang pengembang perangkat lunak, bekerja pada proyek dokumentas avatar Jika Anda mengunjungi issue tracker dan tampaknya membingungkan, hal itu terjadi bukan hanya kepada Anda saja. Perangkat ini membutuhkan banyak pemahaman implisit, tetapi orang lain mampu membantu Anda dalam mengeksplorasi dan Anda bisa bertanya kepada mereka.

-— @shaunagm, ["How to Contribute to Open Source"](http://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/) +— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)

@@ -212,18 +197,19 @@ Open source bukanlah klub ekslusif; Open source dibuat oleh orang-orang seperti Anda bisa melihat dokumen README dan menemukan tautan yang tidak valid atau kesalahan pengetikkan. Atau Anda sebagai pengguna baru dan melihat bahwa ada yang salah, atau sebuah laporan dimana Anda rasa penting untuk didokumentasikan. Daripada mengabaikannya, atau meminta orang lain untuk memperbaikinya, cari tahu apakah Anda bisa membantu dengan ikut serta didalamnya. Itulah makna sesungguhnya dari open source! -> [28% dari kontribusi umum](http://www.igor.pro.br/publica/papers/saner2016.pdf) pada open source adalah berupa dokumentasi, seperti kesalahan pengetikkan, pemformatan ulang, atau menuliskan terjemahan. +> [28% dari kontribusi umum](https://www.igor.pro.br/publica/papers/saner2016.pdf) pada open source adalah berupa dokumentasi, seperti kesalahan pengetikkan, pemformatan ulang, atau menuliskan terjemahan. Anda juga bisa menggunakan salah satu dari beberapa sumber daya berikut untuk mencari dan berkontribusi pada proyek baru: * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) -* [First Timers Only](http://www.firsttimersonly.com/) -* [Your First PR](https://yourfirstpr.github.io/) +* [First Timers Only](https://www.firsttimersonly.com/) * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) -* [Up For Grabs](http://up-for-grabs.net/) -* [Contributor-ninja](https://contributor.ninja) +* [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/) ### Daftar sebelum Anda berkontribusi @@ -375,7 +361,7 @@ Sebuah proyek yang bersahabat dan menyambut menandai bahwa mereka sangat menerim avatar Setiap kali Anda melihat diskusi yang panjang, amati respon dari pengembang inti di bagian akhir dari diskusi. Apakah mereka meringkasnya secara konstruktif dan mengambil langkah-langkah untuk mendapatkan kesimpulan tanpa mengabaikan sopan santun? Jika Anda melihat banyak perdebatan yang tidak konstruktif (_flame war_), biasanya merupakan sebuah tanda bahwa energi dihabiskan untuk berargumentasi dibandingkan untuk pengembangan proyek.

-— @kfogel, [_Producing OSS_](http://producingoss.com/en/evaluating-oss-projects.html) +— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)

@@ -391,7 +377,7 @@ Apakah Anda merupakan kontributor atau mencoba untuk bergabung dengan sebuah kom avatar \[Sebagai kontributor baru,\] saya menyadari bahwa saya perlu bertanya jika ingin menutup sebuah laporan masalah. Saya mengamati kode program. Setelah saya mengetahui situasinya, saya bertanya untuk pengarahan lebih lanjut. Dan akhirnya! Saya berhasil menutup sebuah laporan masalah setelah mendapatkan semua informasi relevan yang saya butuhkan.

-— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://medium.freecodecamp.com/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39#.pcswr2e78) +— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)

@@ -447,7 +433,7 @@ Jika Anda tidak bisa menemukan ide Anda dimanapun, Anda siap untuk bergerak. Jik Sebelum Anda membuka sebuah laporan masalah atau melakukan pull request, periksa dokumen kontribusi proyek (biasanya pada dokumen bernama CONTRIBUTING, atau pada README), untuk melihat apakah Anda perlu mencantumkan informasi yang spesifik. Sebagai contoh, mereka mungkin meminta Anda untuk mengikuti sebuah template, atau mengharuskan Anda untuk menggunakan perangkat pengujian. -Jika Anda hendak melakukan kontribusi yang cukup substansial, buatlah sebuah laporan masalah sebelum memulai bekerja. Sangatlah bermanfaat untuk mengamati proyek dalam kurun waktu tertentu (pada Github, [Anda bisa memilih menu "Watch"](https://help.github.com/articles/watching-repositories/) untuk mendapatkan notifikasi dari semua percakapan), dan mengenal anggota komunitas, sebelum memulai pekerjaan yang belum tentu akan diterima. +Jika Anda hendak melakukan kontribusi yang cukup substansial, buatlah sebuah laporan masalah sebelum memulai bekerja. Sangatlah bermanfaat untuk mengamati proyek dalam kurun waktu tertentu (pada GitHub, [Anda bisa memilih menu "Watch"](https://help.github.com/articles/watching-repositories/) untuk mendapatkan notifikasi dari semua percakapan), dan mengenal anggota komunitas, sebelum memulai pekerjaan yang belum tentu akan diterima. @@ -105,15 +97,15 @@ Terdapat tiga struktur pengelolaan yang umumnya dipakai pada proyek open source. * **BDFL:** BDFL kependekan dari "Benevolent Dictator for Life". Pada struktur ini, satu orang (biasanya pendiri proyek) memiliki keputusan final terhadap semua keputusan proyek. [Python](https://github.com/python) adalah contoh klasik. Proyek yang lebih kecil biasanya menganut model BDFL secara default, karena hanya terdapat satu atau dua pengelola. Sebuah proyek yang berawal dari sebuah perusahaan juga bisa masuk kedalam kategori BDFL. -* **Meritokrasi:** **(Catatan: istilah "meritokrasi" memiliki konotasi negatif pada beberapa komunitas dan [sejarah sosial dan politis yang kompleks](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Pada model meritokrasi, kontributor aktif sebuah proyek (mereka yang "layak") diberikan peran dalam pengambilan keputusan formal. Keputusan biasanya dilakukan berdasarkan konsensus voting. Konsep ini diciptakan oleh [Yayasan Apache](http://www.apache.org/); [semua proyek Apache](http://www.apache.org/index.html#projects-list) menganut model ini. Kontribusi hanya dapat dilakukan secara perseorangan mewakili dirinya sendiri, bukan untuk sebuah perusahaan. +* **Meritokrasi:** **(Catatan: istilah "meritokrasi" memiliki konotasi negatif pada beberapa komunitas dan [sejarah sosial dan politis yang kompleks](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Pada model meritokrasi, kontributor aktif sebuah proyek (mereka yang "layak") diberikan peran dalam pengambilan keputusan formal. Keputusan biasanya dilakukan berdasarkan konsensus voting. Konsep ini diciptakan oleh [Yayasan Apache](https://www.apache.org/); [semua proyek Apache](https://www.apache.org/index.html#projects-list) menganut model ini. Kontribusi hanya dapat dilakukan secara perseorangan mewakili dirinya sendiri, bukan untuk sebuah perusahaan. -* **Kontribusi liberal:** Pada model ini, orang-orang yang banyak melakukan pekerjaan adalah yang dianggap berperan, namun ini berbasiskan pada pekerjaan saat ini dan bukan kontribusi yang lampau. Pengambilan keputusan pada proyek berdasarkan pada proses pencarian konsensus dibandingkan voting murni, dan mencoba melibatkan banyak pandangan dari komunitas. Contoh populer proyek yang menggunakan model ini meliputi [Node.js](https://nodejs.org/en/foundation/) dan [Rust](https://www.rust-lang.org/en-US/). +* **Kontribusi liberal:** Pada model ini, orang-orang yang banyak melakukan pekerjaan adalah yang dianggap berperan, namun ini berbasiskan pada pekerjaan saat ini dan bukan kontribusi yang lampau. Pengambilan keputusan pada proyek berdasarkan pada proses pencarian konsensus dibandingkan voting murni, dan mencoba melibatkan banyak pandangan dari komunitas. Contoh populer proyek yang menggunakan model ini meliputi [Node.js](https://foundation.nodejs.org/) dan [Rust](https://www.rust-lang.org/). Mana yang harus Anda gunakan? Semuanya tergantung Anda! Setiap model memiliki kelebihan dan kekurangan. Meskipun pada awalnya mereka tampak berbeda di awal, semua model memiliki banyak kesamaan. Jika Anda tertarik untuk mengadopsi salah satu model tersebut, silahkan lihat beberapa template berikut: * [template model BDFL](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) * [template model meritokrasi](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) -* [kebijakan kontribusi liberal Node.js](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79) +* [kebijakan kontribusi liberal Node.js](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) ## Apakah saya perlu dokumentasi pengelolaan ketika Saya merilis proyek Saya? @@ -125,7 +117,7 @@ Jika Anda bagian dari sebuah perusahaan yang merilis proyek open source, maka ak @@ -72,7 +64,7 @@ Di satu sisi, jika salah satu dari lisensi ketergantungan Anda adalah "copyleft" Anda juga perlu memperhatikan **komunitas** akan menggunakan dan berkontribusi pada proyek Anda: -* **Apakah Anda ingin proyek Anda digunakan sebagai ketergantungan oleh proyek lain?** Mungkin paling tepat untuk menggunakan lisensi yang paling populer pada komunitas Anda. Sebagai contoh, [MIT](https://choosealicense.com/licenses/mit/) adalah lisensi yang paling populer untuk [pustaka npm](https://libraries.io/npm). +* **Apakah Anda ingin proyek Anda digunakan sebagai ketergantungan oleh proyek lain?** Mungkin paling tepat untuk menggunakan lisensi yang paling populer pada komunitas Anda. Sebagai contoh, [MIT](https://choosealicense.com/licenses/mit/) adalah lisensi yang paling populer untuk [pustaka npm](https://libraries.io/search?platforms=NPM). * **Apakah Anda ingin proyek Anda menarik bagi kalangan bisnis skala besar?** Kalangan bisnis yang berskala besar memiliki kencenderungan untuk menggunakan lisensi paten ekspress dari semua kontributor. Dalam hal ini, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) dapat mencakup Anda dan mereka. * **Apakah Anda ingin proyek Anda menarik bagi kontributor yang tidak ingin hasil kontribusinya tidak digunakan pada perangkat lunak tertutup?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) atau (jika mereka juga tidak mau berkontribusi pada layanan tertutup) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) merupakan pilihan yang tepat. @@ -96,7 +88,7 @@ Alternatif lain, Anda bisa mendapatkan persetujuan kontributor di awal (melalui ## Apakah proyek saya membutuhkan perjanjian kontributor tambahan? -Kemungkinan tidak. Untuk sebagian besar proyek open source, lisensi open source secara implisit berfungsi sebagai lisensi inbound (dari kontributor) dan outbound (bagi kontributor dan pengguna lainnya). Jika proyek Anda berada pada GitHub, Perjanjian Layanan GitHub membuat aturan "inbound=outbound" [default secara eksplisit](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license). +Kemungkinan tidak. Untuk sebagian besar proyek open source, lisensi open source secara implisit berfungsi sebagai lisensi inbound (dari kontributor) dan outbound (bagi kontributor dan pengguna lainnya). Jika proyek Anda berada pada GitHub, Perjanjian Layanan GitHub membuat aturan "inbound=outbound" [default secara eksplisit](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). Sebuah perjanjian kontributor tambahan -- seringkali disebut Contributor License Agreement (CLA) -- bisa menimbulkan pekerjaan administratif tambahan bagi pengelola proyek. Seberapa banyak pekerjaan tersebut tergantung dari proyek dan implementasinya. Sebuah perjanjian yang sederhana mungkin meminta kontributor untuk melakukan konfirmasi dengan satu klik, bahwa mereka memiliki hak yang cukup untuk berkontribusi dibawah lisensi open source. Perjanjian yang lebih kompleks mungkin membutuhkan review hukum dan tanda tangan dari perusahaan yang memperkerjakan kontributor tersebut. @@ -106,13 +98,13 @@ Juga, dengan menambahkan "pekerjaan administratif" yang dipercaya oleh sebagian avatar Kami telah menghilangkan CLA untuk Node.js. Dengan melakukan hal ini akan mengurangi hambatan bagi kontributor Node.js untuk bergabung sehingga memperluas area basis kontributor.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

Beberapa situasi dimana Anda ingin mempertimbangkan perjanjian kontributor tambahan pada proyek Anda meliputi: -* Pengacara Anda ingin semua kontributor menerima perjanjian kontribusi (_tandatangan_, online atau offline), karena mereka merasa lisensi open source tidaklah cukup (meskipun sebenarnya sudah!). Jika ini merupakan satu-satunya alasan, sebuah perjanjian kontributor yang mengakui lisensi open source sudahlah cukup. [Perjanjian Lisensi Kontributor Individual jQuery](https://contribute.jquery.org/CLA/) adalah contoh bagus dari perjanjian kontributor tambahan yang sederhana. Untuk beberapa proyek [Developer Certificate of Origin](https://github.com/probot/dco) mungkin menjadi alternatif yang lebih sederhana. +* Pengacara Anda ingin semua kontributor menerima perjanjian kontribusi (_tandatangan_, online atau offline), karena mereka merasa lisensi open source tidaklah cukup (meskipun sebenarnya sudah!). Jika ini merupakan satu-satunya alasan, sebuah perjanjian kontributor yang mengakui lisensi open source sudahlah cukup. [Perjanjian Lisensi Kontributor Individual jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) adalah contoh bagus dari perjanjian kontributor tambahan yang sederhana. Untuk beberapa proyek [Developer Certificate of Origin](https://github.com/probot/dco) mungkin menjadi alternatif yang lebih sederhana. * Proyek Anda menggunakan lisensi open source yang tidak menyertakan ijin patent (seperti MIT), dan Anda perlu pengajuan patent dari semua kontributor, beberapa diantaranya yang mungkin bekerja pada perusahaan dengan portofolio paten yang besar yang bisa digunakan untuk menyerang Anda atau kontributor atau pengguna proyek Anda. [Perjanjian Lisensi Kontributor Individual Apache](https://www.apache.org/licenses/icla.pdf) adalah perjanjian kontributor tambahan yang sering dipakai dan memiliki ijin penggunaan patent mengikuti apa yang bisa ditemukan pada lisensi Apache 2.0. * Proyek Anda berada dibawah lisensi copyleft, tetapi Anda juga perlu mendistribusikan versi tertutup dari proyek Anda. Anda mungkin perlu meminta setiap kontributor untuk menyatakan hak cipta kepada Anda atau memberikan ijin kepada Anda (tetapi bukan kepada publik) sebuah lisensi yang bersifat _permissive_. [Perjanjian Kontributor MongoDB](https://www.mongodb.com/legal/contributor-agreement) adalah contoh jenis perjanjian ini. * Anda berpikir proyek Anda perlu mengubah lisensi dikemudian hari dan ingin para kontributor untuk menyetujuinya di awal terhadap perubahan tersebut. @@ -141,18 +133,18 @@ Jika Anda merilis proyek open source perusahaan Anda pertama kalinya, informasi Dalam jangka panjang, tim hukum Anda bisa melakukan lebih banyak lagi dengan membantu perusahaan untuk mendapatkan lebih banyak dari keterlibatannya pada open source: -* **Kebijakan kontribusi karyawan:** Pertimbangkan untuk mengembangkan kebijakan perusahaan yang menentukan bagaimana karyawan berkontribusi pada proyek open source. Sebuah kebijakan yang jelas akan mengurangi kebingungan pada karyawan Anda dan membantu mereka untuk berkontribusi pada proyek open source yang penting bagi perusahaan, baik sebagai bagian dari pekerjaan mereka atau dimasa senggang mereka. Sebuah contoh bagus adalah [Model IP dan Kebijakan Kontribusi Open Source](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) milik Rackspace. +* **Kebijakan kontribusi karyawan:** Pertimbangkan untuk mengembangkan kebijakan perusahaan yang menentukan bagaimana karyawan berkontribusi pada proyek open source. Sebuah kebijakan yang jelas akan mengurangi kebingungan pada karyawan Anda dan membantu mereka untuk berkontribusi pada proyek open source yang penting bagi perusahaan, baik sebagai bagian dari pekerjaan mereka atau dimasa senggang mereka. Sebuah contoh bagus adalah [Model IP dan Kebijakan Kontribusi Open Source](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) milik Rackspace. * **Apa yang dirilis:** [(Hampir) semuanya?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) jika tim hukum Anda memahami dan berinvestasi pada strategi open source perusahaan Anda, mereka akan banyak membantu dibandingkan merugikan Anda. -* **Kesesuaian:** Meskipun perusahaan Anda tidak merilis proyek open source, perusahaan Anda menggunakan perangkat lunak open source milik orang lain. [Kewaspadaandan proses](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program) bisa mencegah masalah, keterlambatan produk, dan tuntutan hukum. +* **Kesesuaian:** Meskipun perusahaan Anda tidak merilis proyek open source, perusahaan Anda menggunakan perangkat lunak open source milik orang lain. [Kewaspadaandan proses](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) bisa mencegah masalah, keterlambatan produk, dan tuntutan hukum. -[Terdapat banyak alasan](http://ben.balter.com/2015/11/23/why-open-source/) kenapa seseorang atau sebuah organisasi ingin membuka proyek open source. Beberapa diantaranya meliputi: +[Terdapat banyak alasan](https://ben.balter.com/2015/11/23/why-open-source/) kenapa seseorang atau sebuah organisasi ingin membuka proyek open source. Beberapa diantaranya meliputi: * **Kolaborasi:** Proyek open source bisa menerima perubahan dari siapapun juga di seluruh dunia. [Exercism](https://github.com/exercism/), sebagai contoh, adalah kerangka latihan pemrograman dengan lebih dari 350 kontributor. -* **Adopsi dan menggabungkan:** Proyek open source bisa digunakan oleh siapapun untuk hampir semua tujuan. Bahkan bisa digunakan untuk membangun proyek lain. [WordPress](https://github.com/WordPress), sebagai contoh, dimulai dari hasil _fork_ dari proyek yang sudah ada bernama [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md). +* **Adopsi dan menggabungkan:** Proyek open source bisa digunakan oleh siapapun untuk hampir semua tujuan. Bahkan bisa digunakan untuk membangun proyek lain. [WordPress](https://github.com/WordPress), sebagai contoh, dimulai dari hasil _fork_ dari proyek yang sudah ada bernama [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). -* **Transparansi:** Setiap orang dapat melihat kesalahan atau inkonsistensi pada proyek open source. Transparansi sangat penting bagi pemerintah seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) atau [Amerika Serikat](https://sourcecode.cio.gov/), industri yang memiliki regulasi seperti perbankan atau kesehatan, dan perangkat lunak keamanan seperti [Let's Encrypt](https://github.com/letsencrypt). +* **Transparansi:** Setiap orang dapat melihat kesalahan atau inkonsistensi pada proyek open source. Transparansi sangat penting bagi pemerintah seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) atau [Amerika Serikat](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), industri yang memiliki regulasi seperti perbankan atau kesehatan, dan perangkat lunak keamanan seperti [Let's Encrypt](https://github.com/letsencrypt). Open source bukan hanya untuk perangkat lunak saja. Anda bisa membuka tentang apa saja mulai dari kumpulan data hingga buku. Silahkan lihat [GitHub Explore](https://github.com/explore) untuk ide yang dapat Anda buka sebagai open source. @@ -85,7 +79,7 @@ Jika tujuan akhir Anda adalah untuk menunjukkan hasil pekerjaan Anda, Anda mungk avatar Pada suatu titik saya menciptakan UIAlertView hasil modifikasi yang saya gunakan...dan saya memutuskan untuk membuatnya menjadi open source. Lalu saya memodifikasinya menjadi lebih dinamis dan menyimpannya di GitHub. Saya menulis dokumentasi pertama saya dengan menjelaskan kepada pengembang lain bagaimana untuk menggunakannya pada proyek mereka. Mungkin saja tidak ada orang lain yang akan menggunakannya karena merupakan proyek sederhana, tetapi saya memiliki perasaan yang baik tentang kontribusi yang saya lakukan.

-— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576#.zhwo5krlq) +— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)

@@ -101,7 +95,7 @@ Jika Anda membutuhkan pendanaan yang permanen atau alokasi staf untuk promosi, o avatar Ketika Anda mulai untuk membuka proyek Anda pada open source, sangatlah penting untuk memastikan bahwa proses manajemen Anda memperhatikan kontribusi dan kemampuan dari komunitas disekeliling proyek Anda. Jangan takut untuk melibatkan kontributor yang bukan merupakan karyawan sebagai aspek kunci dalam proyek - terutama jika mereka adalah kontributor yang aktif.

-— @captainsafia, ["So you wanna open source a project, eh?"](https://writing.safia.rocks/2016/12/06/so-you-wanna-open-source-a-project-eh/) +— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)

@@ -156,10 +150,10 @@ Pada dokumen README, cobalah untuk menjawab pertanyaan berikut: Anda bisa menggunakan README untuk menjawab pertanyaan lainnya, seperti bagaiman Anda akan menangani kontribusi, apa tujuan akhir dari proyek, dan informasi tentang lisensi. Jika Anda tidak ingin menerima kontribusi, atau proyek Anda belum siap untuk produksi, tuliskan informasi ini. @@ -185,7 +179,7 @@ Selain aspek teknis, dokumen CONTRIBUTING juga merupakan kesempatan untuk mengko Menggunakan nada yang bersahabat dan menawarkan tawaran yang spesifik untuk kontribusi (misalnya menuliskan dokumentasi, atau membuat halaman web) bisa membuat pendatang merasa nyaman dan diterima serta tertarik untuk berpartisipasi. -Sebagai contoh, [Active Admin](https://github.com/activeadmin/activeadmin/) memulai [panduan kontribusinya](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) dengan: +Sebagai contoh, [Active Admin](https://github.com/activeadmin/activeadmin/) memulai [panduan kontribusinya](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) dengan: > Pertama-tama, terima kasih karena Anda mempertimbangkan untuk berpartisipasi pada Active Admin. Orang-orang seperti Anda yang membuat Active Admin menjadi sebuah perangkat yang hebat. @@ -193,7 +187,7 @@ Pada fase awal dari proyek Anda, dokumen CONTRIBUTING bisa sangat sederhana. And Seiring dengan berjalannya waktu, Anda bisa menambahkan pertanyaan yang paling sering ditanyakan pada dokumen CONTRIBUTING. Menuliskan informasi ini berarti lebih sedikit orang yang akan bertanya pertanyaan yang sama kepada Anda berulang kali. -Untuk bantuan tentang penulisan dokumen CONTRIBUTING, silahkan lihat [template panduan berkontribusi](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) milik @nayafia atau ["Bagaimana Membangun Dokumen CONTRIBUTING.md"](http://mozillascience.github.io/working-open-workshop/contributing/) milik @mozilla. +Untuk bantuan tentang penulisan dokumen CONTRIBUTING, silahkan lihat [template panduan berkontribusi](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) milik @nayafia atau ["Bagaimana Membangun Dokumen CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) milik @mozilla. Hubungkan dokumen CONTRIBUTING dari README, sehingga lebih banyak orang yang melihatnya. Jika Anda [meletakkan dokumen CONTRIBUTING pada repositori proyek](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub akan secara otomatis menghubungkan ke dokumen Anda ketika seorang kontributor membuat sebuah laporan masalah atau membuat pull request. @@ -205,7 +199,7 @@ Hubungkan dokumen CONTRIBUTING dari README, sehingga lebih banyak orang yang mel avatar Kita semua pernah memiliki pengalaman dimana kita dihadapkan dengan penyalahgunaan, baik sebagai pengelola yang menjelaskan kenapa sesuatu harus dilakukan dengan cara tertentu, atau sebagai pengguna...bertanya sebuah pertanyaan sederhana. (...) Kode etik merupakan dokumen yang mudah untuk dijadikan referensi yang mengindikasikan bahwa tim Anda sangat memperhatikan wacana yang bersifat membangun.

-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f#.v4qhl7t7v) +— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)

@@ -256,13 +250,13 @@ Baik dokumentasi resmi atau email sehari-hari, gaya penulisan Anda merupakan bag avatar Saya berusaha untuk ikut terlibat pada setiap diskusi pada mailing list, dan memberikan contoh panutan, bertindak baik kepada orang-orang, menganggap masalah mereka sebagai sesuatu yang serius, dan berusaha untuk membantu. Setelah beberapa waktu, orang-orang tidak hanya berhenti karena ada masalah, namun juga ikut membantu, dan mereka mengikuti gaya saya.

-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](http://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)

Menggunakan bahasa yang hangat, inklusif (seperti "mereka", meskipun mengacu pada satu orang) bisa membuat proyek Anda lebih nyaman bagi kontributor baru. Gunakan bahasa sederhana, karena bisa jadi banyak pengguna Anda bukan merupakan pengguna yang menggunakan bahasa Inggris sehari-harinya. -Selain bagaimana Anda menuliskan kata-kata, gaya pemrograman Anda juga bisa menjadi bagian dari citra proyek Anda. [Angular](https://github.com/johnpapa/angular-styleguide) dan [jQuery](http://contribute.jquery.org/style-guide/js/) adalah dua contoh proyek dengan gaya pemrograman dan panduan yang lengkap. +Selain bagaimana Anda menuliskan kata-kata, gaya pemrograman Anda juga bisa menjadi bagian dari citra proyek Anda. [Angular](https://github.com/johnpapa/angular-styleguide) dan [jQuery](https://contribute.jquery.org/style-guide/js/) adalah dua contoh proyek dengan gaya pemrograman dan panduan yang lengkap. Tidaklah penting untuk menuliskan gaya penulisan untuk proyek Anda ketika Anda baru memulainya dan Anda mungkin senang untuk mencoba beberapa gaya pemrograman pada proyek Anda. Tetapi Anda perlu mengantisipasi bagaimana penulisan dan pemrograman Anda bisa memikat orang atau malah membuat orang untuk menghindari proyek Anda. Tahap awal dari proyek Anda adalah kesempatan untuk menentukan arah yang Anda tuju. @@ -330,7 +324,7 @@ Jika Anda perseorangan:
@@ -360,7 +354,7 @@ Jika Anda merupakan perusahaan atau organisasi:
diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md new file mode 100644 index 00000000000..15064842755 --- /dev/null +++ b/_articles/it/best-practices.md @@ -0,0 +1,275 @@ +--- +lang: it +title: Buone pratiche per i manutentori del codice. +description: Semplificarti la vita come sostenitore dell'open source, dal processo di documentazione fino a ottenere il massimo dalla community. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Cosa significa essere un manutentore del codice? + +Se il tuo lavoro è mantenere un progetto open source utilizzato da molte persone, probabilmente avrai notato che passi più tempo a rispondere alle domande che a programmare. + +Nelle prime fasi di un progetto, trascorri del tempo sperimentando nuove idee e prendendo decisioni in base a ciò che ti piace. Man mano che il tuo progetto cresce in popolarità, ti ritroverai in una situazione in cui lavorerai sempre di più con i tuoi utenti e collaboratori. + +Il mantenimento di un progetto richiede molto più del semplice codice. Questi compiti vengono solitamente trascurati, ma sono altrettanto importanti per un progetto in crescita. Abbiamo messo insieme alcune idee che ti semplificheranno la vita, dal processo di documentazione all'ottenimento del massimo dalla community. + +## Documentare i tuoi processi + +Contrassegnare le procedure è una delle migliori pratiche che puoi seguire come manutentore del codice. + +Documentare non solo chiarisce il tuo pensiero, ma aiuta anche gli altri a capire di cosa hai bisogno o cosa ti aspetti senza nemmeno doverlo chiedere. + +Tenendo conto dei processi, è più facile per te dire di no quando la proposta di qualcuno non si adatta al tuo contesto. Quindi rende anche più facile per altre persone unirsi e aiutare. Non sai mai chi potrebbe leggere o utilizzare il tuo progetto. + +Anche se non sei il tipo che scrive interi paragrafi, annotare i punti chiave è meglio di niente. + +### Chiarire la visione del tuo progetto + +Inizia scrivendo gli obiettivi del tuo progetto. Aggiungili al tuo file README o crea un file separato chiamato VISION. Se ci sono altri elementi che possono essere d'aiuto, come una mappa di progetto, rendili pubblici. + +Avere una visione chiara e documentata ti mantiene concentrato e aiuta a evitare malintesi sull'ambito da parte di altri contributori. + +Per esempio: +@lord ha scoperto che avere una visione del progetto lo ha aiutato a capire a quali richieste dare priorità. Essendo un sostenitore del codice alle prime armi, si è lamentato di non essere fedele allo scopo del progetto quando ha ricevuto la tua prima richiesta di funzionalità [Slate](https://github.com/lord/slate). + + + +### Comunica le tue aspettative + +A volte può essere difficile formulare le regole in modo che altre persone possano contribuire. Potresti avere la sensazione di comportarti come un poliziotto o di rovinare il divertimento degli altri. + +Tuttavia, le buone regole scritte e applicate in modo equo danno potere ai manutentori del codice. Ti impediscono di farti coinvolgere in cose che non vuoi fare. + +La maggior parte delle persone che incontrano il tuo progetto non sanno nulla di te o delle tue circostanze. Potrebbero presumere che tu sia pagato per lavorarci, soprattutto se è qualcosa che usano e da cui dipendono regolarmente. Forse una volta dedicavi molto tempo al tuo progetto, ma ora sei impegnato con un nuovo lavoro o con un membro della famiglia. + +Va tutto bene! Assicurati solo che la gente lo sappia. + +Sia che il mantenimento del tuo progetto sia part-time o solo volontario, sii onesto su quanto tempo hai. Questo non è lo stesso di quanto tempo pensi che richiederà il progetto o di quanto tempo gli altri vogliono che tu spenda. + +Ecco alcune regole che vale la pena tenere a mente: + +* Come viene esaminato e accettato l'input (_Hai bisogno di fare qualche test? Qualche modello da utilizzare per i problemi?_) +* I tipi di contributi che accetterai (_Vuoi aiuto solo con una parte del codice?_) +* Quando è opportuno dare seguito (_ad esempio "Puoi aspettarti una risposta dal supporto del codice entro i prossimi 7 giorni. Se non hai ricevuto alcuna risposta entro allora, sentiti libero di eseguire il ping del thread."_) +*Quanto tempo dedichi al progetto (_es. "Investiamo solo circa 5 ore settimanali in questo progetto"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), e [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) questi sono alcuni esempi di progetti con regole chiare per manutentori e contributori. + +### Mantenere la comunicazione pubblica + +Non dimenticare di documentare anche le tue interazioni. Dove puoi, mantieni la comunicazione pubblica sul tuo progetto. Se qualcuno tenta di contattarti personalmente per discutere di una richiesta di funzionalità o di un'esigenza di supporto, indirizzalo educatamente a un canale di comunicazione pubblico, come un elenco di posta elettronica o un tracker dei problemi. + +Se incontri altri sostenitori o prendi decisioni importanti in privato, documenta tali conversazioni pubblicamente, anche se pubblichi solo i tuoi appunti. + +In questo modo, chiunque si unisca alla tua comunità avrà accesso alle stesse informazioni di chi è stato lì. Per anni. + +## Impara a dire di "No" + +Hai scritto tu la roba. Idealmente, tutti leggeranno la tua documentazione, ma in realtà dovrai ricordare agli altri che questa conoscenza esiste. + +Tuttavia, avere tutto scritto aiuta a spersonalizzare le situazioni in cui le regole devono essere applicate. + +Dire di no non è divertente, ma _"Il tuo contributo non soddisfa i criteri per questo progetto"_ sembra meno personale di _"Non mi piace il tuo contributo"_. + +Dire "no" si applica a molte situazioni che incontrerai come sostenitore del codice: richieste di funzionalità che non rientrano nell'ambito, qualcuno che deraglia una discussione, che fa lavoro non necessario per altri. + +### Mantieni la conversazione amichevole + +Uno dei posti più importanti in cui ti eserciterai a dire di no è nella coda di rilascio e richiesta pull. Come project manager, riceverai inevitabilmente proposte che non vuoi accettare. + +Forse il contributo cambia la portata del tuo progetto o non si adatta alla tua visione. Forse l'idea è buona, ma la realizzazione è pessima. + +Indipendentemente dal motivo, puoi gestire con tatto i contributi che non soddisfano gli standard del progetto. + +Se ricevi un messaggio che non vuoi accettare, la tua prima reazione potrebbe essere quella di ignorarlo o di far finta di non averlo visto. Ciò può ferire i sentimenti dell'altra persona e persino scoraggiare altri potenziali contributori nella tua comunità. + + + +Non lasciare aperto un contributo non richiesto perché ti senti in colpa o vuoi essere gentile. Nel corso del tempo, le tue domande senza risposta e le tue PR diventeranno ridondanti. Ciò renderà il lavoro sul tuo progetto molto più stressante e imbarazzante. + +È meglio chiudere immediatamente i contributi che sai di non voler accettare. Se il tuo progetto soffre già di un ampio arretrato o di un elenco di funzionalità da implementare, @steveklabnik ha suggerimenti su [come selezionare le domande in modo efficace](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +In secondo luogo, ignorare i contributi invia un segnale negativo alla tua comunità. Contribuire a un progetto può essere intimidatorio, soprattutto se è la prima volta per qualcuno. Anche se non accetti il ​​loro contributo, congratulati con la persona che sta dietro al progetto e ringraziala per il suo interesse. È un grande complimento! + +Se non desideri accettare una donazione: + +* **Grazie** per il loro contributo. +* **Spiegare perché non soddisfa** l'ambito del progetto e offrire chiari suggerimenti per il miglioramento, se possibile. Lo so, gentile ma fermo. +* **Condividi informazioni rilevanti** se ne hai. Se noti ripetute richieste di cose che non vuoi accettare, aggiungile alla tua documentazione per evitare di spiegare sempre la stessa cosa. +* **Chiudi la richiesta** + +Non dovresti avere più di 1-2 frasi a cui rispondere. Ad esempio, quando un utente [celery](https://github.com/celery/celery/) segnalato un errore relativo a Windows, @berkerpeksag [lui a risposto con](https://github.com/celery/celery/issues/3383): + +[celery screenshot](/assets/images/best-practices/celery.png) + +Se l'idea di dire di no ti terrorizza, non sentirti sola. Come @jessfraz [dice](https://blog.jessfraz.com/post/the-art-of-closing/): + +> Ho parlato con manutentori del codice di molti diversi progetti open source, Mesos, Kubernetes, Chromium, e sono tutti d'accordo sul fatto che una delle parti più difficili dell'essere un manutentore del codice è: dire "No" alle patch che non vuoi utilizzare + +Non sentirti in colpa per non voler accettare il contributo di qualcuno. La prima regola dell'open source, [secondo](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No, è temporaneo; sì, è per sempre."_ Sebbene martirizzare l'entusiasmo di un'altra persona sia una buona cosa, rifiutare un contributo non è la stessa cosa che rifiutare la persona che sta dietro ad esso. + +Dopotutto, se un contributo non è abbastanza buono, non sei obbligato ad accettarlo. So che sii gentile e accomodante quando le persone contribuiscono al tuo progetto, ma accetta solo i cambiamenti che ritieni veramente miglioreranno il tuo progetto. Più ti eserciti a dire di no, più diventa facile. È una promessa. + +### Sii proattivo + +Per ridurre innanzitutto il volume dei contributi non richiesti, spiega il processo del tuo progetto per l'invio e l'accettazione dei contributi nella guida ai contributi. + +Se ricevi troppi contributi di bassa qualità, chiedi ai contributori di svolgere del lavoro in anticipo, ad esempio: + +* Completa un modello o un elenco di controllo per problemi o PR +*Apri un problema prima di inviare un PR + +Se non seguono le tue regole, chiudi immediatamente il problema e indirizzali alla tua documentazione. + +Sebbene questo approccio possa sembrare inizialmente imbarazzante, essere proattivi è in realtà positivo per entrambe le parti. Riduci la possibilità che qualcuno investa molte ore di lavoro sprecato su una richiesta pull che non accetti. E semplifica la gestione del carico. + + + +A volte, quando dici di no, il tuo potenziale collaboratore potrebbe arrabbiarsi o criticare la tua decisione. Se il tuo comportamento diventa ostile, [prendi provvedimenti per disinnescare la situazione](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) o addirittura rimuoverli dalla tua comunità se non sono disposti a collaborare in modo costruttivo. + +### Scegli il tutoraggio + +Forse qualcuno nella tua comunità invia regolarmente contributi che non soddisfano gli standard del tuo progetto. Può essere frustrante per entrambe le parti sottoporsi ripetutamente al processo di rifiuto. + +Se vedi qualcuno che ti entusiasma, ma ha bisogno di un po' di pratica, sii paziente. In ogni situazione, spiega chiaramente il motivo. il loro contributo non soddisfa le aspettative del progetto. Prova a dare loro un compito più semplice o meno ambiguo, come un problema etichettato come "buon primo problema" per riscaldarli. Se hai tempo, valuta la possibilità di fare da mentore tramite il tuo primo contributo o trova qualcun altro nella tua comunità che sia interessato. pronto ad istruirli. + +##Utilizzo della comunità + +Non devi fare tutto da solo. La tua community di progetto esiste per un motivo! Anche se non hai ancora una comunità attiva di contributori, se hai molti utenti, lasciali lavorare. + +### Condividi il carico + +Se stai cercando altri a cui unirsi, inizia chiedendo in giro. + +Quando vedi nuovi contributori che contribuiscono ripetutamente, dovresti riconoscere il loro lavoro offrendo loro maggiori responsabilità. Documenta come gli altri possono ottenere ruoli di leadership, se lo desiderano. + +Incoraggiare gli altri a [condividere la proprietà del progetto](../building-community/#condividi-la-proprietà-del-tuo-progetto) può ridurre significativamente il carico di lavoro, come ha trovato @lmccart nel suo progetto, [p5.js](https://github.com/processing/p5.js). + + + +Se hai bisogno di allontanarti dal tuo progetto, temporaneamente o permanentemente, non c'è vergogna nel chiedere a qualcun altro di subentrare al tuo posto. + +Se altre persone sono entusiaste della direzione del progetto, dai loro il permesso di essere coinvolte o di cedere formalmente il controllo a qualcun altro. Se qualcuno crea un fork del tuo progetto e questo viene mantenuto attivamente da qualche altra parte, considera di collegare il fork dal tuo progetto originale. È fantastico che così tante persone vogliano che il tuo progetto venga sviluppato! + +@progrium [trovato quello](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documentare la visione del tuo progetto, [Dokku](https://github.com/dokku/dokku), aiutare questi obiettivi a continuare, anche oltre ciò che resta del progetto: + +> Ho scritto una pagina wiki che descrive cosa voglio e perché lo voglio. Per qualche motivo sono rimasto sorpreso da questo! Lasciamo che i manutentori inizino a muovere il progetto in questa direzione! È successo? Come lo faresti esattamente? Non sempre. Ma comunque sia stato affrontato, ho realizzato il progetto come volevo. + +### Lascia che siano gli altri a creare le soluzioni di cui hanno bisogno + +Se un potenziale collaboratore ha un'opinione diversa su ciò che dovrebbe fare il tuo progetto, potresti dover incoraggiarlo gentilmente a lavorare sul proprio fork. + +Biforcare un progetto non è necessariamente una cosa negativa. Essere in grado di copiare e modificare progetti è una delle cose migliori dell'open source. Incoraggiare i membri della tua comunità a lavorare sul proprio fork può fornire lo sbocco creativo di cui hanno bisogno senza entrare in conflitto con la visione del tuo progetto. + + + +Lo stesso vale per un utente che desidera davvero una soluzione che semplicemente non hai la capacità di creare. Offrire API e hook personalizzati può aiutare gli altri a soddisfare le proprie esigenze senza dover modificare direttamente la fonte. +@orta [ha trovato che](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) incoraggiando i plugin CocoaPods ad "alcune delle idee più interessanti": + +> È quasi inevitabile che una volta che un progetto diventa grande, i manutentori debbano essere molto più conservatori su come introdurre il nuovo codice. Sai dire di no, ma molte persone hanno bisogni legittimi. Pertanto, finisci per trasformare il tuo strumento in una piattaforma. + +## Porta avanti i robot + +Quindi, proprio come ci sono compiti in cui altre persone possono aiutarti, ci sono anche compiti che nessun essere umano dovrebbe svolgere. I robot sono tuoi amici. Usali per semplificarti la vita come manutentore del codice. + +### Richiedi test e altri controlli per migliorare la qualità del tuo codice + +Uno dei modi più importanti per automatizzare il tuo progetto è attraverso i test. + +I test aiutano i contributori a sentirsi sicuri che non romperanno nulla. Inoltre, facilitano la revisione e l'accettazione rapida dei contributi. Più sei ricettivo, più sarai coinvolto. sii la tua comunità. + +Imposta test automatizzati per eseguire tutti i contributi in arrivo e garantire che possano essere eseguiti localmente dai contributori. È necessario che tutti i contributi al codice superino i test prima di poter essere inviati. Contribuirà a stabilire uno standard minimo di qualità per tutte le applicazioni. +[Sono necessari controlli sullo stato](https://help.github.com/articles/about-required-status-checks/) su GitHub può aiutare a garantire che nessuna modifica venga unita senza prima eseguire i test. + +Se aggiungi test, assicurati di spiegare come funzionano nel tuo file CONTRIBUTING. + + + +### Utilizza strumenti per automatizzare le attività di manutenzione di base + +La buona notizia nel mantenere un progetto popolare è che altri manutentori hanno probabilmente riscontrato problemi simili e hanno creato una soluzione per questo. + +Sono disponibili [vari strumenti](https://github.com/showcases/tools-for-open-source) per automatizzare alcuni aspetti del lavoro di manutenzione. Alcuni esempi: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automatizzare i tuoi rilasci +* [mention-bot](https://github.com/facebook/mention-bot) menzionare possibili revisori per le richieste del timone +* [Danger](https://github.com/danger/danger) aiuta ad automatizzare la revisione del codice + +Per segnalazioni di bug e altri contributi generali, GitHub dispone di [modelli di richiesta di rilascio e pull](https://github.com/blog/2111-issue-and-pull-request-templates), che puoi creare per semplificare la comunicazione che ricevi. Puoi anche configurare [filtri email](https://github.com/blog/2203-email-updates-about-your-own-activity) per gestire le tue notifiche email. + +Se vuoi diventare un po' più avanzato, le guide di stile possono standardizzare i contributi del progetto e renderli più facili da rivedere e adottare. + +Tuttavia, se i tuoi standard sono troppo complessi, possono aumentare gli ostacoli alla contribuzione. Assicurati di aggiungere solo regole per rendere la vita più semplice a tutti. + +Se non sei sicuro di quali strumenti utilizzare, controlla cosa stanno facendo altri progetti popolari, in particolare quelli nel tuo ecosistema. Ad esempio, come si presenta il processo di contribuzione per gli altri moduli Node? Anche l'utilizzo di strumenti e approcci simili faciliterà. Rendi il tuo processo più familiare ai tuoi associati target. + +## È una bella pausa + +Il lavoro open source una volta ti dava gioia. Forse ora è così che iniziano a farti sentire evasivo o colpevole. + +Forse ti senti sopraffatto o provi un crescente senso di paura quando pensi ai tuoi progetti. E nel frattempo si accumulano problemi e pull request. + +Il burnout è un problema reale e pervasivo nel lavoro open source, soprattutto tra i manutentori. In qualità di manutentore, la tua felicità è un requisito non negoziabile per la sopravvivenza di qualsiasi progetto open source. + +Anche se dovrebbe essere ovvio, prenditi una pausa! Non devi aspettare finché non ti senti stanco per fare una pausa. @brettcannon, uno sviluppatore Python, ha deciso di prendersi una [mese di vacanza](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) dopo 14 anni OSS volantariato. + +Come qualsiasi altro tipo di lavoro, fare delle pause regolari ti manterrà motivato. freschi, felici ed entusiasti del loro lavoro. + + + +A volte può essere difficile prendersi una pausa dal lavoro open source quando ritieni che il mondo intero abbia bisogno di te. Le persone potrebbero anche provare a farti sentire in colpa per esserti allontanato. + +Fai del tuo meglio per trovare supporto per i tuoi utenti e la tua comunità mentre sei lontano da un progetto. Se non riesci a trovare il supporto di cui hai bisogno, prenditi comunque una pausa. Ricordati di comunicare quando non sei disponibile in modo che le persone non si sentano confuse dalla tua mancanza di reattività. + +Fare le vacanze è qualcosa di più delle semplici vacanze. Se non vuoi lavorare con l'open source nei fine settimana o durante l'orario lavorativo, comunica queste decisioni ad altri in modo che sappiano che non sarai disturbato. + +## Prenditi cura di te prima! + +Mantenere un progetto popolare richiede competenze diverse rispetto alle prime fasi di crescita, ma non è per questo meno gratificante. In qualità di manutentore, eserciterai le capacità di leadership e di gestione delle persone a un livello che poche persone possono sperimentare. Anche se non è sempre facile da gestire, stabilire dei limiti chiari e prendere solo ciò che ti fa sentire a tuo agio ti aiuterà. per mantenerti felice, aggiornato e produttivo. diff --git a/_articles/it/building-community.md b/_articles/it/building-community.md new file mode 100644 index 00000000000..94ec2a38069 --- /dev/null +++ b/_articles/it/building-community.md @@ -0,0 +1,276 @@ +--- +lang: it +title: Costruire comunità accoglienti +description: Costruire una comunità che incoraggi le persone a utilizzare, contribuire ed educare con il tuo progetto +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Prepara il tuo progetto per il successo + +Hai appena lanciato il tuo progetto, stai spargendo la voce e le persone ti seguono. Brillante! Ora, come fai a farli restare? + +Una comunità accogliente è un investimento sul futuro del tuo progetto e della tua reputazione. Se il tuo progetto sta appena iniziando a vedere i primi contributi, inizia offrendo ai primi contributori un'esperienza positiva e rendendo facile per loro continuare a tornare. + +### Fai sentire le persone benvenute + +Un modo di pensare alla community del tuo progetto è attraverso quello che @MikeMcQuaid chiama [funnel del collaboratore](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Canalizzazione del collaboratore](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +Mentre costruisci la tua community, considera come qualcuno in cima alla canalizzazione (un potenziale utente) potrebbe teoricamente scendere verso il basso (un sostenitore attivo). Il tuo obiettivo è ridurre l'attrito in ogni fase dell'esperienza associata. Quando le persone ottengono vittorie facili, saranno motivate a fare di più. + +Inizia con la tua documentazione: + +* **Semplifica le cose per coloro che hanno bisogno di utilizzare il progetto.** [Documento README intuitivo](../starting-a-project/#scrivi-readme) e chiari esempi di codice lo renderanno facile da usare. È un inizio facile per chiunque si imbatta nel tuo progetto. +* **Spiega chiaramente come contribuire** utilizzando [CONTRIBUTING file](../starting-a-project/#scrivi-le-linee-guida-per-il-tuo-contributo) e mantieni aggiornati i tuoi problemi. +* **Buone prime edizioni**: per aiutare i nuovi contributori a iniziare, pensa chiaramente a [sottolineare gli argomenti che sono abbastanza semplici da poter essere gestiti da un principiante](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub mostrerà quindi questi problemi in vari punti della piattaforma, aumentando i contributi utili e riducendo la pressione degli utenti che affrontano questioni troppo difficili per il loro livello. + +[Sondaggio open source GitHub 2017](http://opensourcesurvey.org/2017/) ha dimostrato che la documentazione incompleta o confusa è il problema più grande per gli utenti open source. Una buona documentazione invita le persone a interagire con il tuo progetto. Alla fine, qualcuno aprirà un problema o una richiesta. Usa queste interazioni come opportunità per spostarle lungo la canalizzazione. + +* **Quando qualcuno di nuovo si unisce al tuo progetto, ringrazialo per il suo interesse!** Basta un'esperienza negativa per far sì che qualcuno non voglia più tornare. +* **Sii reattivo.** Se non rispondi alla loro domanda per un mese, è probabile che si siano già dimenticati del tuo progetto. +* **Sii di mentalità aperta riguardo ai tipi di contributi che accetti.** Molti contributori iniziano segnalando un bug o apportando una piccola correzione. Ci sono [molti modi per contribuire](../how-to-contribute/#cosa-significa-contribuire) ad un progetto. Lascia che le persone aiutino nel modo in cui vogliono aiutare. +* **Se c'è un contributo con cui non sei d'accordo,** ringrazialo per la sua idea e [spiegate perchè](../best-practices/#impara-a-dire-di-no) non soddisfa lo scopo del progetto, con un collegamento alla documentazione pertinente, se disponibile. + + + +La maggior parte dei contributori open source sono "collaboratori occasionali": persone che contribuiscono a un progetto solo occasionalmente. Un collaboratore occasionale potrebbe non avere il tempo di familiarizzare completamente con il tuo progetto, quindi il tuo compito è facilitare il suo contributo. + +Incoraggiare altri contributori è anche un investimento su te stesso. Quando permetti ai tuoi più grandi fan di lavorare sul lavoro che li appassiona, c'è meno pressione nel dover fare tutto da solo. + +### Documenta tutto + + + +Quando si inizia un nuovo progetto, può sembrare naturale mantenere segreto il proprio lavoro. Ma i progetti open source prosperano quando documenti pubblicamente il tuo processo. + +Quando documenti le cose, più persone possono essere coinvolte in ogni fase del processo. Potresti ricevere aiuto per qualcosa di cui non sapevi nemmeno di aver bisogno. + +Annotare le cose significa molto più che una semplice documentazione tecnica. Ogni volta che senti il ​​bisogno di scrivere qualcosa o discutere del tuo lavoro in privato, chiediti se puoi renderlo pubblico. + +Sii trasparente riguardo alla roadmap del tuo progetto, ai tipi di contributi che stai cercando, a come vengono considerati i contributi o al motivo per cui hai preso determinate decisioni. + +Se noti che molti utenti hanno lo stesso problema, documenta le risposte nel README. + +Per le riunioni, valuta la possibilità di pubblicare i tuoi appunti o i tuoi appunti in un thread correlato. Il feedback che otterrai da questo livello di trasparenza potrebbe sorprenderti. + +Documentare tutto vale anche per il lavoro che svolgi. Se stai lavorando a un aggiornamento importante del tuo progetto, inseriscilo in una richiesta pull e contrassegnalo come work in progress (WIP). In questo modo, altre persone possono sentirsi coinvolte fin dall'inizio nel processo. + +### Sii reattivo + +Mentre [promuovi il tuo progetto](../finding-users), le persone avranno feedback su di te. Potrebbero avere domande su come funzionano le cose o aver bisogno di aiuto per iniziare. + +Cerca di essere reattivo quando qualcuno segnala un problema, invia una richiesta pull o pone una domanda sul tuo progetto. Quando rispondi rapidamente, le persone si sentiranno parte di un dialogo e saranno più entusiaste di partecipare. + +Anche se non puoi esaminare immediatamente la richiesta, confermarla tempestivamente aiuta ad aumentare il coinvolgimento. Ecco come @tdreyno ha risposto a una richiesta pull su [Middleman](https://github.com/middleman/middleman/pull/1466): + +![Middleman richiesta di download](/assets/images/building-community/middleman_pr.png) + +[Questo è ciò che ha scoperto uno studio Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) i contributori che hanno ricevuto revisioni del codice entro 48 ore hanno avuto un tasso di rendimento e ricontribuzione molto più elevato. + +Le discussioni sul tuo progetto potrebbero svolgersi anche altrove sul Web, come Stack Overflow, Twitter o Reddit. Puoi impostare le notifiche in alcuni di questi luoghi in modo da ricevere una notifica quando qualcuno menziona il tuo progetto. + +### Offri alla tua comunità un luogo in cui riunirsi + +Ci sono due ragioni per dare alla tua comunità un luogo in cui riunirsi. + +Il primo motivo è per loro. Aiuta le persone a conoscersi. Le persone con interessi comuni vorranno inevitabilmente un posto dove parlarne. E quando la comunicazione è pubblica e accessibile, chiunque può leggere gli archivi del passato per imparare e partecipare. + +Il secondo motivo è per te. Se non offri alle persone un luogo pubblico in cui parlare del tuo progetto, probabilmente ti contatteranno direttamente. All'inizio può sembrare abbastanza semplice rispondere ai messaggi privati ​​"solo per questa volta". Ma col tempo, soprattutto se il tuo progetto diventa popolare, ti sentirai esausto. Resisti alla tentazione di comunicare in privato con le persone riguardo al tuo progetto. Indirizzali invece a un canale pubblico specifico. + +La comunicazione pubblica può essere semplice come invitare le persone ad aprire un problema invece di inviarti direttamente un'e-mail o commentare sul tuo blog. Puoi anche impostare una mailing list o creare un account Twitter, Slack o un canale IRC affinché le persone possano parlare del tuo progetto. Oppure prova tutto quanto sopra! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) dedica ore di lavoro ogni due settimane per aiutare i membri della comunità: + +> Kops inoltre dedica del tempo ogni settimana per offrire aiuto e guida alla comunità. I manutentori di Kops hanno concordato di dedicare del tempo specificatamente dedicato al lavoro con i nuovi arrivati, aiutando con le PR e discutendo le nuove funzionalità. + +Eccezioni notevoli alla comunicazione pubblica sono: 1) questioni di sicurezza e 2) violazioni sensibili del codice di condotta. Dovresti sempre avere la possibilità che le persone possano segnalare questi problemi di persona. Se non desideri utilizzare la tua email personale, imposta un indirizzo email dedicato. + +## Fai crescere la tua comunità + +Le comunità sono estremamente forti. Questo potere può essere una benedizione o una maledizione, a seconda di come lo eserciti. Man mano che la community del tuo progetto cresce, ci sono modi per aiutarla a diventare una forza di costruzione, non di demolizione. + +### Non tollerare i cattivi attori + +Qualsiasi progetto popolare attirerà inevitabilmente persone che danneggiano, non aiutano, la tua comunità. Potrebbero avviare dibattiti non necessari, discutere su aspetti banali o fare il prepotente con gli altri. + +Fai del tuo meglio per adottare una politica di tolleranza zero nei confronti di questo tipo di persone. Se lasciate senza controllo, le persone negative metteranno a disagio le altre persone nella tua comunità. Potrebbero anche andarsene. + + + +Discussioni regolari su aspetti banali del tuo progetto distraggono gli altri, te compreso, dal concentrarsi su compiti importanti. Le nuove persone che arrivano al tuo progetto potrebbero vedere queste conversazioni e non voler partecipare. + +Quando vedi che si verifica un comportamento negativo, fai un'osservazione pubblica al riguardo. Spiegare in tono amichevole perché tale comportamento non è accettabile. Se il problema persiste, potrebbe essere necessario [chiedergli di andarsene](../code-of-conduct/#le-tue-responsabilità-come-manutentore). Il tuo [codice di condotta](../code-of-conduct/) può essere una guida costruttiva per queste conversazioni. + +### Incontra i contributori ovunque si trovino + +Una buona documentazione diventa sempre più importante man mano che la tua comunità cresce. I contributori occasionali che altrimenti potrebbero non avere familiarità con il tuo progetto leggono la tua documentazione per ottenere rapidamente il contesto di cui hanno bisogno. + +Nel tuo file CONTRIBUTING, indica esplicitamente ai nuovi contributori come iniziare. Potresti anche voler creare una sezione speciale per questo scopo. [Django](https://github.com/django/django), ad esempio, ha una pagina di destinazione speciale per accogliere i nuovi contributori. + +![Django pagin acon i nuovi contributori](/assets/images/building-community/django_new_contributors.png) + +Nella coda degli argomenti, contrassegna i bug appropriati per i diversi tipi di contributori: ad esempio [_"per principianti"_](https://kentcdodds.com/blog/first-timers-only), _"buon primo argomento"_ o _"documentazione"_. [Questi appunti](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) rendi facile per qualcuno che non conosce il tuo progetto scansionare rapidamente i tuoi argomenti e iniziare. + +Infine, usa la tua documentazione per far sentire le persone benvenute in ogni fase del processo. + +Non interagirai mai con la maggior parte delle persone che saranno coinvolte nel tuo progetto. Potrebbero esserci contributi che non hai ricevuto perché qualcuno si è sentito intimidito o non sapeva da dove cominciare. Anche poche parole gentili possono evitare che qualcuno lasci deluso il tuo progetto. + +Ad esempio, ecco come [Rubinius](https://github.com/rubinius/rubinius/) ha iniziato [la sua guida che contribuisce](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> Vogliamo iniziare ringraziandoti per aver utilizzato Rubinius. Questo progetto è un lavoro d'amore e apprezziamo tutti gli utenti che rilevano bug, apportano miglioramenti alle prestazioni e aiutano con la documentazione. Ogni contributo conta, quindi grazie per aver partecipato. Tenendo questo a mente, ecco alcune linee guida che ti chiediamo di seguire per poter risolvere con successo il tuo problema. + +### Condividi la proprietà del tuo progetto + + + +Le persone sono entusiaste di contribuire ai progetti quando sentono un senso di appartenenza. Ciò non significa che devi stravolgere la visione del tuo progetto o accettare input che non desideri. Ma più riconosci gli altri, più rimarranno presenti. + +Vedi se riesci a trovare modi per condividere il più possibile la proprietà con la tua comunità. Ecco alcune idee: + +* **Evita di correggere bug facili (non critici).** Usali invece come opportunità per reclutare nuovi contributori o fare da mentore a qualcuno che vorrebbe contribuire. All'inizio può sembrare innaturale, ma il tuo investimento verrà ripagato nel tempo. Ad esempio, @michaeljoseph ha chiesto a un collaboratore di inviare una richiesta pull per il problema [Cookiecutter](https://github.com/audreyr/cookiecutter) di seguito invece di risolverlo da solo. + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Avvia un file CONTRIBUTORI o AUTORI nel tuo progetto** che elenca tutti coloro che hanno contribuito al tuo progetto come [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Se hai una community numerosa, **invia una newsletter o scrivi un post sul blog** ringraziando i contributori. [This Week in Rust](https://this-week-in-rust.org/) di Rust e [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) di Hood sono due ottimi esempi. + +* **Concedi l'accesso al commit a ogni collaboratore.** @felixge ha scoperto che rendeva le persone [più entusiaste di migliorare le proprie soluzioni](https://felixge.de/2013/03/11/the-pull-request-hack.html) e ha anche trovato nuovi manutentori per progetti su cui non lavorava da un po'. + +* Se il tuo progetto è su GitHub, **sposta il tuo progetto dal tuo account personale a [Organizzazione](https://help.github.com/articles/creating-a-new-organization-account/)** e aggiungilo a almeno un amministratore di backup. Le organizzazioni facilitano il lavoro di progetto con collaboratori esterni. + +La realtà è che [la maggior parte dei progetti ha solo](https://peerj.com/preprints/1233/) uno o due manutentori che svolgono la maggior parte del lavoro. Più grande è il tuo progetto e la tua comunità, più facile sarà trovare aiuto. + +Anche se potresti non trovare sempre qualcuno che risponda alla chiamata, diffondere il segnale aumenta le possibilità che altre persone vengano coinvolte. E prima inizi, prima le persone potranno aiutarti. + + + +## Risoluzione dei conflitti + +Nelle prime fasi del tuo progetto, prendere decisioni importanti è facile. Quando vuoi fare qualcosa, fallo e basta. + +Man mano che il tuo progetto diventa più popolare, sempre più persone saranno interessate alle decisioni che prendi. Anche se non hai una grande comunità di contributori, se il tuo progetto ha molti utenti, troverai persone che valutano soluzioni o sollevano i propri problemi. + +Nella maggior parte dei casi, se hai coltivato una comunità amichevole e rispettosa e hai documentato apertamente i tuoi processi, la tua comunità dovrebbe essere in grado di trovare una soluzione. Ma a volte ti imbatti in un problema un po' più difficile da risolvere. + +### Stabilisci lo standard di civiltà + +Quando la tua comunità è alle prese con una questione difficile, il morale può risollevarsi. Le persone potrebbero arrabbiarsi o frustrarsi e prendersela con gli altri o con te. + +Il tuo compito come sostenitore è evitare che queste situazioni peggiorino. Anche se hai una forte opinione sulla questione, prova ad assumere la posizione di moderatore o facilitatore invece di buttarti nella mischia e promuovere le tue opinioni. Se qualcuno è scortese o monopolizza la conversazione, [agisci immediatamente](../building-community/#non-tollerare-i-cattivi-attori) per mantenere la discussione civile e produttiva. + + + +Altre persone si rivolgono a te per avere una guida. Dai il buon esempio. Puoi ancora esprimere frustrazione, infelicità o preoccupazione, ma fallo con calma. + +Mantenere la calma non è facile, ma mostrare leadership migliora la salute della tua comunità. Internet ti ringrazia. + +### Tratta il tuo README come una costituzione + +Il tuo README è [più di un semplice insieme di istruzioni](../starting-a-project/#scrivi-readme). È anche un luogo in cui parlare dei tuoi obiettivi, della visione del prodotto e della tabella di marcia. Se le persone sono troppo concentrate nel discutere i meriti di una particolare funzionalità, potrebbe essere utile rivisitare il tuo README e parlare della visione più elevata del tuo progetto. Concentrarsi sul README spersonalizza anche la conversazione in modo da poter avere una discussione costruttiva. + +### Concentrati sul viaggio, non sulla destinazione + +Alcuni progetti utilizzano un processo di voto per prendere decisioni importanti. Anche se a prima vista ragionevole, il voto enfatizza il raggiungimento di una "risposta" piuttosto che l'ascolto e la considerazione delle preoccupazioni degli altri. + +Il voto può diventare politico quando i membri della comunità si sentono spinti a fare favori o a votare in un certo modo. Non tutti votano, siano essi [la maggioranza silenziosa](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) nella tua comunità o tra gli utenti attuali che non sapevano che fosse in corso una votazione. + +A volte è richiesto un voto di parità. Tuttavia, per quanto puoi, enfatizza ["la ricerca del consenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), piuttosto che consenso. + +In un processo di ricerca del consenso, i membri della comunità discutono le preoccupazioni chiave finché non sentono di essere stati adeguatamente ascoltati. Quando rimangono solo preoccupazioni secondarie, la comunità va avanti. La ricerca del consenso riconosce che una comunità potrebbe non essere in grado di arrivare a una risposta perfetta. Invece, dà priorità all'ascolto e alla discussione. + + + +Anche se in realtà non adotti un processo di ricerca del consenso, come progetto di supporto è importante che le persone sappiano che stai ascoltando. Far sì che le altre persone si sentano ascoltate e impegnate a risolvere le loro preoccupazioni è molto utile per allentare la tensione in situazioni delicate. Quindi segui le tue parole con l'azione. + +Non affrettarti a prendere una decisione per il gusto di prendere una decisione. Assicurati che tutti si sentano ascoltati e che tutte le informazioni siano condivise prima di passare a una decisione. + +### Mantieni la conversazione focalizzata sull'azione + +La discussione è importante, ma esiste una differenza tra conversazioni produttive e improduttive. + +Incoraggiare la discussione fintanto che si muove attivamente verso la risoluzione. Se è chiaro che la conversazione sta morendo o sta andando fuori tema, che il fastidio sta diventando personale o che le persone litigano su dettagli minori, è ora di chiuderla. + +Consentire che queste conversazioni continuino non è solo dannoso per il problema in questione, ma anche per la salute della tua comunità. Invia il messaggio che questo tipo di conversazione è consentito o addirittura incoraggiato e potrebbe scoraggiare le persone dal sollevare o risolvere problemi futuri. + +Per ogni punto sollevato da te o da altri, chiediti: "In che modo questo ci avvicina a una soluzione?"_ + +Se la conversazione inizia a sgretolarsi, chiedi al gruppo _"Quali passi dovremmo intraprendere dopo?"_ per reindirizzare la conversazione. + +Se la conversazione non sta chiaramente andando da nessuna parte, non c'è alcuna azione chiara da intraprendere o l'azione appropriata è già stata intrapresa, chiudi il problema e spiega perché l'hai chiuso. + + + +### Scegli saggiamente le tue battaglie + +Il contesto è importante. Considera chi partecipa alla conversazione e come rappresenta il resto della comunità. + +Tutti nella comunità sono sconvolti o addirittura preoccupati per questo? Oppure è un piantagrane solitario? Ricorda di considerare i membri silenziosi della tua comunità, non solo le voci attive. + +Se il problema non rappresenta le esigenze più ampie della tua comunità, potresti dover semplicemente accogliere le preoccupazioni di alcune persone. Se si tratta di un problema ricorrente senza una soluzione chiara, rimandali alle discussioni precedenti sull'argomento e chiudi l'argomento. + +### Definire il criterio di equilibrio comunitario + +Con un buon comportamento e una comunicazione chiara, le situazioni più difficili vengono risolte. Tuttavia, anche in una discussione produttiva, potrebbe esserci semplicemente una divergenza di opinioni su come procedere. In questi casi, identifica una persona o un gruppo di persone che possano fungere da equilibratore. + +Un livellatore può essere il principale sostenitore del progetto, oppure può essere un piccolo gruppo di persone che prendono una decisione in base a un voto. Idealmente, è necessario definire un livellatore e la procedura associata in un file GOVERNANCE prima di doverlo utilizzare. + +La decisione sulla parità dovrebbe essere l'ultima risorsa. Le questioni di divisione rappresentano un'opportunità per la tua comunità di crescere e imparare. Cogli queste opportunità e utilizza un processo collaborativo per procedere verso la risoluzione quando possibile. + +## La community è ❤️ open source + +Comunità sane e fiorenti alimentano le migliaia di ore investite ogni settimana nell'open source. Molti contributori citano altre persone come motivo per lavorare - o non lavorare - con l'open source. Imparando a sfruttare questo potere in modo costruttivo, aiuterai qualcuno a vivere un'esperienza open source indimenticabile. diff --git a/_articles/it/code-of-conduct.md b/_articles/it/code-of-conduct.md new file mode 100644 index 00000000000..678174ad1e2 --- /dev/null +++ b/_articles/it/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: it +title: Il tuo codice di condotta +description: Facilitare un comportamento comunitario sano e costruttivo adottando e applicando un codice di condotta. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Perché ho bisogno di un codice di condotta? + +Un codice di condotta è un documento che definisce le aspettative comportamentali dei partecipanti al tuo progetto. L'adozione e l'applicazione di un codice di condotta può contribuire a creare un'atmosfera sociale positiva per la tua comunità. + +I codici di condotta aiutano a proteggere non solo i tuoi partecipanti ma anche te stesso. Se stai portando avanti un progetto, potresti scoprire che l'atteggiamento improduttivo degli altri partecipanti può farti sentire svuotato o insoddisfatto del tuo lavoro nel tempo. + +Un Codice di condotta ti consente di facilitare un comportamento sano e costruttivo nella comunità. Essere proattivi riduce le probabilità che tu o gli altri vi stanchiate del vostro progetto e vi aiuta ad agire quando qualcuno fa qualcosa con cui non siete d'accordo. + +## Stabilire un codice di condotta + +Cerca di creare un codice di condotta il prima possibile: idealmente quando crei per la prima volta il tuo progetto. + +Oltre a comunicare le vostre aspettative, il codice di condotta descrive quanto segue: + +* Dove entra in vigore il codice di condotta _(solo per problemi e pull request o attività della community come eventi?)_ +* A chi si applica il codice di condotta _(membri della comunità e sostenitori, ma per quanto riguarda gli sponsor?)_ +* Cosa succede se qualcuno infrange il codice di condotta +* Come qualcuno può segnalare violazioni + +Usa la tecnica precedente dove puoi. [Accordo dei contributori](https://contributor-covenant.org/) è un codice di comportamento utilizzato da oltre 40.000 progetti open source, inclusi Kubernetes, Rails e Swift. + +[Il codice di condotta di Django](https://www.djangoproject.com/conduct/) e [Il codice di condotta dei cittadini](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sono due buoni esempi di codice di condotta. + +Inserisci un file CODE_OF_CONDUCT nella directory principale del tuo progetto e rendilo visibile alla tua comunità collegandolo dal tuo file CONTRIBUTING o README. + +## Decidi come applicherai il tuo codice di condotta + + + +È necessario spiegare come verrà applicato il codice di condotta **_prima_** di una violazione. Ci sono diversi motivi per farlo: + +* Dimostra che sei seriamente intenzionato ad agire quando necessario. + +* La tua comunità si sentirà più sicura che i reclami vengano effettivamente esaminati. + +* Assicurerai alla tua comunità che il processo di revisione è giusto e trasparente nel caso in cui si trovassero indagati per una violazione. + +Dovresti fornire alle persone un modo personale (ad esempio un indirizzo e-mail) per segnalare una violazione del codice di condotta e spiegare chi riceve tale segnalazione. Potrebbe trattarsi di un manutentore, di un gruppo di manutentori o di un gruppo di lavoro sul codice di condotta. + +Ricorda che qualcuno può chiedere di segnalare una violazione a una persona che riceve queste segnalazioni. In questo caso, date loro la possibilità di segnalare le violazioni a qualcun altro. Ad esempio, @ctb e @mr-c [spiegano il loro progetto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> Casi di abuso, molestie o comportamenti altrimenti inaccettabili possono essere segnalati inviando un'e-mail a **khmer-project@idyll.org** solo a C. Titus Brown e Michael R. Crusoe. Per segnalare un problema con uno di questi, inviare un'e-mail a **Judi Brown Clarke, Ph.D.** Direttore della Diversità presso il BEACON Center for the Study of Evolution in Action, NSF Science and Technology Center.* + +Per trovare ispirazione, consulta il [manuale di applicazione delle norme](https://www.djangoproject.com/conduct/enforcement-manual/) di Django (anche se potresti non aver bisogno di qualcosa di così completo, a seconda delle dimensioni del tuo progetto). + +## Applicare il codice di condotta + +A volte, nonostante i tuoi migliori sforzi, qualcuno fa qualcosa che viola questo codice. Esistono diversi modi per affrontare un comportamento negativo o dannoso quando si verifica. + +### Raccogli informazioni sulla situazione + +Considera la voce di ogni membro della comunità importante quanto la tua. Se ricevi una segnalazione secondo cui qualcuno ha violato il codice di condotta, prendila sul serio e indaga sulla questione, anche se non corrisponde alla tua esperienza con quella persona. Ciò segnala alla tua comunità che apprezzi la loro prospettiva e ti fidi del loro giudizio. + +Il membro della comunità in questione potrebbe essere un recidivo che mette costantemente a disagio gli altri, o potrebbe aver detto o fatto qualcosa solo una volta. In entrambi i casi, possono costituire motivo di azione a seconda del contesto. + +Prima di rispondere, concediti il ​​tempo di capire cosa è successo. Leggi i commenti e le conversazioni passate della persona per capire meglio chi è e perché potrebbe essersi comportato in quel modo. Prova a raccogliere punti di vista diversi dal tuo su questa persona e sul suo comportamento. + + + +### Intraprendi le azioni appropriate + +Una volta raccolte ed elaborate informazioni sufficienti, dovrai decidere cosa fare. Mentre consideri i passaggi successivi, ricorda che il tuo obiettivo come moderatore è promuovere un ambiente sicuro, rispettoso e collaborativo. Considera non solo come gestire la situazione in questione, ma anche come la tua risposta influenzerà il comportamento e le aspettative del resto della tua comunità in futuro. + +Quando qualcuno segnala una violazione del codice di condotta, è compito tuo, non suo, occupartene. A volte un giornalista rivela informazioni che mettono a grave rischio la sua carriera, reputazione o incolumità fisica. Costringerli ad affrontare il loro aggressore può mettere il giornalista in una posizione compromettente. È necessario mantenere una comunicazione diretta con la persona in questione, a meno che chi ha segnalato non richieda espressamente il contrario. + +Esistono diversi modi per rispondere a una violazione del codice di condotta: + +* **Dai alla persona in questione un avvertimento pubblico** e spiega come il suo comportamento ha influenzato negativamente gli altri, preferibilmente nel canale in cui è successo. Quando possibile, la comunicazione pubblica comunica al resto della comunità che si prende sul serio il codice di condotta. Sii gentile ma fermo nella tua comunicazione. + +* **Contatta di persona la persona in questione** per spiegare in che modo il suo comportamento ha influenzato negativamente gli altri. Potresti voler utilizzare un canale di comunicazione privato se la situazione coinvolge informazioni personali sensibili. Se stai comunicando con qualcuno in privato, è una buona idea mettere in copia coloro che per primi hanno segnalato la situazione in modo che sappiano che hai preso provvedimenti. Chiedere il consenso all'informatore prima di inviarlo in CC. + +A volte non è possibile raggiungere alcuna soluzione. La persona in questione può diventare aggressiva o ostile quando confrontata o non cambiare il proprio comportamento. In questa situazione, potresti prendere in considerazione l'idea di intraprendere azioni più drastiche. Per esempio: + +* **Espulsione della persona in questione** dal progetto, imposta tramite un'interdizione temporanea dalla partecipazione a qualsiasi aspetto del progetto + +* **Permanente** banna la persona dal progetto + +L'esclusione dei membri non dovrebbe essere presa alla leggera e rappresenta una divergenza di opinioni permanente e inconciliabile. Dovresti adottare queste misure solo quando è chiaro che non è possibile raggiungere una soluzione. + +## Le tue responsabilità come manutentore + +Un codice di condotta non è una legge applicata arbitrariamente. Tu sei il garante del codice di condotta ed è tua responsabilità seguire le regole stabilite dal codice di condotta. + +In qualità di manutentore, stabilisci le linee guida per la tua comunità e applichi tali linee guida secondo le regole stabilite nel tuo codice di condotta. Ciò significa prendere sul serio ogni segnalazione di violazione del codice di condotta. Al giornalista è dovuta un'analisi approfondita e corretta della sua denuncia. Se ritieni che il comportamento segnalato non costituisca una violazione, chiariscilo e spiega perché non intendi intraprendere alcuna azione in merito. Ciò che fanno dipende da loro: tollerare il comportamento con cui hanno avuto problemi o smettere di partecipare alla comunità. + +Segnalare un comportamento che _tecnicamente_ non viola il codice di condotta può comunque indicare che c'è un problema nella tua comunità e dovresti indagare su quel potenziale problema e agire di conseguenza. Ciò potrebbe comportare la revisione del codice di condotta per chiarire quale sia il comportamento accettabile e/o parlare alla persona il cui comportamento è stato segnalato e dirle che, sebbene non abbia violato il codice di condotta, sta aggirando il limite di ciò che ci si aspetta e assicurarsi che i partecipanti si sentano a disagio. + +In definitiva, come sostenitore, definisci e applichi gli standard di comportamento accettabile. Hai la capacità di plasmare i valori della comunità del progetto e i partecipanti si aspettano che tu applichi tali valori in modo giusto ed equo. + +## Incoraggia il comportamento che vuoi vedere nel mondo 🌎 + +Quando un progetto appare ostile o inospitale, anche se si tratta di una sola persona il cui comportamento è tollerato dagli altri, rischi di perdere molti altri contributori, alcuni dei quali potresti non incontrare nemmeno. Non è sempre facile adottare o far rispettare un codice di condotta, ma promuovere un ambiente accogliente aiuterà la tua comunità a crescere. diff --git a/_articles/it/finding-users.md b/_articles/it/finding-users.md new file mode 100644 index 00000000000..02d01187e2a --- /dev/null +++ b/_articles/it/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: it +title: Trovare utenti per il tuo progetto +description: Aiuta il tuo progetto open source a crescere mettendolo nelle mani di utenti soddisfatti. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Diffondere la parola + +Non esiste una regola che dice che devi pubblicizzare un progetto open source al momento del lancio. Ci sono molte buone ragioni per passare all'open source che non hanno nulla a che fare con la popolarità. Invece di sperare che altri trovino e utilizzino il tuo progetto open source, dovresti spargere la voce sul tuo duro lavoro! + +## Trasmetti il ​​tuo messaggio + +Prima di iniziare il lavoro vero e proprio di promozione del tuo progetto, devi essere in grado di spiegare cosa fa e perché è importante. + +Cosa rende il tuo progetto diverso o interessante? Perché l'hai creato? Rispondere solo a queste domande ti aiuterà a comunicare l'importanza del tuo progetto. + +Ricorda che le persone vengono coinvolte come utenti e alla fine diventano contributori perché il tuo progetto risolve loro un problema. Mentre pensi al messaggio e al valore del tuo progetto, prova a vederlo attraverso la lente di ciò che _utenti e contributori_ potrebbero desiderare. + +Ad esempio, @robb utilizza esempi di codice per comunicare chiaramente perché il suo progetto, [Cartography](https://github.com/robb/Cartography), è utile: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +Per un approfondimento sulla messaggistica, consulta l'esercizio ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) di Mozilla sullo sviluppo dei personaggi degli utenti. + +## Aiuta le persone a trovare e seguire il tuo progetto + + + +Aiuta le persone a trovare e ricordare il tuo progetto indirizzandole a un singolo spazio dei nomi. + +**Avere un approccio chiaro per promuovere il tuo lavoro.** Un handle di Twitter, un URL GitHub o un canale IRC è un modo semplice per indirizzare le persone al tuo progetto. Questi punti vendita forniscono anche un luogo di ritrovo per la crescente comunità del tuo progetto. + +Se ancora non vuoi creare output per il tuo progetto, promuovi il tuo account Twitter o GitHub in tutto ciò che fai. Promuovere il tuo Twitter o GitHub permetterà alle persone di sapere come contattarti o seguire il tuo lavoro. Se parli a una riunione o a un evento, assicurati che le informazioni di contatto siano incluse nella biografia o nelle diapositive. + + + +**Considera l'idea di creare un sito web per il tuo progetto.** Un sito web rende il tuo progetto più user-friendly e facile da navigare, soprattutto se abbinato a documentazione e tutorial chiari. Avere un sito web suggerisce anche che il tuo progetto è attivo, il che farà sentire il tuo pubblico più a suo agio nell'utilizzarlo. Fornisci esempi per dare alle persone idee su come utilizzare il tuo progetto. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), сco-creatore di Django, ha detto che il sito web è stato _"di gran lunga la cosa migliore che abbiamo fatto con Django nei primi giorni"_. + +Se il tuo progetto è ospitato su GitHub, puoi utilizzare [GitHub Pages](https://pages.github.com/) per creare facilmente un sito web. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) e [Middleman](https://middlemanapp.com/) sono [alcuni esempi](https://github.com/showcases/github-pages-examples) di siti Web eccellenti e completi. + +![Pagina iniziale di Vagrant](/assets/images/finding-users/vagrant_homepage.png) + +Ora che hai un annuncio sul tuo progetto e un modo semplice per consentire alle persone di trovarlo, usciamo e parliamo con il tuo pubblico! + +## Vai dove si trova il pubblico del tuo progetto (online) + +La sensibilizzazione online è un ottimo modo per condividere e spargere rapidamente la voce. Utilizzando i canali online, hai il potenziale per raggiungere un pubblico molto vasto. + +Sfrutta le community e le piattaforme online esistenti per raggiungere il tuo pubblico. Se il tuo progetto open source è un progetto software, probabilmente puoi trovare il tuo pubblico in [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) o [Quora](https://www.quora.com/). Trova i canali in cui ritieni che le persone trarranno maggiori benefici o saranno entusiaste del tuo lavoro. + + + +Vedi se riesci a trovare modi per condividere il tuo progetto in modi appropriati: + +* **Conosci progetti e comunità open source rilevanti.** A volte non è necessario pubblicizzare direttamente il tuo progetto. Se il tuo progetto è perfetto per i data scientist che utilizzano Python, consulta la community di data science di Python. Man mano che le persone ti conosceranno, ci saranno opportunità naturali per parlare e condividere il tuo lavoro. +* **Trova persone che affrontano il problema risolto dal tuo progetto.** Cerca nei forum correlati le persone che rientrano nel pubblico target del tuo progetto. Rispondi alla loro domanda e trova un modo discreto, se appropriato, per presentare il tuo progetto come soluzione. +* **Chiedi feedback.** Presenta te stesso e il tuo lavoro a un pubblico che lo troverà pertinente e interessante. Sii specifico su chi ritieni trarrà beneficio dal tuo progetto. Prova a completare la frase: _"Penso che il mio progetto aiuterà davvero X persone che stanno cercando di fare Y_". Ascolta e rispondi al feedback degli altri invece di limitarti a promuovere il tuo lavoro. + +In generale, concentrati sull'aiutare gli altri prima di chiedere qualcosa in cambio. Dato che chiunque può facilmente pubblicizzare un progetto online, ci sarà molto fermento. Per distinguerti dalla massa, dai alle persone un contesto su chi sei, non solo cosa vuoi. + +Se nessuno presta attenzione o risponde al tuo contatto iniziale, non scoraggiarti! La maggior parte dei lanci di progetti sono un processo iterativo che può richiedere mesi o anni. Se non ricevi risposta la prima volta, prova una tattica diversa o cerca prima modi per aggiungere valore al lavoro degli altri. Promuovere e lanciare il tuo progetto richiede tempo e dedizione. + +## Vai dove si trova il pubblico del tuo progetto (offline) + +![Discorso pubblico](/assets/images/finding-users/public_speaking.jpg) + +Gli eventi offline sono un modo popolare per promuovere nuovi progetti al pubblico. Sono un ottimo modo per raggiungere un pubblico coinvolto e creare connessioni umane più profonde, soprattutto se sei interessato a raggiungere gli sviluppatori. + +Se sei [nuovo nel parlare in pubblico](https://Speaking.io/), inizia trovando un incontro locale correlato alla lingua o all'ecosistema del tuo progetto. + + + +Se non hai mai parlato a un evento prima, è del tutto normale sentirsi nervoso! Ricorda che il tuo pubblico è lì perché vuole davvero conoscere il tuo lavoro. + +Mentre scrivi il tuo discorso, concentrati su ciò che il tuo pubblico troverà interessante e da cui trarrà beneficio. Mantieni il tuo linguaggio amichevole e accessibile. Sorridi, respira e divertiti. + + + +Quando ti senti pronto, considera di parlare a una conferenza per promuovere il tuo progetto. Le conferenze possono aiutarti a raggiungere più persone, a volte da tutto il mondo. + +Cerca conferenze specifiche per la tua lingua o ecosistema. Prima di inviare il tuo discorso, fai ricerche sulla conferenza per adattare il tuo discorso ai tuoi partecipanti e aumentare le tue possibilità di essere accettato a parlare alla conferenza. Spesso puoi farti un'idea del tuo pubblico guardando i relatori della conferenza. + + + +## Costruisci una reputazione + +Oltre alle strategie sopra descritte, il modo migliore per invitare le persone a condividere e contribuire al tuo progetto è condividere e contribuire ai loro progetti. + +Aiutare i nuovi arrivati, condividere risorse e contribuire in modo ponderato ai progetti di altre persone ti aiuterà a costruire una reputazione positiva. Essere un membro attivo della comunità open source aiuterà le persone a trovare un contesto per il tuo lavoro e ad essere più propense a prestare attenzione e a condividere il tuo progetto. Lo sviluppo di collegamenti con altri progetti open source può anche portare a partenariati formali. + + + +Non è mai troppo presto o troppo tardi per iniziare a costruire la tua reputazione. Anche se hai già avviato il tuo progetto, continua a cercare modi per aiutare gli altri. + +Non esiste una soluzione immediata per creare un pubblico. Guadagnarsi la fiducia e il rispetto degli altri richiede tempo e costruire la propria reputazione non finisce mai. + +## Continuare! + +Può volerci molto tempo prima che le persone notino il tuo progetto open source. Questo è buono! Alcuni dei progetti più popolari oggi hanno impiegato anni per raggiungere livelli elevati di attività. Concentrati sulla costruzione di relazioni invece di sperare che il tuo progetto ottenga spontaneamente popolarità. Sii paziente e continua a condividere il tuo lavoro con chi lo apprezza. diff --git a/_articles/it/getting-paid.md b/_articles/it/getting-paid.md new file mode 100644 index 00000000000..709d46e2ef4 --- /dev/null +++ b/_articles/it/getting-paid.md @@ -0,0 +1,177 @@ +--- +lang: it +title: Essere pagati per il lavoro open source +description: Mantieni il tuo lavoro open source ottenendo supporto finanziario per il tuo tempo o il tuo progetto. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Perché alcune persone cercano un sostegno finanziario + +Gran parte del lavoro open source è volontario. Ad esempio, qualcuno potrebbe imbattersi in un bug in un progetto che sta utilizzando e inviare una soluzione rapida, oppure potrebbe divertirsi armeggiare con un progetto open source nel tempo libero. + + + +Ci sono molte ragioni per cui non si vorrebbe essere pagati per il proprio lavoro open source. + +* **Potrebbero già avere un lavoro a tempo pieno che amano,** che consente loro di contribuire all'open source nel tempo libero. +* **A loro piace pensare all'open source come a un hobby** o a una fuga creativa e non vogliono sentirsi finanziariamente obbligati a lavorare sui propri progetti. +* **Ottengono altri vantaggi dal contributo all'open source,** come costruire una reputazione o un portfolio, apprendere nuove competenze o sentirsi vicini a una comunità. + + + +Per altri, soprattutto quando il contributo è in corso o richiede molto tempo, essere pagati per contribuire all'open source è l'unico modo per partecipare, sia perché il progetto lo richiede sia per motivi personali. + +Mantenere progetti popolari può essere una responsabilità significativa, impiegando 10 o 20 ore a settimana invece di poche ore al mese. + + + +Il lavoro retribuito consente inoltre a persone provenienti da percorsi di vita diversi di dare un contributo significativo. Alcune persone non possono permettersi di dedicare tempo non retribuito a progetti open source a causa della loro attuale situazione finanziaria, dei debiti, delle responsabilità familiari o di altro tipo. Ciò significa che il mondo non vede mai contributi da parte di persone di talento che non possono permettersi di offrire volontariato. Ciò ha implicazioni etiche, come @ashedryden [descritto](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) poiché il lavoro svolto è distorto nel favorire coloro che hanno già vantaggi nella vita, che poi ricevono ulteriori vantaggi in base ai loro contributi volontari, mentre ad altri che non possono fare volontariato vengono negate opportunità successive, rafforzando l'attuale mancanza di diversità nella comunità open source. + + + +Se stai cercando un sostegno finanziario, ci sono due modi da considerare. Puoi finanziare il tuo tempo come collaboratore oppure puoi trovare finanziamenti organizzativi per il progetto. + +## Finanziare il proprio tempo + +Oggi molte persone vengono pagate per lavorare part-time o full-time nell'open source. Il modo più comune per essere pagato per il tuo tempo è parlare con il tuo datore di lavoro. + +È più semplice sostenere il lavoro open source se il tuo datore di lavoro utilizza effettivamente il progetto, ma sii creativo con la tua presentazione. Forse il tuo datore di lavoro non utilizza il progetto, ma usa Python e il mantenimento di un progetto Python popolare aiuta ad attrarre nuovi sviluppatori Python. Forse fa sembrare il tuo datore di lavoro più amichevole agli sviluppatori in generale. + +Se non hai un progetto open source esistente su cui ti piacerebbe lavorare, ma preferisci che il tuo lavoro attuale sia open source, chiedi al tuo datore di lavoro di rendere open source alcuni dei loro software interni. + +Molte aziende stanno sviluppando programmi open source per rafforzare il proprio marchio e assumere talenti di qualità. + +@hueniverse ad esempio, ha scoperto che c'erano ragioni finanziarie per giustificare [l'investimento di Walmart nell'open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). E @jamesgpearce ha scoperto che il programma open source di Facebook [è importante](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) nel reclutamento: + +> È strettamente correlato alla nostra cultura hacker e al modo in cui la nostra organizzazione veniva percepita. Abbiamo chiesto ai nostri dipendenti: "Conoscevi il programma software open source di Facebook?". Due terzi hanno detto "Sì". La metà ha affermato che il programma ha contribuito positivamente alla decisione di lavorare per noi. Questi non sono numeri estremi e spero che la tendenza continui. + +Se la tua azienda segue questa strada, è importante mantenere chiari i confini tra le operazioni comunitarie e aziendali. Dopotutto, l'open source è supportato dal contributo di persone di tutto il mondo, e questo è più grande di quello di qualsiasi altra azienda o luogo. + + + +Se non riesci a convincere il tuo attuale datore di lavoro a dare priorità al lavoro open source, valuta la possibilità di trovare un nuovo datore di lavoro che incoraggi il contributo dei dipendenti all'open source. Cerca aziende che sottolineano il loro impegno verso l'open source. Per esempio: + +* Ad alcune aziende piace [Netflix](https://netflix.github.io/), hanno siti web che evidenziano il loro coinvolgimento nell'open source + +È probabile che anche i progetti che provengono da una grande azienda, come [Go](https://github.com/golang) o [React](https://github.com/facebook/react), assumano persone per lavorare con l'open source. + +A seconda delle tue circostanze personali, puoi provare a raccogliere fondi in modo indipendente per finanziare il tuo lavoro open source. Per esempio: + +* @Homebrew (e [molti altri sostenitori e organizzazioni](https://github.com/sponsors/community)) finanziano il loro lavoro tramite [Sponsor Github](https://github.com/sponsors) +* @gaearon ha finanziato il suo lavoro su [Redux](https://github.com/reactjs/redux) attraverso una [campagna di crowdfunding Patreon](https://redux.js.org/) +* I fondi @andrewgodwin lavorano sulle migrazioni dello schema Django [tramite campagna Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +Infine, a volte i progetti open source offrono premi per problemi che potresti considerare di aiutare. + +* @ConnorChristie è riuscito a essere pagato per [aiuto](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol stanno lavorando sulla propria libreria JavaScript [tramite ricompensa gitcoin](https://gitcoin.co/). +* @mamiM ha realizzato traduzioni giapponesi per @MetaMask dopo [il rilascio è stato finanziato da Bounties Network](https://explorer.bounties.network/bounty/134). + +## Trovare finanziamenti per il tuo progetto + +Oltre agli accordi per i singoli contributori, i progetti a volte raccolgono fondi da aziende, individui o altri per finanziare il lavoro in corso. + +I finanziamenti organizzativi possono essere utilizzati per pagare i contributori attuali, coprire i costi di gestione del progetto (come le tariffe di hosting) o investire in nuove funzionalità o idee. + +Con la crescente popolarità dell'open source, trovare finanziamenti per i progetti è ancora sperimentale, ma esistono alcune opzioni comuni. + +### Raccogli fondi per il tuo lavoro attraverso il crowdfunding o campagne di sponsorizzazione + +Trovare una sponsorizzazione funziona bene se hai già un pubblico o una reputazione forti o se il tuo progetto è molto popolare. +Alcuni esempi di progetti sponsorizzati includono: + +* **[webpack](https://github.com/webpack)** raccoglie denaro da aziende e privati ​​[via OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** organizzazione no-profit che paga il lavoro di [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) e altri progetti infrastrutturali di Ruby + +### Crea un flusso di reddito + +A seconda del tuo progetto, potresti essere in grado di addebitare il supporto commerciale, le opzioni di hosting o le funzionalità aggiuntive. Alcuni esempi includono: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** offre versioni a pagamento per ulteriore supporto +* **[Travis CI](https://github.com/travis-ci)** offre versioni a pagamento del suo prodotto +* **[Ghost](https://github.com/TryGhost/Ghost)** è un'organizzazione no-profit con un servizio gestito a pagamento + +Alcuni progetti popolari, come [npm](https://github.com/npm/cli) e [Docker](https://github.com/docker/docker), stanno addirittura raccogliendo capitali di rischio per sostenere la crescita di i loro affari. + +### Richiedi un finanziamento + +Alcune fondazioni e aziende di software offrono sovvenzioni per il lavoro open source. A volte le sovvenzioni possono essere pagate a individui senza creare un'entità legale per il progetto. + +* **[Leggi i documenti](https://github.com/rtfd/readthedocs.org)** ha ricevuto una sovvenzione da [Support of Mozilla Open Source](https://www.mozilla.org/en-US/grants/) +* Il lavoro su **[OpenMRS](https://github.com/openmrs)** è finanziato dall'[Open Source Retreat of Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** ha ricevuto una sovvenzione dalla [Fondazione Sloan](https://sloan.org/programs/digital-technology) +* **[Python Software Foundation](https://www.python.org/psf/grants/)** offre sovvenzioni per lavori legati a Python + +Per opzioni più dettagliate e casi di studio @nayafia [ha scritto una guida](https://github.com/nayafia/lemonade-stand) su come essere pagato per il lavoro open source. Diversi tipi di finanziamento richiedono competenze diverse, quindi considera i tuoi punti di forza per scoprire quale opzione funziona meglio per te. + +## Costruire una causa per il sostegno finanziario + +Che il tuo progetto sia una nuova idea o sia in circolazione da anni, dovresti aspettarti di dedicare molta attenzione all'identificazione del finanziatore target e alla presentazione di un caso convincente. + +Sia che tu voglia pagare per il tuo tempo libero o raccogliere fondi per un progetto, devi essere in grado di rispondere alle seguenti domande. + +### Impatto + +Perchè è utile questo progetto? Perché piace così tanto ai tuoi utenti o potenziali utenti? Dove sarà tra cinque anni? + +### Trazione + +Cerca di raccogliere prove dell'importanza del tuo progetto, che si tratti di parametri, aneddoti o testimonianze. Ci sono aziende o persone importanti che utilizzano il tuo progetto in questo momento? In caso contrario, una persona di spicco lo ha approvato? + +### Valore per il finanziatore + +Ai finanziatori, siano essi il tuo datore di lavoro o una fondazione che concede sovvenzioni, vengono spesso offerte opportunità. Perché dovrebbero sostenere il tuo progetto rispetto a qualsiasi altra opzione? Come ne traggono beneficio personalmente? + +### Utilizzo dei fondi + +Cosa otterrete esattamente con il finanziamento proposto? Concentrarsi sulle tappe fondamentali o sui risultati finali del progetto piuttosto che sul pagamento di uno stipendio. + +### Come riceverai i fondi + +Il finanziatore ha dei requisiti di rimborso? Ad esempio, potrebbe essere necessario essere un'organizzazione senza scopo di lucro o avere uno sponsor fiscale senza scopo di lucro. O forse i fondi dovrebbero essere assegnati a un singolo appaltatore piuttosto che a un'organizzazione. Questi requisiti variano tra i finanziatori, quindi assicurati di fare le tue ricerche in anticipo. + + + +## Sperimenta e non mollare + +Raccogliere fondi non è facile, che tu sia un progetto open source, un'organizzazione no profit o una startup di software, e nella maggior parte dei casi richiede che tu sia creativo. Determinare come vuoi essere pagato, fare le tue ricerche e metterti nei panni del tuo finanziatore ti aiuterà a costruire un caso convincente per il finanziamento. diff --git a/_articles/it/how-to-contribute.md b/_articles/it/how-to-contribute.md new file mode 100644 index 00000000000..932429a3946 --- /dev/null +++ b/_articles/it/how-to-contribute.md @@ -0,0 +1,526 @@ +--- +lang: it +title: Come contribuire all'open source +description: Vuoi contribuire all'open source? Una guida per fornire contributi open source sia per principianti che per veterani. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Perché contribuire all'Open Source? + + + +Contribuire all'open source può essere un modo gratificante per apprendere, insegnare e sviluppare competenze in quasi tutte le competenze immaginabili. + +Perché le persone contribuiscono all'open source? Molte ragioni! + +### Migliora il software su cui fai affidamento + +Molti contributori open source iniziano come utenti del software a cui contribuiscono. Quando trovi un bug nel software open source che stai utilizzando, potresti voler guardare la fonte per vedere se puoi risolverlo da solo. Se questo è il caso, ripristinare la patch è il modo migliore per garantire che i tuoi amici (e te stesso quando aggiorni alla versione successiva) possano trarne vantaggio. + +### Migliorare le competenze esistenti + +Che si tratti di codifica, progettazione dell'interfaccia utente, progettazione grafica, scrittura o organizzazione, se stai cercando pratica, c'è un progetto open source adatto a te. + +### Incontra persone interessate a cose simili + +I progetti open source con comunità calorose e accoglienti fanno sì che le persone ritornino per anni. Molte persone stringono amicizie durature attraverso la loro partecipazione all'open source, sia che si incontrino alle conferenze o alle chat di burrito online a tarda notte. + +### Trova mentori e insegna agli altri + +Lavorare con altri su un progetto condiviso significa che dovrai spiegare come stai facendo le cose e chiedere aiuto ad altre persone. Gli atti di apprendimento e insegnamento possono essere un'attività soddisfacente per tutti i soggetti coinvolti. + +### Costruisci artefatti pubblici che ti aiutino a sviluppare una reputazione (e una carriera) + +Per definizione, tutto il tuo lavoro open source è pubblico, il che significa che ottieni esempi gratuiti da portare ovunque come dimostrazione di ciò che sai fare. + +### Impara le abilità delle persone + +L'open source offre opportunità per esercitare capacità di leadership e gestione, come la risoluzione dei conflitti, l'organizzazione di gruppi di persone e la definizione delle priorità del lavoro. + +### Essere in grado di apportare cambiamenti, anche piccoli, dà potere + +Non è necessario essere un collaboratore permanente per apprezzare la partecipazione all'open source. Hai mai visto un errore di battitura su un sito web e vorresti che qualcuno lo correggesse? In un progetto open source, puoi fare proprio questo. L'open source aiuta le persone a sentirsi indipendenti riguardo alla propria vita e al modo in cui sperimentano il mondo, e questo di per sé è soddisfacente. + +## Cosa significa contribuire + +Se sei un nuovo collaboratore open source, il processo può creare confusione. Come trovi il progetto giusto? E se non sai programmare? E se qualcosa va storto? + +Non preoccuparti! Esistono molti modi per essere coinvolti in un progetto open source e alcuni suggerimenti ti aiuteranno a ottenere il massimo dalla tua esperienza. + +### Non è necessario aggiungere alcun codice + +Un malinteso comune riguardo al contributo all'open source è che si debba contribuire con il codice. In effetti, sono spesso le altre parti del progetto ad essere [più trascurate o trascurate](https://github.com/blog/2195-the-shape-of-open-source). Farai un _enorme_ favore al progetto offrendoti di contribuire con questo tipo di contributi! + + + +Anche se ti piace scrivere codice, altri tipi di contributi sono un ottimo modo per essere coinvolto in un progetto e incontrare altri membri della comunità. Costruire queste relazioni ti darà l'opportunità di lavorare su altre parti del progetto. + +### Ti piace pianificare eventi? + +* Organizzare workshop o incontri per il progetto, [come ha fatto @fzamperin per NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Organizzare una conferenza di progetto (se applicabile) +* Aiuta i membri della comunità a trovare le conferenze giuste e a inviare proposte di interventi + +### Ti piace progettare? + +* Ristrutturare i layout per migliorare l'usabilità del progetto +* Condurre ricerche sugli utenti per riorganizzare e perfezionare la navigazione o i menu del progetto, [come suggerito da Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Compila una guida di stile per aiutare il progetto ad avere un design visivo coerente +* Crea una grafica per la maglietta o un nuovo logo, [come hanno fatto i contributori di hapi.js](https://github.com/hapijs/contrib/issues/68) + +### Ti piace scrivere? + +* Scrivi e migliora la documentazione del progetto, [come ha fatto @CBID2 per la documentazione di OpenSauced](https://github.com/open-sauced/docs/pull/151) +* Preparare una cartella di esempi che mostrano come viene utilizzato il progetto +* Avvia una newsletter del progetto o cura i punti salienti della mailing list, [come ha fatto @opensauced per il suo prodotto](https://news.opensauced.pizza/about/) +* Scrivi tutorial per il progetto, [come hanno fatto i contributori PyPA](https://packaging.python.org/) +* Scrivi una traduzione per la documentazione del progetto, [come ha fatto @frontendwizard per le istruzioni CSS Flexbox della sfida freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) + + + +### Ti piace organizzare? + +* Collegamento a problemi duplicati e suggerimento di nuovi thread di problemi per mantenerti organizzato +* Esamina i problemi aperti e suggerisci di chiudere quelli vecchi, [come ha fatto @nzakas per ESLint](https://github.com/eslint/eslint/issues/6765) +* Fai domande chiarificatrici sui problemi appena scoperti per portare avanti la discussione + +### Ti piace programmare? + +* Trova un problema aperto da risolvere, [come ha fatto @dianjin per Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Chiedi se puoi aiutare a registrare una nuova funzionalità +* Automatizza le impostazioni del progetto +* Migliorare strumenti e test + +### Ti piace aiutare le persone? + +* Rispondi alle domande sul progetto, ad es. Stack Overflow ([come questo esempio di Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) o Reddit +* Rispondi alle domande delle persone in domande aperte +* Aiuta a moderare forum di discussione o canali di chat + +### Ti piace aiutare gli altri a programmare? + +* Rivedi il codice delle dichiarazioni di altre persone +* Scrivi tutorial su come utilizzare un progetto +* Offrirti di fare da mentore a un altro collaboratore, [come ha fatto @ereichert per @bronzdoc in Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Non devi lavorare solo su progetti software! + +Sebbene "open source" si riferisca spesso al software, puoi collaborare praticamente su qualsiasi cosa. Ci sono libri, ricette, elenchi e lezioni che vengono sviluppati come progetti open source. + +Per esempio: + +* @sindresorhus preparare [un elenco di elenchi "grandi".](https://github.com/sindresorhus/awesome) +* @h5bp mantenere un [elenco di potenziali domande per l'intervista](https://github.com/h5bp/Front-end-Developer-Interview-Questions) per i candidati sviluppatori front-end +* @stuartlynn e @nicole-a-tesla hanno realizzato una [raccolta di curiosità sui puffini](https://github.com/stuartlynn/puffin_facts) + +Anche se sei uno sviluppatore di software, lavorare su un progetto di documentazione può aiutarti a iniziare con l'open source. Spesso è meno intimidatorio lavorare su progetti che non implicano codice e il processo collaborativo aumenterà la tua sicurezza e la tua esperienza. + +## Orientamento verso un nuovo progetto + + + +Oltre a correggere un errore di battitura, contribuire all'open source è come avvicinarsi a un gruppo di sconosciuti a una festa. Se inizi a parlare dei lama mentre sono immersi in una discussione sui pesci rossi, probabilmente ti guarderanno in modo un po' strano. + +Prima di lanciarti alla cieca con i tuoi suggerimenti, inizia imparando a leggere la stanza. In questo modo aumenti le possibilità che le tue idee vengano notate e ascoltate. + +### Anatomia di un progetto open source + +Ogni comunità open source è diversa. + +Trascorrere anni su un progetto open source significa che hai acquisito familiarità con un progetto open source. Passa a un altro progetto e potresti scoprire che il vocabolario, le norme e gli stili di comunicazione sono completamente diversi. + +Tuttavia, molti progetti open source seguono una struttura organizzativa simile. Comprendere i diversi ruoli nella comunità e il processo complessivo ti aiuterà a navigare rapidamente in qualsiasi nuovo progetto. + +Un tipico progetto open source prevede i seguenti tipi di persone: + +* **Autore:** La/e persona/e o organizzazione che ha creato il progetto +* **Proprietario:** la/e persona/e che ha la proprietà amministrativa dell'organizzazione o del repository (non sempre coincide con l'autore originale) +* **Sostenitori:** Collaboratori responsabili della gestione della visione e della gestione degli aspetti organizzativi del progetto (possono anche essere autori o proprietari del progetto.) +* **Contributori:** chiunque abbia contribuito con qualcosa al progetto +* **Membri della comunità:** le persone che utilizzano il progetto. Possono essere attivi nelle conversazioni o esprimere la loro opinione sulla direzione del progetto + +I progetti più grandi possono anche avere sottocomitati o gruppi di lavoro focalizzati su compiti diversi, come strumenti, smistamento, moderazione della comunità e organizzazione di eventi. Cerca nel sito web di un progetto una pagina "team" o il repository della documentazione di gestione per trovare queste informazioni. + +C'è anche la documentazione del progetto. Questi file sono generalmente elencati al livello più alto del repository. + +* **LICENZA:** Per definizione, ogni progetto open source deve avere una [licenza open source](https://choosealicense.com). Se il progetto non ha una licenza, non è open source. +* **README:** Il README è la guida pratica che accoglie i nuovi membri della comunità nel progetto. Spiega perché il progetto è utile e come iniziare. +* **CONTRIBUTO:** Mentre i README aiutano le persone a _utilizzare_ il progetto, i documenti che contribuiscono aiutano le persone a _contribuire_ al progetto. Spiega quali tipi di contributi sono richiesti e come funziona il processo. Anche se non tutti i progetti hanno un file CONTRIBUTOR, la sua presenza segnala che è un progetto accogliente a cui contribuire. Un buon esempio di guida ai contributi efficace sarebbe questo dal [repository di documenti Codecademy](https://www.codecademy.com/resources/docs/contribution-guide). +* **CODE_OF_CONDUCT:** Il Codice di condotta stabilisce le regole di base per la condotta associata dei partecipanti e aiuta a creare un ambiente amichevole e accogliente. Anche se non tutti i progetti hanno un file CODE_OF_CONDUCT, la sua presenza segnala che si tratta di un progetto accogliente a cui contribuire. +* **Altra documentazione:** Potrebbe essere presente documentazione aggiuntiva come tutorial, istruzioni o politiche di gestione, in particolare per progetti più grandi come [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). + +Infine, i progetti open source utilizzano i seguenti strumenti per organizzare la discussione. Leggere gli archivi ti darà una buona idea di come pensa e funziona la comunità. + +* **Tracciamento dei problemi:** dove le persone discutono questioni relative al progetto. +* **Richieste pull:** quando le persone discutono e rivedono le modifiche in corso, sia che si tratti di migliorare l'ordine del codice dei contributori, l'utilizzo della grammatica, l'utilizzo delle immagini, ecc. Alcuni progetti, come [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), utilizzano determinati flussi di azioni GitHub per automatizzare e velocizzare le loro revisioni del codice. +* **Forum di discussione o mailing list:** Alcuni progetti possono utilizzare questi canali per argomenti di conversazione (ad esempio _"Come..."_ o _"Cosa ne pensi di..."_ invece di segnalazioni di bug o richieste per le funzioni). Altri utilizzano il tracker dei problemi per tutte le chiamate. Un buon esempio di ciò potrebbe essere la [newsletter settimanale CHAOSS](https://chaoss.community/news/) +* **Canale di chat sincrono:** alcuni progetti utilizzano canali di chat (come Slack o IRC) per conversazioni informali, collaborazione e scambi rapidi. Un buon esempio di ciò potrebbe essere [EddieHub Discord Community](http://discord.eddiehub.org/). + +## Trova un progetto a cui contribuire + +Ora che hai capito come funzionano i progetti open source, è il momento di trovare un progetto a cui contribuire! + +Se non hai mai contribuito all'open source prima, segui il consiglio del presidente degli Stati Uniti John F. Kennedy, che una volta disse: "Non chiederti cosa può fare il tuo paese per te, chiediti cosa puoi fare tu per il tuo paese". + + + +Il contributo all'open source avviene a tutti i livelli, in tutti i progetti. Non devi pensare troppo a quale sarà esattamente il tuo primo contributo o come sarà. + +Inizia invece pensando ai progetti che già usi o che desideri utilizzare. I progetti a cui partecipi attivamente sono quelli a cui continui a tornare. + +All'interno di questi progetti, ogni volta che ti sorprendi a pensare che qualcosa potrebbe essere migliore o diverso, agisci secondo il tuo istinto. + +L'open source non è un club esclusivo; è fatto da persone proprio come te. "Open source" è solo un termine elegante per considerare i problemi del mondo come risolvibili. + +È possibile eseguire la scansione del README e trovare un collegamento interrotto o un errore di battitura. O sei un nuovo utente e hai notato che qualcosa non funziona, oppure c'è un problema che ritieni dovrebbe essere presente nella documentazione. Invece di ignorarlo e andare avanti o chiedere a qualcun altro di risolverlo, vedi se puoi aiutare partecipando. Ecco cos'è l'open source! + +> Secondo uno studio di Igor Steinmacher e altri ricercatori di informatica, [il 28% dei contributi accessori](https://www.igor.pro.br/publica/papers/saner2016.pdf) in open source sono documenti, come come correzioni di errori di battitura, riformattazione o scrittura di traduzioni. + +Se stai cercando problemi esistenti che puoi risolvere, ogni progetto open source ha una pagina "/contribute" che evidenzia problemi adatti ai principianti con cui puoi iniziare. Vai alla pagina principale del repository GitHub e aggiungi "/contribute" alla fine dell'URL (ad es.[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +Puoi anche utilizzare una delle seguenti risorse per aiutarti a scoprire e contribuire a nuovi progetti: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### Lista di controllo prima di contribuire + +Quando trovi un progetto a cui vuoi contribuire, esegui una rapida scansione per assicurarti che il progetto sia idoneo ad accettare contributi. Altrimenti, il tuo duro lavoro potrebbe non ricevere mai risposta. + +Ecco una pratica lista di controllo per valutare se un progetto è adatto ai nuovi contributori. + +**Soddisfa la definizione di open source** + +
+ + +
+ +**Il progetto accetta attivamente contributi** + +Guarda l'attività di commit sul ramo master. Su GitHub, puoi vedere queste informazioni nella scheda Approfondimenti della home page di un repository, ad esempio[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Poi guarda i problemi del progetto. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Ora fai lo stesso per le richieste pull del progetto. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Il progetto è accogliente** + +Un progetto amichevole e accogliente segnala che saranno ricettivi verso nuovi collaboratori. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## Come inviare un contributo + +Hai trovato un progetto che ti piace e sei pronto a contribuire. Finalmente! Ecco come ottenere il tuo contributo nel modo giusto. + +### Comunicazione effettiva + +Che tu collabori occasionalmente o cerchi di entrare a far parte di una comunità, lavorare con gli altri è una delle competenze più importanti che svilupperai nell'open source. + + + +Prima di aprire un problema o una richiesta pull o porre una domanda in chat, tieni a mente questi punti per aiutare le tue idee a prendere vita in modo efficace. + +**Fornisci contesto.** Aiuta gli altri a salire a bordo rapidamente. Se riscontri un errore, spiega cosa stai cercando di fare e come riprodurlo. Se stai proponendo una nuova idea, spiega perché pensi che sarebbe utile per il progetto (non solo per te!). + +> 😇 _"X non accade quando faccio Y"_ +> +> 😢 _"X è rotto! Per favore aggiustalo."_ + +**Fai i compiti in anticipo.** Va bene non sapere le cose, ma dimostra che ci hai provato. Prima di chiedere aiuto, assicurati di controllare il README del progetto, la documentazione, i problemi (aperti o chiusi), la mailing list e cerca una risposta in Internet. Le persone apprezzeranno quando dimostrerai che stai cercando di imparare. + +> 😇 _"Non sono sicuro di come implementare X. Ho controllato i documenti di aiuto e non ho trovato alcuna menzione."_ +> +> 😢 _"Come faccio X?"_ + +**Mantieni le richieste brevi e dirette.** Come inviare un'email, qualsiasi contributo, non importa quanto semplice o utile, richiede che qualcun altro lo esamini. Molti progetti hanno più richieste in arrivo che persone che possono aiutare. Sii breve. Aumenterai le possibilità che qualcuno possa aiutarti. + +> 😇 _"Vorrei scrivere un tutorial API."_ +> +> 😢 _"L'altro giorno stavo guidando lungo l'autostrada e mi sono fermato per fare benzina e poi ho avuto questa fantastica idea di qualcosa che dovremmo fare, ma prima di spiegartelo, lascia che te lo mostri..."_ + +**Mantieni pubbliche tutte le comunicazioni.** Sebbene sia allettante, non contattare personalmente i manutentori a meno che non sia necessario condividere informazioni sensibili (come un problema di sicurezza o una cattiva condotta grave). Quando mantieni pubblica la conversazione, più persone possono imparare e trarre vantaggio dal tuo scambio. Le discussioni possono essere di per sé un contributo. + +> 😇 _(come commento) "@-maintainer Ciao! Come procediamo con questo PR?"_ +> +> 😢 _(come email) "Ciao, scusa se ti disturbo via email, ma mi chiedevo se avessi la possibilità di rivedere il mio PR"_ + +**Va bene fare domande (ma sii paziente!).** Tutti sono stati nuovi ad un progetto ad un certo punto, e anche i contributori più esperti devono aggiornarsi quando guardano un nuovo progetto. Allo stesso modo, anche i manutentori di lunga data non hanno sempre familiarità con ogni parte del progetto. Mostra loro la stessa pazienza che vorresti che mostrassero a te. + +> 😇 _"Grazie per aver esaminato questo errore. Ho seguito i tuoi suggerimenti. Ecco il risultato."_ +> +> 😢 _"Perché non riesci a risolvere il mio problema? Non è questo il tuo progetto?"_ + +**Rispetta le decisioni della comunità.** Le tue idee potrebbero differire dalle priorità o dalla visione della comunità. Potrebbero offrire feedback o decidere di non perseguire la tua idea. Anche se dovresti discutere e trovare un compromesso, i manutentori devono convivere con la tua decisione più a lungo di te. Se non sei d'accordo con la loro direzione, puoi sempre lavorare sul tuo fork o iniziare il tuo progetto. + +> 😇 _"Mi dispiace che tu non possa supportare il mio caso d'uso, ma come hai spiegato tu riguarda solo una piccola parte di utenti, capisco il motivo. Grazie per l'ascolto."_ +> +> 😢 _"Perché non supporti il ​​mio caso d'uso? Questo è inaccettabile!"_ + +**Soprattutto, mantienilo elegante.** L'open source è composto da contributori provenienti da tutto il mondo. Si perde il contesto tra lingue, culture, aree geografiche e fusi orari. Inoltre, la comunicazione scritta rende più difficile trasmettere il tono o l'umore. Assumi buone intenzioni in queste conversazioni. Va bene rifiutare educatamente un'idea, chiedere più contesto o chiarire ulteriormente la tua posizione. Prova solo a lasciare Internet in un posto migliore di quando l'hai trovato. + +### Raccogli il contesto + +Prima di agire, fai un rapido controllo per assicurarti che la tua idea non sia stata discussa altrove. Visualizza il README del progetto, i problemi (aperti e chiusi), la mailing list e Stack Overflow. Non devi passare ore a esaminare tutto, ma una rapida ricerca di alcuni termini chiave può fare molto. + +Se non riesci a trovare la tua idea altrove, sei pronto a fare una mossa. Se il progetto è su GitHub, probabilmente comunicherai nel modo seguente: + +* **Sollevare un problema:** è come avviare una conversazione o una discussione +* **Le richieste pull** servono per iniziare a lavorare su una soluzione. +* **Canali di comunicazione:** se il progetto ha un canale Discord, IRC o Slack designato, valuta la possibilità di avviare una conversazione o chiedere chiarimenti sul tuo contributo. + +Prima di aprire un problema o una richiesta pull, controlla i documenti che contribuiscono al progetto (di solito un file chiamato CONTRIBUTING o nel README) per vedere se è necessario includere qualcosa di specifico. Ad esempio, potrebbero chiederti di seguire uno schema o richiederti di utilizzare dei test. + +Se vuoi dare un contributo significativo, apri un issue da chiedere prima di lavorarci. È utile guardare il progetto per un po' (su GitHub, [puoi fare clic su "Guarda"](https://help.github.com/articles/watching-repositories/) per ricevere una notifica di tutte le conversazioni) e accedere a conoscere i membri della comunità prima di svolgere lavori che potrebbero non essere accettati. + + + +### Apertura di un problema + +Di solito dovresti aprire un problema nelle seguenti situazioni: + +* Segnala un bug che non puoi risolvere da solo +* Discutere un argomento o un'idea di alto livello (ad esempio comunità, visione o politiche) +* Suggerisci una nuova funzionalità o un'altra idea di progetto + +Suggerimenti per comunicare sui problemi: + +* **Se vedi un problema aperto su cui vuoi lavorare**, commenta il problema per far sapere alle persone che ci stai lavorando. In questo modo, le persone avranno meno probabilità di duplicare il tuo lavoro. +* **Se un problema è stato scoperto qualche tempo fa,** potrebbe essere stato risolto altrove o già risolto, quindi commenta per chiedere conferma prima di iniziare il lavoro. +* **Se hai aperto un problema ma hai trovato la risposta da solo in seguito,** commenta il problema per farlo sapere alle persone, quindi chiudi il problema. Anche documentare questo risultato è un contributo al progetto. + +### Apertura di una richiesta pull + +Di solito dovresti aprire una richiesta pull nelle seguenti situazioni: + +* Invia correzioni minori come errori di battitura, collegamenti interrotti o errori evidenti. +* Inizia a lavorare su un contributo che ti è già stato richiesto o di cui hai già parlato in un numero. + +Una richiesta pull non deve rappresentare un lavoro completato. Di solito è meglio aprire una richiesta pull in anticipo in modo che altri possano guardare o fornire feedback sui tuoi progressi. Basta aprirlo come "bozza" o contrassegnarlo come "WIP" (Lavori in corso) nella riga dell'oggetto o nelle sezioni "Note ai revisori" se fornite (oppure puoi semplicemente crearne una tua. In questo modo: `** # # Note per il revisore**`). Puoi sempre aggiungere altri impegni in un secondo momento. + +Se il progetto è su GitHub, ecco come inviare una richiesta pull: + +* **[Fork il repository](https://guides.github.com/activities/forking/)** e clonalo localmente. Connetti il ​​tuo locale al repository upstream originale aggiungendolo come remoto. Estrai spesso le modifiche da "upstream" per rimanere aggiornato, quindi quando invii la tua richiesta di pull, i conflitti di unione saranno meno probabili. (Vedi istruzioni più dettagliate [qui](https://help.github.com/articles/syncing-a-fork/).) +* **[Crea un ramo](https://guides.github.com/introduction/flow/)** per le tue modifiche. +* **Elenca eventuali problemi rilevanti** o documentazione di supporto nel tuo PR (ad esempio "Chiude n. 37.") +* **Includi screenshot prima e dopo** se le modifiche comportano differenze HTML/CSS. Trascina e rilascia le immagini nel corpo della tua richiesta pull. +* **Testa le tue modifiche!** Esegui le tue modifiche confrontandole con eventuali test esistenti, se presenti, e creane di nuovi quando necessario. È importante assicurarsi che le modifiche non interrompano il progetto esistente. +* **Contribuisci allo stile del progetto** secondo le tue capacità. Ciò può significare utilizzare il rientro, il punto e virgola o i commenti in modo diverso rispetto a quanto faresti nel tuo repository, ma rende più facile per il manutentore unirli e per gli altri comprenderli e mantenerli in futuro. + +Se questa è la tua prima richiesta pull, dai un'occhiata a [Crea una richiesta pull](http://makeapullrequest.com/) che @kentcdodds ha creato come tutorial video dimostrativo. Puoi anche esercitarti a creare una richiesta pull sul repository [First Contributions](https://github.com/Roshanjossey/first-contributions) creato da @Roshanjossey. + +## Cosa succede dopo aver inviato il tuo contributo + +Prima di iniziare a festeggiare, dopo che avrai inviato il tuo contributo si verificherà una delle seguenti situazioni: + +### 😭 Non riceverai risposta + +Ci auguriamo che tu abbia [controllato eventuali segni di attività nel progetto](#lista-di-controllo-prima-di-contribuire) prima di contribuire. Anche con un progetto attivo, però, è possibile che il tuo contributo non riceva risposta. + +Se non ricevi notizie da più di una settimana, è giusto rispondere educatamente nello stesso thread chiedendo a qualcuno di recensire. Se conosci il nome della persona giusta per rivedere il tuo contributo, puoi @ menzionarla in questo thread. + +**Non contattare personalmente questa persona**; ricorda che la comunicazione pubblica è vitale per i progetti open source. + +Se fai un cortese promemoria e continui a non ricevere risposta, è possibile che nessuno risponderà mai. Non è una sensazione fantastica, ma non lasciarti scoraggiare! 😄 Esistono molte possibili ragioni per cui non hai ricevuto una risposta, comprese circostanze personali che potrebbero andare oltre il tuo controllo. Prova a trovare un altro progetto o un modo per contribuire. Se non altro, è un buon motivo per non investire troppo tempo nel contribuire prima che gli altri membri della comunità siano coinvolti e reattivi. + +### 🚧 Qualcuno vuole modifiche al tuo contributo + +È comune che ti venga chiesto di apportare modifiche al tuo contributo, che si tratti di feedback sulla portata della tua idea o di modifiche al tuo codice. + +Quando qualcuno chiede modifiche, sii reattivo. Si sono presi il tempo per rivedere il tuo contributo. Aprire un PR e andarsene è una cattiva forma. Se non sai come apportare modifiche, ricerca il problema e poi chiedi aiuto se ne hai bisogno. Un buon esempio di ciò potrebbe essere [il feedback che un altro collaboratore ha dato a @a-m-lamb sulla sua richiesta di pull ai documenti Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). + +Se non hai più tempo per lavorare sul problema perché la conversazione va avanti da mesi e le tue circostanze sono cambiate o non riesci a trovare una soluzione, informa un manutentore in modo che possa aprire il problema a qualcun altro , come ha fatto [@RitaDee per un problema nelle applicazioni OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). + +### 👎 Il tuo contributo non è accettato + +Il tuo contributo potrebbe essere accettato o meno alla fine. Spero che tu non ci abbia già dedicato troppo lavoro. Se non sei sicuro del motivo per cui non è stato accettato, è perfettamente ragionevole chiedere al manutentore feedback e chiarimenti. Alla fine, però, dovrai rispettare il fatto che è una loro decisione. Non discutere e non essere ostile. Sei sempre il benvenuto ad espanderti e lavorare sulla tua versione se non sei d'accordo! + +### 🎉 Il tuo contributo è accettato + +Evviva! Hai dato con successo un contributo open source! + +## Fallo! 🎉 + +Se hai appena dato il tuo primo contributo open source o stai cercando nuovi modi per contribuire, speriamo che tu sia ispirato ad agire. Anche se il tuo contributo non è stato accettato, assicurati di dire grazie quando il manutentore ha fatto uno sforzo per aiutarti. L'open source è creato da persone come te: un problema, una richiesta pull, un commento o il cinque alla volta. diff --git a/_articles/it/index.html b/_articles/it/index.html new file mode 100644 index 00000000000..4944583ea67 --- /dev/null +++ b/_articles/it/index.html @@ -0,0 +1,7 @@ +--- +layout: index +title: Guide Open Source +lang: it +permalink: /it/ +--- + diff --git a/_articles/it/leadership-and-governance.md b/_articles/it/leadership-and-governance.md new file mode 100644 index 00000000000..42f5eb40749 --- /dev/null +++ b/_articles/it/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: it +title: Leadership e governo +description: I progetti open source in crescita possono trarre vantaggio da regole formali per prendere decisioni. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Comprendere la gestione del tuo progetto in crescita + +Il tuo progetto sta crescendo, le persone sono coinvolte e tu ti impegni a mantenere questa cosa. A questo punto, ti starai chiedendo come includere contributori regolari al progetto nel tuo flusso di lavoro, sia che si tratti di fornire accesso al commit o di risolvere i dibattiti della comunità. Se hai domande, abbiamo le risposte. + +## Quali sono esempi di ruoli formali utilizzati nei progetti open source? + +Molti progetti seguono una struttura simile per quanto riguarda i ruoli dei contributori e il riconoscimento. + +Il significato effettivo di questi ruoli, tuttavia, dipende interamente da te. Ecco alcuni tipi di ruoli che potresti riconoscere: + +* **Supporto** +* **Associato** +* **Committente** + +**Per alcuni progetti, i "sostenitori"** sono le uniche persone in un progetto con accesso come commit. In altri progetti, sono semplicemente le persone elencate nel README come manutentori. + +Un manutentore non deve essere qualcuno che scrive il codice per il tuo progetto. Potrebbe essere qualcuno che ha svolto molto lavoro per evangelizzare il tuo progetto o documentazione scritta che ha reso il progetto più accessibile agli altri. Indipendentemente da ciò che fa quotidianamente, un manutentore è probabilmente qualcuno che si sente responsabile della direzione del progetto e si impegna a migliorarlo. + +Un **"Collaboratore" può essere chiunque** commenti un problema o una richiesta pull, persone che aggiungono valore al progetto (che si tratti di valutare problemi, scrivere codice o organizzare eventi) o chiunque abbia una richiesta pull combinata (magari la definizione più ristretta di contributore). + + + +**Il termine "agente"** può essere utilizzato per distinguere l'accesso all'impegno, che è un tipo specifico di responsabilità, da altre forme di contributo. + +Sebbene tu possa definire i ruoli del tuo progetto come desideri, [considera l'utilizzo di definizioni più ampie](../how-to-contribute/#cosa-significa-contribuire) per incoraggiare più forme di contributo. Puoi utilizzare i ruoli di leadership per riconoscere formalmente le persone che hanno apportato contributi eccezionali al tuo progetto, indipendentemente dalle loro competenze tecniche. + + + +## Come formalizzo questi ruoli di leadership? + +Formalizzare i ruoli di leadership aiuta le persone a sentirsi proprietarie e dice agli altri membri della comunità a chi rivolgersi per chiedere aiuto. + +Per un progetto più piccolo, designare i leader può essere semplice come aggiungere i loro nomi al file di testo README o CONTRIBUTORS. + +Per un progetto più ampio, se hai un sito web, crea una pagina del team o elenca lì i tuoi project manager. Ad esempio, [Postgres](https://github.com/postgres/postgres/) ha una [pagina completa del team](https://www.postgresql.org/community/contributors/) con brevi profili di ciascun contributore. + +Se il tuo progetto ha una comunità di contributori molto attiva, puoi formare un "core team" di manutentori o anche sottocomitati di persone che si assumono la responsabilità di diverse aree problematiche (ad esempio sicurezza, classificazione dei problemi o comportamento della comunità). Consentire alle persone di auto-organizzarsi e fare volontariato per i ruoli che li appassionano di più, piuttosto che esternalizzarli. + + + +I team dirigenti potrebbero voler creare un canale designato (come su IRC) o incontrarsi regolarmente per discutere del progetto (come su Gitter o Google Hangout). Puoi anche rendere pubbliche queste riunioni in modo che altre persone possano ascoltarle. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), ad esempio, [prende ore di lavoro ogni settimana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +Una volta stabiliti i ruoli di leadership, assicurati di documentare come le persone possono raggiungerli! Stabilisci un processo chiaro su come qualcuno può diventare un sostenitore o unirsi a un sottocomitato nel tuo progetto e scrivilo nel tuo GOVERNANCE.md. + +Strumenti come [Vossibility](https://github.com/icecrime/vossibility-stack) possono aiutarti a tenere traccia pubblicamente chi sta (o non sta) contribuendo al progetto. Documentare queste informazioni evita la percezione della comunità secondo cui i manutentori sono una cricca che prende le proprie decisioni in privato. + +Infine, se il tuo progetto è su GitHub, valuta la possibilità di spostare il progetto dal tuo account personale a un'organizzazione e di aggiungere almeno un amministratore di backup. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) semplifica la gestione delle autorizzazioni e di più repository e protegge l'eredità del tuo progetto tramite [proprietà condivisa](../building-community/#condividi-la-proprietà-del-tuo-progetto). + +## Quando dovrei dare a qualcuno l'accesso per impegnarsi? + +Alcune persone pensano che dovresti dare accesso al coinvolgimento a tutti coloro che danno un contributo. Ciò può incoraggiare più persone a sentirsi proprietarie del tuo progetto. + +D'altra parte, soprattutto per progetti più grandi e complessi, potresti voler concedere l'accesso al coinvolgimento solo alle persone che hanno dimostrato il proprio impegno. Non esiste un modo giusto per farlo: fai ciò che ti fa sentire più a tuo agio! + +Se il tuo progetto è su GitHub, puoi utilizzare [rami protetti](https://help.github.com/articles/about-protected-branches/) per gestire chi può puntare a un particolare ramo e in quali circostanze. + + + +## Quali sono alcune delle strutture di governance comuni per i progetti open source? + +Esistono tre strutture di governance generale associate ai progetti open source. + +* **BDFL:** BDFL sta per "Dittatore benevolo per la vita". In questa struttura, una persona (di solito l'autore originale del progetto) ha l'ultima parola su tutte le principali decisioni del progetto. [Python](https://github.com/python) è un classico esempio. I progetti più piccoli probabilmente utilizzano BDFL per impostazione predefinita perché ci sono solo uno o due manutentori. Anche un progetto che nasce da un'azienda può rientrare nella categoria BDFL. + +* **Meritocrazia:** (Nota: il termine "meritocrazia" ha connotazioni negative per alcune comunità e ha una [storia sociale e politica complessa](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** Nella meritocrazia ai partecipanti attivi al progetto (coloro che dimostrano "merito") viene assegnato un ruolo decisionale formale. Le decisioni vengono solitamente prese sulla base del voto per puro consenso. Il concetto di meritocrazia è stato introdotto dalla [Fondazione Apache](https://www.apache.org/); [tutti i progetti Apache](https://www.apache.org/index.html#projects-list) sono meritocrazie. I contributi possono essere versati solo da individui che rappresentano se stessi e non da un'azienda. + +* **Contributo liberale:** In un modello di contribuzione liberale, le persone che lavorano di più sono riconosciute come le più influenti, ma questo si basa sul lavoro attuale, non sul contributo storico. Le decisioni sui grandi progetti vengono prese sulla base di un processo di ricerca del consenso (discussione delle principali lamentele) piuttosto che sul puro voto, e cercano di includere quante più prospettive comunitarie possibile. Esempi popolari di progetti che utilizzano un modello di contribuzione liberale includono [Node.js](https://foundation.nodejs.org/) e [Rust](https://www.rust-lang.org/). + +Quale dovresti usare? Sta a te! Ogni modello presenta vantaggi e compromessi. E anche se a prima vista possono sembrare molto diversi, tutti e tre i modelli hanno più cose in comune di quanto sembri. Se sei interessato ad adottare uno di questi modelli, dai un'occhiata a questi modelli: + +* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## Ho bisogno di documenti gestionali quando inizio il mio progetto? + +Non esiste un momento giusto per scrivere la gestione del tuo progetto, ma è molto più semplice definirlo una volta che hai visto svolgersi le dinamiche della tua comunità. La parte migliore (e più difficile) della gestione open source è che è modellata dalla comunità! + +Tuttavia, alcuni dei primi documenti contribuiranno inevitabilmente alla gestione del progetto, quindi inizia a registrare ciò che puoi. Ad esempio, puoi definire aspettative chiare sul comportamento o sul funzionamento del processo di collaborazione, anche all'inizio del tuo progetto. + +Se fai parte di un'azienda che lancia un progetto open source, vale la pena tenere una discussione interna prima del lancio su come la tua azienda prevede di supportare e prendere decisioni sui progressi del progetto. Potresti anche voler spiegare pubblicamente qualcosa di specifico su come la tua azienda sarà (o non sarà!) coinvolta nel progetto. + + + +## Cosa succede se i dipendenti aziendali iniziano a inviare contributi? + +I progetti open source di successo vengono utilizzati da molte persone e aziende e alcune aziende potrebbero finire per avere flussi di entrate che sono in definitiva legati al progetto. Ad esempio, un'azienda può utilizzare il codice di progetto come componente nell'offerta di un servizio commerciale. + +Man mano che il progetto diventa più diffuso, le persone con esperienza in esso diventano più richieste: potresti essere uno di loro! - e talvolta verranno pagati per il lavoro svolto sul progetto. + +È importante considerare l'attività commerciale come una cosa normale e semplicemente come un'altra fonte di energia per lo sviluppo. Naturalmente, gli sviluppatori pagati non dovrebbero ricevere un trattamento speciale rispetto a quelli non pagati; ogni contributo dovrebbe essere giudicato in base ai suoi meriti tecnici. Tuttavia, le persone dovrebbero sentirsi a proprio agio nell'impegnarsi in attività commerciali e sentirsi a proprio agio nel citare i propri casi d'uso quando si discute a favore di un particolare miglioramento o funzionalità. + +"Commerciale" è pienamente compatibile con "open source". "Commerciale" significa semplicemente che da qualche parte sono coinvolti dei soldi, che il software viene utilizzato commercialmente, il che è sempre più probabile man mano che un progetto ottiene l'accettazione. (Quando il software open source viene utilizzato come parte di un prodotto non open source, il prodotto complessivo è ancora software "proprietario", sebbene, come l'open source, possa essere utilizzato per scopi commerciali e non commerciali.) + +Come chiunque altro, gli sviluppatori motivati ​​dal punto di vista commerciale ottengono influenza nel progetto attraverso la qualità e la quantità del loro contributo. Ovviamente, un programmatore che viene pagato per il suo tempo può essere in grado di guadagnare più di qualcuno che non lo fa, ma va bene così: il pagamento è solo uno dei tanti possibili fattori che possono influenzare quanto qualcuno guadagna. Mantieni le discussioni del tuo progetto focalizzate sul contributo, non sui fattori esterni che consentono alle persone di dare quel contributo. + +## Ho bisogno di una persona giuridica per sostenere il mio progetto? + +Non hai bisogno di un'entità legale per supportare il tuo progetto open source a meno che non gestisci denaro. + +Ad esempio, se desideri avviare un'attività commerciale, ti consigliamo di costituire una C Corp o LLC (se risiedi negli Stati Uniti). Se stai solo lavorando a un contratto relativo al tuo progetto open source, puoi accettare denaro come unico proprietario o formare una LLC (se risiedi negli Stati Uniti). + +Se desideri accettare donazioni per il tuo progetto open source, puoi impostare un pulsante di donazione (utilizzando PayPal o Stripe, ad esempio), ma il denaro non sarà deducibile dalle tasse a meno che tu non sia un'organizzazione no-profit qualificata (501c3, se sei sono negli Stati Uniti). + +Molti progetti non vogliono prendersi la briga di creare un'organizzazione no-profit, quindi trovano invece uno sponsor fiscale senza scopo di lucro. Uno sponsor fiscale accetta donazioni per tuo conto, solitamente in cambio di una percentuale della donazione. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) e [Open Collective](https://opencollective.com/opensource) sono esempi di organizzazioni che fungono da sponsor fiscali per progetti open source. + + + +Se il tuo progetto è strettamente correlato a un particolare linguaggio o ecosistema, potrebbe esserci anche una base software associata con cui puoi lavorare. Ad esempio, la [Python Software Foundation](https://www.python.org/psf/) aiuta a supportare [PyPI](https://pypi.org/), il gestore pacchetti Python e [Node.js Foundation] (https://foundation.nodejs.org/) aiuta a mantenere [Express.js](https://expressjs.com/), un framework basato su Node. diff --git a/_articles/it/legal.md b/_articles/it/legal.md new file mode 100644 index 00000000000..92db8748b90 --- /dev/null +++ b/_articles/it/legal.md @@ -0,0 +1,160 @@ +--- +lang: it +title: Il lato legale dell'open source +description: Tutto quello che ti sei sempre chiesto riguardo al lato legale dell'open source e alcune cose che non ti sei chiesto. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## Comprendere le implicazioni legali dell'open source + +Condividere il tuo lavoro creativo con il mondo può essere un'esperienza emozionante e gratificante. Può anche significare un sacco di cose legali di cui non sapevi di doverti preoccupare. Fortunatamente, con questa guida non è necessario ricominciare da zero. (Prima di approfondire, assicurati di leggere il nostro [disclaimer](/notices/).) + +## Perché le persone si preoccupano così tanto del lato legale dell'open source? + +Sono felice che tu l'abbia chiesto! Quando realizzi un'opera creativa (come scrittura, grafica o codice), quell'opera è protetta da copyright esclusivo per impostazione predefinita. Cioè, la legge presuppone che, come autore del tuo lavoro, tu abbia voce in capitolo su ciò che gli altri possono fare con esso. + +In genere, ciò significa che nessun altro può utilizzare, copiare, distribuire o modificare il tuo lavoro senza correre il rischio di rimozione, squalifica o contenzioso. + +Tuttavia, l'open source è una circostanza insolita perché l'autore si aspetta che altri utilizzino, modifichino e condividano il lavoro. Ma poiché il valore legale predefinito è ancora il diritto d'autore esclusivo, è necessario concedere esplicitamente queste autorizzazioni con una licenza. + +Queste regole si applicano anche quando qualcuno contribuisce al tuo progetto. Senza licenza o altro accordo, tutti i contributi sono di proprietà esclusiva dei loro autori. Ciò significa che nessuno – nemmeno tu – può utilizzare, copiare, distribuire o modificare il proprio contributo. + +Infine, il tuo progetto potrebbe avere dipendenze con requisiti di licenza di cui non eri a conoscenza. La comunità del tuo progetto o le politiche del tuo datore di lavoro potrebbero anche richiedere che il tuo progetto utilizzi licenze open source specifiche. Esamineremo queste situazioni di seguito. + +## Публичните GitHub проекти с отворен код ли са? + +Quando [crei nuovo progetto](https://help.github.com/articles/creating-a-new-repository/) su GitHub, hai la possibilità di rendere il repository **privato** o **pubblico**. + +![Crea un archivio](/assets/images/legal/repo-create-name.png) + +**Rendere pubblico il tuo progetto GitHub non equivale a concedergli una licenza.** I progetti pubblici sono coperti dai [Termini di servizio di GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), che consente ad altri di rivedere e creare un fork del tuo progetto, ma per il resto il tuo lavoro arriva senza autorizzazioni. + +Se desideri che altri utilizzino, distribuiscano, modifichino o contribuiscano al tuo progetto, devi includere una licenza open source. Ad esempio, qualcuno non può utilizzare legalmente alcuna parte del tuo progetto GitHub nel proprio codice, anche se è pubblico, a meno che tu non gli conceda specificatamente il diritto di farlo. + +## Dammi solo un riepilogo di ciò di cui ho bisogno per proteggere il mio progetto. + +Sei fortunato perché oggi le licenze open source sono standardizzate e facili da usare. Puoi copiare e incollare una licenza esistente direttamente nel tuo progetto. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) e [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sono [licenze open source popolari](https://innovationgraph.github.com/global-metrics/licenses), ma ci sono altre opzioni tra cui scegliere. È possibile trovare il testo completo di queste licenze e le istruzioni su come utilizzarle all'indirizzo [choosealicense.com](https://choosealicense.com/). + +Quando crei un nuovo progetto su GitHub, ti verrà [chiesto di aggiungere una licenza](https://help.github.com/articles/open-source-licensing/). + + + +## Quale licenza open source è adatta al mio progetto? + +È difficile sbagliare con la [licenza MIT](https://choosealicense.com/licenses/mit/) se inizi con un foglio bianco. È breve, facile da capire e consente a chiunque di fare qualsiasi cosa purché conservi una copia della licenza, inclusa la nota sul copyright. Potrai rilasciare il progetto con una licenza diversa, se mai ne avessi bisogno. + +Altrimenti, la scelta della giusta licenza open source per il tuo progetto dipende dai tuoi obiettivi. + +Molto probabilmente il tuo progetto ha (o avrà) **dipendenze**, ognuna delle quali avrà la propria licenza open source con termini che dovrai rispettare. Ad esempio, se stai rendendo open source un progetto Node.js, probabilmente utilizzerai le librerie di Node Package Manager (npm). + +Dipendenze con **licenze permissive** come [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc) e [BSD](https://choosealicense.com/licenses/bsd-3-clause) ti consentono di concedere in licenza il tuo progetto come preferisci. + +Le dipendenze con **licenze di copyright** richiedono maggiore attenzione. Inclusa qualsiasi libreria con una licenza copyleft "forte" come [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), o [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) richiede la scelta di una licenza identica o [compatibile](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) per il tuo progetto. Librerie con una licenza copyleft "limitata" o "debole" come [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) e [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) può essere incluso in progetti con qualsiasi licenza, a condizione che si seguano le [regole aggiuntive](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) sottolineano. + +Puoi anche controllare le **community** che speri di utilizzare e contribuire al tuo progetto: + +* **Vuoi che il tuo progetto venga utilizzato come dipendenza da altri progetti?** Probabilmente è meglio utilizzare la licenza più popolare nella comunità pertinente. Ad esempio, [MIT](https://choosealicense.com/licenses/mit/) è la licenza più popolare per [librerie npm](https://libraries.io/search?platforms=NPM). +* **Vuoi che il tuo progetto attiri le grandi imprese?** Le grandi imprese possono essere confortate da una licenza di brevetto espressa da parte di tutti i contributori. In tal caso, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) copre te (e loro). +* **Vuoi che il tuo progetto attiri i contributori che non vogliono che i loro contributi vengano utilizzati in software closed source?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) o (se non vogliono contribuire ai servizi closed source) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) andrà benissimo. + +La tua **azienda** potrebbe avere politiche di licenza per progetti open source. Alcune aziende richiedono che i tuoi progetti abbiano una licenza permissiva per consentire l'integrazione con i prodotti proprietari dell'azienda. Altre politiche impongono una forte licenza copyleft e un accordo di collaborazione aggiuntivo (vedi sotto), in modo che solo la tua azienda possa utilizzare il progetto nel software closed source. Le organizzazioni possono anche avere determinati standard, obiettivi di responsabilità sociale o esigenze di trasparenza che potrebbero richiedere una strategia di licenza specifica. Rivolgiti a [l'ufficio legale della tua azienda](#il-mio-progetto-necessita-di-un-contratto-di-collaborazione-aggiuntivo) per ricevere assistenza. + +Quando crei un nuovo progetto su GitHub, ti viene data la possibilità di scegliere una licenza. Includere una delle licenze sopra menzionate renderà il tuo progetto GitHub open source. Se vuoi vedere altre opzioni, controlla [choosealicense.com](https://choosealicense.com) per trovare la licenza giusta per il tuo progetto, anche se è [non software](https://choosealicense.com/non-software/). + +## Cosa succede se voglio cambiare la licenza del mio progetto? + +Nella maggior parte dei progetti non è mai necessario modificare le licenze. Ma a volte le circostanze cambiano. + +Ad esempio, man mano che il tuo progetto cresce, aggiunge dipendenze o utenti oppure la tua azienda cambia strategie, ognuna delle quali potrebbe richiedere o richiedere una licenza diversa. Inoltre, se hai dimenticato di concedere la licenza al tuo progetto fin dall'inizio, aggiungere una licenza equivale praticamente a modificare le licenze. Ci sono tre cose principali da tenere a mente quando aggiungi o modifichi la licenza del tuo progetto: + +**È complicato.** Determinare la compatibilità e la conformità della licenza e chi possiede il copyright può diventare complicato e creare confusione molto rapidamente. Passare a una licenza nuova ma compatibile per nuove versioni e contributi è diverso dal concedere nuovamente in licenza tutti i contributi esistenti. Coinvolgi il tuo team legale al primo accenno di desiderio di modificare le licenze. Anche se hai o puoi ottenere il permesso dai detentori del copyright del tuo progetto per modificare la licenza, considera l'impatto della modifica sugli altri utenti e contributori al tuo progetto. Pensa a una modifica della licenza come a un "evento di gestione" per il tuo progetto, che è più probabile che si svolga senza intoppi con una comunicazione chiara e una consultazione con le parti interessate del progetto. Un motivo in più per scegliere e utilizzare una licenza adeguata per il tuo progetto fin dal suo inizio! + +**Licenza esistente del tuo progetto.** Se la licenza esistente del tuo progetto è compatibile con la licenza che desideri modificare, puoi semplicemente iniziare a utilizzare la nuova licenza. Questo perché se la licenza A è compatibile con la licenza B, rispetterai i termini di A rispettando allo stesso tempo i termini di B (ma non necessariamente il contrario). Pertanto, se stai attualmente utilizzando una licenza permissiva (ad esempio MIT), puoi passare a una licenza con più termini purché conservi una copia della licenza MIT e di eventuali avvisi di copyright associati (ovvero continui a rispettare i termini minimi della licenza MIT). Ma se la tua licenza attuale non è permissiva (ad esempio copyleft o non hai una licenza) e non sei l'unico detentore del copyright, non puoi semplicemente cambiare la licenza del tuo progetto MIT. In sostanza, con una licenza permissiva, i detentori dei diritti d'autore del progetto hanno dato il permesso preventivo di modificare le licenze. + +**Detentori del copyright esistenti del tuo progetto.** Se sei l'unico collaboratore del tuo progetto, tu o la tua azienda siete gli unici detentori del copyright del progetto. Puoi aggiungere o modificare qualsiasi licenza tu o la tua azienda desideriate. In caso contrario, potrebbero esserci altri titolari di copyright di cui è necessario il consenso per modificare le licenze. Loro chi sono? [Le persone che si sono impegnate nel tuo progetto](https://github.com/thehale/git-authorship) è un buon punto di partenza. Ma in alcuni casi i diritti d'autore saranno detenuti dai datori di lavoro di quelle persone. In alcuni casi le persone avranno dato solo un contributo minimo, ma non esiste una regola ferrea secondo cui i contributi al di sotto di un certo numero di righe di codice non sono soggetti a copyright. Cosa fare? Dipende. Per un progetto relativamente piccolo e giovane, potrebbe essere possibile convincere tutti i contributori esistenti ad accettare una modifica della licenza in un problema o in una richiesta pull. Per progetti grandi e a lungo termine, potrebbe essere necessario cercare molti collaboratori e persino i loro successori. Mozilla ha impiegato anni (2001-2006) per concedere nuovamente la licenza a Firefox, Thunderbird e al relativo software. + +In alternativa, puoi chiedere ai contributori di pre-approvare alcune modifiche alla licenza tramite un contratto di collaborazione aggiuntivo ([vedi su](#quale-licenza-open-source-è-adatta-al-mio-progetto)). Ciò elimina parte della complessità della modifica delle licenze. Avrai bisogno di maggiore aiuto da parte dei tuoi avvocati in anticipo e vorrai comunque comunicare chiaramente con le parti interessate del progetto quando effettui una modifica della licenza. + +## Il mio progetto necessita di un contratto di collaborazione aggiuntivo? + +Probabilmente no. Per la stragrande maggioranza dei progetti open source, la licenza open source funge implicitamente sia da licenza in entrata (dai contributori) che da licenza in uscita (ad altri contributori e utenti). Se il tuo progetto è su GitHub, i Termini di servizio di GitHub rendono "inbound=outbound" [esplicito per impostazione predefinita](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributi-sotto-licenza-repository). + +Un ulteriore contratto di collaborazione, spesso chiamato Contributor License Agreement (CLA), può creare lavoro amministrativo per i manutentori del progetto. La quantità di lavoro aggiunta da un accordo dipende dal progetto e dall'implementazione. Un tipico accordo potrebbe richiedere ai contributori di confermare con un clic di possedere i diritti necessari per contribuire secondo la licenza open source del progetto. Un accordo più complesso può richiedere la revisione legale e la firma da parte dei datori di lavoro dei contributori. + +Inoltre, aggiungendo "documentazione" che alcuni ritengono non necessaria, difficile da comprendere o ingiusta (quando il destinatario dell'accordo ottiene più diritti dei contributori o del pubblico attraverso la licenza open source del progetto), un ulteriore accordo con il contributore può essere percepito come ostile alla comunità del progetto. + + + +Alcune situazioni in cui potresti prendere in considerazione un accordo di collaborazione aggiuntivo per il tuo progetto includono: + +* I tuoi avvocati vogliono che tutti i contributori accettino esplicitamente (_firmano_, online o offline) i termini del contributo, forse perché ritengono che la licenza open source da sola non sia sufficiente (anche se lo è!). Se questa è l'unica preoccupazione, dovrebbe essere sufficiente un accordo di collaborazione che riconosca la licenza open source del progetto. Il contratto di licenza per collaboratore individuale jQuery è un buon esempio di contratto per collaboratore aggiuntivo leggero. +* Tu o i tuoi avvocati volete che gli sviluppatori dichiarino che ogni impegno che assumono è autorizzato. Il requisito del [Certificato di origine dello sviluppatore](https://developercertificate.org/) indica quanti progetti raggiungono questo obiettivo. Ad esempio, la comunità Node.js [utilizza](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [invece di](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) dal loro precedente CLA. Una semplice opzione per automatizzare l'implementazione di DCO nel tuo repository è [DCO Probot](https://github.com/probot/dco). +* Il tuo progetto utilizza una licenza open source che non include una concessione espressa di brevetto (come il MIT) e hai bisogno dell'autorizzazione al brevetto da parte di tutti i contributori, alcuni dei quali potrebbero lavorare per aziende con ampi portafogli di brevetti che potrebbero essere utilizzati per prendere di mira te o altri contributori e utenti del progetto. Il [Contratto di licenza per collaboratore personale Apache](https://www.apache.org/licenses/icla.pdf) è un contratto per collaboratore supplementare comunemente utilizzato che prevede una concessione di brevetto che rispecchia quella presente nella licenza Apache 2.0. +* Il tuo progetto è protetto da licenza copyleft, ma devi anche distribuire la tua versione del progetto. Ogni collaboratore dovrà assegnarti il ​​copyright o concedere a te (ma non al pubblico) una licenza permissiva. Il [Contratto di collaborazione MongoDB](https://www.mongodb.com/legal/contributor-agreement) è un esempio di questo tipo di contratto. +* Ritieni che il tuo progetto potrebbe dover modificare le licenze nel corso della sua vita e desideri che i partecipanti accettino tali modifiche in anticipo. + +Se hai comunque bisogno di utilizzare un contratto di collaborazione aggiuntivo con il tuo progetto, prendi in considerazione l'utilizzo di un'integrazione come [Assistente CLA](https://github.com/cla-assistant/cla-assistant) per ridurre al minimo la distrazione del collaboratore. + +## Cosa deve sapere il team legale della mia azienda? + +Se stai lanciando un progetto open source come dipendente dell'azienda, innanzitutto il tuo team legale deve sapere che sei un progetto open source. + +Nel bene e nel male, considera di farglielo sapere, anche se si tratta di un progetto personale. Probabilmente hai un "accordo di proprietà intellettuale dei dipendenti" con la tua azienda che dà loro un certo controllo sui tuoi progetti, soprattutto se sono legati all'attività aziendale o se stai utilizzando risorse aziendali per sviluppare il progetto. La tua azienda _dovrebbe_ concederti facilmente l'autorizzazione e potrebbe già averlo fatto tramite un accordo IP o una politica aziendale favorevole ai dipendenti. In caso contrario, puoi negoziare (ad esempio spiegando che il tuo progetto serve agli obiettivi di apprendimento e sviluppo professionale dell'azienda per te) o evitare di lavorare sul tuo progetto finché non trovi un'azienda migliore. + +**Se stai cercando un progetto open source per la tua azienda**, faglielo sapere. Probabilmente il tuo team legale ha già delle politiche su quale licenza open source (e forse un accordo di collaborazione aggiuntivo) da utilizzare in base ai requisiti aziendali e all'esperienza dell'azienda nel garantire che il tuo progetto sia conforme alle licenze delle sue dipendenze. In caso contrario, tu e loro siete fortunati! Il tuo team legale dovrebbe essere desideroso di lavorare con te per capire queste cose. Alcune cose a cui pensare: + +* **Materiale di terze parti:** Il tuo progetto ha dipendenze create da altri o include o utilizza in altro modo codice di terze parti? Se sono open source, dovrai rispettare le licenze open source dei materiali. Questo inizia con la scelta di una licenza che funzioni con licenze open source di terze parti ([vedi sopra](#quale-licenza-open-source-è-adatta-al-mio-progetto)). Se il tuo progetto modifica o distribuisce materiale open source di terze parti, il tuo team legale vorrà anche sapere se rispetti altri termini delle licenze open source di terze parti, come il mantenimento degli avvisi di copyright. Se il tuo progetto utilizza codice di terze parti che non dispone di una licenza open source, potresti dover chiedere ai manutentori di terze parti di [aggiungere una licenza open source](https://choosealicense.com/no-license/#for-users) e, se non riesci a ottenerne uno, smetti di usare il loro codice nel tuo progetto. + +* **Segreti commerciali:** Considera se c'è qualcosa nel progetto che l'azienda non vuole rendere disponibile al pubblico in generale. In tal caso, puoi aprire il resto del tuo progetto dopo aver estratto il materiale che desideri mantenere privato. + +* **Brevetti:** La tua azienda sta richiedendo un brevetto per il quale l'open source del tuo progetto costituirebbe [divulgazione pubblica](https://en.wikipedia.org/wiki/Public_disclosure)? Sfortunatamente, ti potrebbe essere chiesto di attendere (o forse la società riconsidererà la ragionevolezza della richiesta). Se ti aspetti contributi al tuo progetto da dipendenti di aziende con un ampio portafoglio di brevetti, il tuo team legale potrebbe richiederti di utilizzare una licenza con una concessione esplicita di brevetto da parte dei contributori (come Apache 2.0 o GPLv3) o un ulteriore accordo con il collaboratore ([vedi sopra](#quale-licenza-open-source-è-adatta-al-mio-progetto)). + +* **Marchi commerciali:** Controlla che il nome del tuo progetto [non sia in conflitto con i marchi esistenti](../starting-a-project/#evitare-conflitti-di-nomi). Se utilizzi i marchi della tua azienda nel progetto, controlla che non ci siano conflitti. [FOSSmarks](http://fossmarks.org/) è una guida pratica per comprendere i marchi nel contesto di progetti gratuiti e open source. + +* **Privacy:** Il tuo progetto raccoglie dati degli utenti? "Telefono di casa" ai server aziendali? Il tuo team legale può aiutarti a rispettare le politiche aziendali e le normative esterne. + +Se stai lanciando il primo progetto open source della tua azienda, quanto sopra è più che sufficiente per farcela (ma non preoccuparti, la maggior parte dei progetti non dovrebbe essere un grosso problema). + +Nel lungo termine, il tuo team legale può fare di più per aiutare l'azienda a ottenere di più dal suo coinvolgimento open source e rimanere al sicuro: + +* **Regole per il contributo dei dipendenti:** Valuta la possibilità di sviluppare una politica aziendale che definisca il modo in cui i tuoi dipendenti contribuiscono ai progetti open source. Una politica chiara ridurrà la confusione tra i tuoi dipendenti e li aiuterà a contribuire a progetti open source nel migliore interesse dell'azienda, sia come parte del loro lavoro che nel loro tempo libero. Un buon esempio è [un IP modello e una politica di contributo open source](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) di Rackspace. + + + +* **Cosa pubblicare:** [(Quasi) tutto?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) АQuando il tuo team legale comprende ed è investito nella strategia open source della tua azienda, sarà in grado di aiutarti meglio piuttosto che ostacolare i tuoi sforzi. +* **Conformità:** Anche se la tua azienda non rilascia progetti open source, utilizza software open source di terze parti. [Consapevolezza e processo](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) possono prevenire mal di testa, ritardi nei prodotti e azioni legali. + + + +* **Brevetti:** la tua azienda potrebbe voler aderire a [Open Invention Network](https://www.openinventionnetwork.com/), un pool di brevetti condiviso e sicuro per proteggere l'uso da parte dei membri di grandi progetti open source o per esplorare altre [licenze di brevetti alternative](https://www.eff.org/document/hacking-patent-system-2016). +* **Governance:** Soprattutto se e quando ha senso trasferire un progetto a [un'entità legale esterna all'azienda](../leadership-and-governance/#ho-bisogno-di-una-persona-giuridica-per-sostenere-il-mio-progetto). diff --git a/_articles/it/maintaining-balance-for-open-source-maintainers.md b/_articles/it/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..1130320d378 --- /dev/null +++ b/_articles/it/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,219 @@ +--- +lang: it +title: Mantenere l'equilibrio per i sostenitori dell'open source +description: Suggerimenti per la cura di sé ed evitare il burnout come caregiver. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +Man mano che il progetto open source cresce in popolarità, diventa importante stabilire confini chiari per aiutarti a mantenere un equilibrio e rimanere aggiornato e produttivo a lungo termine. + +Per ottenere informazioni dettagliate sulle esperienze dei manutentori e sulle loro strategie di bilanciamento, abbiamo condotto un workshop con 40 membri della comunità dei manutentori, che ci ha permesso di imparare da le loro esperienze di prima mano con il burnout open source e le pratiche che li hanno aiutati a mantenere l'equilibrio nel loro lavoro. È qui che entra in gioco il concetto di ecologia personale. + +Allora, cos'è l'ecologia personale? Come descritto dal Rockwood Leadership Institute, implica "mantenere equilibrio, ritmo ed efficienza per sostenere la nostra energia per tutta la vita". Questo inquadra le nostre conversazioni, aiutando i sostenitori a riconoscere le loro azioni e i loro contributi come parti di un ecosistema più ampio che si evolve nel tempo. Burnout, una sindrome derivante dallo stress cronico sul lavoro, come [definita dall'OMS](https://icd.who.int/browse/2025-01/foundation/en#129180281), non è raro tra i manutentori. Ciò spesso porta a una perdita di motivazione, incapacità di concentrazione e mancanza di empatia verso i colleghi e la comunità con cui lavori. + + + +Abbracciando il concetto di ecologia personale, gli operatori sanitari possono evitare in modo proattivo il burnout, dare priorità alla cura di sé e mantenere un senso di equilibrio per svolgere al meglio il proprio lavoro. + +## Suggerimenti per la cura di sé ed evitare il burnout come personale di supporto: + +### Determina le tue motivazioni per lavorare con l'open source + +Prenditi del tempo per pensare a quali parti del supporto open source ti danno energia. Comprendere la tua motivazione può aiutarti a dare priorità al lavoro in un modo che ti mantenga impegnato e pronto per nuove sfide. Che si tratti del feedback positivo degli utenti, della gioia di collaborare e interagire con la community o della soddisfazione di immergersi nel codice, riconoscere le proprie motivazioni può aiutarti a dirigere la tua attenzione. + +### Pensa a cosa ti fa sentire sbilanciato e stressato + +È importante capire cosa ci fa bruciare. Ecco alcuni temi comuni che abbiamo riscontrato tra i sostenitori dell'open source: + +* **Mancanza di feedback positivo:** è molto più probabile che gli utenti si mettano in contatto con noi in caso di reclamo. Se tutto funziona bene, tendono a tacere. Può essere scoraggiante vedere un elenco crescente di problemi senza il feedback positivo che mostri come il tuo contributo stia facendo la differenza. + + + +* **Non dire di "NO":** Può essere facile assumersi più responsabilità del dovuto per un progetto open source. Che si tratti di utenti, contributori o altri sostenitori, non sempre possiamo essere all'altezza delle loro aspettative. + + + +* **Lavorare da soli:** Essere un manutentore può essere incredibilmente solitario. Anche se lavori con un gruppo di manutentori, negli ultimi anni è stato difficile convocare di persona i team distribuiti. + + + +* **Tempo o risorse insufficienti:** Ciò è particolarmente vero per i volontari di supporto che devono sacrificare il proprio tempo libero per lavorare a un progetto. + + + +* **Richieste contrastanti:** L'open source è pieno di gruppi con motivazioni diverse che possono essere difficili da orientare. Se sei pagato per lavorare nell'open source, gli interessi del tuo datore di lavoro a volte possono essere in contrasto con quelli della comunità. + + + +### Fai attenzione ai segni di esaurimento + +Riesci a mantenere il tuo ritmo per 10 settimane? 10 mesi? 10 anni? + +Esistono strumenti come [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) di [@shaunagm](https://github.com/shaunagm) che possono aiutarti a riflettere sul tuo ritmo attuale e vedi se ci sono modifiche che puoi apportare. Alcuni operatori sanitari utilizzano anche la tecnologia indossabile per monitorare parametri come la qualità del sonno e la variabilità della frequenza cardiaca (entrambi legati allo stress). + + + +### Di cosa hai bisogno per continuare a sostenere te stesso e la tua comunità? + +Questo apparirà diverso per ogni manutentore e cambierà a seconda della fase della tua vita e di altri fattori esterni. Ma ecco alcuni temi che abbiamo sentito: + +* **Affidati alla community:** Delegare e trovare collaboratori può alleggerire il carico di lavoro. Avere più punti di contatto per un progetto può aiutarti a stare tranquillo. Connettiti con altri manutentori e con la comunità più ampia - in gruppi come [Comunità dei manutentori](http://maintainers.github.com/). Questa può essere una grande risorsa per il supporto e la formazione tra pari. + + Puoi anche cercare modi per interagire con la comunità di utenti in modo da poter ascoltare regolarmente feedback e comprendere l'impatto del tuo lavoro open source. + +* **Esplora i finanziamenti:** Che tu stia cercando dei soldi per la pizza o stia cercando di passare a tempo pieno all'open source, ci sono molte risorse per aiutarti! Come primo passo, valuta la possibilità di attivare [Sponsor Github](https://github.com/sponsors) per consentire ad altri di sponsorizzare il tuo lavoro open source. Se stai pensando di trasferirti a tempo pieno, fai domanda per il turno successivo [GitHub Accelerator](http://accelerator.github.com/). + + + +* **Utilizza gli strumenti:** esplora strumenti come [GitHub Copilot](https://github.com/features/copilot/) e [GitHub Actions](https://github.com/features/actions), per automatizzare le attività banali e liberare tempo per contributi più significativi. + + + +* **Riposati e ricaricati:** prenditi del tempo per i tuoi hobby e interessi al di fuori dell'open source. Prenditi dei giorni liberi per rilassarti e rigenerarti e imposta il tuo [stato GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), per riflettere la tua disponibilità! Una buona notte di sonno può fare una grande differenza nella tua capacità di sostenere i tuoi sforzi a lungo termine. + + Se trovi particolarmente piacevoli alcuni aspetti del tuo progetto, prova a strutturare il tuo lavoro in modo da poterlo sperimentare durante tutta la giornata. + + + +* **Imposta dei limiti:** non puoi dire sì a ogni richiesta. Può essere semplice come dire "Non posso farlo adesso e non ho piani per il futuro" o specificare cosa vuoi fare e cosa non fare nel README. Ad esempio, potresti dire: "Unisco solo i PR che hanno chiaramente elencato i motivi per cui sono stati creati" oppure "Esamino i problemi solo il giovedì dalle 18:00 alle 19:00". Ciò definisce le aspettative per gli altri e ti dà qualcosa a cui puntare in altri momenti per ridurre le richieste di tempo da parte di collaboratori o utenti. + + + + Impara ad essere fermo nel fermare comportamenti tossici e interazioni negative. È bene non dare energia a cose che non ti interessano. + + + + + +Ricorda che l'ecologia personale è una pratica continua che si evolverà man mano che avanzi nel tuo viaggio open source. Dando priorità alla cura di sé e mantenendo un senso di equilibrio, puoi contribuire alla comunità open source in modo efficace e sostenibile, garantendo sia il tuo benessere che il successo a lungo termine dei tuoi progetti. + +## Risorse addizionali + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid +* [Governing Open](https://governingopen.com/) +* Il programma del seminario è un remix della serie di [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) + +## Associati + +Mille grazie a tutti i manutentori che hanno condiviso con noi la loro esperienza e i loro consigli per questa guida! + +Questa guida è stata scritta da [@abbycabs](https://github.com/abbycabs) con il contributo di: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + moltri altri! diff --git a/_articles/it/metrics.md b/_articles/it/metrics.md new file mode 100644 index 00000000000..08716db858f --- /dev/null +++ b/_articles/it/metrics.md @@ -0,0 +1,128 @@ +--- +lang: it +title: Metriche Open Source +description: Prendi decisioni informate per aiutare il tuo progetto open source a prosperare misurando e monitorandone il successo. +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Perché misurare qualcosa? + +I dati, se utilizzati con saggezza, possono aiutarti a prendere decisioni migliori come sostenitore dell'open source. + +Per ulteriori informazioni, puoi: + +* Scopri come gli utenti reagiscono a una nuova funzionalità +* Scopri da dove provengono i nuovi utenti +* Identificare e decidere se supportare un caso d'uso o una funzionalità eccezionale +*Quantificare la popolarità del tuo progetto +* Scopri come viene utilizzato il tuo progetto +* Raccogliere fondi attraverso sponsorizzazioni e sovvenzioni + +Per esempio [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) scopre che Google Analytics li aiuta a dare priorità al lavoro: + +> Homebrew è fornito gratuitamente ed è gestito interamente da volontari nel loro tempo libero. Di conseguenza, non abbiamo le risorse per effettuare studi dettagliati sugli utenti di Homebrew per decidere come progettare al meglio le funzionalità future e dare priorità al lavoro attuale. L'analisi anonima degli utenti aggregati ci consente di dare priorità a correzioni e funzionalità in base a come, dove e quando le persone utilizzano Homebrew. + +La popolarità non è tutto. Tutti entrano nell'open source per motivi diversi. Se il tuo obiettivo come sostenitore dell'open source è mostrare il tuo lavoro, essere trasparente riguardo al tuo codice o semplicemente divertirti, le metriche potrebbero non essere importanti per te. + +Se sei interessato a comprendere il tuo progetto a un livello più profondo, leggi i modi per analizzare l'attività del tuo progetto. + +## Scoperta + +Prima che chiunque possa utilizzare o contribuire al tuo progetto, deve sapere che esiste. Chiediti: _le persone trovano questo progetto?_ + +![Grafico del traffico](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +Se il tuo progetto è ospitato su GitHub, [puoi vedere](https://help.github.com/articles/about-repository-graphs/#traffic) quante persone arrivano al tuo progetto e da dove provengono . Dalla pagina del tuo progetto, fai clic su Approfondimenti, quindi su Traffico. In questa pagina puoi vedere: + +* **Visualizzazioni di pagina totali:** indica quante volte il tuo progetto è stato visualizzato + +* **Visitatori unici totali:** Ti dice quante persone hanno visto il tuo progetto + +* **Siti di riferimento:** ti dice da dove provengono i tuoi visitatori. Questa metrica può aiutarti a capire dove raggiungere il tuo pubblico e se i tuoi sforzi di promozione stanno funzionando. + +* **Contenuti popolari:** indica dove stanno andando i visitatori nel tuo progetto, suddivisi per visualizzazioni di pagina e visitatori unici. + +[Le stelle di GitHub](https://help.github.com/articles/about-stars/) possono anche aiutare a fornire una misura di base della popolarità. Anche se le star di GitHub non sono necessariamente legate ai download e all'utilizzo, possono dirti quante persone prestano attenzione al tuo lavoro. + +Potresti anche voler [monitorare la rilevabilità di posizioni specifiche](https://opensource.com/business/16/6/pirate-metrics): ad esempio, Google PageRank, traffico proveniente da referral dal sito web del tuo progetto o referral da altri progetti o siti web open source. + +## Utilizzo + +Le persone trovano il tuo progetto in questa cosa selvaggia e folle che chiamiamo Internet. Idealmente, quando vedranno il tuo progetto, si sentiranno obbligati a fare qualcosa. La seconda domanda che dovrai porre è: _ci sono persone che utilizzano questo progetto?_ + +Se utilizzi un gestore di pacchetti come npm o RubyGems.org per distribuire il tuo progetto, potresti essere in grado di monitorare i download del tuo progetto. + +Ogni gestore di pacchetti può utilizzare una definizione leggermente diversa di "download" e i download non sono necessariamente correlati alle installazioni o all'utilizzo, ma forniscono alcune linee di base per il confronto. Prova a utilizzare [Libraries.io](https://libraries.io/) per tenere traccia delle statistiche di utilizzo su molti gestori di pacchetti popolari. + +Se il tuo progetto è su GitHub, apri nuovamente la pagina Traffico. Puoi utilizzare il [grafico dei cloni](https://github.com/blog/1873-clone-graphs) per vedere quante volte il tuo progetto è stato clonato in un determinato giorno, suddiviso in cloni totali e cloni unici. + +![Grafico dei cloni](/assets/images/metrics/clone_graph.png) + +Se l'utilizzo è basso rispetto al numero di persone che hanno scoperto il tuo progetto, ci sono due problemi da considerare. O: + +* Il tuo progetto non sta convertendo con successo il tuo pubblico, o +* Stai attirando il pubblico sbagliato + +Ad esempio, se il tuo progetto arriva sulla prima pagina di Hacker News, probabilmente noterai un picco nella scoperta (traffico) ma un tasso di conversione inferiore perché stai raggiungendo tutti su Hacker News. Tuttavia, se il tuo progetto Ruby viene presentato a una conferenza Ruby, è più probabile che tu ottenga un tasso di conversione elevato da un pubblico target. + +Cerca di capire da dove proviene il tuo pubblico e chiedi feedback agli altri sulla pagina del tuo progetto per scoprire quale di questi due problemi stai affrontando. + +Una volta che sai che le persone utilizzano il tuo progetto, potresti provare a scoprire cosa ne fanno. Si basano su di esso biforcando il codice e aggiungendo funzionalità? Lo usano per la scienza o per gli affari? + +## Presa + +Le persone trovano il tuo progetto e lo usano. La prossima domanda che ti dovrai porre è: _le persone contribuiscono a questo progetto?_ + +Non è mai troppo presto per iniziare a pensare ai collaboratori. Senza l'intervento di altre persone, rischi di metterti in una situazione malsana in cui il tuo progetto è _popolare_ (molte persone lo usano) ma non _mantenuto_ (non abbastanza tempo di supporto per soddisfare la domanda). + +La conservazione richiede anche [un afflusso di nuovi contributori](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) poiché i contributori precedentemente attivi alla fine passeranno a altre cose. + +Esempi di parametri della community che potresti voler monitorare regolarmente includono: + +* **Totale contributori e impegni per collaboratore:** indica quanti collaboratori hai e chi è più o meno attivo. Su GitHub puoi vederlo in Approfondimenti -> Collaboratori. Attualmente, questo grafico riporta solo i contributori che si sono impegnati nel ramo predefinito del repository. + +![Graffico dei collaboratori](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **Primi contributori, collaboratori occasionali e ricorrenti:** ti aiuta a monitorare se ottieni nuovi contributori e se ritornano. (I contributori occasionali sono contributori con un numero limitato di commit. Che si tratti di un commit, di meno di cinque commit o di qualcos'altro dipende da te.) Senza nuovi contributori, la comunità del tuo progetto può ristagnare. + +* **Numero di problemi aperti e richieste pull aperte:** Se questi numeri diventano troppo alti, potresti aver bisogno di aiuto con l'ordinamento dei problemi e le revisioni del codice. + +* **Numero di problemi _aperti_ e richieste pull _aperte_:** I problemi aperti indicano che qualcuno è sufficientemente interessato al tuo progetto da aprire un problema. Se questo numero aumenta nel tempo, significa che le persone sono interessate al tuo progetto. + +* **Tipi di contributi:** Ad esempio, commit, correzione di errori di battitura o di commento o commento su un problema. + + + +## Attività di supporto + +Infine, ti consigliamo di chiudere il ciclo assicurandoti che i sostenitori del tuo progetto siano in grado di gestire il volume dei contributi ricevuti. L'ultima domanda che vorrai farti è: _sto (o stiamo) rispondendo alla nostra community?_ + +I manutentori che non rispondono diventano un ostacolo per i progetti open source. Se qualcuno invia un contributo ma non riceve mai risposta dal manutentore, potrebbe sentirsi scoraggiato e andarsene. + +[Una ricerca di Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggerisce che la reattività del manutentore è un fattore critico nell'incoraggiare la ripetizione dei contributi. + +Prendi in considerazione [il monitoraggio del tempo impiegato da te (o da un altro manutentore) per rispondere alle richieste pull](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), che si tratti di un problema o di una richiesta di download. La risposta non richiede alcuna azione. Potrebbe essere semplice come dire: _"Grazie per il tuo contributo! Esaminerò la questione la prossima settimana."_ + +Puoi anche misurare il tempo necessario per passare da una fase all'altra del processo di contribuzione, ad esempio: + +* Tempo medio in cui il problema rimane aperto +* Se i problemi vengono risolti dai PR +* Se i problemi obsoleti sono chiusi +* Tempo medio per unire una richiesta pull + +## Usa 📊 per conoscere le persone + +Comprendere le metriche ti aiuterà a costruire un progetto open source attivo e in crescita. Anche se non tieni traccia di tutte le metriche della dashboard, utilizza la struttura sopra per focalizzare la tua attenzione sul tipo di comportamento che aiuterà il tuo progetto a prosperare. + +[CHAOSS](https://chaoss.community/) è un'accogliente comunità open source focalizzata su analisi, metriche e software sulla salute della comunità. diff --git a/_articles/it/security-best-practices-for-your-project.md b/_articles/it/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..dc89194cb95 --- /dev/null +++ b/_articles/it/security-best-practices-for-your-project.md @@ -0,0 +1,83 @@ +--- +lang: it +title: Le migliori pratiche di sicurezza per il tuo progetto +description: Rafforza il futuro del tuo progetto creando fiducia attraverso pratiche di sicurezza essenziali, dall'MFA e dalla scansione del codice alla gestione sicura delle dipendenze e alla segnalazione di vulnerabilità private. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +A parte bug e nuove funzionalità, la longevità di un progetto dipende non solo dalla sua utilità, ma anche dalla fiducia che guadagna dai suoi utenti. Misure di sicurezza efficaci sono fondamentali per mantenere viva questa fiducia. Ecco alcune azioni importanti che puoi intraprendere per migliorare significativamente la sicurezza del tuo progetto. + +## Assicurati che tutti i collaboratori con privilegi abbiano abilitato l'autenticazione a più fattori (MFA) + +### Un malintenzionato che riesca a impersonare un collaboratore con privilegi nel tuo progetto causerà danni catastrofici. + +Una volta ottenuto l'accesso con privilegi, questo malintenzionato può modificare il tuo codice per eseguire azioni indesiderate (ad esempio, estrarre criptovalute), oppure può distribuire malware all'infrastruttura dei tuoi utenti, o ancora può accedere a repository di codice privati ​​per esfiltrare proprietà intellettuale e dati sensibili, incluse le credenziali di accesso ad altri servizi. + +L'MFA fornisce un ulteriore livello di sicurezza contro il furto di account. Una volta abilitata, devi accedere con il tuo nome utente e password e fornire un'altra forma di autenticazione che solo tu conosci o a cui hai accesso. + +## Proteggi il tuo codice come parte del tuo flusso di lavoro di sviluppo + +### Le vulnerabilità di sicurezza nel tuo codice sono più economiche da risolvere se rilevate nelle prime fasi del processo rispetto a quando vengono utilizzate in produzione. + +Utilizza uno strumento SAST (Static Application Security Testing) per rilevare le vulnerabilità di sicurezza nel tuo codice. Questi strumenti operano a livello di codice e non necessitano di un ambiente di esecuzione, quindi possono essere eseguiti nelle prime fasi del processo e possono essere integrati perfettamente nel tuo consueto flusso di lavoro di sviluppo, durante la build o durante le fasi di revisione del codice. + +È come avere un esperto qualificato che esamina il tuo repository di codice, aiutandoti a trovare vulnerabilità di sicurezza comuni che potrebbero nascondersi alla vista durante la scrittura del codice. + +Come scegliere il tuo strumento SAST? +Verifica la licenza: alcuni strumenti sono gratuiti per i progetti open source. Ad esempio, GitHub CodeQL o SemGrep. +Verifica la copertura per i tuoi linguaggi + +* Selezionane uno che si integri facilmente con gli strumenti che già utilizzi e con il tuo processo esistente. Ad esempio, è meglio se gli avvisi sono disponibili come parte del tuo processo di revisione del codice e del tuo strumento, piuttosto che passare a un altro strumento per visualizzarli. +* Attenzione ai falsi positivi! Non vorrai certo che lo strumento ti rallenti senza motivo! +* Controlla le funzionalità: alcuni strumenti sono molto potenti e possono tracciare i taint (ad esempio: GitHub CodeQL), alcuni propongono suggerimenti di correzione generati dall'intelligenza artificiale, altri semplificano la scrittura di query personalizzate (ad esempio: SemGrep). + +## Non condividere i tuoi segreti + +### Dati sensibili, come chiavi API, token e password, a volte possono essere accidentalmente inseriti nel tuo repository. + +Immagina questo scenario: sei il responsabile della manutenzione di un popolare progetto open source con contributi di sviluppatori da tutto il mondo. Un giorno, un collaboratore inserisce inconsapevolmente nel repository alcune chiavi API di un servizio di terze parti. Giorni dopo, qualcuno trova queste chiavi e le usa per accedere al servizio senza autorizzazione. Il servizio viene compromesso, gli utenti del tuo progetto subiscono tempi di inattività e la reputazione del tuo progetto ne risente. Come responsabile della manutenzione, ora ti trovi ad affrontare il difficile compito di revocare i segreti compromessi, indagare sulle azioni dannose che l'attaccante potrebbe aver compiuto con questi segreti, avvisare gli utenti interessati e implementare le correzioni. + +Per prevenire tali incidenti, esistono soluzioni di "scansione dei segreti" che ti aiutano a individuare tali segreti nel tuo codice. Alcuni strumenti come GitHub Secret Scanning e Trufflehog di Truffle Security possono impedirti di inviarli a branch remoti, mentre altri strumenti revocheranno automaticamente alcuni segreti per te. + +## Controlla e aggiorna le tue dipendenze + +### Le dipendenze nel tuo progetto possono presentare vulnerabilità che ne compromettono la sicurezza. Mantenere aggiornate manualmente le dipendenze può essere un'attività che richiede molto tempo. + +Immagina questo: un progetto costruito sulle solide fondamenta di una libreria ampiamente utilizzata. In seguito, la libreria rileva un grave problema di sicurezza, ma le persone che hanno sviluppato l'applicazione utilizzandola non ne sono a conoscenza. I dati sensibili degli utenti rimangono esposti quando un aggressore sfrutta questa vulnerabilità, tentando di appropriarsene. Questo non è un caso teorico. È esattamente quello che è successo a Equifax nel 2017: non sono riusciti ad aggiornare la loro dipendenza Apache Struts dopo la notifica del rilevamento di una grave vulnerabilità. La vulnerabilità è stata sfruttata e la famigerata violazione di Equifax ha interessato i dati di 144 milioni di utenti. + +Per prevenire tali scenari, strumenti di analisi della composizione del software (SCA) come Dependabot e Renovate controllano automaticamente le dipendenze alla ricerca di vulnerabilità note pubblicate in database pubblici come NVD o GitHub Advisory Database, e quindi creano richieste pull per aggiornarle a versioni sicure. Rimanere aggiornati con le ultime versioni delle dipendenze sicure salvaguarda il progetto da potenziali rischi. + +## Evita modifiche indesiderate con branch protetti + +### L'accesso illimitato ai tuoi branch principali può portare a modifiche accidentali o dolose che potrebbero introdurre vulnerabilità o compromettere la stabilità del tuo progetto. + +Un nuovo collaboratore ottiene l'accesso in scrittura al branch principale e inserisce accidentalmente modifiche che non sono state testate. In questo modo, grazie alle ultime modifiche, viene scoperta una grave falla di sicurezza. Per prevenire tali problemi, le regole di protezione dei branch garantiscono che le modifiche non possano essere inserite o unite in branch importanti senza prima essere sottoposte a revisione e aver superato specifici controlli di stato. Con questa misura aggiuntiva, che garantisce la massima qualità ogni volta, sei più sicuro e in una posizione migliore. + +## Imposta un meccanismo di acquisizione per la segnalazione delle vulnerabilità + +### È una buona pratica semplificare la segnalazione dei bug da parte degli utenti, ma la domanda fondamentale è: quando un bug ha un impatto sulla sicurezza, come possono segnalartelo in modo sicuro senza renderti un bersaglio per hacker malintenzionati? + +Immagina questa situazione: un ricercatore di sicurezza scopre una vulnerabilità nel tuo progetto ma non trova un modo chiaro o sicuro per segnalarla. Senza un processo definito, potrebbero creare un problema pubblico o discuterne apertamente sui social media. Anche se fossero ben intenzionati e offrissero una soluzione, se lo facessero con una pull request pubblica, altri la vedrebbero prima che venga integrata! Questa divulgazione pubblica esporrebbe la vulnerabilità a malintenzionati prima che tu abbia la possibilità di risolverla, portando potenzialmente a un exploit zero-day che attaccherebbe il tuo progetto e i suoi utenti. + +### Policy di sicurezza + +Per evitare questo problema, pubblica una policy di sicurezza. Una policy di sicurezza, definita in un file `SECURITY.md`, descrive i passaggi per segnalare problemi di sicurezza, creare un processo trasparente per la divulgazione coordinata e stabilire le responsabilità del team di progetto per la gestione dei problemi segnalati. Questa policy di sicurezza può essere semplice come "Si prega di non pubblicare dettagli in un problema pubblico o in una PR, inviarci un'e-mail privata a security@example.com", ma può anche contenere altri dettagli, come ad esempio quando dovrebbero aspettarsi di ricevere una risposta da te. Tutto ciò che può contribuire all'efficacia e all'efficienza del processo di divulgazione. + +### Segnalazione di vulnerabilità private + +Su alcune piattaforme, è possibile semplificare e rafforzare il processo di gestione delle vulnerabilità, dall'acquisizione alla trasmissione, con segnalazioni private. Su GitLab, questo è possibile grazie alle segnalazioni private. Su GitHub, questo si chiama segnalazione di vulnerabilità private (PVR). La PVR consente ai manutentori di ricevere e gestire le segnalazioni di vulnerabilità, il tutto all'interno della piattaforma GitHub. GitHub creerà automaticamente un fork privato per scrivere le correzioni e una bozza di avviso di sicurezza. Tutto ciò rimane riservato finché non si decide di divulgare le segnalazioni e rilasciare le correzioni. Per chiudere il cerchio, verranno pubblicati avvisi di sicurezza che informeranno e proteggeranno tutti gli utenti tramite il loro strumento SCA. + +## Conclusione: pochi passaggi per te, un enorme miglioramento per i tuoi utenti + +Questi pochi passaggi potrebbero sembrarti facili o basilari, ma contribuiscono notevolmente a rendere il tuo progetto più sicuro per i suoi utenti, perché forniranno protezione dai problemi più comuni. + +## Collaboratori + +### Un ringraziamento speciale a tutti i responsabili della manutenzione che hanno condiviso con noi le loro esperienze e i loro suggerimenti per questa guida! + +Questa guida è stata scritta da [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) con contributi di: + +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + molti altri! diff --git a/_articles/it/starting-a-project.md b/_articles/it/starting-a-project.md new file mode 100644 index 00000000000..07e871686c7 --- /dev/null +++ b/_articles/it/starting-a-project.md @@ -0,0 +1,355 @@ +--- +lang: it +title: Avvio di un progetto open source +description: Scopri di più sul mondo dell'open source e preparati a iniziare il tuo progetto. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## Il "cosa" e il "perché" dell'open source + +Quindi stai pensando di iniziare con l'open source? Congratulazioni! Il mondo apprezza il tuo contributo. Parliamo di cos'è l'open source e perché le persone lo fanno. + +### Cosa significa "open source"? + +Quando un progetto è open source, significa che **chiunque è libero di utilizzare, studiare, modificare e distribuire il tuo progetto per qualsiasi scopo.** Queste autorizzazioni si applicano tramite la [licenza open source](https://opensource.org/licenses). + +L'open source è potente perché abbassa le barriere all'adozione e alla collaborazione, consentendo alle persone di distribuire e migliorare rapidamente i progetti. Anche perché offre agli utenti la possibilità di controllare i propri computer, rispetto al closed source. Ad esempio, un'azienda che utilizza software open source ha la possibilità di assumere qualcuno per apportare miglioramenti personalizzati al software invece di affidarsi esclusivamente alle soluzioni di prodotto di un fornitore closed source. + +_Software Libero_ si riferisce allo stesso insieme di progetti di _Open Source_. A volte vedrai anche [questi termini](https://en.wikipedia.org/wiki/Free_and_open-source_software) combinati come "software libero e open source" (FOSS) o "software libero e open source" (FLOSS). _Free_ e _libre_ si riferiscono alla libertà, [non al prezzo](#open-source-significa-gratuito). + +### Защо хората отварят кода на работата си? + + + +[Ci sono molte ragioni](https://ben.balter.com/2015/11/23/why-open-source/) per cui un individuo o un'organizzazione vorrebbe rendere open source un progetto. Alcuni esempi includono: + +* **Collaborazione:** I progetti open source possono accettare modifiche da chiunque nel mondo. [Exercism](https://github.com/exercism/), ad esempio, è una piattaforma di esercizi di programmazione con oltre 350 contributori. + +* **Adozione e remix:** i progetti open source possono essere utilizzati da chiunque per quasi tutti gli scopi. Le persone possono persino usarlo per costruire altre cose. [WordPress](https://github.com/WordPress), ad esempio, è iniziato come fork di un progetto esistente chiamato [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **Trasparenza:** chiunque può verificare la presenza di bug o incoerenze in un progetto open source. La trasparenza è importante per governi come la [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o gli [Stati Uniti](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), settori regolamentati come quello bancario o sanitario e software di sicurezza come [Let's Encrypt](https://github.com/letsencrypt). + +L'open source non riguarda solo il software. Puoi aprire qualsiasi cosa, dai set di dati ai libri. Dai un'occhiata a [GitHub Explore](https://github.com/explore) per idee su cos'altro puoi aprire. + +### Open source significa "gratuito"? + +Uno dei maggiori vantaggi dell'open source è che non costa denaro. Tuttavia, "gratuito" è un sottoprodotto del valore complessivo dell'open source. + +Poiché la [licenza open source richiede](https://opensource.org/definition-annotated/) che chiunque sia in grado di utilizzare, modificare e condividere il tuo progetto per quasi tutti gli scopi, i progetti stessi sono generalmente gratuiti. Se l'utilizzo del progetto costa denaro, chiunque può legalmente farne una copia e utilizzare invece la versione gratuita. + +Di conseguenza, la maggior parte dei progetti open source sono gratuiti, ma "gratuito" non fa parte della definizione di open source. Esistono modi per far pagare i progetti open source indirettamente attraverso doppia licenza o funzionalità limitate, pur rispettando la definizione ufficiale di open source. + +## Dovrei iniziare il mio progetto open source? + +La risposta breve è sì, perché indipendentemente dal risultato, avviare il proprio progetto è un ottimo modo per imparare come funziona l'open source. + +Se non hai mai aperto un progetto open source prima, potresti essere preoccupato per ciò che la gente dirà o se qualcuno se ne accorgerà. Se suona come te, non sei solo! + +Il lavoro open source è come qualsiasi altra attività creativa, che si tratti di scrivere o disegnare. Potresti avere paura di condividere il tuo lavoro con il mondo, ma l'unico modo per migliorare è esercitarsi, anche se non hai un pubblico. + +Se non sei ancora convinto, prenditi un momento per pensare a quali potrebbero essere i tuoi obiettivi. + +### Stabilisci i tuoi obiettivi + +Gli obiettivi possono aiutarti a capire su cosa lavorare, a cosa dire di no e dove hai bisogno dell'aiuto degli altri. Inizia chiedendoti _perché sto utilizzando questo progetto open source?_ + +Non esiste un'unica risposta corretta a questa domanda. Puoi avere più obiettivi per un progetto o progetti diversi con obiettivi diversi. + +Se il tuo unico obiettivo è mettere in mostra il tuo lavoro, potresti non volere nemmeno un contributo e addirittura dirlo nel tuo README. D'altra parte, se desideri contributori, investirai tempo in una documentazione chiara e farai sentire i nuovi arrivati ​​i benvenuti. + + + +Man mano che il tuo progetto cresce, la tua comunità potrebbe aver bisogno di qualcosa di più del semplice codice, da parte tua. Rispondere ai problemi, rivedere il codice ed evangelizzare il tuo progetto sono compiti importanti in un progetto open source. + +Anche se la quantità di tempo che dedichi ad attività non di codifica dipenderà dalle dimensioni e dall'ambito del tuo progetto, dovresti essere preparato come manutentore a gestirle da solo o a trovare qualcuno che ti aiuti. + +**Se fai parte di un'azienda che offre un progetto open source,** assicurati che il tuo progetto disponga delle risorse interne necessarie per prosperare. Ti consigliamo di determinare chi è responsabile del mantenimento del progetto dopo il lancio e come condividerai tali attività con la tua comunità. + +Se hai bisogno di un budget o di personale dedicato per la promozione, le operazioni e la manutenzione del progetto, avvia queste conversazioni in anticipo. + + + +### Contributo ad altri progetti + +Se il tuo obiettivo è imparare a collaborare con gli altri o capire come funziona l'open source, valuta la possibilità di contribuire a un progetto esistente. Inizia con un progetto che già usi e che ti piace. Contribuire a un progetto può essere semplice come correggere un errore di battitura o aggiornare la documentazione. + +Se non sei sicuro di come iniziare come collaboratore, consulta la nostra [Come contribuire alla guida Open Source](../how-to-contribute/). + +## Inizia il tuo progetto open source + +Non esiste il momento perfetto per aprire la tua attività. Puoi rendere open source un'idea, in lavorazione o dopo anni di closed source. + +In generale, dovresti aprire il tuo progetto quando ti senti a tuo agio con gli altri che visualizzano e forniscono feedback sul tuo lavoro. + +Non importa in quale fase decidi di aprire il tuo progetto, ogni progetto deve includere la seguente documentazione: + +* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Code of conduct](../code-of-conduct/) + +In qualità di sostenitore, questi componenti ti aiuteranno a comunicare le aspettative, a gestire i contributi e a proteggere i diritti legali di tutti (inclusi i tuoi). Aumentano notevolmente le tue possibilità di un'esperienza positiva. + +Se il tuo progetto è su GitHub, posizionare questi file nella directory root con i nomi file consigliati aiuterà GitHub a riconoscerli e a mostrarli automaticamente ai tuoi lettori. + +### Selezione della licenza + +Una licenza open source garantisce che altri possano utilizzare, copiare, modificare e contribuire al tuo progetto senza conseguenze. Ti protegge anche da situazioni legali difficili. **Devi includere una licenza quando avvii un progetto open source.** + +Il lavoro legale non è divertente. La buona notizia è che puoi copiare e incollare una licenza esistente nel tuo repository. Ci vorrà solo un minuto per proteggere il tuo duro lavoro. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) e [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) sono le licenze open source più popolari, ma [ci sono altre opzioni](https://choosealicense.com), da qualle scegliere . + +Quando crei un nuovo progetto su GitHub, ti viene data la possibilità di scegliere una licenza. Includere una licenza open source renderà il tuo progetto GitHub open source. + +![Seleziona una licenza](/assets/images/starting-a-project/repository-license-picker.png) + +Se hai altre domande o dubbi sugli aspetti legali della gestione di un progetto open source, [ti abbiamo coperto](../legal/). + +### Scrivi README + +I README fanno molto di più che spiegare come utilizzare il tuo progetto. Spiegano anche perché il tuo progetto è importante e cosa possono farci i tuoi utenti. + +Nel README, prova a rispondere alle seguenti domande: + +* Cosa fa questo progetto? +* Perché è utile questo progetto? +* Come iniziare? +* Dove posso ottenere ulteriore aiuto se ne ho bisogno? + +Puoi utilizzare il file README per rispondere ad altre domande, ad esempio come gestisci i contributi, quali sono gli obiettivi del progetto e informazioni su licenza e attribuzione. Se non vuoi accettare contributi o il tuo progetto non è ancora pronto per la produzione, salva queste informazioni. + + + +A volte le persone evitano di scrivere un README perché pensano che il progetto sia incompiuto o non vogliono contributi. Questi sono tutti ottimi motivi per scriverne uno. + +Per ulteriore ispirazione, prova a utilizzare [la guida "Crea un README" di @dguo](https://www.makeareadme.com/) o [README nel modello](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) di @PurpleBooth per scrivere un completo README. + +Quando includi un file README nella directory root, GitHub lo visualizzerà automaticamente nella home page del repository. + +### Scrivi le linee guida per il tuo contributo + +Un file CONTRIBUTO indica al tuo pubblico come partecipare al tuo progetto. Ad esempio, puoi includere informazioni su: + +* Come inviare una segnalazione di bug (prova a utilizzare [modelli di richiesta problemi e pull](https://github.com/blog/2111-issue-and-pull-request-templates)) +* Come proporre una nuova funzionalità +* Come configurare il tuo ambiente ed eseguire i test + +Oltre ai dettagli tecnici, il file CONTRIBUTI è un'opportunità per comunicare le vostre aspettative per i contributi, come ad esempio: + +* I tipi di contributi che stai cercando +* La tua tabella di marcia o visione per il progetto +* Come i contributori dovrebbero (o non dovrebbero) contattarti + +Usare un tono caldo e amichevole e offrire suggerimenti specifici per i contributi (come scrivere documentazione o creare un sito web) può fare molto per far sentire i nuovi arrivati ​​benvenuti ed entusiasti di partecipare. +Per esempio [Active Admin](https://github.com/activeadmin/activeadmin/) inizia [la sua guida ai contributi](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) con: + +> Innanzitutto, grazie per aver considerato di contribuire ad Active Admin. Sono le persone come te che rendono Active Admin uno strumento così eccezionale. + +Nelle prime fasi del tuo progetto, il tuo file CONTRIBUTO può essere semplice. Dovresti sempre spiegare come segnalare bug o problemi, ed eventuali requisiti tecnici (come i test) per dare un contributo. + +Nel tempo, potresti aggiungere altre domande frequenti al tuo file CONTRIBUTING. Annotare queste informazioni significa che meno persone ti faranno sempre le stesse domande. + +Per ulteriore assistenza nella scrittura del file CONTRIBUTING, consulta @nayafia [modello guida per la collaborazione](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) o @mozilla ["Come creare CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). + +Collega il tuo file CONTRIBUTE dal tuo README in modo che più persone possano vederlo. Se [posiziona il file CONTRIBUTING nel repository del tuo progetto](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub si collegherà automaticamente al tuo file quando un collaboratore crea un problema o apre una richiesta pull. + +![Linee guida per i contributi](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Creazione di un codice di condotta + + + +Infine, un codice di condotta aiuta a definire le regole di base per la condotta dei partecipanti al progetto. Ciò è particolarmente utile se stai avviando un progetto open source per una comunità o un'azienda. Un codice di condotta ti consente di facilitare un comportamento sano e costruttivo nella comunità che ridurrà il tuo stress come sostenitore. + +Per ulteriori informazioni, consultare la nostra [Guida al Codice di condotta](../code-of-conduct/). + +Oltre a comunicare _come_ ci si aspetta che i partecipanti si comportino, un codice di condotta tende anche a descrivere a chi si applicano tali aspettative, quando si applicano e cosa fare se si verifica una violazione. + +Come per le licenze open source, esistono standard emergenti per i codici di condotta, quindi non è necessario scriverne uno proprio. Il [Contributor Covenant](https://contributor-covenant.org/) è un codice di condotta utilizzato da [oltre 40.000 progetti open source](https://www.contributor-covenant.org/adopters), incluso Kubernetes, Rails e Swift. Indipendentemente dal testo che utilizzi, devi essere pronto a far rispettare il tuo codice di condotta quando necessario. + +Incolla il testo direttamente in un file CODE_OF_CONDUCT nel tuo repository. Archivia il file nella directory principale del tuo progetto in modo che sia facile da trovare e collegalo dal tuo file README. + +## Assegna un nome e un marchio al tuo progetto + +Il branding è più di un logo appariscente o di un nome di progetto accattivante. Riguarda il modo in cui parli del tuo progetto e chi raggiungi con il tuo messaggio. + +### Scegliere il nome giusto + +Scegli un nome che sia facile da ricordare e che, idealmente, dia un'idea di ciò che fa il progetto. Per esempio: + +* [Sentry](https://github.com/getsentry/sentry) monitora le applicazioni di segnalazione degli arresti anomali +* [Thin](https://github.com/macournoyer/thin) è un server web Ruby facile e veloce + +Se stai sviluppando un progetto esistente, usare il loro nome come prefisso può aiutarti a chiarire cosa fa il tuo progetto (ad esempio [node-fetch](https://github.com/bitinn/node-fetch) porta `window.fetch` a Node.js). + +Pensa prima alla chiarezza. I giochi di parole sono divertenti, ma ricorda che alcune battute potrebbero non essere applicabili ad altre culture o persone con esperienze diverse dalle tue. Alcuni dei tuoi potenziali utenti potrebbero essere dipendenti dell'azienda: non vuoi farli sentire a disagio quando devono spiegare il tuo progetto al lavoro! + +### Evitare conflitti di nomi + +[Verifica la presenza di progetti open source con nomi simili](https://ivatomic.com/), soprattutto se condividi la stessa lingua o ecosistema. Se il tuo nome si sovrappone a un popolare progetto esistente, potresti confondere il tuo pubblico. + +Se desideri che un sito web, un account Twitter o altre proprietà rappresentino il tuo progetto, assicurati di poter ottenere i nomi che desideri. Idealmente, [salva questi nomi adesso](https://instantdomainsearch.com/) per la massima tranquillità, anche se non intendi ancora utilizzarli. + +Assicurati che il nome del tuo progetto non violi alcun marchio. Un'azienda potrebbe chiederti di rimuovere il tuo progetto in un secondo momento o addirittura intraprendere un'azione legale contro di te. Non vale la pena rischiare. + +Puoi controllare il [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) per eventuali conflitti tra marchi. Se lavori in un'azienda, questa è una delle cose in cui il tuo [team legale può aiutarti](../legal/). + +Infine, esegui una rapida ricerca su Google per il nome del tuo progetto. Le persone riusciranno a trovare facilmente il tuo progetto? C'è qualcos'altro che appare nei risultati di ricerca che non vuoi che venga visualizzato? + +### Anche il modo in cui scrivi (e codifichi) influisce sul tuo marchio! + +Nel corso della vita del tuo progetto, scriverai molto: README, tutorial, documenti della community, risposte a problemi, forse anche newsletter e mailing list. + +Che si tratti di documentazione formale o di un'e-mail informale, il tuo stile di scrittura fa parte del marchio del tuo progetto. Pensa a come potresti percepire il tuo pubblico e se questo è il tono che vuoi trasmettere. + + + +Usare un linguaggio caldo e inclusivo (come "loro" anche quando si riferisce a una sola persona) può fare molto per far sì che il tuo progetto si senta accogliente per i nuovi contributori. Attieniti a un linguaggio semplice poiché molti dei tuoi lettori potrebbero non essere di madrelingua inglese. + +Oltre al modo in cui digiti le parole, anche il tuo stile di codifica può diventare parte del marchio del tuo progetto. [Angular](https://angular.io/guide/styleguide) e [jQuery](https://contribute.jquery.org/style-guide/js/) sono due esempi di progetti con stili e linee guida di codifica rigorosi. + +Non è necessario scrivere una guida di stile per il tuo progetto quando hai appena iniziato e potresti scoprire che ti diverti comunque a incorporare diversi stili di codifica nel tuo progetto. Ma devi prevedere in che modo il tuo stile di scrittura e programmazione potrebbe attrarre o scoraggiare diversi tipi di persone. Le prime fasi del tuo progetto sono la tua opportunità per creare il precedente che desideri vedere. + +## La tua lista di controllo pre-lancio + +Pronto per aprire il tuo progetto? Ecco una lista di controllo per aiutarti. Seleziona tutte le caselle? Sei pronto per andare! [Fai clic su "pubblica"](https://help.github.com/articles/making-a-private-repository-public/) e datti una pacca sulla spalla. + +**Documentazione** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Код** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Хора** + +Se sei un privato: + +
+ + +
+ +Se sei un'azienda o un ente: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## Fallo! + +Congratulazioni per il tuo primo progetto open source. Qualunque sia il risultato, il servizio pubblico è un dono per la comunità. Con ogni coinvolgimento, commento e richiesta pull, crei opportunità per te e gli altri di apprendere e crescere. diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md new file mode 100644 index 00000000000..d1aa3c43487 --- /dev/null +++ b/_articles/ja/best-practices.md @@ -0,0 +1,276 @@ +--- +lang: ja +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) は、メンテナーとコントリビューターのための基本ルールを定めたプロジェクトの良い例です。 + +### コミュニケーションを公開しよう + +あなたのやり取りをドキュメント化することも忘れないようにしましょう。可能な限りどこでも、プロジェクトについてのコミュニケーションを公開しましょう。機能要望やサポートリクエストについてプライベートにコンタクトしてくる人がいたら、彼らをメーリングリストやイシュートラッカーのようなパブリックなコミュニケーションチャネルに丁寧に誘導しましょう。 + +他のメンテナーと会ったり、プライベートに大きな決断をしたりした場合は、これらの会話を公の場にドキュメント化しましょう。たとえ、メモ書きを投稿するだけだとしてもです。 + +このようにして、コミュニティに参加した人は誰でも何年も所属している人と同程度の情報にアクセスできるようになるでしょう。 + +## ノーと言うやり方を学ぼう + +ここまでで様々なものを明文化してきました。あらゆる人があなたのドキュメントを読んでくれるのが理想ですが、現実はドキュメントが存在することを伝える必要があるでしょう。 + +とはいえ、あらゆるものをドキュメント化する事は、ルールを遵守してもらう必要があるときに属人性を排除するのに役立ちます。 + +ノーと言うのは楽しいことではありません、しかし _「あなたのコントリビュートはこのプロジェクトの優先事項にはマッチしません。」_ という方が _「あなたのコントリビュートが好きではありません。」_ というよりも個人的でない印象になります。 + +メンテナーとして直面する様々な状況でノーを言う場面があります：プロジェクトのスコープに当てはまらない機能要望、議論を脱線させる人、他人のために不要な作業をすることなどです。 + +### 会話を友好的に保ちましょう + +ノーと言うことを実践する上で最も重要な場所の一つが、イシューやプルリクエスト上です。プロジェクトのメンテナーとして、受け入れたくない提案を受けることは避けられないでしょう。 + +そのコントリビュートはプロジェクトのスコープを変更してしまうか、ビジョンにマッチしないのかもしれません。アイデアは良くても、実装が良くないのかもしれません。 + +その理由にかかわらず、あなたのプロジェクトの基準を満たさないコントリビュートをそつなく対処する事は可能です。 + +もし受け入れたくないコントリビュートを受け取った場合は、あなたの最初の反応はそれを無視するか見なかったことにすることでしょう。そのようなことは他の人の感情を傷つけ、さらにコミュニティの中にいる潜在的なコントリビューターのやる気まで削いでしまいます。 + + + +望ましくないコントリビュートをオープンのまま放置しないようにしましょう。放置すると罪悪感を感じたり親切になろうとしてしまいます。時間が経つにつれて、回答されていないイシューやプルリクエストによって、プロジェクトを進めることがストレスを伴い、恐怖を感じるものになってしまいます。 + +受け入れるつもりのないコントリビュートはすぐに閉じてしまうのが良いです。もし既に膨大なバックログで困っているのであれば、 @steveklabnik の[イシューを効率的にトリアージする方法](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)が役に立つでしょう。 + +また、コントリビュートを無視することはコミュニティに悪い影響を与えます。プロジェクトにコントリビュートすることは威圧感があります。特に初めてのコントリビュートであればなおさらです。たとえ、そのコントリビュートを受け入れないとしても、その人に対して受け入れない旨と感謝の気持ちを伝えましょう。それは大きな賛辞となります！ + +もし、コントリビュートを受け入れたくないのであれば： + +* 彼らのコントリビュートに**感謝しましょう** +* なぜプロジェクトのスコープに**マッチしないか説明しましょう**。そして、可能であれば、明確な改善提案をしましょう。親切に、しかし確固たる態度で行いましょう。 +* もしあれば、**関連するドキュメントにリンクしましょう**。もし受け入れたくない内容が繰り返し提案されるようであれば、ドキュメントにその旨を追記して繰り返しの作業をなくしましょう。 +* **リクエストをクローズしましょう**。 + +1 ~ 2文以上の返答は不要です。例えば、 [celery](https://github.com/celery/celery/) のユーザーが Windows 関連のエラーを報告してきたときに、 @berkerpeksag は[このように返答しました](https://github.com/celery/celery/issues/3383)： + +![Celery screenshot](/assets/images/best-practices/celery.png) + +ノーと言うのが恐ろしいと感じるのはあなただけではありません。あなたは一人ではないのです。 @jessfraz も[こう書いています](https://blog.jessfraz.com/post/the-art-of-closing/)： + +> 私はこれまで Mesos や Kubernetes 、 Chromium といったオープンソースプロジェクトのメンテナーと話をしてきました。そして、彼ら全員が同意した事は、メンテナーとして最も難しいことの1つは、受け入れたくないパッチに対して「ノー」を言うことだ、という点です。 + +コントリビュートを受け入れたくないと思うことを罪に感じる必要はありません。オープンソースの第一のルールは、 @shykes [によると](https://twitter.com/solomonstre/status/715277134978113536)： _「ノーは一時的だが、イエスは永遠である」_ 。他の人の熱意に共感するのは良いことですが、コントリビュートを拒否することはその人自身を拒否することとは異なります。 + +最終的に、コントリビュートがあまり良くないものであれば、それを受け入れる義務はありません。人々がプロジェクトにコントリビュートしてくれたときには親切に、またきちんと返事をするようにしましょう。しかし、本当にプロジェクトのためになると思う変更のみを受け入れましょう。ノーと頻繁に言えば言うほど、それはより簡単になっていきます。約束します。 + +### 先回りしよう + +まず第一に不要なコントリビュートの量を減らすには、コントリビュートガイドでコントリビュートを提案するプロセスとコントリビュートを受け入れるプロセスを説明しましょう。 + +もし品質の低いコントリビュートを多く受け取るようであれば、コントリビューターに事前に確認してもらうよう要求しましょう。例えば： + +* イシューやプルリクエストのテンプレート/チェックリストを埋めてもらう +* プルリクエストを提出する前にイシューを開いてもらう + +もしあなたのルールに従わない人がいたら、即座にイシューを閉じてドキュメントを共有しましょう。 + +はじめはこのやり方は親切ではないと感じるかもしれませんが、先回りしておくことは両者にとって良いことなのです。コントリビュートする人にとっては、受け入れられる見込みのないプルリクエストに何時間も費やす機会が減ります。そして、あなた自身の作業量もやりくりしやすくなります。 + + + +時には、ノーということで、潜在的なコントリビューターが怒ったり決定を批判したりするかもしれません。もしそれらの行動が敵対的であれば、[状況を沈静化するために行動を起こす](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items)か、建設的に協調できないようであればコミュニティから抜けてもらいましょう。 + +### メンターシップを受け入れよう + +プロジェクトの基準に満たないコントリビュートを定期的に提出する人がいるかもしれません。何度も拒絶を経験するのはお互いにとってイライラするものです。 + +もしその人がプロジェクトに対して情熱があるけれども上達が必要だとわかっている場合は、辛抱強くなりましょう。プロジェクトの期待する水準になぜ満たないのかをそれぞれの状況ごとに明確に説明しましょう。より簡単な、もしくはより明確なタスクを紹介しましょう。例えば、手始めに取り掛かるのにちょうど良いイシューに _"good first issue,"_ ラベルを付けるといったことです。もし時間があるのであれば、初めてのコントリビュートを通じて彼らのメンターとなることも検討しましょう。もしくは、コミュニティの中で喜んでメンターとなってくれそうな人を探しましょう。 + +## コミュニティを活用しよう + +あらゆる事を一人で行う必要はありません。あなたのプロジェクトのコミュニティはそのためにあるのですから！たとえ現時点ではまだ活発なコントリビューターコミュニティが無かったとしても、たくさんのユーザーがいるのであれば、その人達に仕事をしてもらいましょう。 + +### 作業負荷を共有しよう + +もし他の人に支援してもらいたいなら、まずはお願いして回る所からはじめましょう。 + +新しいコントリビューターが繰り返しコントリビュートを行っていることに気づいたら、より大きい責任を提供することで彼らの仕事を認めましょう。望むならどのようにリーダーの役割を担えるよう成長出来るのかについてもドキュメント化しましょう。 + +他の人に対して[プロジェクトの所有権を共有する](../building-community/#プロジェクトの所有権を共有しよう)よう推奨することはあなたの作業負荷を大いに減らすことに繋がります。 @lmccart が彼女のプロジェクトである [p5.js](https://github.com/processing/p5.js) で認識したように。 + + + +もし、暫定的であれ恒久的であれ、あなたがプロジェクトから離れる必要があるのであれば、他の誰かに引き継ぎをお願いするのは少しも恥ずかしいことではありません。 + +もしプロジェクトの方向性に熱意を持っている人がいれば、その人にコミット権限を与えるか、公式にその人にプロジェクトの管理を引き渡しましょう。もしあなたのプロジェクトをフォークしている人がいて、フォーク先が活発にメンテナンスされているのであれば、あなたの元々のプロジェクトとフォーク先をリンクすることを検討しましょう。非常にたくさんの人々があなたのプロジェクトが生き続けて欲しいと望んでくれるのは素晴らしいことです！ + +@progrium が彼のプロジェクトである [Dokku](https://github.com/dokku/dokku) で[気づいたこととして](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/)、プロジェクトのビジョンをドキュメントに明記しておくことで、たとえ彼がプロジェクトから退いてもプロジェクトのゴールが生き続けたというものがあります： + +> 私は wiki に望むこととその理由を書きました。私にとって驚きだったのは、プロジェクトのメンテナーたちがその方向に向かい始めたことでした！私がやろうとしたことが実際に実現されたかって？常にそうだったわけではありません。しかし、それでも私が描いた理想像にプロジェクトが近づいていったのです。 + +### 他の人に彼らが必要な解決策を作ってもらおう + +もし潜在的なコントリビューターがあなたのプロジェクトがやるべきことについて異なる意見を持っているのであれば、彼ら自身のフォークを作ることを推奨するのも一つの手です。 + +プロジェクトをフォークすることは必ずしも悪いことではありません。プロジェクトをコピーしてそれを修正できるということはオープンソースの最も素晴らしい点の1つです。コミュニティメンバーに対して彼ら自身のフォークを作ることを推奨することで、あなたのプロジェクトのビジョンと衝突することなく、メンバーの創造性を発揮するはけ口を作り出すことが出来ます。 + + + +同じことが、あなたが構築する余裕の無い解決策を本当に望んでいるユーザーに対しても言えます。 API とカスタマイズのためのフックを提供することで、他の人が彼ら自身のニーズを、ソースコードを直接修正することなく実現する助けとなります。 @orta は CocoaPods 向けのプラグインを他の人に作ってもらうことで、「最も面白いアイデア」が出てきたと[言っています](https://artsy.github.io/blog/2016/07/03/handling-big-projects/)： + +> プロジェクトが大きくなっていくにつれて、メンテナーが新しいコードを追加することに対して保守的になっていくのはほぼ避けようがない。「ノー」ということが上手になっていくだろうが、多くの人は理にかなったニーズを持っています。そこで代わりに、あなたのツールをプラットフォーム化することになるのです。 + +## ロボットを使おう + +他の人に手伝ってもらえるタスクがたくさんあるのと同様に、人間がやる必要のないタスクも多数あります。ロボットは友達です。ロボットを使うことでメンテナーとして過ごす日々を楽にしましょう。 + +### コードの品質を向上させるためにテストやチェックを要求しよう + +プロジェクトを自動化する最も重要な方法の1つは、テストを追加することです。 + +テストがあることで、コントリビューターは何一つ壊していない事を自信を持って確認することができます。また、あなたにとっても、コントリビュートをすばやくレビューし取り込みやすくなります。より早く反応すればするほど、コミュニティもより活発になるのです。 + +全てのコントリビュートに対してテストを自動的に実行するように設定し、またコントリビューターがローカルで簡単にテストを実行できるようにしておきましょう。コントリビュートが提出される前に全てのテストが成功している事を要求しましょう。こうすることで、全てのコントリビュートが提出される前に、最低限の品質基準を設けることができるようになります。 GitHub の [Required status checks](https://help.github.com/articles/about-required-status-checks/) 機能を使うことで、テストが成功していない変更はマージされないよう保証することができます。 + +テストを追加したら、 CONTRIBUTING ファイルでテストがどう実行されるかを説明しましょう。 + + + +### ツールを使って基本的なメンテナンス作業を自動化しよう + +人気のあるプロジェクトをメンテナンスすることについての良いニュースとしては、他のメンテナーも似たような問題に直面し、そのための解決策を作っているということです。 + +メンテナンス作業の一部を自動化するために、[非常に幅広いツール](https://github.com/showcases/tools-for-open-source)があります。幾つか例を挙げましょう： + +* [semantic-release](https://github.com/semantic-release/semantic-release) はリリースを自動化します +* [mention-bot](https://github.com/facebook/mention-bot) はプルリクエストのレビュアーになってくれる可能性のある人にメンションを送ります +* [Danger](https://github.com/danger/danger) はコードレビューを自動化します + +バグ報告や他のよくあるコントリビュートに対しては、 GitHubに [イシューテンプレートとプルリクエストテンプレート](https://github.com/blog/2111-issue-and-pull-request-templates) という機能があります。これを使うことで、コミュニケーションを簡素化することができます。 @TalAter はイシューやプルリクエストのテンプレートを作成する助けとなるよう、 [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) を作りました。 + +メール通知を管理する際、優先順位を設定するために[メールフィルター](https://github.com/blog/2203-email-updates-about-your-own-activity)を使うことができます。 + +更に発展させたいのであれば、スタイルガイドやリンターを使うことで、プロジェクトへのコントリビュートを標準化し、レビューや取り込みを簡単にできます。 + +しかし、あなたが設定した標準が複雑すぎると、コントリビュートへの障壁が高くなってしまいます。皆の作業を簡単に行うために十分なルールだけを追加するように気をつけましょう。 + +どのツールを使うべきかわからないのであれば、他の有名なプロジェクトがどのようにしているかを探してみましょう。特に、同じエコシステムのプロジェクトを見てみましょう。例えば、他の Node モジュールではコントリビュートプロセスをどのようにしているでしょうか？他のプロジェクトと似たようなツールや方法を使うことで、ターゲットとするコントリビューターがコントリビュートプロセスに親しみやすくなります。 + +## 活動停止しても良い + +オープンソース活動はかつては喜びをもたらしてくれました。しかし今となっては辞めたいと感じていたり、うしろめたい気持ちになっているかもしれません。 + +おそらく、あなたは困惑しているか、プロジェクトについて考えるのが怖いと感じているかもしれません。その間にも、イシューやプルリクエストは積み上がっていくのです。 + +オープンソース活動において、燃え尽きてしまうことは特にメンテナーの間で現実に発生し、よく起きることなのです。メンテナーとしてあなた自身が幸福であることは、オープンソースプロジェクトが生き残る上で交渉の余地なく必要なことです。 + +言うまでもないことですが、休みを取りましょう！バケーションを取るのに、燃え尽きたと感じるまで待つ必要はないのです。 Python のコア開発者である @brettcannon は、14年間に及ぶ OSS ボランティア活動を経て、[1ヶ月の休みを取る](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/)ことを決断しました。 + +他の仕事と同じように、休みを取ることでリフレッシュし、幸せを感じ、仕事に熱中できるのです。 + + + +時には、皆があなたを必要としていると感じられて、オープンソース活動を休むのは難しいと感じることがあるかもしれません。あなたが退くことに対して、罪悪感を感じさせようとする人さえいるかもしれません。 + +プロジェクトから離れる間にユーザーやコミュニティをサポートしてくれる人を探すために最善を尽くしましょう。もし必要なサポートを見つけられなかったとしても、とにかく休みを取りましょう。不在のときはきちんとその旨を共有しましょう。そうすることで、あなたからの返答がないことで人々を困惑させることもありません。 + +休みを取ることはバケーションを取ることだけではありません。もし週末であったり、業務時間中にはオープンソース活動をやりたくないのであれば、他の人にその希望を共有しましょう。そうすることで、彼らはあなたを悩ませないようにしてくれるでしょう。 + +## まずはじめに自分を労ろう！ + +人気のあるプロジェクトをメンテナンスすることは、成長の初期ステージに必要なものとは異なるスキルが必要となります。しかし、それはなおも報われるものです。メンテナーとして、ごくわずかな人しか経験できないレベルのリーダーシップと個人スキルを実践することになります。常に簡単に対処できる訳ではありませんが、明確に線引をし、あなたが心地よく感じることだけを行うようにすることで、幸福でリフレッシュしていて、生産的な状態を維持する助けとなるのです。 diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md new file mode 100644 index 00000000000..22a34b08a22 --- /dev/null +++ b/_articles/ja/building-community.md @@ -0,0 +1,275 @@ +--- +lang: ja +title: 居心地の良いコミュニティを築こう +description: 人々があなたのプロジェクトを使ったり、コントリビュートしたり、人に伝えたくなるようなコミュニティを築きましょう。 +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## あなたのプロジェクトの成功のためのお膳立てをしよう + +プロジェクトを立ち上げ、言葉を広め、人々は注目しています。素晴らしい！さて、彼らに定着してもらうにはどうしたら良いでしょうか？ + +居心地の良いコミュニティを作り上げることによって、プロジェクトの未来や評判に投資することができます。プロジェクトで初めてのコントリビュートが行われるようになってきたら、初期のコントリビューターにポジティブな経験を与え、再度プロジェクトを訪れるようにしましょう。 + +### 歓迎の気持ちを伝えよう + +プロジェクトのコミュニティについて考える一つの方法として、 @MikeMcQuaid が [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) と呼ぶものを使ってみましょう: + +![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +コミュニティを築く際、漏斗の一番上にいる人（潜在的なユーザー）が一番下（活動的なメンテナー）に向かってどのように理論的に進むのかを考えましょう。あなたのゴールは、コントリビューターが各段階で経験する障害を減らすことです。もし簡単に進めるようになれば、より多くのことをしたいと思うようになるでしょう。 + +まずはドキュメント化から始めましょう： + +* **あなたのプロジェクトを使いやすくしよう** [親切な README](../starting-a-project/#readme-を書く) とわかりやすいコードの例によって、あなたのプロジェクトに着手した人が使い始めやすくなります。 +* **コントリビュートの仕方をわかりやすく説明しよう**。その際、 [CONTRIBUTING ファイルを使い](../starting-a-project/#コントリビュートのガイドラインを書く)、イシューの状態を最新に保ちましょう。 + +[GitHub の 2017 Open Source Survey](http://opensourcesurvey.org/2017/) では、未完成であったり混乱するドキュメントはオープンソースプロジェクトのユーザーにとって最大の問題である事が示されています。良いドキュメントが人々をあなたのプロジェクトに招き入れます。結果として、イシューやプルリクエストを登録する人が出てきます。こういったやり取りを、漏斗の底に近づいてもらう機会として利用しましょう。 + +* **新しくプロジェクトに参加してくれた人に対して、興味を示してくれたことへの感謝の気持ちを伝えよう！** 一度ネガティブな経験をしただけで、人は戻ってきてくれなくなってしまいます。 +* **すぐに返事を返すようにしよう。** 一ヶ月もの間イシューに返事をしなければ、おそらく彼らはあなたのプロジェクトのことを忘れ去ってしまうでしょう。 +* **受け入れるコントリビュートの種類について心を広く持とう。** 多くのコントリビューターがバグレポートや小さな修正から始めます。プロジェクトへの[コントリビュートには多くのやり方](../how-to-contribute/#コントリビュートするということが意味するもの)があります。人々が望むやり方でコントリビュートできるように手助けしましょう。 +* **受け入れられないコントリビュートがあった場合は、** そのアイデアに感謝を示しつつ、なぜプロジェクトのスコープから外れているのかを[説明しましょう](../best-practices/#ノーと言うやり方を学ぼう)。その際、関連するドキュメントも共有しましょう。 + + + +オープンソースのコントリビューターの大部分は「通りすがりのコントリビューター」です：彼らはプロジェクトへのコントリビュートを時々するだけの人々です。通りすがりのコントリビューターはあなたのプロジェクトに十分に理解する時間がないかもしれないため、彼らがコントリビュートしやすくするべきです。 + +他のコントリビューターを励ますことはあなた自身への投資にもなります。あなたの大ファンにワクワクする仕事をする裁量を与えることで、自分であらゆる仕事をやらないといけないというプレッシャーを減らすことができます。 + +### あらゆる事を記録しよう + + + +新しいプロジェクトを始めるときは、あなたのやっていることを秘密にしておきたいと感じるのは当然です。しかし、オープンソースプロジェクトはその過程を公開して記録することで成長していきます。 + +文書に記録することで、より多くの人がその過程の各ステップに参加することができます。それによって、必要だと思っていなかったことまでも助けてもらえるかもしれません。 + +文書に記録するというのは技術的なドキュメントに限った話ではありません。何かを書き留めておきたいという衝動を感じたり、プロジェクトについて非公式に議論するときはいつでも、それを公開できないか自問してみましょう。 + +プロジェクトのロードマップ、求めているコントリビュートの種類、コントリビュートがどのようにしてレビューされるか、ある決断をした理由といった情報の透明性を高めておきましょう。 + +もし複数のユーザーが同じ問題に遭遇しているのであれば、その解決策を README に書きましょう。 + +ミーティングに関しては、あなたのメモや学びを関連するイシューで公開することを検討しましょう。このレベルの情報の透明性によって得られるフィードバックにあなたは驚くかもしれません。 + +あらゆる事を記録するというのはあなた自身の作業についても当てはまります。プロジェクトにおいてなにか大きなアップデートに取り組んでいる場合、プルリクエストを作成し、作業中（ WIP ）という印をつけましょう。その方が、他の人がプロセスの早い段階から一緒に取り組んでいると感じることができます。 + +### すぐに反応しよう + +[プロジェクトの存在を周知していく](../finding-users)につれて、人々からのフィードバックをもらうことになるでしょう。どのように動作しているのか質問があるかもしれないし、始めるにあたって助けを求めているかもしれません。 + +イシューが登録されたり、プルリクエストが提出されたり、プロジェクトについて質問を受けた場合はすぐに反応するようにしましょう。素早く返事をすれば、人々は会話に参加していると感じ、より熱心に参加してくれるでしょう。 + +たとえすぐにプルリクエストのレビューをできない場合であっても、その旨を素早く伝える事で繋がりを強めることができます。@tdreyno が [Middleman](https://github.com/middleman/middleman/pull/1466) のプルリクエストに対し、どのように返答しているかを見てみましょう： + +![Middleman pull request](/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 といったインターネットにおける他の場所でもあなたのプロジェクトについての会話が交わされることがあります。そのような場所からも通知が来るよう設定しておくことで、誰かがあなたのプロジェクトに言及したときに通知を受け取ることができます。 + +### コミュニティに集いの場を作ろう + +コミュニティに集いの場を作るのには2つの理由があります。 + +1つ目はコミュニティメンバーのためです。人々が互いに知り合うのを助けましょう。共通の興味を持つ人々は、当然それについて会話する場を求めるでしょう。そして、そのコミュニケーションが公開されていてアクセスできるのであれば、誰でも過去のアーカイブを読むことで最新の情報に追いつき参加することができます。 + +2つ目の理由はあなたのためです。プロジェクトについて会話する公の場を作らなければ、あなたに直接コンタクトが来るようになるでしょう。初めは、「今回だけ」とプライベートメッセージで反応するのも十分簡単かもしれません。しかし時間が経つにつれ、特にあなたのプロジェクトが有名になると、あなたは疲れ切ってしまうでしょう。あなたのプロジェクトについて人々とプライベートにコミュニケーションしたいという衝動に抵抗しましょう。かわりに、プロジェクト用の公開チャンネルに誘導しましょう。 + +公の場でコミュニケーションすることは、あなたに直接メールを送ったり、ブログにコメントする代わりにイシューを開いてもらうように人々を誘導するのと同じ位簡単なことです。また、メーリングリストを設定したり、 Twitter アカウント、 Slack、 IRC チャンネルなどを作って、プロジェクトについての会話を可能にすることもできます。もしくは、それを全部やってもよいのです！ + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) は、コミュニティメンバーを助けるために隔週でオフィスアワーを設定しています： + +> Kops はコミュニティを支援しガイダンスを提供するために隔週で時間を設けています。Kops のメンテナーは、新しく参加した人との共同作業、プルリクエストの支援、新機能についての議論に時間を確保することに同意しています。 + +公の場でのコミュニケーションにも注意すべき例外があります：1) セキュリティに関するイシューや 2) 慎重に扱うべき行動規範への違反です。こういったイシューに関しては、内密に報告する手段を常に用意しておくべきです。あなた個人のメールを使いたくない場合は、専用のメールアドレスを確保しましょう。 + +## コミュニティを発展させよう + +コミュニティは非常にパワフルです。このパワーは使い方によっては恵みにもなりえますし、災いにもなりえます。プロジェクトのコミュニティの発展にあたり、それが破壊的な力ではなく生産的な力にする方法があります。 + +### 悪い参加者を許容しない + +どんな人気のあるプロジェクトにおいても、コミュニティの助けになるよりも害をなす人々を引き寄せてしまうことは避けられないでしょう。彼らは不要な議論をし始めたり、些末な機能に難癖をつけたり、他の人を脅したりするかもしれません。 + +こういった類の人々に対しては、ゼロ・トレランスポリシー（訳注：1990年代にアメリカで始まった教育方針の一つ。ポリシー違反には厳密に処分を行う）を適用することに最善を尽くしましょう。もし放置されてしまうと、有害な人々によって、コミュニティ内の人々は居心地が悪いと感じてしまうでしょう。コミュニティを去ってしまいさえするかもしれません。 + + + +プロジェクトの些末な点について議論することが日常的になってしまうと、あなたを含むプロジェクトの人々が重要なタスクに集中することから気が逸れてしまいます。新たにあなたのプロジェクトにやってきた人もこういった議論を見て、参加したくないと思うかもしれません。 + +もしあなたのプロジェクトで有害な行動を見つけたら、公の場で指摘しましょう。温和ながらも断固たるトーンで、なぜその行動が受け入れられないのか説明しましょう。もし問題が続くようであれば、[彼らに立ち去るように言う](../code-of-conduct/#行動規範を遵守してもらおう)必要があるかもしれません。[行動規範](../code-of-conduct/)は、こういった会話を生産的にする助けになりえます。 + +### コントリビューターを出迎えよう + +優れたドキュメントは、コミュニティが成長するにつれてより重要になります。あなたのプロジェクトに精通していない通りすがりのコントリビューターは、ドキュメントを読むことで必要とする周辺知識を得ることができます。 + +CONTRIBUTING ファイルに、新しいコントリビューターに始め方を明示しましょう。この説明のために専用のセクションを作成したいとさえ思うかもしれません。例えば [Django](https://github.com/django/django) は、新しいコントリビューターを迎えるためのランディングページを用意しています。 + +![Django new contributors page](/assets/images/building-community/django_new_contributors.png) + +イシューのリストにおいて、バグに対してコントリビューターの種類に応じたラベル付けをしましょう：例えば、 [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only) や _"good first issue"_ 、 _"documentation"_ といったものです。[こういったラベル](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14)によって、あなたのプロジェクトに詳しくない人がイシューをざっと目を通してコントリビュートを始める事が簡単になります。 + +最後に、あらゆるステップにおいて歓迎されていると人々に感じてもらえるようにドキュメントを活用しましょう。 + +プロジェクトを見たほとんどの人はあなたとやり取りすることはないでしょう。人々は恐れを感じたり、どのように始めたらよいかわからないといった理由で、コントリビュートをやめたかもしれません。そういった場合でも、ほんの少しでも彼らを歓迎する言葉があれば、彼らがイライラしてプロジェクトを去ってしまう事を防ぐことができます。 + +これは [Rubinius](https://github.com/rubinius/rubinius/) の[コントリビュートガイド](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md)の書き出しの例です： + +> まず最初に、Rubinius を使ってくれてありがとうとお伝えしたいと思います。このプロジェクトは愛の結晶であり、バグを見つけてくれたり、性能を向上させたり、ドキュメントを書くことを手伝ってくれる全てのユーザーに感謝しています。あらゆるコントリビュートには意味があるので、参加してくれることに感謝しています。そうは言っても、私達があなた達の問題に首尾よく取り組む事ができるように、いくつかのガイドラインに従うようお願いしたいと思います。 + +### プロジェクトの所有権を共有しよう + + + +人々は、自分にもプロジェクトの所有権があるという感覚を持つときに、コントリビュートすることにワクワクしてくれます。これはあなたが望まない方向にプロジェクトのビジョンを切り替えたり、望まないコントリビュートを受け入れるということではありません。しかし、他者を信用すればするほど、彼らはよりプロジェクトに留まってくれるようになるでしょう。 + +コミュニティの人々に所有権を共有する方法があるかどうか可能な限り検討しましょう。以下にいくつかアイデアを挙げます： + +* **簡単な（致命的でない）バグを直すのを我慢しよう。** 代わりに、そのバグを新しいコントリビューターを募集したり、コントリビュートしたいと思っている人を指導したりするために活用しましょう。初めは不自然に感じるかもしれませんが、時間が経てばその投資の効果が表れるでしょう。例えば、 @michaeljoseph は以下の [Cookiecutter](https://github.com/audreyr/cookiecutter) のイシューに対して、彼自身で修正するのではなく、プルリクエストを送ってもらうよう求めています。 + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **CONTRIBUTORS ファイルや AUTHORS ファイルをプロジェクトに作ろう。** [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) が実施しているように、これらのファイルにプロジェクトにコントリビュートしてくれた人すべてをリストしましょう。 + +* かなり大きなコミュニティを既に獲得しているのであれば、コントリビューターへの感謝を伝える **ニュースレターを送ったり、ブログポストを書いたりしましょう。** Rust の [This Week in Rust](https://this-week-in-rust.org/) や Hoodie の [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) はどちらも良い事例です。 + +* **全てのコントリビューターにコミット権限を与えよう。** @felixge はこれによって人々が [パッチに磨きをかけることによりワクワクするようになる](https://felixge.de/2013/03/11/the-pull-request-hack.html)ことに気づき、更にしばらくの間取り組んでいなかったプロジェクトの新しいメンテナーを見つけることさえできたのです。 + +* もしプロジェクトが GitHub 上にあるのであれば、 **プロジェクトをあなた個人のアカウントから [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** に移し、最低でも一人代わりの管理者を追加しましょう。 Organization によって外部の協力者と一緒にプロジェクト上での作業をしやすくなります。 + +実際のところ、[ほとんどのプロジェクトはたった](https://peerj.com/preprints/1233/) 一人か二人のメンテナーしかおらず、彼らがほとんどの作業を行っています。プロジェクトやコミュニティが大きくなるほど、協力者を見つけるのがより簡単になります。 + +常に要求に応じてくれる人が見つかるとは限りませんが、そういったシグナルを出しておくことで、協力してくれる人が出てくるチャンスが増えます。そしてより早く始めると、より早く人々が助けてくれるでしょう。 + + + +## 衝突を解消しよう + +プロジェクトの初期段階では、大きな決定をするのは簡単です。もし何かをやりたいのであれば、行動あるのみです。 + +プロジェクトが有名になるにつれて、人々はあなたが下す決定に興味を持ち始めます。たとえ大きなコントリビューターのコミュニティがなかったとしても、たくさんのユーザーがいるのであれば、人々が決断について考えていたり、彼ら自身の問題を提起したりしていることに気づくでしょう。 + +ほとんどの場合、友好的で互いを尊重するコミュニティを作り上げ、プロセスを公開して記録してきているのであれば、コミュニティによって解決策を見つけることができるようになっているはずです。しかし、時々解決するのがやや難しい問題に遭遇することがあるでしょう。 + +### 親切さの基準を設けよう + +コミュニティの人々が難しい問題に取り組んでいるときは、カッとなりやすくなるものです。人々は怒ったりイライラして、他の誰か、もしくはあなたに八つ当たりするかもしれません。 + +メンテナーとしてのあなたの仕事はこういった状況が悪化しないようにすることです。たとえあなたがそのトピックについて強い意見を持っていたとしても、争いに飛び込んであなたの意見を押し付けるのではなく、調停役やファシリテーターとして振る舞うようにしましょう。もし誰かが不親切であったり会話を独り占めしたりしている場合は、議論を市民的かつ生産的に保つために[即座に行動しましょう](../building-community/#悪い参加者を許容しない)。 + + + +他の人々はあなたの指導を求めています。良い手本を示しましょう。がっかりしていたり、良い気分でなかったり、心配したりしている事を表明することもできますが、その場合も穏やかに行うようにしましょう。 + +常に冷静でいるのは簡単なことではありませんが、リーダーシップを示すことで、コミュニティの健全性を向上させることができます。インターネット上の人々はあなたに感謝することでしょう。 + +### README を憲法のように扱おう + +README は[単なる手順書以上の存在です](../starting-a-project/#readme-を書く)。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/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md new file mode 100644 index 00000000000..91fa5226cbb --- /dev/null +++ b/_articles/ja/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: ja +title: 行動規範 +description: 行動規範を採用し遵守してもらうことで、健全で建設的なコミュニティ作りを促進しよう。 +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## なぜ行動規範が必要なのか？ + +行動規範は、あなたのプロジェクトの参加者に期待する振る舞いをまとめたドキュメントです。行動規範を採用し遵守してもらうことで、コミュニティにポジティブな雰囲気をもたらす事ができます。 + +行動規範は、コミュニティの参加者だけでなく、あなた自身を守ることにも役に立ちます。もしあなたがメンテナーなのであれば、参加者の生産的でない態度に対処することに疲れを感じ、不幸せだと感じることでしょう。 + +行動規範は、健全で生産的なコミュニティ作りを促進する助けとなります。事前に行動規範を決めておくことで、あなた自身やプロジェクトの参加者が疲れ果ててしまう可能性を下げることができ、あなたが好ましいと思わない事が起きたときに、それに対して行動を起こす助けとなります。 + +## 行動規範を制定しよう + +できるだけ早い段階で行動規範を制定しましょう： 理想的にはプロジェクトを始めに立ち上げるときに作りましょう。 + +あなたの期待することを伝えることに加えて、行動規範には下記の内容も記述しましょう: + +* 行動規範が有効な範囲はどこまでか _(イシューやプルリクエスト上だけで有効なのか、それともイベントのようなコミュニティ活動でも有効なのか？)_ +* 行動規範が適用されるのは誰か _(コミュニティメンバーやメンテナー以外にもスポンサーも適用範囲なのか？)_ +* 行動規範に違反したら何が起きるのか +* 違反はどのようにして報告するのか + +できる限り、既存の行動規範を使いましょう。 [Contributor Covenant](https://contributor-covenant.org/) は40,000以上のオープンソースプロジェクトで使われている行動規範で、 Kubernetes 、 Rails 、 Swift でも使われています。 + +[Django Code of Conduct](https://www.djangoproject.com/conduct/) や [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) の2つもよく使われる行動規範です。 + +CODE_OF_CONDUCT ファイルをプロジェクトのルートディレクトリに置き、 CONTRIBUTING や README ファイルからリンクを張ってコミュニティの皆がすぐに見れるようにしましょう。 + +## どのように行動規範を遵守してもらうかを決めよう + + + +行動規範の違反が発生する **前に** どのように行動規範を遵守してもらうかを説明するべきです。そうするべき理由はいくつかあります： + +* 必要な時にはあなたが行動を起こすということに本気であるということを示す事ができる。 + +* 不平不満に対して実際にレビューが入ることで、コミュニティのメンバーを安心させることができる。 + +* コミュニティのメンバーたちに対して違反について調査をするときに、レビュープロセスが公正で透明性の高いものであると安心させることができる。 + +メンバーに対しては、行動規範の違反を報告するための（メールアドレスのような）プライベートな方法を与え、それを受け取るのが誰なのかを説明するべきです。それは一人のメンテナーかもしれないし、メンテナー達のグループかもしれないし、行動規範チームかもしれません。 + +行動規範違反の報告を受けている人自身の違反行為を、誰かが報告するかもしれないことを忘れてはいけません。この場合は、他の人に違反を報告できるような選択肢を設けましょう。例えば、 @ctb と @mr-c は、彼らの [khmer](https://github.com/dib-lab/khmer) というプロジェクトで[このように説明しています](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst): + +> 不正行為やハラスメント、受け入れられない行為は、 **khmer-project@idyll.org** にメールを送ることによって報告することが出来ます。このメールは、 C. Titus Brown と Michael R. Crusoe のみが受け取ります。彼ら二人のどちらかが関係する問題について報告する場合は、 NSF Center for Science and Technology の BEACON Center for the Study of Evolution in Action のダイバーシティディレクターの **Judi Brown Clarke, Ph.D.** にメールで報告して下さい。* + +他にも Django の [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) も参考になります （ただし、プロジェクトのサイズによってはここまで網羅したものは必要ないかもしれません）。 + +## 行動規範を遵守してもらおう + +どんなに努力したとしても、時には行動規範を違反するような行為をする人も出てきます。こういったネガティブで害のある行為を解決する方法は幾つかあります。 + +### 状況についての情報を集めよう + +コミュニティメンバーの声を、あなた自身の意見と同じくらい大事に扱いましょう。誰かが行動規約に違反していると報告を受けたら、たとえあなた自身の経験と照らし合わせてその人らしくないと感じたとしても、報告を真剣に受け止め調査しましょう。そうすることでコミュニティに対して、コミュニティメンバーのものの見方に価値を見出しており、またコミュニティメンバーの判断を信頼しているという事を示すことが出来ます。 + +疑いのあるメンバーは、何度も人を不愉快にさせている人かもしれないし、一度だけやってしまった人かもしれません。状況によってはどちらも行動が必要な理由になります。 + +行動を起こす前に、時間を取って何が起きたのか理解しましょう。その人の過去のコメントや会話に目を通して、彼らがどういった人物でなぜそういった行動に出たのかを良く理解しましょう。その人自体やその人の行動に関して、あなたの観点よりも他の人の観点をより集めましょう。 + + + +### 適切な行動を取ろう + +十分な情報を集めて処理したら、何をするか決める必要があります。次のステップを考える際に覚えておく必要があるのは、調整役としてのあなたのゴールは、安全でお互いを尊重しあえる協力的な環境を推進する事であるということです。問題となっている状況にどのように対処するかだけでなく、あなたの対応が今後どのようにコミュニティの残りのメンバーの行動や期待に影響するかを考える必要があります。 + +行動規約に対する違反が報告されたら、それに対処するのは報告した人ではなくあなたの仕事です。報告者は彼ら自身のキャリアや名声、物理的な安全性をリスクにさらしてまで報告をしていることもあるのです。そんな彼らを違反者に直面させてしまえば、報告者は妥協せざるを得なくなります。そのため、報告者が明確に望まない限りは、あなたが問題の人物と直接やり取りをするべきです。 + +行動規約を違反した人に対しての対処法はいくつかあります: + +* **公の場で問題の人物に警告を与え**、彼らの行動がどのように他の人に対して悪い影響を与えているかを、できるだけ問題が起きたチャネル上で説明しましょう。公の場でのやり取りは、コミュニティの残りのメンバーに対して、あなたが行動規約を重要なものだと捉えている事を示すことが出来ます。丁寧に、しかしはっきりとした態度でコミュニケーションしましょう。 + +* **問題の人物に個別に連絡を取り**、彼らの行動がどのように他の人に対して悪い影響を与えているかを説明しましょう。取扱に注意が必要な個人情報を含んでいる場合には、個別のコミュニケーションチャネルを使いたいと思うでしょう。もし個別でやり取りをするのであれば、最初に問題を報告した人を CC に入れるのは良い考えです。そうすることで、報告者に対して行動を取っているということを知らせることができるためです。ただし、報告者を CC に入れる前に彼らに同意を取りましょう。 + +時には解決に至らないこともあります。問題の人物が攻撃的になったり、対面したときに悪意をむき出しにしたり、振る舞いを改めなかったりするかもしれません。そういった場合には、より強い行動に出る必要があるかもしれません。例えば： + +* プロジェクトにおける問題の**人物の活動を一時停止させる**。そのために、一時的にプロジェクトのあらゆる活動に参加するのを拒否しましょう。 + +* 問題の人物をプロジェクトから**永久に追放する**。 + +メンバーをプロジェクトから追放するのは軽々しく行うべきではありません。それは、考え方の違いが今後もずっと続くということを意味するからです。こういった措置は、明らかに問題が解決できない場合にのみ取るようにしましょう。 + +## メンテナーとしての責任 + +行動規約は、勝手に施行される法規とは異なります。あなたが行動規範の施行者であり、行動規範が定めているルールに従ってもらうようにするのはあなたの責任なのです。 + +メンテナーとして、あなたはコミュニティのガイドラインを定め、そのルールを行動規範の中で定めることによってガイドラインを遵守させるのです。こうすることで、行動規範に対する違反を報告することが重要であると示すことが出来るのです。報告者は、彼らの苦情を徹底的かつ公正にレビューをするべきです。報告された行動が行動規範に違反していないと判断するのであれば、報告者に対してはっきりとそれを伝え、なぜそれに対して対処を取るつもりがないのかを説明しましょう。それに対して報告者がどうするかは彼ら次第です： 問題だと思っている行動を我慢するか、それともそのコミュニティに参加するのを辞めるかです。 + +_厳密には_ 行動規範を違反していない行動に対して報告があった場合、コミュニティに問題があるということを示しているかもしれません。そのため、この潜在的な問題を調査し、相応の対処をするべきです。相応の対処とは、受け入れられる行動をより明確にするために行動規範を書き換える事かもしれないし、報告された人物に対して、彼らが行動規範を違反しているわけではないが、期待される行動のぎりぎりの行動をとっており、ある人を不愉快にさせているということを伝えることかもしれません。 + +以上のように、あなたはメンテナーとして、受け入れられる振る舞いについての基準を定め、それを遵守させているのです。あなたにはプロジェクトの価値観を定める資格があり、プロジェクトの参加者はそれらの価値観を公明正大なやり方で遵守することを期待しているのです。 + +## あなたが世界中で見たいと望む行動を推奨しましょう 🌎 + +プロジェクトが友好的でなく歓迎的でもない場合、皆が我慢している人物がたった一人しかいなかったとしても、コントリビューターの多くを失うリスクを抱えているのです。そのうちの何人かは一度も会ったことがないかもしれません。行動規範を採用して遵守させるのは必ずしも簡単なことではありません。しかし、歓迎的な環境を育てていくことはコミュニティを成長させる役に立つでしょう。 diff --git a/_articles/ja/finding-users.md b/_articles/ja/finding-users.md new file mode 100644 index 00000000000..7dfc476f9f2 --- /dev/null +++ b/_articles/ja/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: ja +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 の ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) に目を通してみましょう。これはユーザーペルソナを作る練習になります。 + +## 人々にあなたのプロジェクトを見つけてフォローしてもらいやすくしよう + + + +単一の名前空間に向かわせることで、人々がプロジェクトを見つけて覚えてもらいやすくしましょう。 + +**あなたの作業を宣伝するためにわかりやすいハンドルを使いましょう** Twitter のハンドル、 GitHub の URL や IRC チャンネルは、あなたのプロジェクトを人々に示す事ができる簡単な方法です。こうした場所は、拡大するコミュニティに対して集まる場所を提供することにもなります。 + +もしそういった場所を作るにはまだ早いと思うのであれば、あなた自身の Twitter やあなたが実際に活動している GitHub のハンドルを宣伝しましょう。あなたの Twitter や GitHub のハンドルを宣伝することで、人々はどうやってあなたに接したり、あなたの仕事をフォローできるのか知ることができます。もしミートアップやイベントで発表するのであれば、自己紹介やスライドに連絡先情報を含めているか確認しましょう。 + + + +**ウェブサイトを作ることを検討しましょう** ウェブサイトを作ることで、あなたのプロジェクトはより友好的で簡単に誘導することができます。特にそのウェブサイトにわかりやすいドキュメントとチュートリアルがあればなおさらです。ウェブサイトがあることで、あなたのプロジェクトが活動をしているということも示すことができます。これによって、プロジェクトを見ている人は安心して使うことができるようになります。あなたのプロジェクトをどのように使うのかの例も提供しましょう。 + +Django の共同作者の [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) は、 _「ウェブサイトを作ったことは 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 のデータサイエンスコミュニティと知り合いになりましょう。人々があなたのことを知るにつれて、あなたのやっていることについて話して共有する機会が自然とやってくるでしょう。 +* **あなたのプロジェクトが解決する問題に遭遇している人を探そう。** あなたのプロジェクトのターゲットに該当する人をフォーラムを通して探しましょう。彼らの質問に答え、機転を利かせて適切なタイミングで、あなたのプロジェクトが解決策となることを提案しましょう。 +* **フィードバックを求めよう。** あなたのプロジェクトが適切であり面白いと感じてくれるであろう人々に対して、あなた自身とあなたのプロジェクトを紹介しましょう。あなたのプロジェクトから利益を得るであろう人を具体的にしましょう。そして、次のように話を締めくくりましょう： _「私のプロジェクトは Y をしようとしている X にとって本当に役に立つと考えています」。_ そして、単にあなたのやったことを宣伝するのではなく、フィードバックをもらい、それに対応しましょう。 + +一般的に、何かをお願いする前に人々を助けることに専念しましょう。プロジェクトをオンラインで宣伝するのは誰でも簡単にできるので、ノイズが多いのです。そういった大勢の中で目立つために、あなたが望むものだけでなく、あなたが誰であるかという背景を人々に伝えましょう。 + +もし誰も注意を払ってくれなかったり、あなたに反応してくれない場合でも、がっかりしないで下さい！ほとんどのプロジェクトの立ち上げは、数ヶ月や数年もかかる、反復プロセスなのです。初回で反応が得られなくても、他の戦術で試してみたり、他の人のやっていることに価値を追加するやり方を探しましょう。プロジェクトの宣伝や立ち上げには時間と献身が必要なのです。 + +## ユーザーがいる場所に行こう（オフライン） + +![Public speaking](/assets/images/finding-users/public_speaking.jpg) + +オフラインのイベントは新しいプロジェクトを人々に紹介するためによく用いられる方法です。これは多忙な人々に接触して、より深い関係を構築するのに非常に良い方法です。開発者に接触しようとしている場合は特に有効です。 + +もし[公の場で話すことに慣れていない](http://speaking.io/)のであれば、あなたのプロジェクトの言語やエコシステムに関連する地元のミートアップを探すところから始めてみましょう。 + + + +これまで一度もイベントで発表をしたことがないのであれば、緊張するのは全くもって普通のことです！あなたの聴衆はあなたの話が聞きたいと心から思っているからそこにいるのだということを忘れないようにしましょう。 + +あなたの発表に準備する時に、聞き手にとって何が面白く、価値を得られるのかという点に集中しましょう。言葉遣いを友好的で親しみやすいものにしましょう。笑って、深呼吸して、楽しみましょう。 + + + +準備ができたと感じたら、あなたのプロジェクトを宣伝するためにカンファレンスで発表することを検討しましょう。カンファレンスは、より多くの人々、時には世界中の人々と接点を持つ役に立ちます。 + +あなたの言語やエコシステムに特化したカンファレンスを探しましょう。発表の申込みをする前に、カンファレンスについて調査をして、あなたの発表を参加者に合うよう調整し、カンファレンスでの発表が採用されるチャンスを増やしましょう。カンファレンスの発表者を調べることで、聴衆についての感覚を得ることができることもあります。 + + + +## 評判を築こう + +ここまでに書いた戦略に加えて、あなたのプロジェクトを人々に共有してコントリビュートしてもらうのに最も良い方法は、彼らのプロジェクトを共有してコントリビュートすることです。 + +他の人のプロジェクトで、新しく来た人を助け、リソースを共有し、親切なコントリビュートをすることで、あなたは良い評判を築く事ができるでしょう。オープンソースコミュニティのメンバーとして活発に活動することで、あなたのやっていることの文脈を伝え、あなたのプロジェクトに注意を払ってもらいやすくなります。他のオープンソースプロジェクトと関係を構築することで公式なパートナーシップに繋がることさえあります。 + + + +評判を築くのに早すぎたり遅すぎることはありません。既にプロジェクトを立ち上げていたとしても、他の人を助ける方法を探し続けましょう。 + +一夜で人々を引きつけるようなやり方はありません。信頼や尊敬を得るには時間がかかりますし、評判を築く事は永遠に終わることはありません。 + +## やり続けよう！ + +人々があなたのオープンソースプロジェクトに気づくまでには時間がかかるかもしれません。それで良いのです！今日最も有名なプロジェクトの中には活発になるまでに何年もかかったものもあります。あなたのプロジェクトが自然と人気を獲得するのを願うのではなく、関係を構築することに集中しましょう。あなたのプロジェクトを喜んでくれる人に対して、辛抱強く、やっていることを伝え続けましょう。 diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md new file mode 100644 index 00000000000..0e0164a6b59 --- /dev/null +++ b/_articles/ja/getting-paid.md @@ -0,0 +1,177 @@ +--- +lang: ja +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)、倫理的な問題があります。コントリビュートが、既に余裕のある人からだけに偏ってしまい、このボランティア活動によって彼らが更にメリットを得ることになるのです。その一方、ボランティア活動を行うことのできない人は機会を得ることができず、オープンソースコミュニティにおける多様性の不足がより増長されてしまいます。 + + + +もし金銭的なサポートを探しているのであれば、考えられる道は2つあります。コントリビューターとして有償で活動をするか、プロジェクトの支援をしてくれる組織を探すかです。 + +## あなたの時間に資金を出してもらおう + +今日では、多くの人がオープンソース活動でパートタイムやフルタイムの給与を得ています。これを実現するもっともよくあるケースは、雇用主に話してみることです。 + +もし雇用主がそのプロジェクトを使っているのであれば、オープンソース活動をするのはより簡単になるでしょう。しかし、説明の仕方はよく練る必要があります。そのプロジェクトを使っていないかもしれませんが、 Python を使っているとすれば、 Python の有名なプロジェクトに関わることで新しい Python 開発者を惹き付ける役に立つでしょう。こう説明することで、雇用主はより友好的になるでしょう。 + +もし取り組みたい既存のオープンソース活動がないけれども、現在の仕事の成果をオープンソースにしたいと望んでいる場合は、社内のソフトウェアをオープンソース化する事例を作りましょう。 + +多くの企業が、ブランド構築と有能な開発者の採用のためにオープンソースプログラムを作っています。 + +例えば @hueniverse は、[ウォルマートがオープンソースに投資する](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/) といった企業は、彼らのオープンソースへの関わりをまとめたウェブサイトを持っています。 +* [Rackspace](https://www.rackspace.com/en-us) は従業員向けに[オープンソースコントリビュートポリシー](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/)を公開しています + +[Go](https://github.com/golang) や [React](https://github.com/facebook/react) のような大企業がはじめたプロジェクトでは、オープンソース活動を行う人々を採用する可能性があります。 + +あなた個人の状況によっては、あなた個人でオープンソース活動に資金を出してもらう試みをすることも可能です。例えば： + +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) +* @gaearon は [Patreon でのクラウドファンディング](https://redux.js.org/)を通じて、 [Redux](https://github.com/reactjs/redux) の活動の資金を得ています。 +* @andrewgodwin は [Kickstarter のキャンペーン](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)を通じて、 Django のスキーママイグレーションの活動の資金を得ています。 + +最後に、オープンソースプロジェクトの中には問題解決を手伝ってもらうために報奨金を提示しているものもあります。 + +* @ConnorChristie は [gitcoin の報奨金制度](https://gitcoin.co/)で @MARKETProtocol が JavaScript ライブラリの作業を[手伝う](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)ことで金銭を得ました。 +* @mamiM は @MetaMask の日本語訳作業が [Bounties Network に資金提供された際に](https://beta.bounties.network/bounty/v1/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 の Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) から資金を得ています。 +* **[Libraries.io](https://github.com/librariesio)** は [Sloan Foundation](https://sloan.org/programs/digital-technology) から助成金を得ています。 +* **[Python Software Foundation](https://www.python.org/psf/grants/)** は Python 関連のプロジェクトに対して助成金を提供しています。 + +更に詳細な選択肢や事例については、 @nayafia がオープンソース活動において資金を得るための[ガイドを書いています](https://github.com/nayafia/lemonade-stand)。資金調達方法によって必要なスキルは異なるので、あなたの強みを分析してどの選択肢が最善か検討しましょう。 + +## 資金援助のための論拠を構築しよう + +あなたのプロジェクトが新しいアイデアであろうと、何年も取り掛かってきたものだろうと、ターゲットとなる資金提供者を特定し、説得力のある論拠をつくるために考慮する必要があります。 + +あなた自身の活動に対して資金を得るにせよ、プロジェクトの資金調達をするにせよ、下記の質問に答えられるようにしておくべきです。 + +### インパクト + +なぜこのプロジェクトが役に立つのでしょうか？ユーザーや潜在的なユーザーはあなたのプロジェクトを気に入っているのでしょうか？5年後はどうなっているでしょうか？ + +### トラクション + +あなたのプロジェクトが重要である証拠を集めましょう。それはメトリクスでも良いですし、事例でもユーザーの声でも構いません。今現在、あなたのプロジェクトを使っている企業や特筆すべき人々はいるでしょうか？もしいないのであれば、有名な人が支援してくれないでしょうか？ + +### 資金提供者への価値 + +雇用主であれ助成金を出す財団であれ、資金提供者は多くの人から相談を受けています。他の人ではなくあなたのプロジェクトを支援するべき理由は何でしょう？彼ら自身にはどういったメリットがあるでしょうか？ + +### 資金の使い道 + +資金を得たら、あなたはそれを使って具体的に何を達成するつもりでしょうか？給与の支払いではなく、プロジェクトのマイルストーンやプロジェクトの成果に焦点を当てましょう。 + +### 資金をどのように受け取る予定か？ + +資金提供者は、支払いに関して何か要求していることはあるでしょうか？例えば、非営利である必要があったり、非営利の資金スポンサーがついている必要があるかもしれません。もしくは、資金が組織に対してではなく個人の請負として提供される必要があるかもしれません。これらの要求は資金提供者によって異なるので、事前に確かめておきましょう。 + + + +## 実験し、諦めないようにしよう + +資金調達は簡単ではありません、たとえそれがオープンソースプロジェクトであれ、非営利であれ、ソフトウェアスタートアップであれ。そして、多くの場合では創造的である必要があります。どのように支払ってほしいかを特定し、調査をし、資金提供者の立場で考えることで、資金調達に向けて納得感のある論拠を構築できるようになるでしょう。 diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md new file mode 100644 index 00000000000..baf923ea5a2 --- /dev/null +++ b/_articles/ja/how-to-contribute.md @@ -0,0 +1,514 @@ +--- +lang: ja +title: オープンソースにコントリビュートする方法 +description: オープンソースにコントリビュートしたいですか？このガイドではオープンソースへのコントリビュートの方法を、初めての人だけでなく熟練の方にも紹介します。 +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## オープンソースにコントリビュートする理由は？ + + + +オープンソースにコントリビュートすることはやりがいがあり、あなたが思い描くどんなスキルに対しても、学習し、教え、経験を積むことができます。 + +なぜ人々はオープンソースにコントリビュートするのでしょう？理由は様々です！ + +### 既に持っているスキルを改善する + +あなたが練習したいと思っていることが、コーディングであれ、UIデザインやグラフィックデザイン、文章を書くこと、組織を作ることであれ、オープンソースプロジェクトにはあなたのためのタスクがあります。 + +### 似たようなことに興味を持っている人に会う + +暖かく迎えてくれるコミュニティを持ったオープンソースプロジェクトでは、人々が何年経っても戻って来続けます。多くの人がオープンソースに参加することによって生涯に渡る友好関係を築いています。たとえそれがカンファレンスでばったり会うという形であったり、夜遅くにブリトーについてチャットをしているという形であれ。 + +### メンターを見つけ互いに教えあう + +同じプロジェクトで他の人と一緒に働くということは、あなたが仕事をやる方法を説明するだけでなく、他の人に助けを求める必要が出てきます。学習し、教えることは関わる人全てにとって充実した活動となります。 + +### あなたの評判（やキャリア）を育てるのに役立つ成果物を作り上げる + +その定義からして、すべてのオープンソースはパブリックです。このことはあなたがやっていることをどこでも自由に紹介できる事例を得られるということを意味します。 + +### ピープルスキルを学ぶ + +オープンソースは、人々の衝突を解消したり、チームを組織したり、仕事の優先順位付けをするなどといったリーダーシップやマネジメントスキルを実践する機会を提供してくれます。 + +### 変化を起こせるようになる助けとなる、たとえそれが小さな変化であったとしても + +あなたは何もオープンソースに生涯に渡って常に参加し続ける必要があるわけではありません。ウェブサイトでタイポを見つけて、直してほしいと思ったことはありませんか？オープンソースプロジェクトでは、あなたがそれをできるのです。オープンソースによって、人々は人生や世界をどう経験するかが自分自身のものだと感じられることを助けてくれます。そしてその事自体が大きな喜びとなるのです。 + +## コントリビュートするということが意味するもの + +オープンソースコントリビューターになりたてで自信が持てないと感じているかもしれません。どのようにして正しいプロジェクトを見つけるのでしょう？もしコーディングの仕方を知らないとしたらどうでしょう？もし何かが間違ってしまったらどうしましょう？ + +心配ありません！オープンソースプロジェクトに関わるにはあらゆる方法があります。そして、少しのコツがあればあなたの経験を最大限活かす事ができるでしょう。 + +### かならずしもコードを書く必要はありません + +オープンソースへのコントリビュートについてのよくある勘違いとしては、あなたはコードを書く必要があるというものです。実際、それはしばしばプロジェクトの中で最も[無視されるか見落とされている部分](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)、Tシャツや新しいロゴのデザインをする + +### 文章を書くのが好きですか？ + +* プロジェクトのドキュメントを書いたり改善する +* プロジェクトがどのように使われているかの事例を選別する +* プロジェクトのニュースレターを始めたり、メーリングリストのハイライトを整理する +* [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 が Rust で @bronzdoc にやったように](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)、他のコントリビューターのメンターをやる + +### 必ずしもソフトウェアプロジェクトで働く必要はありません + +「オープンソース」はしばしばソフトウェアのことを指していますが、あなたはどんなものでもコラボレートできるのです。本やレシピ、リストや授業もオープンソースプロジェクトとして開発されているのです。 + +例えば: + +* @sindresorhus は["素敵なもの"のリストを作っています](https://github.com/sindresorhus/awesome) +* @h5bp はフロントエンド開発者のための[面接での質問集](https://github.com/h5bp/Front-end-Developer-Interview-Questions)をまとめています +* @stuartlynn と @nicole-a-tesla は[ツノメドリについての愉快な事柄のコレクション](https://github.com/stuartlynn/puffin_facts)を作っています + +たとえあなたがソフトウェアエンジニアだったとしても、ドキュメントを書くことはオープンソース活動を始めるにあたって良いスタートとなります。ときにはコードを書かないプロジェクトに関わることのほうが障壁が低く、コラボレーションのプロセスを通じて自信と経験を身につけることができます。 + +## 新しいプロジェクトに順応しよう + + + +タイポの修正以上のものであればなんでも、オープンソースにコントリビュートするというのは知らない人たちのパーティに近づいていくようなものです。もしあなたがラマについて話し始めたとして、一方で彼らは金魚について深い議論をしていたら、おそらくあなたのことを少し奇妙な目で見るでしょう。 + +盲目的にあなた自身の提案をする前に、部屋の雰囲気を読み取る方法を学びましょう。そうすることによって、あなたのアイデアの存在に気づいてもらい聞き入れてもらうチャンスが増すでしょう。 + +### オープンソースプロジェクトの構造 + +それぞれのオープンソースコミュニティは異なります。 + +ある一つのオープンソースプロジェクトで長い時間を過ごしたということは、ある一つのオープンソースプロジェクトについて理解したということを意味します。異なるプロジェクトに移ると、使っている言葉や規範、コミュニケーションスタイルが全く異なることに気づくでしょう。 + +とはいえ、多くのオープンソースプロジェクトは似たような組織構造を持っています。異なるコミュニティの役割や全体のプロセスを理解することは新しいプロジェクトに早く順応するための助けになるでしょう。 + +典型的なオープンソースプロジェクトは下記のような種類の人々がいます: + +* **オーサー:** そのプロジェクトを作った人(たち)もしくは組織 +* **オーナー:** 組織やリポジトリに対して管理上の所有権を持っている人(たち)もしくは組織(かならずしも元のオーサーと同じとは限らない) +* **メンテナー:** ビジョンを推し進め、プロジェクトの組織的なマネジメントを行うコントリビューター(彼らはオーサーやオーナーであることもある) +* **コントリビューター:** プロジェクトに対して何かしらのコントリビュートをするすべての人 +* **コミュニティメンバー:** プロジェクトを使っている人々。彼らは議論をしたり、プロジェクトの方向性に対して意見を表明したりする + +より大きなプロジェクトでは、ツールの整備やコミュニティのモデレートやイベントの運営など異なるタスクに特化した分科会やワーキンググループがあるかもしれません。プロジェクトのウェブサイトの「チーム」についてのページや、リポジトリの運営に関するドキュメントをみて、こういった情報を見つけましょう。 + +プロジェクトにはドキュメントもあります。これらのファイルはたいていリポジトリのトップレベルに置かれています。 + +* **LICENSE:** その定義から、すべてのオープンソースプロジェクトは[オープンソースライセンス](https://choosealicense.com)を持っている必要があります。もしそのプロジェクトがライセンスを持っていないのであれば、それはオープンソースではありません。 +* **README:** README はそのプロジェクトへの新しいコミュニティメンバーを迎えるための操作マニュアルです。そこではなぜそのプロジェクトが便利で、どのように始めるかの説明があります。 +* **CONTRIBUTING:** README が人々がそのプロジェクトを _使う_ 手助けをする一方、 CONTRIBUTING ドキュメントは人々が _コントリビュートする_ 手助けをします。そこではどういった種類のコントリビュートが必要とされていて、そのプロセスがどうなっているかの説明があります。すべてのプロジェクトが CONTRIBUTING ファイルを持つわけではないですが、そのファイルがあることによって、そのプロジェクトがコントリビュートを歓迎していることの印になります。 +* **CODE_OF_CONDUCT:** 行動規範は参加者の振る舞いに対する基本原則を設定し、友好的な環境を作る手助けをします。すべてのプロジェクトが CODE_OF_CONDUCT ファイルを持つわけではないですが、そのファイルがあることによって、そのプロジェクトがコントリビュートを歓迎していることの印になります。 +* **その他のドキュメント:** それ以外にも、特に大きなプロジェクトではチュートリアル、ウォークスルー、運営方針などといったドキュメントがあることがあります。 + +最後に、オープンソースプロジェクトは議論を整理するために次のようなツールを使います。アーカイブを読み通すことで、そのコミュニティがどのように考え動いてきたかを把握することができるでしょう。 + +* **イシュートラッカー:** そのプロジェクトに関連するイシューを議論する場所 +* **プルリクエスト:** 作業中の変更について議論し、レビューをする場所 +* **ディスカッションフォーラムやメーリングリスト:** いくつかのプロジェクトではあるトピックについて会話 (例えば、バグの報告や機能要望の代わりに _「これはどうやって・・・すると良いのでしょう？」_ や _「・・・についてどう思いますか？」_ といったもの) をするのにこれらのチャネルを使うかもしれません。また、すべての会話をイシュートラッカー上で行うプロジェクトもあります。 +* **同期的なチャットチャネル:** カジュアルな会話やコラボレーション、簡単なやりとりについては ( Slack や IRC のような) チャットチャネルを使うプロジェクトもあります。 + +## コントリビュートするプロジェクトを見つけよう + +さてあなたはオープンソースプロジェクトがどのように働くのかを理解しました。次はコントリビュートするプロジェクトを見つける番です！ + +もしあなたがこれまでにオープンソースプロジェクトにコントリビュートしたことが一度もないのであれば、アメリカ大統領のジョン・F・ケネディのアドバイスを聞いてみましょう。彼はかつて、 _「あなたの国があなたのために何をしてくれるのかを問うのではなく、あなたが国のために何ができるかを問いなさい」_ と言いました。 + +オープンソースへのコントリビュートはあらゆる階層で、プロジェクトをまたいで行われています。あなたの最初のコントリビュートが具体的にどういったものであるかや、どのようなものなのかを考えすぎる必要はありません。 + +代わりにあなたが既に使っていたり使いたいと思っているプロジェクトについて考え始めましょう。活発にコントリビュートすることになるプロジェクトは、何度も戻ってきたいと思うようなものなのです。 + +そういったプロジェクトの中で、何かをよくできたり違ったものにできると考え始めたときはいつでも、あなたの直感に従って行動しましょう。 + +オープンソースは排他的なクラブではありません。あなたのような人々からなっているのです。「オープンソース」は世の中の問題が解決可能であると扱うための単なるきらびやかな名前でしかないのです。 + +README を読んで、壊れたリンクやタイポを見つけるかもしれません。もしくは、あなたは新しいユーザーで、何かが壊れていたり、ドキュメントに書かれているべきと考えるイシューがあるかもしれません。それを無視して先に進んだり、他の誰かに直してとお願いする代わりに、あなたが参加することで手助けができないかどうか確かめてみましょう。これがオープンソースというものなのです！ + +> オープンソースへの[ふとしたコントリビュートの28%](https://www.igor.pro.br/publica/papers/saner2016.pdf) がタイポの修正やフォーマットの修正や翻訳といったドキュメントに対するものなのです。 + +また、新しいプロジェクトを見つけてコントリビュートする手助けとして、次のようなリソースのうちの一つを使うこともできます: + +* [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/) + +### コントリビュートする前のチェックリスト + +コントリビュートしたいプロジェクトを見つけたら、そのプロジェクトがコントリビュートを受け入れる体制ができているかどうかを確かめるために簡単に調べてみましょう。さもないと、あなたの懸命な努力が全くの無反応で終わってしまうかもしれません。 + +次に、プロジェクトが新しいコントリビューターにとって良いかどうかを評価する簡単なチェックリストを記載しました。 + +**オープンソースの定義に適っているか** + +
+ + +
+ +**プロジェクトがコントリビュートを積極的に受け入れているか** + +master ブランチのコミットアクティビティをみてみましょう。 GitHub ではリポジトリのホームページでこの情報を見ることができます。 + +
+ + +
+ +
+ + +
+ +
+ + +
+ +次に、プロジェクトのイシューをみてみましょう。 + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +次にプロジェクトのプルリクエストに対して同じことをしましょう。 + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**プロジェクトは歓迎してくれるか** + +友好的で歓迎してくれるプロジェクトは新しいコントリビューターを受け入れてくれる印です。 + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## コントリビュートする方法 + +あなたは好きなプロジェクトを見つけ、コントリビュートをする準備ができています。ついに！次にあなたのコントリビュートを効果的に行う方法を紹介します。 + +### 効果的にコミュニケーションする + +あなたが一度きりのコントリビューターであろうとコミュニティに参加しようとしているのであろうと、他の人と働くことはオープンソースで獲得するスキルの中で最も大事なものの一つです。 + + + +イシューやプルリクエストをオープンする前に、あなたのアイデアが効果的に扱われる助けのために、これらのことを心にとどめておきましょう。 + +**コンテキストを与えましょう。** 他の人がすぐに把握する手助けをしましょう。もしあなたがエラーに遭遇しているのであれば、あなたが何をしようとしていて、どうやって再現させるのかを説明しましょう。もしあなたが新しいアイデアを提案しているのであれば、なぜそれがプロジェクトにとって（あなたにとってだけではなく！）便利だと思うのかを説明しましょう。 + +> 😇 _"Yを行った時にXが起きません"_ +> +> 😢 _"Xが壊れています！直して下さい。"_ + +**まずは自分の手を動かしましょう。** 何かを知らないのは問題ないのですが、トライしたことは示しましょう。助けを求める前に、プロジェクトの README やドキュメント、イシュー（オープンなものもクローズされたものも）、メーリングリストや答えをインターネットで探したか確認しましょう。人々はあなたが学ぼうとしていることを示せば、それを評価してくれるでしょう。 + +> 😇 _"私は X を実装するやり方がわかりません。ヘルプドキュメントを見たのですが、それについての言及を見つけることができませんでした。"_ +> +> 😢 _"わたしはどうやったら X ができますか？"_ + +**要求は短く直接的にしましょう。** メールを送るのと同じように、それぞれのコントリビュートは、それがいくらシンプルで役に立つものであっても、他の誰かのレビューを必要とします。多くのプロジェクトでは、人々が助けられる以上の数の要求が来ています。簡潔にしましょう。そうすれば、誰かが助けてくれるチャンスを増やすことができるでしょう。 + +> 😇 _" API チュートリアルを書こうと思っています。"_ +> +> 😢 _"私は先日高速道路を走っていて、給油のため止まりました。すると、我々がやるべき素晴らしいアイデアが思い浮かんだのです。しかし、それを説明する前に・・・"_ + +**全てのコミュニケーションを公開の場でしましょう。** いくらやりたくなったとしても、機密情報（セキュリティイシューや重大な行動指針違反など）を共有するのでもない限り、メンテナーに非公開に接触するのはやめましょう。会話を公開の場で行い続ければ、あなたの会話からより多くの人が学び、利益を得ることができます。会話することはそれ自体がコントリビュートとなりうるのです。 + +> 😇 _(コメントで) "@メンテナー こんにちは！このプルリクエストはどうやって進めたら良いですか？"_ +> +> 😢 _(メールで) "こんにちは、メールを送ってすみませんが、私のプルリクエストをレビューしていただけないかと思いまして。"_ + +**質問をするのは問題ありません（ただし、辛抱強く！）** 誰しもがある時点ではそのプロジェクトに慣れていなく、経験のあるコントリビューターでさえ新しいプロジェクトを見るときは最新情報が必要となります。同様に、古くからのメンテナーでさえ常にそのプロジェクトのあらゆる部分に詳しいわけではありません。あなたが彼らに望むような辛抱強さをあなたも彼らに対して示しましょう。 + +> 😇 _"このエラーについて調べてくれてありがとうございます。あなたの提案に従ってみました。こちらがその出力です。"_ +> +> 😢 _"なぜ私の問題を解決できないのでしょう？これはあなたのプロジェクトじゃないんですか？"_ + +**コミュニティの決定を尊重しましょう。** あなたのアイデアはコミュニティの優先事項やビジョンとは異なっているかもしれません。彼らはフィードバックを提供したり、あなたのアイデアを採用しないと決定するかもしれません。あなたは議論したり妥協点を見出したりするべきですが、メンテナーはあなたよりも長い期間あなたのアイデアと付き合っていく必要があるのです。もしあなたが彼らの方向性に賛成出来ないのなら、あなたはいつでもあなた自身のフォークやあなた自身のプロジェクトを始めることができるのです。 + +> 😇 _"あなたが私のユースケースを支持できないのは残念ですが、あなたが説明してくれたようにそれはユーザーのうちの一部にしか影響しませんし、私も理由を理解できます。意見を聞いてくださりありがとうございます。"_ +> +> 😢 _"なぜあなたは私のユースケースを支持しないのですか？これは受け入れられません！"_ + +**なにより常にポジティブでいましょう。** オープンソースは世界中のコラボレータによって成り立っています。言語や文化、地理、タイムゾーンをまたぐことでコンテキストが失われてしまいます。加えて、テキストコミュニケーションでは調子や雰囲気を伝えるのが難しいです。これらの会話では相手は前向きであると仮定しましょう。丁寧にアイデアを先送りしたり、さらなるコンテキストを聞いたり、あなたのポジションを更に明確にするのは良いことです。インターネットがあなたが見つけたときよりもよりよい場所であるように心がけましょう。 + +### コンテキストを集める + +何かをする前に、あなたのアイデアが他の場所で既に議論されていないか確かめましょう。そのプロジェクトの README やイシュー（オープンなものもクローズされたものも）、メーリングリストやスタックオーバーフローにざっと目を通しましょう。全てに目を通すのに何時間もかける必要はありませんが、いくつかのキーワードで検索するので十分です。 + +もしあなたのアイデアが他で見つけられないのであれば、動き出す準備ができたことになります。そのプロジェクトが GitHub 上にあるのであれば、あなたはおそらくイシューやプルリクエストをオープンすることでコミュニケーションするでしょう。 + +* **イシュー** は会話や議論を始めるようなものです +* **プルリクエスト** は解決に向けて仕事を始めることです +* 確認や方法を聞く質問のような、**軽いコミュニケーションには** 、もしそのプロジェクトが使っているのであれば、スタックオーバーフロー、 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" リポジトリを remote として追加することで紐づけましょう。 "upstream" からの変更を頻繁にプルすることで、プルリクエストを提出する時にマージコンフリクトが起きづらくなるように、最新に追いついているようにしましょう。（より詳細な手順は[こちら](https://help.github.com/articles/syncing-a-fork/)を確認して下さい)。 +* あなたの変更のための**[ブランチを切りましょう](https://guides.github.com/introduction/flow/)**。 +* プルリクエストの中で**あらゆる関連するイシュー** や関連するドキュメントを参照しましょう （例えば、 "Closes #37." のように)。 +* もしあなたが HTML/CSS を変更するのであれば、**前後のスクリーンショットを含めましょう**。あなたのプルリクエストの本文に画像をドラッグアンドドロップしましょう。 +* **あなたの変更をテストしましょう！** もし既存のテストがあるのであれば、あなたの変更に対してそのテストを実行したり、必要であれば新しいテストを作りましょう。既存のテストの有無にかかわらず、あなたの変更が既存のプロジェクトを壊さないことを確かめましょう。 +* できる限り**そのプロジェクトのスタイルに従ってコントリビュートしましょう**。これによってインデントやセミコロン、コメントがあなた自身のリポジトリの使い方とは異なるかもしれないということを意味します。しかし、メンテナーがマージしやすくしたり、他の人が理解して将来もメンテナンスしやすいようにしましょう。 + +もしこれがあなたの初めてのプルリクエストであれば、 [Make a Pull Request](http://makeapullrequest.com/) という、 @kentcdodds が作成したビデオチュートリアルを確認しましょう。また、プルリクエストを作る練習を [First Contributions](https://github.com/Roshanjossey/first-contributions) という、 @Roshanjossey によって作成されたリポジトリで行うこともできます。 + +## コントリビュートを提出した後に起こること + +やりました！おめでとう、あなたはオープンソースコントリビューターになりました。これからも多数のコントリビュートを行う第一歩になることを願っています。 + +コントリビュートを提出した後、下記のうちのどれかが起きるでしょう： + +### 😭 返事をもらえない + +あなたはコントリビュートを行う前に、[そのプロジェクトの活動の様子を調べていると思います](#コントリビュートする前のチェックリスト)。しかしながら、アクティブなプロジェクトだったとしても、あなたのコントリビュートに対して返事が無いことがおき得ます。 + +一週間以上返事がないようであれば、同じスレッドにて、誰かにレビューを丁寧にお願いするのは妥当でしょう。あなたのコントリビュートをレビューするのに適切な人の名前を知っているのであれば、そのスレッドにて@メンションを使うことができます。 + +その人に非公開の場で接触するのは**やめましょう**。オープンソースプロジェクトにとって、公開の場でコミュニケーションすることは必要不可欠であるということを思い出しましょう。 + +もしあなたが丁寧につついてもまだ誰も反応しないのであれば、ずっと誰も反応しない可能性があります。良い気分ではないでしょうが、落胆しないようにしましょう。それは誰に対しても起こることなのです！返事をもらえない理由はたくさんあり、それにはあなたがコントロールできない個人的な状況も含まれます。他のプロジェクトや他のコントリビュートの方法を探しましょう。いずれにしても、他のコミュニティメンバーが携わってくれて反応してくれるようになる前にコントリビュートをするのに大きな時間を投資しないほうが良いのです。 + +### 🚧 あなたのコントリビュートに対して変更を要求する人がいる + +あなたのコントリビュートに対して変更を要求されるのはよくあることです。その要求はあなたのアイデア自体に対してのフィードバックであることもあれば、コードに対する変更であることもあります。 + +変更を要求する人が居たら、すぐに返事をしましょう。彼らはあなたのコントリビュートに対して時間をとってレビューしてくれたのです。プルリクエストを開いて居なくなってしまうのは良くないやり方です。もしあなたが変更の仕方を知らないのであれば、その問題を調査し、必要であれば助けを求めましょう。 + +もしあなたがその問題に対してそれ以上の時間をかけることができない（例えばその会話が何ヶ月にも渡り、あなたの状況が変わったなど）場合は、メンテナーにそれを伝え、返答ができない旨を伝えましょう。他の誰かが喜んで引き継いでくれるはずです。 + +### 👎 あなたのコントリビュートが受け入れられない + +あなたのコントリビュートは最終的に受け入れられるかもしれないし、受け入れられないかもしれません。既に多大なコストを払っていないとよいのですが。もしなぜ受け入れられないかわからないのであれば、メンテナーにフィードバックや確認をするのは全くもって理にかなっています。しかし、究極的にはそれが彼らの決定であると尊重する必要があるでしょう。異議を唱えたり、敵意を示さないようにしましょう。もし彼らに賛成出来ないのであれば、あなたはいつでもフォークしてあなた自身のプロジェクトを始めることができるのです。 + +### 🎉 あなたのコントリビュートが受け入れられた + +バンザイ！あなたは無事にオープンソースにコントリビュートできました！ + +## やりました！ + +初めてのオープンソースへのコントリビュートをしたのであれ、他のコントリビュートの方法を探しているのであれ、あなたがなにか行動を起こそうという気持ちになっていたら嬉しいです。たとえあなたのコントリビュートが受け入れられなかったとしても、メンテナーがあなたを助けるために労力を割いてくれたことに対して感謝を伝えるのを忘れないようにしましょう。オープンソースはあなたのような、イシュー、プルリクエスト、コメントや挨拶をするような、人々で成り立っているのです。 diff --git a/_articles/ja/index.html b/_articles/ja/index.html new file mode 100644 index 00000000000..a7cf02f62cb --- /dev/null +++ b/_articles/ja/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: オープンソースガイドライン +lang: ja +permalink: /ja/ +--- diff --git a/_articles/ja/leadership-and-governance.md b/_articles/ja/leadership-and-governance.md new file mode 100644 index 00000000000..630ee1eb0c4 --- /dev/null +++ b/_articles/ja/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: ja +title: リーダーシップと組織運営 +description: 意思決定するためのルールを決めることで、オープンソースプロジェクトを成長させる助けとなります。 +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## 成長中のプロジェクトの運営方法を理解しよう + +あなたのプロジェクトは成長しており、人々が携わっていて、あなたは物事がこのまま進むように維持することに熱心でしょう。この段階では、あなたはどのようにして通常のコントリビューターをワークフローに組み込むのが良いか悩んでいるかもしれません。誰かにコミット権限を与えるかどうかであったり、コミュニティの議論をどのように収集させるのかであったり。もしこういった疑問があるのであれば、私達は答えを知っています。 + +## オープンソースプロジェクトで使われる公式の役割の例はなんですか？ + +多くのプロジェクトでは、コントリビューターの役割は似たようなものを使っています。 + +しかし、こういった役割が実際の所何を意味するのかは、完全にあなた次第です。下記にあなたが知っているであろう役割を挙げます： + +* **メンテナー** +* **コントリビューター** +* **コミッター** + +**幾つかのプロジェクトでは、「メンテナー」は** コミット権限を持っている唯一の人です。他のプロジェクトでは、単に README にメンテナーとして記載されている人であることもあります。 + +メンテナーはプロジェクトでコードを書いている人である必要はありません。プロジェクトの布教を熱心に行っている人でも良いですし、多くのドキュメントを書くことで他の人がプロジェクトにアクセスしやすくしている人でも良いのです。日常的に何をやっているのかにかかわらず、メンテナーはプロジェクトの方向性に責任を持っていると感じていて、またプロジェクトを改善するのに熱心である人でしょう。 + +**「コントリビューター」は誰でもなり得ます。** それは、イシューやプルリクエストにコメントを書いている人かもしれないし、プロジェクトに価値を与える（イシューを選別する、コードを書く、イベントを運営するなど）人かもしれないし、プルリクエストをマージしてもらった人（おそらくこれが最も狭義のコントリビューターの定義です）かもしれません。 + + + +**「コミッター」という言葉は** コミットアクセスという特定の種類の責務を、他の種類のコントリビュートと区別するために使われるでしょう。 + +あなたの好きなようにプロジェクトの役割を定義できますが、より多くの種類のコントリビュートを奨励するためにより[広い定義を検討しましょう](../how-to-contribute/#コントリビュートするということが意味するもの)。プロジェクトに多大なコントリビュートをしている人に対しては、その人の技術スキルがどうであれ、その人のコントリビュートを公式に認めるために、リーダーの役割を使うことができます。 + + + +## どのようにしてリーダーシップの役割を明確にするか？ + +リーダーシップの役割を明確にすることで、人々に責任を持たせ、他のコミュニティメンバーが助けが必要な時に誰に聞くべきかが明確になります。 + +小さいプロジェクトでは、リーダーを任命することは単に README や CONTRIBUTORS ファイルに名前を追加するだけで済むこともあります。 + +大きなプロジェクトでは、ウェブサイトを持っているのであれば、チームページやプロジェクトリーダーのリストのページを作りましょう。例えば、 [Postgres](https://github.com/postgres/postgres/) では [チームのリストページ](https://www.postgresql.org/community/contributors/) に各コントリビューターの短いプロフィールを記載しています。 + +もしあなたのプロジェクトのコントリビューターが非常に活発なのであれば、メンテナーの「コアチーム」を作ったり、異なる問題領域ごと（例えば、セキュリティ、イシューの選別、コミュニティ運営）に責任を持つ分科会を持っているかもしれません。あなたが指名するのではなく、人々が自分の興味のある領域の役割に自律的にボランティアしてくれるように任せましょう。 + + + +リーダーシップチームは( IRC のような)専用のチャンネルを作りたいと思ったり、プロジェクトについて定期的に議論するために( Gitter 上や Google Hangout 上で)集まりたいと思うかもしれません。こういったミーティングでさえも公にする事で、他の人も議論を聞けるようにしましょう。例えば、 [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) では、 [毎週オフィスアワーを設けています](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs)。 + +一度リーダーシップの役割を確立したなら、どのようにして彼らにコンタクトを取れるかドキュメントにまとめることを忘れないようにしましょう。メンテナーにどのようにしたらなれるかであったりどのように分科会に参加するのかのプロセスを明確に確立し、 GOVERNANCE.md ファイルにそれを記載しましょう。 + +[Vossibility](https://github.com/icecrime/vossibility-stack) のようなツールは、プロジェクトに対するコントリビュートを誰がやっているのか（やっていないのか）を公にトラッキングするのに役立ちます。こういった情報をドキュメント化することで、メンテナーは非公開の場で意思決定を行う派閥を作っているとコミュニティから認識されることを避けることができます。 + +最後に、プロジェクトが GitHub 上にあるのであれば、プロジェクトを個人アカウントから Organization に移し、少なくとも一人の管理者をバックアップとして追加することを検討しましょう。 [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) を使うことで、権限や複数のリポジトリを管理し、[所有権を共有することで](../building-community/#プロジェクトの所有権を共有しよう)プロジェクトの資産を守ることがやりやすくなります。 + +## いつ他の人にコミット権限を与えるべきだろうか？ + +コントリビュートをするすべての人にコミット権限を与えるべきだと考える人もいます。そうすることで、より多くの人にプロジェクトに対して責任を感じてもらうことができます。 + +その一方で、大きく複雑なプロジェクトでは、プロジェクトに対して熱心に献身している人のみにコミット権限を与えたいと思うかもしれません。唯一の正解はありません - あなたが最も良いと思うことをやりましょう。 + +もしプロジェクトが GitHub 上にあるのであれば、 [protected branches](https://help.github.com/articles/about-protected-branches/) を使うことで、どういった状況で誰が特定のブランチに push できるのかを管理することができます。 + + + +## オープンソースプロジェクトによくある運営方法はどのようなものでしょうか？ + +オープンソースプロジェクトに関連して、3つのよく使われる運営方法があります。 + +* **BDFL:** BDFL は "Benevolent Dictator for Life（優しい終身の独裁者）" の略です。これは、一人の人間（大抵はプロジェクトを立ち上げた人）が、全てのプロジェクトの大きな決断に最終承認を出すやり方です。 [Python](https://github.com/python) は、古くからある例です。小さなプロジェクトではおそらく初めから BDFL を採用しているでしょう。なぜなら、メンテナーが一人か二人しかいないからです。企業が始めたプロジェクトも BDFL のカテゴリーに入るでしょう。 + +* **業績主義:** **(メモ: "業績主義"という言葉は、コミュニティによっては否定的な意味を持つかもしれなく、[複雑な社会的、政治的歴史](http://geekfeminism.wikia.com/wiki/Meritocracy)があります。)** 業績主義のもとでは、活動的なプロジェクトコントリビューター（「業績」を出した人）が、公式の意思決定の役割を与えられます。意思決定はたいてい投票によって行われます。業績主義のコンセプトは [Apache Foundation](https://www.apache.org/) が先鞭をつけました; [全ての Apache プロジェクト](https://www.apache.org/index.html#projects-list)は業績主義で運営されています。コントリビュートは、全て企業ではなく代表する個人によってのみ行われます。 + +* **自由主義的なコントリビュート:** 自由主義的なコントリビュートモデルでは、最も働いている人が最も影響力があると認められますが、これはこれまでのコントリビュートではなく現時点での仕事に基づきます。プロジェクトでの大きな意思決定は、純粋な投票ではなく合意の模索プロセス（大きな不満点について議論する）によって行われます。そして、可能な限りコミュニティ内の多くの知見を集めようと努力します。自由主義的なコントリビュートモデルを採用している有名なプロジェクトの例としては、 [Node.js](https://foundation.nodejs.org/) や [Rust](https://www.rust-lang.org/) があります。 + +どのモデルを使うべきでしょうか？それはあなた次第です！それぞれのモデルには利点と欠点があります。そして、はじめはこれらのモデルは全く異なるように見えるかもしれませんが、見かけ以上にこれらのモデルは共通点が多いのです。もしこれらのモデルのうちの1つを採用することに興味があるのであれば、これらのテンプレートを確認してみましょう： + +* [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) + +## プロジェクトを立ち上げる時に、運営ドキュメントは必要でしょうか？ + +プロジェクトの運営についてドキュメントを書くのに適切なタイミングはありませんが、コミュニティの力学が明らかになってから定義するほうがずっと簡単です。オープンソース運営における最善の（そして最も大変な）点は、コミュニティによって形作られているということです！ + +しかしながら、初期段階でドキュメントを書くことでは必ずプロジェクト運営に寄与するでしょう。なので、書けるものから書き始めましょう。例えば、どういった行動を期待するかを明確に定義したり、コントリビューターのプロセスはどうなっているかといったものを、プロジェクトの立ち上げ時点に書きましょう。 + +もしあなたがオープンソースプロジェクトを立ち上げようとしている企業に所属しているのであれば、立ち上げの前にプロジェクトを進めるにあたって何をコミュニティに期待し、どのように意思決定するのかを内部で議論しておくことは価値のあることです。特に、あなたの企業がプロジェクトにどのように関わるか（もしくはかかわらないか）に関して公に説明しておきたいと思うかもしれません。 + + + +## 企業の従業員がコントリビュートを提出したら何が起きますか？ + +成功したオープンソースプロジェクトは多くの人々や企業によって使われるようになります。そして、幾つかの企業では、プロジェクトが最終的な収益への流れに結びつくことになるかもしれません。例えば、プロジェクトのコードを商用のサービスの一部として使っているかもしれません。 + +プロジェクトが広く使われるようになるほど、そのプロジェクトに習熟した人たちの需要が高まります - あなた自身もそうかもしれません！そして、プロジェクトでやっている仕事で採用されることも時にはあるでしょう。 + +企業の活動も、普通の活動と同じであり、1つの開発リソースの源であると捉えることは重要です。当然、給与をもらって開発している人を特別扱いすべきではありません; それぞれのコントリビュートは技術的な功績によって評価されるべきです。しかしながら、企業活動に従事する事を苦痛に感じるべきではありませんし、特定の改善や機能について議論するときにはユースケースを主張することにも苦痛を感じるべきではありません。 + +「商用利用」は、「オープンソース」とは完全に両立可能です。「商用利用」は単にどこかでお金が絡んでいることを意味するに過ぎません - それはソフトウェアが商取引で使われているということで、プロジェクトが多く採用されるにつれてその可能性は増していきます。（オープンソースソフトウェアがオープンソースではない製品の一部として使われる時、プロダクト全体はそれでも「プロプライエタリ」ソフトウェアですが、オープンソースのように商用も非商用のどちらでも利用可能です。） + +他の皆と同様に、お金を支払われて開発を行っている人もプロジェクト内の影響力を得るのは、コントリビュートの質や量によってです。明らかに、お金を支払われている開発者は支払われていない開発者よりも多くのことをできますが、それで良いのです：お金を得ているかどうかは、その人がどのくらいコントリビュートするかに影響を与える要素が多くある中の1つでしかありません。プロジェクト内の議論では、コントリビュートを行う上での外部要因ではなく、コントリビュート自体に集中し続けましょう。 + +## プロジェクトを運営するのに法人は必要ですか？ + +お金を扱うのでなければ、オープンソースプロジェクトの運営に法人は必要ありません。 + +例えば、商用ビジネスを立ち上げたいのであれば、（もし US で行うのであれば） C 株式会社や有限会社の立ち上げを考えているでしょう。あなたがオープンソースプロジェクトに関連した請負作業を行うだけであれば、あなたが単独で報酬を受け取るか、もしくは（ US で行うのであれば） LLC を設立することもできます。 + +あなたのオープンソースプロジェクトで寄付を受け取りたいのであれば、（例えば PayPal や Stripe を使うことで）寄付ボタンを設置することができます。ただし、非営利団体（ US の場合は 501c3 ）でない場合は課税控除の対象にはなりません。 + +多くのプロジェクトでは非営利団体を設立するという面倒を避けるために、代わりに非営利の財政スポンサーを見つけています。財政スポンサーは、寄付額の一定の割合を受け取ることと引き換えにあなたの代わりに寄付を受け取ります。 [Software Freedom Conservancy](https://sfconservancy.org/) や [Apache Foundation](https://www.apache.org/) 、 [Eclipse Foundation](https://www.eclipse.org/org/) 、 [Linux Foundation](https://www.linuxfoundation.org/projects) 、 [Open Collective](https://opencollective.com/opensource) は、オープンソースプロジェクトの財政スポンサーとして活動している団体の例です。 + + + +もしあなたのプロジェクトが特定の言語やエコシステムと密接に関係しているのであれば、連携できるソフトウェア財団もあるかもしれません。例えば、 [Python Software Foundation](https://www.python.org/psf/) は [PyPI](https://pypi.org/) という Python のパッケージマネジャーをサポートしていますし、 [Node.js Foundation](https://foundation.nodejs.org/) は [Express.js](https://expressjs.com/) という Node ベースのフレームワークをサポートしています。 diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md new file mode 100644 index 00000000000..6ed9b3437b6 --- /dev/null +++ b/_articles/ja/legal.md @@ -0,0 +1,158 @@ +--- +lang: ja +title: オープンソースの法的側面 +description: オープンソースの法的側面についてあなたが疑問に思うだろうことや、思いもしないだろうことについて。 +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## オープンソースの法的意味を理解しよう + +あなたの創造的な仕事を世界に共有することは、とても興奮することであり報われる経験になり得ます。しかし、それは懸念する必要があることをそもそも知らなかったような、多くの法的な事柄が必要になるということでもあるのです。ありがたいことに、あなたはゼロから始める必要はありません。あなたが必要な法的知識をここにまとめました。（読み進める前に、[免責事項](/notices/)をお読みください。） + +## なぜオープンソースの法的な側面を気にするんですか？ + +よくぞ聞いてくれました！何か作品（文書、グラフィックス、コードなど）を創作するときには、その作品はデフォルトで排他的な著作権によって守られます。つまり、あなたは作品の作者として、他の人があなたの作品についてやって良いことについて意見があるということを法律は想定しています。 + +この事は、一般的にはあなたの作品を使ったり、コピーしたり、配布したり、修正することは、取り下げや捜査、訴訟のリスクが発生することを意味します。 + +しかし、オープンソースでは他の人が使って、修正して、それを共有することを推奨しており、通常とは異なる状況です。しかし、法的にはデフォルトで排他的な著作権で守られており、他の人に許可する事項を明確にライセンスで宣言する必要があります。 + +もしオープンソースライセンスを適用しないと、プロジェクトにコントリビュートする全員が、彼らの作業についての排他的な著作権を持つことになります。つまり、彼らのコントリビュートに関しては他の誰もそれを使ったり、コピーしたり、配布したり、変更することができません。そして、あなたもそれに含まれます。 + +最後に、あなたのプロジェクトの依存関係の中には、あなたが気付いていないような要求をするライセンスのものがあるかもしれません。プロジェクトのコミュニティや雇用主の方針によって、あなたのプロジェクトで特定のオープンソースライセンスを使うよう要求されることもあるかもしれません。これらの状況については、後述します。 + +## パブリックな GitHub プロジェクトはオープンソースですか？ + +GitHub 上で[新しいプロジェクトを作る](https://help.github.com/articles/creating-a-new-repository/)際、リポジトリをパブリックにするかプライベートにするか、2 つの選択肢があります。 + +![リポジトリの作成](/assets/images/legal/repo-create-name.png) + +**GitHub 上のプロジェクトをパブリックにするということと、プロジェクトにライセンスを設定することは同じではありません。** パブリックプロジェクトは [GitHub の Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) によって保護されます。これによって、他の人があなたのプロジェクトを見たりフォークすることを許可します。しかし、それ以外の点については許可していません。 + +もし、他に人に対してプロジェクトの利用、配布、変更、コントリビュートをしてもらいたいと思うのであれば、オープンソースライセンスをプロジェクトに含める必要があります。たとえあなたのプロジェクトがパブリックだったとしても、もしあなたがプロジェクトのソースコードを他のプロジェクトで使って良いと明記しない限りは、他の人はそのプロジェクトのコードのどの部分も合法的に使うことができません。 + +## 私のプロジェクトを守るのに必要な概要だけを教えてください。 + +あなたはラッキーです。なぜなら、今日ではオープンソースライセンスは標準化されていて、簡単に使うことができます。既存のライセンスを直接プロジェクトにコピーペーストすることが可能です。 + +[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 といったものがあります。 + +その一方で、もし依存するライブラリの中に「強いコピーレフト」（寛容なライセンス同様、誰でも利用してよいが、その条件としてライブラリを利用するプロジェクトも同じライセンスである必要がある）の場合、あなたのプロジェクトでも同じライセンスを使う必要が出るでしょう。よく使われる強いコピーレフトのライセンスには、 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/)も使うことができます。 + +## プロジェクトのライセンスを変更したいときはどうしたら良いでしょう？ + +ほとんどのプロジェクトはライセンスを変更する必要は発生しません。しかし、時々状況が変わることがあります。 + +例えば、プロジェクトが成長するに従って依存関係やユーザーが増えたり、あなたの企業が戦略を変更したり、こういった理由によって異なるライセンスが必要になることがあります。それに加えて、もしプロジェクトを開始する際にライセンスを指定していなかったら、ライセンスをあとから追加するということはライセンスを変更することと実質上同じになります。ライセンスを追加したり変更する際に考えるべき重要なポイントは 3 つあります： + +**事態は複雑です。** ライセンスの互換性や遵守を検討したり、誰がコピーライトを保持しているのかを調査することは、すぐに複雑で混乱するものだとわかるでしょう。新しいリリースやコントリビュートについてのみ、新しいが互換性のあるライセンスに切り替えるのと、過去のコントリビュートの全てのライセンスを切り替えることとは事情が異なります。ライセンスを変更したいと思い始めた時に、法務部門を巻き込みましょう。たとえプロジェクトのコピーライトの保有者からライセンスの変更について許可を得ている（もしくは得ることが可能）としても、プロジェクトの他のユーザーやコントリビューターへの影響をきちんと考慮しましょう。ライセンスの変更は、あなたのプロジェクトにおける「運営上の大きな出来事」だと考えるようにしましょう。そうすることで、プロジェクトの利害関係者と明確なコミュニケーションと相談を行い、物事が円滑に進むようになります。プロジェクト発足時に適切なライセンスを選んで使うべきなのはこういった事情のためです！ + +**プロジェクトの既存のライセンス。** もし既存のライセンスとこれから変更しようとしているライセンスで互換性があるのであれば、単に新しいライセンスを使い始めれば大丈夫です。なぜなら、もしライセンス A がライセンス B と互換性がある場合、ライセンス B の規約に従っているのであればライセンス A の規約も遵守していることになるからです（ただし、必ずしも逆は成り立ちません）。もし現在使っているのが寛容なライセンス（例えば MIT ）であれば、 MIT ライセンスと関連するコピーライト表示を保ちつづける（つまり、 MIT ライセンスの最低限の条件は守り続ける）かぎりは、より条件の多いライセンスに変更することができます。しかし、現在使っているライセンスが寛容でなく（例えばコピーレフトやライセンスがない場合）、あなたが単一のコピーライト保持者ではない場合、単純にライセンスを MIT に変更することはできません。基本的に寛容なライセンスでは、プロジェクトのコピーライト保有者は前もってライセンスの変更を許可しているということになります。 + +**プロジェクトの既存のコピーライト保有者。** もしあなたがプロジェクトの単独のコントリビューターなのであれば、あなたかあなたの会社がプロジェクトの単独のコピーライト保有者です。あなたやあなたの企業が望むどんなライセンスの追加や変更をすることができます。そうでない場合は、ライセンスの変更にあたって同意を取る必要のある他のコピーライト保有者がいるかもしれません。それは誰でしょうか？あなたのプロジェクトにコミットをしたことがある人は第一の候補になります。しかし、場合によってはコピーライトを保有しているのは彼らの雇用主かもしれません。他にも、ほんの少しのコントリビュートをした人々について考慮が必要かもしれません。一定量以下の変更しかないコントリビュートに対してはコピーライトを保有できないという明確なルールがない場合もあるからです。比較的小さくて歴史の浅いプロジェクトであれば、イシューやプルリクエストで全ての既存のコントリビューターからライセンスの変更についての同意を取ることは実現可能かもしれません。巨大で歴史の長いプロジェクトであれば多くのコントリビューター、場合によってはその相続人を探し出す必要があります。 Mozilla は Firefox や Thunderbird と関連するソフトウェアのライセンスを変更するのに多くの時間（2001 年ー 2006 年）を費やしました。 + +こういったことを行う代わりに、既存のオープンソースライセンスの範疇を超えて、前もってコントリビューターとある特定の条件でライセンス変更を許容するような同意（後述の追加のコントリビューターアグリーメント）を結ぶこともできます。こうすることで、ライセンス変更の複雑さは少しは緩和されます。事前に弁護士からより多くの助けを得ることができるでしょうし、実際にライセンス変更をする際にはプロジェクトの利害関係者を明確なコミュニケーションができるでしょう。 + +## 私のプロジェクトでは追加のコントリビューターアグリーメントが必要でしょうか？ + +おそらく必要ありません。大部分のオープンソースプロジェクトでは、オープンソースライセンスはインバウンド（コントリビューターから）もアウトバウンド（他のコントリビューターやユーザー向け）の両方のライセンスとして使うことができます。もしプロジェクトを GitHub 上においているのであれば、 GitHub の利用規約によってインバウンドとアウトバウンドが同じであるということがデフォルトとして[明記されています](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license)。 + +追加のコントリビューターアグリーメントはしばしば Contributor License Agreement (CLA) と呼ばれます。これを作ることで、プロジェクトのメンテナーは運用上の手間が必要になってきます。どのくらいの手間がかかるかはプロジェクトとやり方によります。簡単な同意であれば、コントリビューターに対してプロジェクトのオープンソースライセンスに従ってコントリビュートする権利があるとクリックひとつで同意できる様になるでしょう。より複雑な同意になると、法務のレビューとコントリビューターの雇用主の署名が必要になるかもしれません。 + +加えて、「書類作業」が必要になることによって、中にはその作業が不必要、理解しがたい、公正ではない（プロジェクトのオープンソースライセンスによって、同意を受ける人や一般の人がコントリビューターより多くの権利を得る場合）と感じる人が出てくるかもしれません。このような状況では、追加のコントリビューターアグリーメントはプロジェクトのコミュニティからは友好的でないと受け取られるかもしれません。 + + + +追加のコントリビューターアグリーメントがプロジェクトに必要になってくるケースにはこういったものがあります： + +* あなたの弁護士が全てのコントリビューターが明示的にコントリビュート規約に同意する（オンラインかオフラインでの _サイン_）必要があると判断した場合。これはおそらく、オープンソースライセンスだけでは十分でない（たとえ実際には十分だったとしても！）と感じているからでしょう。もしこれが唯一の懸念なのであれば、あるオープンソースライセンスを支持する旨のコントリビューターアグリーメントで十分なはずです。 [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) が、軽量な追加のコントリビューターアグリーメントの良い例です。 +* あなたや弁護士が、開発者が行う全てのコミットは承認されていると表明してほしいと考える場合。[Developer Certificate of Origin](https://developercertificate.org/) の要件はこれを達成するプロジェクトの数です。例えば、Node.js コミュニティは彼らが以前使っていた CLA の[代わりに](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution)、DCO を[使っています](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md)。あなたのリポジトリでDCOの執行を自動化するためのシンプルなオプションは [DCO Probot](https://github.com/probot/dco) を使うことです。 +* プロジェクトで使っているオープンソースライセンスに特許許諾が明記されておらず（ MIT ライセンスのように）、全てのコントリビューターから特許許諾を取る必要がある場合。これは、コントリビューターの中にあなたのプロジェクトやプロジェクトのコントリビューター、ユーザーを巨大な特許ポートフォリオの対象にする企業があるかもしれないためです。 [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) は、 Apache License 2.0 に記載されている特許許諾をコピーした追加のコントリビューターアグリーメントで、一般的に使われています。 +* プロジェクトがコピーレフトライセンスを使っているが、プロプライエタリバージョンも提供する必要がある場合。この場合、全てのコントリビューターから、コピーライトをあなたに割り当てるか、寛容なライセンスを（パブリックに対してではなく）あなたに対して許諾する必要があるでしょう。 [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) はこの種の同意の例です。 +* プロジェクトが成熟するに連れてライセンスを変更する必要があると考えており、コントリビューターに前もってライセンス変更の同意を得ておきたい場合。 + +追加のコントリビューターアグリーメントがあなたのプロジェクトで必要なのであれば、コントリビューターの手間を最小限に留めるために [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/) はフリーやオープンソースプロジェクトの文脈における商標について理解するための実践的なガイドです。 + +* **プライバシー：** あなたのプロジェクトではユーザーのデータを収集していますか？企業のサーバーに秘密の通信を行っていませんか？法務部門が企業の方針や外部の規制を遵守するために手助けしてくれます。 + +もし企業内で初めてのオープンソースプロジェクトを公開しようとしているのであれば、オープンソース化の道のりには上記以外にもあるかもしれません（でも心配しないでください、ほとんどのプロジェクトでは大きな問題はありません）。 + +長期的には、法務部門は企業がオープンソースに関わることでより多くのことを安全に獲得する助けとなります： + +* **従業員のコントリビュートポリシー：** 従業員がどのようにオープンソースにコントリビュートするかを定めた社内規約を作ることを検討しましょう。明確な規約を作ることで従業員同士の混乱も減りますし、従業員に対して企業が最も関心のあるオープンソースプロジェクトに業務の一環であれ空き時間でコントリビュートする手助けにもなります。 Rackspace の [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) もし法務部門が企業のオープンソース戦略を理解し、それに投資している場合は、あなたの努力を妨害するよりもむしろ助けとなってくれるでしょう。 +* **コンプライアンス：** たとえあなたの企業が 1 つもオープンソースプロジェクトをリリースしていないとしても、他の人のオープンソースソフトウェアを使っているはずです。 [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. + + + +* **特許：** あなたの企業は [Open Invention Network](https://www.openinventionnetwork.com/) に参加したいと望むかもしれません。これはメンバーが有名なオープンソースプロジェクトを使うための共有の防御的パテントプールです。もしくは[代替となる特許ライセンス](https://www.eff.org/document/hacking-patent-system-2016)を調査してみましょう。 +* **組織運営：** [社外の法人](../leadership-and-governance/#プロジェクトを運営するのに法人は必要ですか)にプロジェクトを移すことが理にかなっているときは特に必要です。 diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..785398d8472 --- /dev/null +++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,219 @@ +--- +lang: ja +title: オープンソースメンテナーのバランス維持 +description: メンテナンス担当者としてのセルフケアと燃え尽き症候群を避けるためのヒント。 +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +人気のあるオープンソースプロジェクトが成長するにつれて、バランスを保ち、長期的にリフレッシュし、生産性を維持するために明確な境界線を設定することが必要になります。 + +メンテナーの経験とバランスを取るための戦略を知るために、私たちは 40 人の maintainer community のメンバーとワークショップを行い、彼らのオープンソースでの燃え尽き症候群に対する第一線での経験と、バランスを保つための実践を学ぶことができました。ここで「パーソナルエコロジー」という概念が登場します。 + +「パーソナルエコロジー」とはなんでしょうか？described by the Rockwood Leadership Institute によると、「生涯にわたってエネルギーを維持するために、バランス、ペース、効率を維持すること」を意味します。これにより、私たちの会話のフレームワークを作り、メンテナーが自分の行動や貢献を、時間とともに進化する大きな生態系の一部であると認識する助けとなりました。燃え尽き症候群は、[WHO によって定義されるように](https://icd.who.int/browse/2025-01/foundation/en#129180281) 、慢性的な職場でのストレスから生じる症候群であり、メンテナーの間では珍しくありません。これは、モチベーションの喪失、集中力の欠如、および共同作業者やコミュニティとの共感の欠如に繋がります。 + + + +パーソナルエコロジーの概念を取り入れることで、燃え尽き症候群を積極的に回避し、セルフケアを優先し、最高の仕事をするためのバランスを維持することができます。 + +## メンテナーとしてのセルフケアと燃え尽き症候群を回避するためのヒント + +### オープンソースで働く動機を明確にする + +オープンソースのメンテナンスのどの部分にあなたの活力が湧いてくるか、じっくり考えてみましょう。あなたのモチベーション理解することで、新しい課題に取り組む準備ができ、仕事に優先順位をつけることができます。ユーザーからの好意的なフィードバックであれ、コミュニティとの協力や交流の喜び、コードに没頭する満足感など、あなたのモチベーションを認識することで、集中力を高める指針になります。 + +### バランスを崩し、ストレスを感じる原因を振り返る + +燃え尽きてしまう原因を理解することは重要です。オープンソースのメンテナーの間で見られるいくつかの共通のテーマは以下の通りです。 + +* **肯定的なフィードバックの欠如:** ユーザーは苦情があるときに接触する可能性が高いです。全てが順調に進んでいる場合、ユーザーは黙っている傾向があります。あなたの貢献がどのような変化をもたらしているかを示すポジティブなフィードバックがないまま、問題のリストが増えていくのを見るのは、がっかりするでしょう。 + + + +* **「No」と言わない:** オープンソースプロジェクトでは、必要以上の責任を負うことは簡単です。それがユーザーであれ、貢献者であれ、他のメンテナーであれ、彼らの期待に答えられるとは限りません。 + + + +* **一人での作業:** メンテナーであることは非常に孤独です。例え同じメンテナーのグループで働いていたとしても、ここ数年、分散チームを直接集めるのは難しくなっています。 + + + +* **時間やリソースの不足:** これは特にプロジェクトに取り組むために自分の自由な時間を犠牲にしなければならないボランティアのメンテナーにとって特に当てはまります。 + + + +* **矛盾する要求:** オープンソースは様々な動機を持ったグループで溢れており、その間を行き来するのは難しいことがあります。オープンソースの仕事で給料をもらっている場合、雇用主の利益はコミュニティの利益と対立することがあります。 + + + +### 燃え尽きの兆候に注意 + +あなたは 10 週間、10 ヶ月、10 年とこのペースを続けることができますか？ + +[@shaunagm](https://github.com/shaunagm) による [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) や のようなツールがあり、自分の現在のペースを振り返り、調整できる点があるかどうかを確認することができます。一部のメンテナーは、睡眠の質や心拍数変動 (両方ともストレスに関連している) のような指標を追跡するためにウェアラブル技術も利用しています。 + + + +### 自分自身とコミュニティを維持し続けるためには何が必要だろうか？ + +これは各メンテナーによって異なり、生活の段階や外部要因によって変わるでしょう。しかし、以下は私たちが耳にしたいくつかのテーマです： + +* **コミュニティに頼る:** 仕事の委譲や貢献者の探し方は、仕事の負担を軽減できます。プロジェクトの連絡窓口を複数持つことで、心配することなく休憩を取ることができます。[Maintainer Community](http://maintainers.github.com/) のようなグループで他のメンテナーや広いコミュニティと繋がることができます。これは、相互支援や学びのための素晴らしいリソースとなるでしょう。 + + ユーザーコミュニティとの交流方法も探して、定期的にフィードバックを受け取り、オープンソースの作業の影響を理解することができます。 + +* **資金調達をさぐる:** ピザのお金を探しているのか、フルタイムのオープンソースを探しているのか、サポートするリソースはたくさんあります！最初のステップとして、[GitHub Sponsors](https://github.com/sponsors)を有効にして、他の人があなたのオープンソースの作業をスポンサーすることを許可します。フルタイムに移行することを考えている場合は、次回の [GitHub Accelerator](http://accelerator.github.com/) に応募してみて下さい。 + + + +* **ツールを使う:** [GitHub Copilot](https://github.com/features/copilot/) や [GitHub Actions](https://github.com/features/actions) のようなツールを使って、退屈な作業を自動化し、より意味のある貢献のために時間を確保しましょう。 + + + +* **休息と充電:** オープンソース以外の趣味や興味の時間を作りましょう。週末は休んでリフレッシュし、[GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) に反映させましょう！一晩ぐっすり眠れるかどうかで、長期的な努力を継続できるかどうかが大きく変わってきます。 + + プロジェクトのある側面が特に楽しいと感じるのであれば、その楽しさを 1 日を通して体験できるように仕事を構成してみましょう。 + + + +* **境界線を設ける:** 全ての要求に「 Yes 」と言うわけにはいきません。これは、「今すぐそれに対応することはできませんし、将来的にも考えていません」とシンプルに伝えることや、READMEに自分が取り組みたいことや取り組みたくないことを明記することも含みます。例として、「明確な理由が示されたPRだけをマージする」とか、「隔週の木曜日の18時から19時にだけ問題をレビューする」といったことを伝えることができます。これにより、他の人たちに対する期待値を明確にし、また、あなたの時間に求められることに対して柔軟に対応するための基準を提供することができます。 + + + + 不利益な行動や否定的な交流を断ち切る毅然とした態度を身につけましょう。どうでもいいことにはエネルギーを使わなくても大丈夫です。 + + + + + +忘れないでください、パーソナルエコロジーは継続的な実践であり、オープンソースの旅を進める中で進化していきます。自分自身のケアを優先し、バランスを保つことで、効果的かつ持続可能にオープンソースコミュニティに貢献できます。これにより、あなた自身の幸福とプロジェクトの長期的な成功の両方を確保することができます。 + +## その他のリソース + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid +* [Governing Open](hhttps://governingopen.com/) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series + +## 貢献者 + +このガイドのために経験やヒントを提供してくれた全てのメンテナーに感謝します！ + +このガイドブックは、[@abbycabs](https://github.com/abbycabs) によって作成されました。： + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/ja/metrics.md b/_articles/ja/metrics.md new file mode 100644 index 00000000000..756ff67548c --- /dev/null +++ b/_articles/ja/metrics.md @@ -0,0 +1,126 @@ +--- +lang: ja +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 をいつ、どこで、どのように使っているかを知ることができ、修正や機能の優先順位付けができるようになっています。 + +人気を得ることだけが全てではありません。人々がオープンソースプロジェクトに参加する理由は様々です。メンテナーとしてのあなたのゴールが注目を集めることであったり、あなたのコードを共有すること、もしくは単に楽しみたいのであれば、メトリクスはあなたにとって重要ではないかもしれません。 + +もしあなたがプロジェクトをより深いレベルで _理解したいと思っている_ のであれば、以降を読んでプロジェクトの活動を分析する方法を学びましょう。 + +## 発見 + +他の人があなたのプロジェクトにコントリビュートしてくれるようになるには、彼らにあなたのプロジェクトの存在を知ってもらう必要があります。この質問を自問してみましょう: _人々はこのプロジェクトをみつけられているだろうか？_ + +![トラフィックグラフ](/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 、プロジェクトのウェブサイトからの流入や他のオープンソースプロジェクトやウェブサイトからの流入などです。 + +## 使われ方 + +人々は、インターネットという荒野であなたのプロジェクトを見つけようとしているのです。理想的には、あなたのプロジェクトを見かけたらすぐに、使いたいと思って欲しいわけです。そこで、あなたが気になるであろう2つ目の質問はこれです： _人々はこのプロジェクトを使っているだろうか？_ + +もしプロジェクトを配布するのに 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) + +もし、プロジェクトを訪問してくれている人の数に比べて利用率が低いようであれば、考えられる理由は以下の2つのどちらかでしょう: + +* 訪問してくれた人にユーザーになってもらうのに失敗している +* 間違った人々にアピールしている + +例えば、あなたのプロジェクトが Hacker News のトップページに載った場合、トラフィックのスパイクが発生するでしょうが、コンバージョンレートは低下します。 Hacker News を見ている全員にリーチしてしまうからです。しかし、もしあなたのプロジェクトが Ruby を使っていて、 Ruby のカンファレンスで取り上げられたのであれば、ターゲットとしている人々にリーチできるのでより高いコンバージョンレートになる可能性が高くなります。 + +あなたのプロジェクトに興味を持った人がどこから来ているかを把握し、上記の2つの問題が起きていないかプロジェクトページでフィードバックを求めてみましょう。 + +人々があなたのプロジェクトを使っていることがわかったら、どのように使っているかを知りたくなるでしょう。あなたのプロジェクトをフォークして、機能を追加しているのでしょうか？彼らは科学プロジェクトのために使っているのでしょうか、それともビジネスで使っているのでしょうか？ + +## リテンション + +あなたのプロジェクトを見つけて使っている人がいるということがわかりました。あなたが自問するであろう次の疑問はこれでしょう： _人々はプロジェクトにコントリビュートしているだろうか？_ + +コントリビューターについて考え始めるのに早すぎる事はありません。あなた以外の人々からの支援なしでは、プロジェクトが有名（沢山の人が使っている）になってもサポートされていない（必要なメンテナー作業を行うことが出来ない）という不健康な状況に陥るリスクがあります。 + +活動的だったコントリビューターも最終的には他に移ってしまうため、リテンションには[新しいコントリビューターの流入](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) + +* **初めてのコントリビューター、一時的なコントリビューター、常連のコントリビューター:** 新しいコントリビューターを獲得できているかどうかや、彼らが再度コントリビュートしてくれているかどうかをトラッキングします。（一時的なコントリビューターとは、コミット数が少ないコントリビューターのことです。それが1コミットだけの人なのか、5コミット以下の人なのかはあなた次第です）。新しいコントリビューターが来ないと、プロジェクトのコミュニティは停滞してしまいます。 + +* **オープンなイシューとオープンなプルリクエストの数:** もしこれらの数値が高すぎるようであれば、イシューのトリアージやコードレビューに手助けが必要かもしれません。 + +* **_オープンされた_ イシューと _オープンされた_ プルリクエストの数:** オープンされたイシューの数から、イシューをオープンするほどあなたのプロジェクトを気にかけている人がいるということがわかります。もし時間を経るに従ってその数が増えているのであれば、より多くの人がプロジェクトに興味を持ってくれているということを示しています。 + +* **コントリビュートの種類:** 例えば、コミット、タイポやバグの修正、イシューへのコメントなどです。 + + + +## メンテナーの活動 + +最後に、プロジェクトのメンテナーが受け取ったコントリビュートを処理することが出来ているかどうかを確かめましょう。自問すべき最後の質問はこれです： _私は（もしくは私達は）コミュニティに反応しているだろうか？_ + +反応のないメンテナーはオープンソースプロジェクトのボトルネックとなります。もし誰かがコントリビュートしようとしても、メンテナーから返事がなければ彼らはがっかりして去ってしまうでしょう。 + +[Mozilla の調査によると](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)、メンテナーの反応の早さは繰り返しコントリビュートしてもらうための重大な要素です。 + +イシューに対してでもプルリクエストに対してでも、コントリビュートに対してあなた（もしくは別のメンテナー）が反応するのにかかった時間をトラッキングすることを検討しましょう。反応をするために必ずしもアクションを起こす必要はありません。一言こういうだけでも良いのです： _「提案ありがとうございます！来週確認します。」_ + +下記のようなコントリビュートのプロセスのステージごとの時間を計測することも出来ます： + +* イシューがオープンである平均期間 +* イシューがプルリクエストによってクローズされたかどうか +* 古くなったイシューがクローズされたかどうか +* プルリクエストをマージするまでの平均期間 + +## 人々について学ぶために📊を使いましょう + +メトリクスを理解することで、活発で成長するオープンソースプロジェクトを作り上げる助けとなります。たとえ全ての指標をダッシュボードで可視化していなくても、プロジェクトを成功させるために必要な行動の種類に注目するために上述のフレームワークを使いましょう。 diff --git a/_articles/ja/security-best-practices-for-your-project.md b/_articles/ja/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..c1274dc144b --- /dev/null +++ b/_articles/ja/security-best-practices-for-your-project.md @@ -0,0 +1,158 @@ +--- +lang: ja +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/ja/starting-a-project.md b/_articles/ja/starting-a-project.md new file mode 100644 index 00000000000..6eca1de6a5e --- /dev/null +++ b/_articles/ja/starting-a-project.md @@ -0,0 +1,357 @@ +--- +lang: ja +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/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/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 がそれを認識し、見ている人に自動的に表示してくれます。 + +### ライセンスを選ぶ + +オープンソースライセンスは、他の人が恐れを感じることなくあなたのプロジェクトを使い、コピーし、修正し、コントリビュートする事を保証します。また、あなたを法的な面倒事からも守ってくれます。**あなたがプロジェクトをオープンソースにするときは必ずライセンスを含めるようにしましょう。** + +法的な作業は楽しくはありません。既存のライセンスをあなたのリポジトリにコピーペーストできるというのは良い知らせでしょう。あなたの大事な作品を守るのに1分しかかかりません。 + +[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 プロジェクトはオープンソースになります。 + +![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) + +オープンソースプロジェクトを管理する上での法的な面でまだ疑問や懸念があるのであれば、[こちらを参照して下さい](../legal/)。 + +### README を書く + +README はあなたのプロジェクトをどうやって使うかを説明するだけにとどまりません。そこでは、なぜあなたのプロジェクトが重要なのか、そしてユーザーはあなたのプロジェクトで何ができるかということも説明するためのものです。 + +README には、下記の質問に答えるようにしましょう： + +* このプロジェクトは何をするものなのか？ +* なぜこのプロジェクトは便利なのか？ +* どのようにして使い始められるのか？ +* もし必要な場合、どうやったら助けを得られるか？ + +README では、コントリビュートをどのように扱うか、プロジェクトのゴールはなにか、ライセンスや帰属についての情報などといった他の疑問に答えるのに使うこともできる。もしコントリビュートを受け入れたくなかったり、あなたのプロジェクトは運用に乗せる準備が整っていなかったりする場合は、その情報も書きましょう。 + + + +時々、プロジェクトが未完了であったりコントリビュートを求めていないといった理由で README を書くのを避ける人が居ます。これらも README に書いておくと良いでしょう。 + +さらなるヒントとしては、完全な README を書くために @18F の ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) か @PurpleBooth の [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) を読んでみると良いでしょう。 + +README ファイルをルートディレクトリに置くことで、 GitHub が自動的にリポジトリのホームページに表示してくれます。 + +### コントリビュートのガイドラインを書く + +CONTRIBUTING ファイルはあなたのプロジェクトにどうやって参加するのかを伝えるためのものです。例えば、下記の様な情報を含めると良いでしょう： + +* バグレポートの登録の仕方 ([イシューやプルリクエストのテンプレート](https://github.com/blog/2111-issue-and-pull-request-templates)を使ってみましょう) +* 新しい機能の提案の仕方 +* 環境のセットアップとテストの実行の仕方 + +技術的な詳細に加えて、 CONTRIBUTING ファイルはコントリビュートに対する期待値を伝える機会でもあります。例えば： + +* あなたが求めているコントリビュートの種類 +* プロジェクトのロードマップやビジョン +* コントリビューターがどのようにしてあなたにコンタクトすべきか（もしくはすべきでないか） + +暖かく友好的なトーンを使って、（ドキュメントを書く、もしくはウェブサイトを作る、といったような）コントリビュートを具体的に提示することで、新しく来る人が歓迎されていて是非参加したいと思ってもらうのにとても役に立ちます。 + +例えば、 [Active Admin](https://github.com/activeadmin/activeadmin/) は[コントリビュートガイド](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)を下記の内容から始めています： + +> まずはじめに、 Active Admin へのコントリビュートを考えてくれてありがとうございます。あなたのような人々が Active Admin を偉大なツールにしているのです。 + +あなたのプロジェクトの最初期では、 CONTRIBUTING ファイルはシンプルで大丈夫です。常にバグの報告の仕方かイシューの登録の仕方、コントリビュートをする際の技術的な要求（テストなど）を書くようにしましょう。 + +時間が経つにつれて、 CONTRIBUTING ファイルに頻繁に聞かれる質問を加えるでしょう。こういった情報を書くことによって、同じ質問を何度も繰り返ししてくる人が減っていくでしょう。 + +CONTRIBUTING ファイルを書くときに更に役に立つものとして、 @nayafia の [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) や @mozilla の ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) も参考になるでしょう。 + +README に CONTRIBUTING ファイルへのリンクをすることで、より多くの人の目に触れるようになります。 [CONTRIBUTING ファイルをプロジェクトのリポジトリに置くことで](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)、 GitHub でコントリビューターがイシューを登録したり、プルリクエストをオープンする際に、そのファイルへのリンクが自動的に表示されます。 + +![Contributing guidelines](/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) は Node.js に `window.fetch` を追加するものです）。 + +明快さを第一に考えましょう。ダジャレは面白いですが、ジョークは他の文化やあなたとは異なる経験を持った人には通じないこともあるということを覚えておきましょう。潜在的なユーザーには企業の従業員もいるかもしれません。彼らがあなたのプロジェクトについて職場で説明する時に居心地の悪い思いをさせたくはないでしょう。 + +### 名前の衝突を避ける + +[同じような名前のオープンソースプロジェクトを調べましょう](http://ivantomic.com/projects/ospnc/)。同じ言語やエコシステムを共有する場合は特にです。もし既存の有名なプロジェクトと名前が同じ部分があると、外から見た人を混乱させてしまうでしょう。 + +ウェブサイトや Twitter のハンドルや他であなたのプロジェクト名を使いたいのであれば、使いたい名前を使えるかどうか確かめましょう。理想的には、心の平穏のために[すぐにそれらの名前を予約しましょう](https://instantdomainsearch.com/)。たとえ、今すぐに使うつもりがないとしても。 + +プロジェクトの名前が商標の侵害をしていないか確かめましょう。後になってある企業があなたのプロジェクトをやめるように言ってきたり、法的措置さえしてくるかもしれません。そんなリスクは見合いません。 + +商標を侵害していないかを調べるには [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) を確認しましょう。もし企業にいるのであれば、この点は[法務部門が助けてくれる](../legal/)ことの一つでしょう。 + +最後に、あなたのプロジェクト名で Google 検索をしてみましょう。人々は簡単にあなたのプロジェクトを見つけることができるでしょうか？検索結果の中になにか望ましくないものが表示されていないでしょうか？ + +### 文書（やコード）の書き方はあなたのブランディングにも影響します！ + +あなたのプロジェクト全体を通して、多くの文書を書くでしょう： README 、チュートリアル、コミュニティドキュメント、イシューへの返答、もしかしたらニュースレターやメーリングリストもあるかもしれません。 + +公式のドキュメントであれ、カジュアルなメールであれ、あなたの文書のスタイルはプロジェクトのブランドの一部になります。見る人にどのようにして伝わるかや、あなたが伝えたいトーンかどうかを検討しましょう。 + + + +暖かく、排他的でない言葉遣い（一人の人を指すときであっても「彼ら」を使う、といったような）をすることで、あなたのプロジェクトで新しいコントリビューターが歓迎されていると感じてもらうことに繋がります。シンプルな言葉遣いをすることにこだわりましょう。あなたのプロジェクトを見る人の多くは英語のネイティブスピーカーではないかもしれません。 + +あなたがどう文書を書くかに加えて、あなたのコーディングスタイルもプロジェクトのブランドの一部になるかもしれません。 [Angular](https://github.com/johnpapa/angular-styleguide) と [jQuery](https://contribute.jquery.org/style-guide/js/) の2つは厳密なコーディングスタイルとガイドラインを持つプロジェクトの例です。 + +かならずしもプロジェクトを始める際にスタイルガイドを書く必要はありませんし、とにかく異なるコーディングスタイルを盛り込むのが楽しいと思うかもしれません。しかし、あなたの文書やコーディングスタイルが異なるタイプの人々を惹きつけることもあれば落胆させることもあるということを予期しておくべきです。プロジェクトの最初期はあなたが望む先例を作る良い機会です。 + +## 立ち上げ前のチェックリスト + +あなたのプロジェクトをオープンソースにする準備が整いましたか？ここにあなたの助けとなるよう、チェックリストを用意しました。全てにチェックが付きましたか？そうであれば準備万端です！ +["publish" をクリックして](https://help.github.com/articles/making-a-private-repository-public/)、自分を褒めてあげましょう。 + +**ドキュメント** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**コード** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**人々** + +もし個人でやっているのであれば： + +
+ + +
+ +企業や組織でやっているのであれば： + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## やりました！ + +おめでとう！あなたの最初のプロジェクトをオープンソースにしました。成果はどうあれ、公の場で働くことはコミュニティへの贈り物です。あらゆるコミット、コメント、プルリクエストによって、あなた自身や他の人が学び、成長する機会を提供しているのです。 diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md index 6d6ec6a0e4e..26a6bb5407e 100644 --- a/_articles/ko/best-practices.md +++ b/_articles/ko/best-practices.md @@ -1,15 +1,8 @@ --- lang: ko -title: 메인테이너를 위한 모범 사례 -description: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈소스 메인테이너로서 여러분의 삶을 편하게 만들어줍니다. +title: 관리자의 모범 +description: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈소스 관리자로서 여러분의 삶을 더 편하게 만들어 줍니다. class: best-practices -toc: - what-does-it-mean-to-be-a-maintainer: "메인테이너가 된다는 것은 무엇을 의미하나요?" - documenting-your-processes: "진행과정을 문서화하기" - learning-to-say-no: "아니오라고 말하는 것을 배우기" - leverage-your-community: "커뮤니티 활용하기" - bring-in-the-robots: "로봇 가져오기" - its-okay-to-hit-pause: "멈추는것도 좋습니다" order: 5 image: /assets/images/cards/best-practices.png related: @@ -17,264 +10,267 @@ related: - leadership --- -## What does it mean to be a maintainer? +## 관리자라는 직책이란 -많은 사람들이 사용하는 오픈소스 프로젝트를 유지한다면, 적은 양으로 코딩하고 더 많은 이슈에 대응할 수 있습니다. +여러분이 많은 사람들이 사용하는 오픈소스 프로젝트를 관리하고 있다면, 점점 코딩은 덜 하고 이슈에 더 많이 반응하고 있다는 것을 알아차렸을 것입니다. -프로젝트 초기 단계에서 새로운 아이디어를 실험하고 원하는 것을 기반으로 의사 결정을 내리고 있습니다. 프로젝트의 인기가 높아짐에 따라 사용자와 기여자들과 더 잘 일할 수 있습니다. +프로젝트의 초기 단계에서, 여러분은 새로운 아이디어를 실험하고 여러분이 원하는 것을 바탕으로 결정을 내리고 있습니다. 프로젝트가 인기를 끌면서 여러분은 사용자 및 기여자들과 더 많은 일을 하게 될 것입니다. -프로젝트를 유지하려면 코드 이상의 것을 요구합니다. 이러한 작업은 예상치 못한 경우가 많지만 성장하는 프로젝트와 마찬가지로 중요합니다. 우리는 진행 문서화에서 시작해서 커뮤니티 활용에 이르기까지 당신의 삶을 편하게 해주는 몇 가지 방법을 모아봤습니다. +프로젝트 유지에는 코드 이상의 것이 필요합니다. 종종 예상치 못한 과제가 주어지기도 하지만 성장하는 프로젝트에게 이는 중요한 일입니다. 프로세스를 문서화하는 것에서부터 커뮤니티를 활용하는 것까지 여러분의 삶을 더 쉽게 만들 수 있는 몇 가지 방법을 모아 보았습니다. -## Documenting your processes +## 프로세스 문서화하기 -글을 작성하는 것은 메인테이너가 할 수있는 가장 중요한 일 중 하나입니다. +기록해두는 것은 여러분이 관리자로서 할 수 있는 가장 중요한 일 중 하나입니다. -문서는 자신의 생각을 분명히 할 뿐만 아니라, 다른 사람들이 물어보기도 전에 필요하거나 기대하는 것을 이해하도록 도와줍니다. +문서화는 여러분의 생각을 분명히 할 뿐만 아니라 여러분이 필요로 하거나 기대하는 것을 사람들이 직접 물어보지 않고도 알 수 있게 합니다. -글을 쓰게되면 무언가 범위에 맞지 않을 때 아무 말도 달지 않게됩니다. 또한 사람들이 쉽게 참여하게 도움을 줍니다. 다만 누가 프로젝트를 읽고 사용하는지 알 수는 없습니다. +문서화를 해 두면 여러분의 의도에 맞지 않는 의견을 기각하기 더 쉬워집니다. 또한 사람들이 프로젝트에 참여하기 더 쉽게 만듭니다. 어떤 사람들이 여러분의 프로젝트를 보거나 사용하고 있는지 모르니까요. -전체 단락을 사용하지 않더라도, 글 머리 기호라도 적어둔다면 아에 작성하지 않는 것보다는 좋습니다. +모든 항목에 대해 작성하지 않아도 괜찮습니다. 주요 항목에 대해 적어두는 것이 아무 것도 적어놓지 않는 것보다는 낫습니다. -### 프로젝트의 비전을 써내려가기 +여려분의 문서를 항상 최신으로 유지할 수 있도록 노력하세요. 항상 업데이트하기 어렵다면 오래된 문서를 지우거나 'outdated'로 표시해서 기여자들의 업데이트를 환영한다고 알리세요. -먼저 프로젝트의 목표를 써내려갑니다. README에 추가하거나, VISION이라 불리는 별도의 파일을 작성하십시오. 프로젝트 로드맵과 같이 도움이 될 수 있는 다른 인위적인 결과물이 있는 경우, 이를 공개 할 수도 있습니다. +### 프로젝트의 비전을 서술하세요 -명확하고, 문서화된 비전을 가지고 있으면 집중력을 유지하고 다른 기여자로부터 "scope creep"를 피할 수 있습니다. +프로젝트의 목표를 이야기하는 것부터 시작하세요. 이를 README 파일 또는 새로운 VISION 파일에 추가하세요. 프로젝트 로드맵 등 도움이 될만한 자료가 더 있다면 그것도 게시하세요. -예를 들어, @lord는 프로젝트 비전을 가짐으로써 시간을 보낼 요청을 파악하는 데 도움이 된다는 것을 발견했습니다. 새로운 메인테이너인 그는 [Slate](https://github.com/lord/slate)에 대한 첫번째 기능 요청을 받았을 때 프로젝트의 범위를 고수하지 않은 것을 후회했습니다. +명료하고 문서화된 비전은 여러분을 집중할 수 있게 하고, 사람들의 기여로부터 생길 수 있는 'scope creep'을 피할 수 있도록 해줍니다. + +예를 들어 @lord는 프로젝트 비전을 가지면 어떤 요구에 시간을 투자해야 하는지 파악하는 데 도움이 된다는 사실을 깨달았습니다. 새로운 관리자로서의 그는 [Slate](https://github.com/lord/slate)의 첫 기능 요청을 받았을 때 프로젝트의 본 목적에 집중하지 않았던 것을 아쉽게 생각했습니다. -### 생각을 소통하기 +### 기대하는 바를 전달하세요 -규칙은 신경을 쓸 수록 더 쓰일 수 있습니다. 때로는 다른 사람들의 행동을 감시하거나 모든 재미를 없애는 것처럼 느껴질 수도 있습니다. +규칙을 나열하는 것은 머리 아픈 일입니다. 가끔 여러분이 사람들의 행동에 간섭하거나 재미를 없애는 것이 아닌가 하는 생각이 들 수도 있습니다. -그러나 공정하게 작성되고 시행되면, 좋은 규칙은 메인테이너에게 힘을 줍니다. 그것들은 하고 싶지 않은 일을 하도록 끌리지 못하게 합니다. +그러나 공정하게 제정되고 시행되는 좋은 규칙은 관리자에게 제어력을 부여합니다. 하고 싶지 않은 일에 억지로 끌려들어가지 않게 해줍니다. -프로젝트를 직접 경험하는 대부분의 사람들은 메인테이너가 겪는 상황에 대해 알지 못합니다. 그들은 그것에 대해 일하기 위해 돈을 받는다고 가정할 지도 모릅니다, 특히 그들이 정기적으로 사용하고 의존하는 것들이 대부분입니다. 하지만 메인테이너는 어쩌다 한번에 프로젝트에다가 많은 시간을 할애하지만, 이제는 새로운 직업이나 가족 구성원으로인해 바빠졌습니다. +여러분의 프로젝트를 찾아오는 대부분의 사람들은 여러분이나 여러분의 환경에 대해 아무것도 알지 못합니다. 프로젝트에 의지하며 꾸준히 사용하는 사람들은 여러분이 그 프로젝트에서 작업하면서 보수를 받는다고 추측할지도 모릅니다. 언젠가는 프로젝트에 많은 시간을 쏟아부을 수 있었어도 이제는 새 직장이나 가족 구성원으로 정신없을 수도 있습니다. -이 모든 것은 완벽하게 괜찮습니다! 다른 사람들이 그것에 대해 알고 있는지 확인하시기 바랍니다. +전부 괜찮습니다! 대신 사람들에게 그렇다는 사실을 알리세요. -당신의 프로젝트를 아르바이트로 유지하거나 순수하게 자원 봉사로 진행하는 경우, 당신이 가진 시간에 대해 솔직하게 말하십시오. 이것은 프로젝트가 요구하는 시간, 또는 다른 사람들이 당신의 개발에 소비하기를 원하는 시간과 같지 않습니다. +프로젝트 관리를 아르바이트식 혹은 자발적으로 하고 있다면 여러분이 가진 시간에 대해 솔직해지세요. 프로젝트에 투자해야 한다고 여러분이 생각하는 시간과, 사람들이 여러분이 프로젝트에 투자하기를 원하는 시간과는 다릅니다. -다음과 같은 몇 가지 규칙을 적어 두는 것이 좋습니다: +아래와 같은 규칙은 정해 두는 편이 좋습니다. -* 기여를 검토하고 수락하는 방법 (_검사가 필요한가요? 이슈 템플릿?_) -* 당신이 수락할 기여 유형 (_코드의 특정 부분에 대해서만 도움을 원하십니까?_) -* 후속 조치가 필요한 순간 (_ex. "7일 이내에 관리자로부터 응답을 받을 수 있습니다. 그때까지 아무 것도 듣지 못했다면 쓰레드에 핑을 보내세요."_) -* 프로젝트에 할애하는 시간 (_ex. "이 프로젝트에 일주일 중 약 5시간만 할애하고 있습니다."_) +* 기여를 검토하고 받아들이는 방식 (_테스트를 수행해야 하나요? 정해진 이슈 템플릿이 있나요?_) +* 여러분이 받아들이고자 하는 기여 유형 (_코드의 일부분에만 기여를 받고 싶은가요?_) +* 피드백까지 예상되는 시간 (_ex. "일주일 안에는 관리자의 답변을 받으실 수 있을 것입니다. 그때까지 소식이 없다면 주저 말고 스레드에서 관리자를 호출해주세요" 등._) +* 여러분이 프로젝트에 투자하는 시간 (_ex. "저희는 이 프로젝트에 일주일에 약 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)는 메인테이너와 기여자를 위한 기본 원칙이 있는 프로젝트의 몇 가지 예시입니다. +[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)는 관리자와 기여자를 위한 행동 원칙을 가진 프로젝트의 예시입니다. -### 열린 소통을 유지하기 +### 열린 장소에서 소통하세요 -상호 작용을 문서화하는 걸 잊지 마십시오. 가능한 모든 곳에서 프로젝트 공개에 대한 의사 소통을 유지하십시오. 누군가가 개인적으로 연락하여 기능 요청 또는 지원 필요성에 대해 토론하려고하면, 정중하게 메일링 리스트 또는 이슈 트래커와 같은 공개 의사 소통 채널로 안내합니다. +다양한 토의나 질답을 문서화하는 것을 잊지 마세요. 가능하면 어디에서든 여러분의 프로젝트에 대한 이야기는 공개적으로 하는 것이 좋습니다. 누군가 기능이나 지원 요청을 하기 위해 사적으로 연락한다면, 정중하게 메일링 리스트 혹은 이슈 트래커 등의 공개된 채널로 안내하세요. -다른 메인테이너와 만나거나, 비공개로 중요한 결정을 내릴 경우, 또는 메모를 게시하는 경우에도 마찬가지로, 공개적으로 문서에 기록하십시오. +다른 관리자와 만나거나, 공개하기 어려운 중요한 결정을 내린다면 여러분의 메모 정도라고 해도 내용은 공개적으로 게시하세요. -그러면, 커뮤니티에 가입한 사람은 수년간 그 곳에 있었던 사람과 동일한 정보에 접근 할 수 있습니다. +그러면 여러분의 프로젝트에 막 찾아온 사람도 몇 년간 있었던 사람과 같은 양의 정보를 획득할 수 있습니다. -## Learning to say no +## 거절하는 법 배우기 -당신이 글을 썼습니다. 이상적으로는 모든 사람이 당신의 문서를 읽을 것이지만, 실제로 이 지식이 존재한다는 것을 모르는 다른 사람들에게도 상기시켜야 할 것입니다. +필요한 것들을 문서화했나요? 모두가 문서를 읽는다면 이상적이겠지만 현실은 그렇지 않습니다. 사람들에게 그런 문서가 있다는 사실을 알려주어야 합니다. -그러나 모든 것을 적어둔다면, 규칙을 집행해야 할 상황일때 평범한 상황으로 복귀하는 것에 도움이 됩니다. +그러나 모든 것을 기록하면 규칙을 적용해야 할 때 객관적으로 상황을 해결할 수 있습니다. -아니오라고 말하는 것은 재미없지만, _"기여가 이 프로젝트의 기준과 일치하지 않습니다."_ 는 _"전 당신의 기여가 싫어요"_ 보다 개인적인 느낌이 들었습니다. +거절하는 것은 썩 유쾌한 일이 아닙니다. 하지만 _"당신의 기여는 프로젝트 기준에 맞지 않아요."_가 _"당신의 기여가 마음에 들지 않네요."_보다는 덜 감정적으로 느껴집니다. -당신이 메인테이너로서 만날 수 있는 많은 상황에 적용됩니다: 범위에 맞지 않는 기능 요청, 토론을 이탈한 사람, 불필요한 다른 일을 하는 사람들. +관리자로서, 본 목적에 맞지 않는 기능 요청, 토론과 관련 없는 발언, 불필요한 작업 등 거절이나 제지가 필요한 많은 상황을 맞닥뜨릴 것입니다. -### 친근한 대화를 유지하기 +### 친절한 태도를 유지하세요 -가장 중요한 장소 중 하나인 No라고 말하면서 이슈와 pull request 대기열을 가져옵니다. 프로젝트 메인테이너로서, 여러분은 받아들이기를 원치않는 제안을 필연적으로 받게됩니다. +여러분이 거절하는 경우가 실제로 생기는 중요한 장소 중에는 이슈 목록과 풀 리퀘스트 목록이 있습니다. 프로젝트 관리자로서 피치 못하게 원하지 않는 제안을 받을 때가 있습니다. -기여 내용이 프로젝트의 범위를 변경하거나 비전과 일치하지 않을 수 있습니다. 어쩌면 그 아이디어가 좋지만 구현도가 낮을 수 있습니다. +기여가 프로젝트의 목적을 뒤바꾸거나 비전과 맞지 않을 수도 있고, 아이디어는 좋지만 비효율적으로 구현되어 있을 수 있습니다. -이유에 관계없이, 프로젝트 표준에 맞지 않는 기여 내용을 현명하게 처리할 수 있습니다. +이유와는 상관없이, 여러분은 프로젝트의 기준을 충족하지 않는 기여에 적절하게 대처하면 됩니다. -동의하지 않는 기여를 받는 경우, 첫번째 반응으로는 무시하거나 보지 못했다고 둘러댈 수 있습니다. 이렇게 한다면 다른 사람의 감정에 해를 끼칠 수 있으며 커뮤니티내의 다른 잠재적인 기여자의 능력도 떨어뜨릴 수 있습니다. +적용하고 싶지 않은 기여를 받았을 때, 여러분의 첫 반응은 그 기여를 무시하거나 못 본 척하는 것일지도 모릅니다. 그렇게 하면 기여자의 기분을 상하게 하는 것은 물론, 커뮤니티의 다른 잠재적 기여자들이 동기를 잃게 만들 수도 있습니다. -죄책감을 느끼거나 좋은 사람이 되기위해 원하지 않는 기여는 하지마십시오. 시간이 지남에 귀하의 답변되지 않은 이슈와 PR은 프로젝트에 대한 작업을 훨씬 더 스트레스와 협박으로 느낄 것입니다. +죄책감을 느끼고 싶지 않거나 친절함을 유지하고 싶다고 해서 원치 않는 기여를 내버려 두지 마세요. 시간이 흐르면서 그렇게 남겨진 이슈와 풀 리퀘스트가 여러분이 그 프로젝트에서 하는 작업을 더 성가시고 답답하게 만들 것입니다. -수락하고 싶지 않은 기여는 즉시 닫는 것이 좋습니다. 프로젝트에 이미 많은 양의 백로그가 있는 경우, @steveklabnik 는 [문제를 효율적으로 분류하는 방법](http://words.steveklabnik.com/how-to-be-an-open-source-gardener)에 대한 제안 사항을 제공합니다. +받아들이고 싶지 않은 기여는 즉각적으로 닫는 것이 좋습니다. 이미 여러분의 프로젝트가 쌓인 잔무로 고생하고 있다면, @steveklabnik가 [이슈를 효율적으로 분류하는 요령](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)을 정리해 두었으니 참고하세요. -두번째로는, 기여를 무시하면 귀하의 커뮤니티에 부정적인 신호가 보내집니다. 프로젝트에 기여하는 것은 위협적일 수 있습니다. 특히 다른 사람이 처음인 경우에는 더욱 그렇습니다. 기여를 수락하지 않더라도 그 뒤에 있는 사람을 인정하고 관심을 가져 주신 것에 감사하길 바랍니다. 큰 칭찬입니다! +기여를 무시하는 것은 커뮤니티에 부정적인 신호를 보내는 것과 마찬가지입니다. 프로젝트에의 기여는 쉬운 일이 아닙니다. 특히 처음 기여하는 사람이라면 더 그렇습니다. 그들의 기여를 받아들이고 싶지 않다면, 적어도 그들이 보인 흥미와 노력에 대해 감사를 표하세요. 그것만으로도 큰 칭찬입니다! -기여를 받지 않는다고 가정한 경우에는 이렇게 하십시오: +기여를 받아들이고 싶지 않다면 다음과 같은 방법을 사용하세요. -* 그들의 기여에 **감사해 합니다** -* 가능한 경우 프로젝트의 **범위에 맞지 않는 이유를 설명하고** 개선을 위한 명확한 제안을 합니다. 친절하고 단호하게 말하십시오. -* 필요한 경우 **관련 문서를 링크겁니다**. 수락하고 싶지 않은 것에 대한 반복적인 요청을 발견한 경우, 문서를 반복하여 번복하지 않도록 합시다. -* **request를 닫습니다** +* 기여에 대해 **감사를 표하세요**. +* **왜 기여가 프로젝트의 목적에 맞지 않는지 설명**하고, 가능하다면 개선점을 제시하세요. 친절하면서도 단호하게 말해야 합니다. +* **관련된 문서가 있다면 링크를 첨부**하세요. 비슷한 유형의 잘못된 기여가 계속된다면 문서에 관련 내용을 추가해서 반복 설명하게 되는 일이 없도록 하세요. +* **스레드를 닫으세요**. -응답하는 데 1-2문장 이상 필요하지 않습니다. 예시로, [celery](https://github.com/celery/celery/)의 사용자가 윈도우 관련 오류를 보고 했을때, @berkerpeksag는 [이렇게 반응했습니다](https://github.com/celery/celery/issues/3383): +답변에는 한두 문장이면 충분합니다. 예를 들어 @berkerpeksag는 [celery](https://github.com/celery/celery/) 유저가 윈도우와 관련된 에러를 제보했을 때 [이렇게 답변했습니다](https://github.com/celery/celery/issues/3383). ![Celery screenshot](/assets/images/best-practices/celery.png) -아무도 말을 하지않는다고 해도, @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/)처럼 혼자가 아닙니다: +그래도 거절하기가 두렵다고요? [@jessfraz의 말](https://blog.jessfraz.com/post/the-art-of-closing/)처럼 여러분은 혼자가 아닙니다. -> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want. +> Mesos, Kubernetes, Chromium 같은 여러 오픈소스 프로젝트 관리자들과 이야기해봤는데요. 다들 관리자로서 맡아야 하는 가장 어려운 일이 '원하지 않는 패치를 거절하는 것'이라는 점에 동의했죠. -누군가의 기여를 받아들이지 않으려고 죄책감을 느끼지 마십시오. 오픈소스의 첫 규칙은, @shykes [에 따르면](https://twitter.com/solomonstre/status/715277134978113536): _"아니오는 일시적이며, 예는 영원합니다."_입니다 다른 사람의 열정에 공감하는 것은 좋은 일이지만 기여를 거절하는 것은 그 뒤에있는 사람을 거절하는 것과 동일하지 않습니다. +누군가의 기여를 거절하는 것에 죄책감을 느끼지 마세요. [@shykes의 말](https://twitter.com/solomonstre/status/715277134978113536)에 따르면 오픈소스의 첫 번째 규칙은 _"NO는 일시적이지만 YES는 영원하다"_입니다. 다른 사람이 열중하는 일에 공감하는 것은 좋은 일이지만, 기여를 거절하는 것이 기여를 한 사람을 거절하는 것은 아닙니다. -궁극적으로, 기여가 충분하지 않은 경우, 기여를 수락 할 의무는 없습니다. 사람들이 프로젝트에 기여할 때에는 친절하고 즉각적이어야 하지만, 프로젝트를 더 좋게 만들 것이라고 생각되는 변경 사항만 수락하십시오. 더 자주 아니오라고 말하는 연습을 하면 쉽게 됩니다. 약속합시다. +궁극적으로, 기여가 충분히 좋지 않다면 여러분은 그 기여를 받아들일 의무가 없습니다. 여러분의 프로젝트에 기여하는 사람들을 친절하게 대하고 적극적으로 반응해야겠지만, 여러분의 프로젝트를 발전시킬 것이라고 생각되는 변화만을 받아들이세요. 일단 거절하다 보면 점점 쉬워질 것입니다. 약속할게요. -### 대책 세우기 +### 사전대책을 세우세요 -처음에 원치 않는 기여를 줄이려면, 기여 가이드에 기여를 제출하고 수락하는 프로젝트 진행 과정을 설명하십시오. +처음부터 원치 않는 기여의 양을 줄이고 싶다면 기여 가이드에 여러분의 프로젝트가 기여를 제출 받고 적용하는 과정이 어떻게 이루어지는지 설명하세요. -너무 많은 저품질 기여를 받는다면, 이와 같이 기여자들이 미리 약간의 작업을 해줄 것을 요구하십시오: +질이 낮은 기여를 너무 많이 받고 있다면 기여자들에게 약간의 사전 작업을 요청하세요. 예를 들면 다음과 같습니다. -* 이슈 또는 PR 템플릿/체크리스트 작성하기 -* PR을 제출하기 전에 이슈를 열기 +* 이슈 혹은 풀 리퀘스트 템플릿/체크리스트 작성 +* 풀 리퀘스트 제출 전 이슈 열기 -만약 그들이 규칙에 따르지 않는다면, 즉시 이슈를 닫고 문서를 가리킵니다. +규칙을 따르지 않는다면 바로 이슈를 닫고 관련 문서로 안내하세요. -이러한 접근 방식이 처음에는 불친절하다고 느낄 수도 있지만, 이 대책은 실제로 서로에게도 좋습니다. 그것은 누군가가 받아 들일 수 없는 pull request에 많은 시간 낭비를 초래할 가능성을 줄여줍니다. 또한 작업 부하를 보다 쉽게 ​​관리할 수 ​​있습니다. +이런 접근 방식이 처음에는 불친절하게 느껴질 수도 있지만, 사전에 대비하는 태도는 양쪽 모두에게 좋습니다. 이는 여러분이 어차피 받아들이지 않을 풀 리퀘스트에 누군가 많은 시간을 낭비하는 사태를 방지합니다. 그리고 여러분의 작업 목록을 관리하기 쉽게 만들어 줍니다. -때로는 아니오라고 말하면 잠재적 기여자가 결정을 뒤집거나 비판할 수 있습니다. 그들의 행동이 적대적으로 된다면, [상황을 완화시키기 위한 조치를 취하십시오.](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) 또는 건설적으로 협업하지 않으려는 경우 커뮤니티 자체에서 제거할 수도 있습니다. +가끔 잠재적 기여자가 여러분의 거부 의사를 기분 나빠하거나 비판할 수 있습니다. 그들의 행동이 적대적으로 변한다면 [상황을 완화시키기 위한 조치](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items)를 취하거나, 그들이 건설적으로 협조하려 하지 않는다면 커뮤니티에서 배제하세요. -### 멘토십을 포옹하기 +### 조언을 아끼지 마세요 -커뮤니티의 누군가가 프로젝트 표준에 맞지 않는 기여를 정기적으로 제출할 수도 있습니다. 각자 당사자가 거절을 반복해서 거치는 것은 좌절할 수 있습니다. +커뮤니티의 누군가가 주기적으로 프로젝트의 기준을 충족하지 않는 기여를 제출하는 경우가 있습니다. 그런 기여와 기각이 반복되는 것은 어느 쪽에게든 좌절감을 줍니다. -누군가 당신의 프로젝트에 열성적이지만 약간의 수정이 필요하다면 인내심을 가집시다. 그들의 공헌이 프로젝트의 기대에 부합하지 않는 이유를 각 상황에서 분명하게 설명합니다. 발을 젖게하기 위해 _"좋은 첫 버그,"_라고 표시된 이슈와 같이 더 쉽거나 덜 모호한 작업을 가리키도록 하십시오. 시간이 있다면, 첫번째 기여를 통해 멘토링을 고려하거나 멘토를 기꺼이 도울 수 있는 다른 사람을 커뮤니티에서 찾을 수 있습니다. +누군가 여러분의 프로젝트에 열성적이지만 약간의 개선이 필요해 보인다면, 인내심을 가지세요. 매 상황마다 기여가 왜 프로젝트의 기대를 채우지 못하는지 구체적으로 설명하세요. 뭔가 할 수 있는 일을 주기 위해 _"good first issue"_ 라벨이 달린 이슈처럼 더 쉽고 명료한 작업을 맡기세요. 시간이 있다면 그들의 첫 기여 과정을 직접 멘토링하거나, 커뮤니티에서 적절한 멘토를 구해주는 것도 고려해 보세요. -## Leverage your community +## 커뮤니티 활용하기 -당신은 모든 것을 스스로 할 필요가 없습니다. 프로젝트 공동체가 존재합니다! 적극적으로 참여한 커뮤니티가 없는 경우에도 많은 사용자가 있는 경우, 일하도록 하십시오. +혼자서 모든 일을 맡을 필요는 없습니다. 프로젝트 커뮤니티가 존재하는 이유가 있습니다! 기여자 커뮤니티가 아직 활성화되어 있지 않더라도, 사용자가 많다면 그들을 작업에 이끌어 보세요. -### 작업량을 분할하기 +### 일을 분담하세요 -피치를 받을 다른 사람을 찾고 있다면 주위에 물어보십시오. +함께 일할 사람이 필요하다면 주위에 부탁하는 것에서부터 시작하세요. -새로운 기여자가 반복적으로 기여를 하는 것을 보았을 때, 더 많은 책임을 제공함으로써 자신의 업무로 인정합시다. 원한다면 다른 사람들이 리더십 역할로 성장할 수 있는 방법을 문서화하십시오. +반복적으로 기여하고 있는 사람을 찾았다면 그들에게 더 많은 권한을 주며 그들의 공로를 인정하세요. 그들이 원한다면 관리자 자리까지 맡게 되는 모범적인 경우를 더 많은 사람들에게 보일 수도 있습니다. -@lmccart가 프로젝트 [p5.js](https://github.com/processing/p5.js?files=1)에서 발견한대로 [프로젝트 소유권 공유](../building-community/#share-ownership-of-your-project)를 권장하면 자신의 작업량을 크게 줄일 수 있습니다. +@lmccart가 프로젝트 [p5.js](https://github.com/processing/p5.js)에서 발견한 대로 사람들이 [프로젝트의 소유감을 나눌 수 있도록](../building-community/#프로젝트를-공동으로-소유하세요) 독려하면 여러분이 맡는 일의 양을 현저히 줄일 수 있습니다. -프로젝트가 중단되거나 영구히 중단되어야하는 경우, 다른 사람에게 자신을 대신하도록 요청하는 것은 부끄러운 일이 아닙니다. +잠깐이든 영원히든 여러분의 프로젝트를 떠나야 한다면 누군가에게 여러분의 역할을 대신해 달라고 부탁하는 것을 부끄럽게 생각하지 마세요. -다른 사람들이 그 방향에 열성적이라면, 그들에게 접근을 허용하거나 공식적으로 다른 사람에게 통제 권한을 넘겨주도록 하십시오. 다른 사람이 프로젝트를 포크하고 다른 곳에서 적극적으로 유지 관리하는 경우, 원래 프로젝트의 포크에 연결하는 것이 좋습니다. 많은 사람들이 귀하의 프로젝트가 살아가기를 원합니다! +프로젝트 방침에 열성적인 사람이 있다면 커밋이나 커뮤니티 관리 권한을 부여하세요. 여러분의 프로젝트를 포크해서 활동적으로 유지보수하는 사람이 있다면 여러분의 원본 프로젝트에서 링크를 제공하는 것도 고려해보세요. 여러분의 프로젝트가 계속 발전하길 바라는 사람이 많다는 것은 좋은 일입니다! -@progrium은 프로젝트의 비전을 문서화[한 것으로 밝혀지면서](http://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) [Dokku](https://github.com/dokku/dokku)가 프로젝트에서 물러 난 후에도 이러한 목표를 달성 할 수 있도록 도왔습니다. +@progrium은 그의 프로젝트 [Dokku](https://github.com/dokku/dokku)에 비전을 적어둔 것이 그가 프로젝트 관리에서 물러나고서도 [원래 목표를 향해 나아가는 데 도움](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/)이 되었다는 사실을 알았습니다. -> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down. +> 저는 제가 원했던 것과 왜 그걸 원했는지에 대해 위키 페이지를 만들어 설명했어요. 관리자들이 프로젝트를 제가 의도한 대로 움직이기 시작한 것을 보고 놀라지 않을 수 없었습니다! 항상 정확히 제가 의도한 대로 되지는 않았지만, 기록해둔 것과는 가까웠지요. -### 다른 사람들이 필요한 솔루션을 구축하게하기 +### 각자에게 필요한 솔루션을 구축하게 하세요 -잠재적 기여자가 프로젝트에서 해야 할 일에 대해 다른 견해를 가지고 있다면, 그들을 자신의 포크로 작업하도록 부드럽게 격려하고 싶을 수 있습니다. +잠재적 기여자가 여러분의 프로젝트가 나아갈 방향에 대해 다른 견해를 가지고 있다면 그들이 따로 만든 포크에서 작업하도록 정중하게 권할 수 있습니다. -프로젝트 포킹은 나쁜 일이 아닙니다. 프로젝트를 복사하고 수정할 수 있다는 것이 오픈소스에 관한 가장 좋은 것 중 하나입니다. 커뮤니티 회원들이 자신의 포크로 작업하도록 권장하면 프로젝트 비전과 상충하지 않고, 필요한 창의적인 판로를 제공 할 수 있습니다. +프로젝트를 포크하는 것은 나쁜 일이 아닙니다. 온갖 프로젝트를 복사하고 수정할 수 있다는 것은 오픈소스의 최고 장점 중 하나입니다. 커뮤니티 구성원들이 포크해서 작업할 수 있게 권장하면 프로젝트 비전과 충돌하는 일 없이 그들의 상상력을 표출할 곳을 마련해줄 수 있습니다. -실제로 대역폭을 구축 할 필요가 없는 솔루션을 원하는 사용자에게도 마찬가지입니다. API 및 사용자 정의 후크를 제공하면 소스를 직접 수정하지 않고도 다른 사람들이 자신의 필요를 충족시킬 수 있습니다. @orta는 CocoaPods용 플러그인이 "가장 흥미로운 아이디어 중 일부"를 이끌어 냈다는 것을 [알게 되었습니다](http://artsy.github.io/blog/2016/07/03/handling-big-projects/) +여러분의 대역폭이 닿지 않는 기능을 간절히 원하는 사용자가 있을 때도 같은 방법이 적용됩니다. API와 사용자 정의 후크를 제공하면 사용자들이 소스를 직접 수정하지 않고서도 필요한 것을 구현하는 데 도움이 됩니다. @orta는 CocoaPods에서 플러그인 제작을 권장한 덕분에 몇몇 흥미로운 아이디어를 [얻기도 했습니다](https://artsy.github.io/blog/2016/07/03/handling-big-projects/). -> 프로젝트가 커지면 메인테이너는 새로운 코드를 어떻게 도입할 것인지 훨씬 보수적으로 판단해야합니다. 당신은 "아니오"라고 말하는 것이 좋지만 많은 사람들이 합법적인 필요를 가지고 있습니다. 따라서 도구가 대신 플랫폼으로 변환됩니다. +> 프로젝트가 커지면 관리자들이 새 코드에 보수적이게 되는 것은 거의 피할 수 없는 일입니다. 거절하는 데에는 익숙해지지만, 여전히 많은 사람들이 합리적인 수요를 가지고 있지요. 그래서 툴로서 개발했던 것을 대신 플랫폼으로 바꾸게 되었습니다. -## Bring in the robots +## 봇 활용하기 -다른 사람들이 당신을 도울 수 있는 작업이 있는 것처럼, 인간도 할 일이 없어야합니다. 로봇은 당신의 친구입니다. 그것들을 사용하여 메인테이너로서의 삶을 더 쉽게 만듭니다. +남들이 도와줄 수 있는 일이 있는 것처럼, 굳이 사람이 할 필요가 없는 일도 있습니다. 로봇은 여러분의 친구입니다. 관리자로서의 삶을 더 쉽게 만들기 위해 로봇을 이용하세요. -### 코드의 품질을 향상시키는 데 필요한 테스트 및 기타 검사 +### 코드의 질을 개선하기 위해 테스트를 거치도록 하세요 -프로젝트를 자동화하는 가장 중요한 방법 중 하나는 테스트를 추가하는 것입니다. +여러분의 프로젝트를 자동화하는 가장 중요한 방법 중 하나는 테스트를 추가하는 것입니다. -테스트는 기여자가 아무 것도 망가트리지 않을 것이라고 확신하는 데 도움이 됩니다. 또한 기여를 신속하게 검토하고 수락하기가 더 쉽습니다. 반응이 좋을수록 커뮤니티의 참여도가 높아집니다. +테스트는 기여자가 아무것도 망가트리지 않았다는 확신을 가질 수 있게 해줍니다. 여러분이 기여를 더 빨리 검토하고 적용하기에도 좋습니다. 여러분이 더 적극적으로 반응한다면 커뮤니티의 모두도 더 적극적으로 참여할 것입니다. -들어오는 모든 기여에 대해 실행할 자동 테스트를 설정하고, 기여자가 테스트를 로컬에서 쉽게 실행할 수 있도록 하십시오. 제출하기 전에 모든 코드가 테스트에 합격해야합니다. 모든 제출물에 대해 최소한의 품질 기준을 설정하는 데 도움이됩니다. GitHub의 [Required status checks](https://help.github.com/articles/about-required-status-checks/)는 테스트 통과없이 변경 사항이 병합되지 않도록 도와줍니다. +들어오는 기여를 대상으로 자동으로 수행되는 테스트를 작성하고, 기여자들이 테스트를 로컬에서도 쉽게 수행할 수 있게 구성하세요. 모든 코드 기여는 제출되기 전에 테스트를 통과하도록 하세요. 모든 제출물에 대해 최소한의 수준을 확보할 수 있을 것입니다. GitHub의 [Required status checks](https://help.github.com/articles/about-required-status-checks/) 기능은 어떤 커밋도 테스트를 통과하지 않고서는 병합되지 않도록 도와줍니다. -만약 테스트를 추가한다면, 그것들이 CONTRIBUTING 파일에 어떻게 작동하는지 설명합시다. +테스트를 추가할 때는 반드시 CONTRIBUTING 파일에 어떻게 테스트가 동작하는지 설명하세요. -### 자동적인 기본 관리 작업 도구를 사용하기 +### 기본적인 유지보수에는 툴을 이용하세요 + +인기 있는 프로젝트를 관리하는 사람들에게 좋은 소식은, 다른 관리자들이 이미 비슷한 상황을 겪어 그에 대한 해결책을 마련해두었다는 점입니다. -인기있는 프로젝트를 유지하는 것에 대한 좋은 소식은 다른 메인테이너가 비슷한 문제에 직면해 있고, 그에 대한 해결책을 마련한다는 것입니다. +유지보수 작업의 몇몇 사항을 자동화해주는 [다양한 툴](https://github.com/showcases/tools-for-open-source)이 있습니다. 이하는 약간의 예시입니다. -유지 보수 작업의 일부 측면을 자동화하는 데 도움이되는 [다양한 도구](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)는 코드 검토의 자동화를 지원합니다. -* [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) 코드 리뷰 자동화를 도와주기 +GitHub에서는 버그 제보나 기타 평범한 기여에 사용할 [이슈 템플릿과 풀 리퀘스트 템플릿](https://github.com/blog/2111-issue-and-pull-request-templates)을 제공합니다. 이를 활용하면 의사소통을 능률적으로 진행할 수 있습니다. @TalAter는 여러분의 이슈와 풀 리퀘스트 템플릿 작성을 돕기 위해 [Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/) 가이드를 만들었습니다. -버그 보고서 및 기타 일반적인 공헌을 위해 GitHub는 [이슈 템플릿과 Pull Request 템플릿](https://github.com/blog/2111-issue-and-pull-request-templates)를 제공합니다, 귀하가 받을 수 있는 커뮤니케이션을 합리화하기 위해 만들 수 있습니다. [이메일 필터](https://github.com/blog/2203-email-updates-about-your-own-activity)를 설정하여 이메일 알림을 관리 할 수도 있습니다. +이메일 알림 관리에는 우선순위별로 이메일을 분류하는 [이메일 필터](https://github.com/blog/2203-email-updates-about-your-own-activity)를 설정하는 방법이 있습니다. -좀 더 진보적인 스타일을 원한다면, 스타일 가이드와 linter가 프로젝트 기여를 표준화하고 검토하고 받아들이기가 쉬워질 수 있습니다. +여기에 더하고 싶다면 스타일 가이드와 린터(linter)를 이용해 프로젝트에의 기여를 표준화하고, 검토하거나 적용하기 더 쉽게 만들 수 있습니다. -그러나, 표준이 너무 복잡하면, 기여에 대한 장벽이 높아질 수 있습니다. 모든 사람의 삶을 편하게 하기위한 규칙만 추가하고 있는지 확인하십시오. +하지만 너무 복잡한 기준은 기여까지의 장벽을 높입니다. 모두의 삶을 편하게 해줄 수 있는 필요한 규칙만 추가하세요. -어떤 도구를 사용해야하는지 잘 모르는 경우 다른 인기있는 프로젝트, 특히 같은 생태계에 있는 프로젝트를 살펴보십시오. 예를 들어, 다른 Node 모듈에 대한 기여 진행과정은 어떻게됩니까? 유사한 도구와 접근 방식을 사용하면 진행과정은 대상 기여자에게 더 익숙하게 됩니다. +어떤 툴을 사용할지 잘 모르겠다면 다른 유명한 프로젝트들은 어떻게 하고 있는지 살펴보세요. 특히 여러분의 프로젝트와 비슷한 분야를 찾아보세요. 예컨대, 다른 Node 모듈은 어떤 기여 과정을 가지고 있나요? 다른 프로젝트들과 비슷한 툴과 접근 방식을 적용하면 잠재적 기여자들에게 과정이 익숙하다는 장점도 있습니다. -## It's okay to hit pause +## 잠시 멈춰도 괜찮습니다 -오픈소스 작업은 한 때 기쁨을 가져다주었습니다만. 어쩌면 이제는 회피하거나 죄책감을 느낄 수 있습니다. +오픈소스는 즐겨야만 의미가 있습니다. 혹시 오픈소스가 여러분에게 부담감이나 죄책감을 가져다주고 있지는 않나요? -아마도 당신은 이 프로젝트에 대해 생각할 때, 위압적이거나 두려움에 시달리고 있습니다. 그리고 그 동안 이슈와 pull request가 늘어납니다. +어쩌면 여러분은 여러분이 맡은 프로젝트를 생각할 때마다 의지가 꺾이거나 두려움을 느낄지도 모릅니다. 게다가 그러는 동안에도 이슈와 풀 리퀘스트는 쌓이고 있고요. -번아웃은 특히 메인테이너 간 오픈소스 작업에서 실제로 발생하는 보편적인 문제입니다. 메인테이너로서 여러분의 행복은 모든 오픈소스 프로젝트의 생존을 위한 협상을 할 수 없는 요구 사항입니다. +신경쇠약은 오픈소스 관리자들이 실제로 직면하는 보편적인 문제입니다. 관리자로서 여러분의 행복은 그 어떤 오픈소스 프로젝트의 생존과도 타협하고 포기해야 하는 것이 아닙니다. -아무 말도하지 말고 쉬쉽시오! 휴가를 위해 번아웃될 때까지 기다릴 필요가 없습니다. -파이썬 핵심 개발자인 @brettcannon은 14년간 OSS 자원 봉사를 한 후 [1개월간의 휴가](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering)를 하기로 결정했습니다. +말할 것도 없지만, 쉬면서 하세요! 완전히 지쳤을 때에만 휴가를 낼 필요는 없습니다. Python 핵심 개발자인 @brettcannon은 14년간의 자발적인 오픈소스 기여 후 [한 달간의 휴가](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering)를 떠나기로 결정했습니다. -다른 유형의 일과 마찬가지로 정기적인 휴식을 취하면 일에 대해 새롭고, 행복하며, 짜릿함을 유지할 수 있습니다. +다른 일들이 그렇듯, 정기적으로 휴식을 취하면 상쾌함과 행복감을 유지할 수 있고 여러분의 업무가 즐거울 것입니다. -때때로, 모든 사람들이 당신을 필요로 할 때 오픈소스 작업에서 휴식을 취하는 것이 어려울 수 있습니다. 사람들은 심지어 당신이 발걸음을 딛고 죄책감을 갖도록하려고 할 수도 있습니다. +가끔, 모두가 여러분을 필요로 하는 것처럼 느껴져 쉬기 곤란할 때가 있습니다. 심지어 사람들이 여러분이 업무를 멈추지 못하게 하려고 부담을 줄 수도 있습니다. -프로젝트를 떠나려는 동안 사용자와 커뮤니티에 대한 지원을 찾으려면 최선을 다하십시오. 필요한 지원을 찾을 수 없으면 어쨌든 휴식을 취하십시오. 사용할 수 없을 때, 반드시 의사 소통을 해야하므로 응답성이 부족하게하여 사람들에게 혼동을 주지 않도록하십시오. +여러분이 프로젝트를 떠나 있는 동안 커뮤니티를 관리할 사람을 찾는 데 최선을 다하세요. 필요한 도움을 구하지 못했어도 하여튼 쉴 때는 쉬어야 합니다. 사람들이 여러분의 무반응에 혼란스러워하지 않도록, 작업을 맡지 않고 있을 때에도 의사소통은 잊지 마세요. -휴식을 취하는 것은 방학기간이상 적용됩니다. 주말이나 근무 시간 중에 오픈소스 작업을 하고싶지 않다면, 그 계획을 다른 사람들에게 알려줌으로써 그들은 당신을 귀찮게하지 않을 것입니다. +휴식을 취한다는 것은 단순히 휴가를 말하는 것이 아닙니다. 주말 혹은 근무 시간 중에는 오픈소스 작업을 하고 싶지 않다면 사람들이 여러분을 번거롭게 하지 않도록 그 사실을 알리세요. -## Take care of yourself first! +## 여러분이 최우선입니다 -인기있는 프로젝트를 유지하려면 성장 초기 단계와는 다른 기술이 필요하지만 그다지 보람이 없습니다. 메인테이너로서, 소수의 사람들이 경험할 수 있는 수준에서 리더십과 개인 기술을 연습하게됩니다. 관리가 항상 쉬운 것은 아니지만, 명확한 경계를 설정하고 자신이 편안하게 느끼는 것을 취하는 것만으로도 행복하고 생기넘치며 생산적으로 머물 수 있습니다. +인기 있는 프로젝트의 관리는 초기 성장 단계와 다른 기술을 필요로 하지만 그만큼 보람 있는 일입니다. 관리자로서 여러분은 소수의 사람들만이 경험할 수 있는 수준에서 리더십과 개인 기술을 연마할 수 있습니다. 관리가 항상 쉬운 것은 아니지만, 명확한 경계를 설정하고 여러분이 편하게 느끼는 일을 맡아 하며 행복과 신선함과 생산성을 유지하세요. diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md index 277939b82f7..307442652bb 100644 --- a/_articles/ko/building-community.md +++ b/_articles/ko/building-community.md @@ -1,12 +1,8 @@ --- lang: ko -title: 환영하는 커뮤니티 구축 -description: 사람들이 프로젝트를 사용하고, 기여하고, 전파하도록 격려하는 커뮤니티를 구축합니다. +title: 마음을 끄는 커뮤니티 만들기 +description: 사람들이 프로젝트를 사용하고, 기여하고, 전파하도록 격려하는 커뮤니티를 만드세요. class: building -toc: - setting-your-project-up-for-success: "성공을 위한 프로젝트 설정하기" - growing-your-community: "커뮤니티 성장하기" - resolving-conflicts: "충돌 해결하기" order: 4 image: /assets/images/cards/building.png related: @@ -14,267 +10,267 @@ related: - coc --- -## Setting your project up for success +## 프로젝트의 성공을 위해 준비하기 -프로젝트를 시작하고, 단어를 전파하면, 사람들이 그것을 확인하고 있습니다. 굉장합니다! 자, 어떻게 그들을 주변에 붙이게 할까요? +여러분의 프로젝트가 공개되었습니다. 홍보를 하니 찾아오는 사람들도 생겼습니다. 멋지군요! 그들을 곁에 머물게 하려면 이제 어떻게 해야 할까요? -환영하는 커뮤니티는 프로젝트의 미래와 평판에 대한 투자입니다. 프로젝트가 처음으로 기여한 것을 보기 시작한 경우, 초반 참여자에게 긍정적인 경험을 제공하고, 그들이 계속해서 다시 돌아올 수 있도록 하십시오. +마음을 끄는 커뮤니티를 만드는 것은 프로젝트의 미래와 평판을 위한 투자입니다. 여러분의 프로젝트가 이제 막 첫 기여를 받는 시점이라면, 기여자들에게 좋은 경험을 안겨 주고 계속 다시 돌아오게 만드세요. -### 사람들이 환영받는다고 느끼게하기 +### 사람들이 환영받는다고 느끼게 하세요 -프로젝트 커뮤니티에 대해 생각하는 한 가지 방법은 @MikeMcQuaid는 [contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)라고 언급했습니다: +@MikeMcQuaid가 [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/)(기여자 깔때기)이라고 부르는 것을 통해 프로젝트 커뮤니티에 대해 생각해 볼 수 있습니다. ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) -커뮤니티를 구축하면서 깔때기의 맨 위에 있는 누군가(잠재 사용자)가 이론적으로 맨 아래(활동중인 메인테이너)로 나아갈 수있는 방법을 생각해보십시오. 목표는 기여자 환경의 각 단계에서 마찰을 줄이는 것입니다. 사람들이 쉽게 이를 이겨낸다면, 더 많은 일을 하도록 동기 부여를 느낄 것입니다. +커뮤니티가 성장함에 따라 깔때기 맨 위에 있는 누군가(잠재 사용자)가 맨 아래(활동적인 유지관리자)까지 나아갈 수 있는 방법을 생각해 보세요. 여러분의 목표는 기여 경험의 각 단계에서 발생하는 마찰력을 최소화하는 것입니다. 사람들은 쉽게 보답을 받을수록 더 많은 일을 할 동기를 받습니다. -문서화로 시작하기: +문서화에서부터 시작하세요. -* **프로젝트를 쉽게 사용할 수 있도록하십시오.** [친숙한 README](../starting-a-project/#writing-a-readme)와 명확한 코드 예제를 사용한다면 프로젝트에 착수한 모든 사람이 쉽게 시작할 수 있습니다. -* **기여 방법을 분명히 설명하십시오.**, [CONTRIBUTING 파일](../starting-a-project/#writing-your-contributing-guidelines)를 사용하고 이슈를 최신 상태로 유지하시기 바랍니다. +* **프로젝트를 사용하기 쉽게 만드세요.** [친절한 README](../starting-a-project/#readme-파일-작성하기)와 명료한 코드 예제를 사용한다면 프로젝트에 막 착수한 사람도 쉽게 시작할 수 있습니다. +* **기여 방법을 명확하게 설명하세요.**, [CONTRIBUTING 파일](../starting-a-project/#기여-가이드라인-작성하기)을 관리하고 이슈를 최신 상태로 유지하세요. -[깃허브의 2017 오픈소스 설문](http://opensourcesurvey.org/2017/)에 따르면 불완전하거나 혼란스러운 문서가 오픈소스 사용자에게 가장 큰 문제임이 드러났습니다. 좋은 문서는 사람들이 프로젝트와 상호 작용하도록 유도합니다. 결국 누군가가 이슈를 열거나 pull request를 진행합니다. 이러한 상호 작용을 통해 유입 경로로 이동할 수 있습니다. +[GitHub의 2017 오픈소스 설문조사](http://opensourcesurvey.org/2017/)에 따르면 오픈소스 사용자들에게 가장 큰 문제는 불완전하거나 애매한 문서화라고 합니다. 좋은 문서화는 사람들이 여러분의 프로젝트에 관심을 갖게 합니다. 결국 누군가 이슈나 풀 리퀘스트를 열 것입니다. 다음과 같은 방법을 사용해 사람들을 깔때기 아래까지 이끌어 보세요. -* **누군가 새로운 프로젝트를 시작했을 때 관심을 가져주셔서 감사합니다!** 누군가가 돌아오고 싶지 않게 만드는 것은 부정적인 경험 하나로도 충분합니다. -* **즉각 반응합니다.** 한달동안 이슈에 답변하지 않으면, 프로젝트에 대해 이미 잊어버렸을 가능성이 있습니다. -* **받아들일 수 있는 기여 유형에 대해 개방적이어야합니다.** 많은 기여자는 버그 신고 또는 작은 수정으로 시작합니다. 프로젝트에 [기여할 수 있는 많은 방법](../how-to-contribute/#what-it-means-to-contribute)이 있습니다. 사람들이 어떻게 도와주고 싶어하는지 거들어주십시오. -* **당신이 동의하지 않는 기여가 있다면,** 그들에게 아이디어에 대해 감사해하고, 프로젝트의 범위에 맞지 않는 [이유를 설명](../best-practices/#learning-to-say-no)하며, 관련 문서를 링크하면됩니다. +* **새로운 사람이 프로젝트에 찾아오면 그들의 관심에 감사를 표하세요!** 처음 온 사람은 단 한 번의 부정적인 경험으로도 다시 프로젝트에 돌아오지 않게 될 수 있습니다. +* **적극적으로 반응하세요.** 이슈에 한 달 이상 반응하지 않았다면 이슈를 올린 사람은 이미 여러분의 프로젝트를 잊었을지도 모릅니다. +* **열린 마음을 가지고 다양한 유형의 기여를 받아들이세요.** 많은 기여자들이 처음에는 버그 제보나 작은 수정에서부터 시작합니다. 프로젝트에 기여하는 데에는 [다양한 방법](../how-to-contribute/#기여한다는-것의-의미)이 있습니다. 그들이 원하는 방식으로 여러분을 도울 수 있게 하세요. +* **받아들일 수 없는 기여가 있다면,** 먼저 그들의 아이디어에 감사하고, 왜 그 기여가 프로젝트의 의도에 맞지 않는지 [이유를 설명](../best-practices/#거절하는-법-배우기)하세요. 관련 문서가 있다면 링크를 첨부하는 것이 좋습니다. -오픈소스 제공자의 대다수는 "임시 기여자"입니다. 때때로 프로젝트에만 기여하는 사람들입니다. 캐주얼 기여자는 프로젝트 진행 속도를 최대로 끌어 올릴 시간이 없을 수도 있기 때문에, 당신의 일은 그들이 기여하기 쉽게 만드는 것입니다. +오픈소스 제공자의 대다수는 이따금씩만 프로젝트에 기여하는 "임시 기여자"입니다. 임시 기여자들은 프로젝트의 진도를 따라갈 시간이 없을 수도 있습니다. 즉 그들이 기여하기 쉬운 환경을 만들어두는 것은 여러분의 역할입니다. -다른 참여자를 격려하는 것은 자신에게도 투자입니다. 가장 열렬한 팬에게 흥분을 줄 수있는 힘을 실어 줄 때, 모든 것을 스스로 할 수있는 부담이 줄어 듭니다. +사람들의 기여를 장려하는 것은 여러분 스스로를 위한 투자이기도 합니다. 여러분의 프로젝트를 가장 좋아하는 사람에게 그들이 좋아하는 일을 할 수 있는 권한을 준다면, 모든 것을 혼자 해야 하는 부담감을 덜 수 있습니다. -### 모든 곳에 문서화하기 +### 모든 것을 문서화하세요 -새로운 프로젝트를 시작하면, 작업을 비공개로 유지하는 것이 자연스럽게 느껴질 수 있습니다. 그러나 오픈소스 프로젝트는 공개적으로 프로세스를 문서화할 때 번창합니다. +새로운 프로젝트를 시작하면 작업 내용을 공개하고 싶지 않을 수도 있습니다. 하지만 오픈소스 프로젝트는 여러분의 작업 과정을 공개해야 번창할 수 있습니다. -당신이 일을 적을 때, 더 많은 사람들이 모든 단계에서 참여할 수 있습니다. 자신이 필요로 하지 않는 것에 대해서 도움을 받을 수도 있습니다. +여러분이 하고 있는 일을 기록해 두면 더 많은 사람들이 각 단계에서 프로젝트에 참여할 수 있습니다. 여러분이 생각지도 못한 부분에서 도움을 얻을 수도 있습니다. -무언가를 쓰는 것은 기술 문서 이상의 것을 의미합니다. 뭔가를 쓰거나 프로젝트에 대해 개인적으로 토론할 충동을 느낄 때마다, 공개할 수 있는지 스스로에게 자문 해보십시오. +작업 내용을 적는다는 것은 단순한 기술적 문서화 이상의 것을 의미합니다. 뭔가 기록하거나 사적으로 프로젝트에 대해 토론하고 싶다는 생각이 들면 이를 공개할 수 있을지 자문해 보세요. -프로젝트의 로드맵, 찾고있는 기여 유형, 기여 검토 방법 또는 특정 결정을 한 이유에 대해 투명하게 공개하십시오. +프로젝트 로드맵, 원하는 기여 유형, 기여를 검토하는 방식, 특정 결정을 내린 이유 등을 분명하게 밝히세요. -여러 사용자가 동일한 문제를 겪고있는 경우, README에 답변을 문서화하십시오. +여러 사용자가 같은 문제를 겪는 것을 알게 됐다면 그 해결책을 README에 문서화하세요. -회의의 경우, 관련 이슈에 메모나 테이크아웃을 게시하는 것을 고려하십시오. 이 투명성 수준에서 얻을 수있는 피드백은 당신을 놀라게 할 수 있습니다. +회의의 경우, 관련 이슈에 메모나 테이크아웃을 게시해 보세요. 이 투명성 수준에서 얻을 수 있는 피드백은 당신을 놀라게 할 수 있습니다. -모든 것을 문서화하는 것은 당신이 하는 일에도 적용됩니다. 프로젝트에 대한 실질적인 업데이트를 진행중인 경우, pull request에 넣고 진행중인 작업(WIP)으로 표시합니다. 그렇게하면 다른 사람들이 조기에 프로세스에 참여할 수 있습니다. +모든 것의 문서화는 여러분이 진행 중인 작업에도 해당됩니다. 여러분이 프로젝트의 큰 업데이트 작업을 하고 있다면 이를 풀 리퀘스트로 열고 WIP(Work In Progress; 작업 중)로 표시하세요. 그렇게 하면 일찍부터 사람들이 과정에 참여할 수 있습니다. -### 반응하기 +### 적극적으로 반응하세요 -당신의 [프로젝트를 홍보](../finding-users)하는 것처럼, 사람들은 당신을 위해 의견을 갖습니다. 그들은 어떻게 일을하는지, 시작하는 데 도움이 필요하다는 것에 대해 질문을 할 수 있습니다. +[프로젝트를 홍보](../finding-users)하다 보면 사람들이 여러분에게 피드백을 제공할 것입니다. 어떤 부분이 어떻게 동작하는지 알고 싶어할 수도 있고, 처음 접하는 데 도움이 필요할 수도 있습니다. -누군가가 이슈를 제기하거나, pull request를 제출하거나, 프로젝트에 관한 질문을 하면 좋게 반응하십시오. 신속하게 대처할 때, 사람들은 대화의 일부에 참여했다는 기분을 느낄 것이며, 더 적극적으로 참여할 것입니다. +누군가 이슈를 열거나 풀 리퀘스트를 제출하거나 질문을 하면 적극적으로 반응할 수 있도록 노력하세요. 제때 피드백에 반응하면 사람들은 대화에 참여하고 있다는 느낌을 받고, 더 열정적으로 기여할 것입니다. -요청을 즉시 검토할 수 없더라도 조기에 이를 인정하면 참여를 늘리는 데 도움이됩니다. @tdreyno가 [Middleman](https://github.com/middleman/middleman/pull/1466)의 pull request에 응답 한 방법은 다음과 같습니다: +즉시 반응하기 힘들더라도 그 사실을 알려두는 것이 참여율을 높이기 좋습니다. @tdreyno가 [Middleman](https://github.com/middleman/middleman/pull/1466)에서 풀 리퀘스트에 어떻게 대응했는지 참고하세요. -![중개인 pull request](/assets/images/building-community/middleman_pr.png) +![Middleman 풀 리퀘스트](/assets/images/building-community/middleman_pr.png) -48시간 내에 코드 리뷰를 받은 기여자들이 훨씬 더 높은 수익률과 반복 기여도를 보였습니다는 것을 [모질라 스터디가 발견했습니다](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177). +[Mozilla에서의 조사](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)에 따르면 48시간 안에 코드 리뷰를 받은 기여자는 추가 기여를 할 확률이 훨씬 높다고 합니다. -스택 오버플로우, 트위터 또는 레딧과 같은 인터넷상의 다른 장소에서도 프로젝트에 대한 토의가 발생할 수 있습니다. 이러한 장소중 일부에서 알림을 설정하여 누군가가 프로젝트를 언급할 때 알림을 받을 수 있습니다. +여러분의 프로젝트에 대한 대화는 Stack Overflow나 Twitter, Reddit처럼 인터넷상의 다른 곳에서 이루어지고 있을 수도 있습니다. 이러한 사이트에서 여러분의 프로젝트가 언급되었을 때 알 수 있도록 알림을 설정할 수 있습니다. -### 커뮤니티에 모일 곳을 제공하기 +### 커뮤니티가 모일 장소를 제공하세요 -커뮤니티에 모일 수 있는 이유는 두 가지입니다. +커뮤니티가 모일 장소를 제공해야 하는 데에는 두 가지 이유가 있습니다. -첫번째 이유는 그들을 위한 것입니다. 사람들이 서로를 알게 도와주세요. 공통 관심사를 가진 사람들은 필연적으로 그것에 대해 이야기 할 곳을 원할 것입니다. 커뮤니케이션이 공개되고 접근이 용이할 때, 누구나 과거 기록을 읽어 신속하게 참여하고 참여할 수 있습니다. +첫 번째 이유는 커뮤니티 구성원들을 위해서입니다. 사람들이 서로 알아갈 수 있도록 도우세요. 같은 분야에 흥미가 있는 사람들은 그것에 대해 이야기 나눌 곳을 원하기 마련입니다. 그리고 의사소통이 접근성 있는 장소에서 공개적으로 이루어져야 누구나 대화 내역을 읽고 현재 상황을 따라잡아 프로젝트에 빠르게 참여할 수 있습니다. -두번째 이유는 당신을 위한 것입니다. 사람들에게 프로젝트에 관해 이야기 할 수 있는 공공장소를 제공하지 않으면 직접 연락을 취할 것입니다. 처음에는 개인 메시지에 "단지 한 번" 응답하는 것만큼 쉬운 것처럼 보일 수 있습니다. 그러나 시간이 지남에 따라 프로젝트가 대중화되면 특히 체력이 고갈될 것입니다. 개인적으로 프로젝트에 대한 사람들과 소통하려는 유혹에 현혹되지 마십시오. 대신 지정된 공개 채널로 안내하십시오. +두 번째 이유는 여러분을 위해서입니다. 프로젝트에 대해 이야기할 공개된 장소가 없다면 사람들은 여러분에게 직접 연락할 것입니다. 처음에는 이런 개인 메시지에 답하는 방식이 "일단은" 충분히 편하게 느껴질 수 있습니다. 하지만 시간이 지나 프로젝트가 유명해지면 결국 지치고 말 것입니다. 여러분의 프로젝트에 대해 비공개적으로 이야기하고 싶은 유혹을 참고 공개된 채널로 사람들을 안내하세요. -공개적인 의사소통은 사람들에게 직접 이메일을 보내거나 블로그에 댓글을 다는 대신 문제를 열도록 지시하는 것처럼 간단할 수 있습니다. 또한 메일링 리스트를 설정하거나 Twitter 계정, 슬랙 또는 IRC채널을 만들어 사람들이 프로젝트에 관해 이야기할 수 있습니다. 또는 위의 모든 것을 시도하십시오! +공개적인 의사소통은 사람들이 여러분에게 직접 메일을 보내거나 블로그에 댓글을 다는 대신 이슈를 열게 하는 것처럼 간단하게 이룰 수 있습니다. 프로젝트 관련 대화를 위해 메일링 리스트, Twitter 계정, Slack이나 IRC 채널을 만드는 방법도 있습니다. 물론 전부 다 할 수도 있습니다! -[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved)은 커뮤니티 회원들을 돕기 위해 격주로 근무 시간을 따로 지정합니다: +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved)는 격주마다 커뮤니티 구성원들을 돕기 위해 일과 중 시간을 마련했습니다. -> Kops는 또한 격주로 커뮤니티에 도움과 안내를 제공하기 위해 시간을 마련했습니다. Kops 메인테이너는 신규 이민자와의 협력, 홍보 및 새로운 기능 토론에 전념한 시간을 별도로 마련하기로 동의했습니다. +> 또한 Kops는 커뮤니티에 대한 도움과 안내를 제공하기 위해 격주마다 시간을 마련했다. Kops 관리자들은 신입을 돕거나, 풀 리퀘스트에 협조하거나, 새 기능에 대해 토론하기 위한 시간을 할당하는 데 찬성했다. -공공 커뮤니케이션에 대한 주목할만한 예외로는: 1) 보안 문제와 2) 민감한 행동 규범 위반이 있습니다. 사람들이 이러한 문제를 개인적으로 보고할 수 있는 방법을 항상 마련해야합니다. 개인 이메일을 사용하지 않으려면 전용 이메일 주소를 설정하십시오. +공개적인 의사소통은 중요하지만 예외도 있습니다. 보안 관련 이슈나 민감한 행동 강령 위반 사항이 바로 그것입니다. 이러한 문제는 비공개적으로 보고될 수 있어야 합니다. 개인 이메일을 사용하기 꺼려진다면 프로젝트를 위한 이메일 주소를 준비하세요. -## Growing your community +## 커뮤니티 성장시키기 -커뮤니티는 매우 강력합니다. 그 힘은 어떻게 사용하는지에 따라 축복이나 저주가 될 수 있습니다. 프로젝트 공동체가 성장함에 따라, 그것이 파괴가 아닌 건설의 힘이 될 수 있도록 돕는 방법이 있습니다. +커뮤니티는 아주 강력한 힘을 지니고 있습니다. 그 힘은 어떻게 다루느냐에 따라 축복이 될 수도, 저주가 될 수도 있습니다. 성장하는 커뮤니티를 파괴의 힘이 아닌 창조의 힘으로 이끄는 방법을 알아봅시다. -### Don't tolerate bad actors +### 악당에게 관용을 베풀지 마세요 -모든 인기있는 프로젝트는 필연적으로 커뮤니티를 돕기보다는, 해를 입는 사람들도 끌어 들일 것입니다. 그들은 불필요한 논쟁을 시작하거나, 사소한 기능을 말다툼하거나, 다른 사람들을 괴롭힐 수 있습니다. +인기 있는 프로젝트라면 커뮤니티를 돕기는커녕 해치는 사람들이 나타나기 마련입니다. 불필요한 논쟁을 일으키고, 사소한 기능에 트집을 잡고, 남을 괴롭히는 사람들입니다. -이러한 유형의 사람들에 대한 무관용 정책을 채택하기 위해 최선을 다하십시오. 선택하지 않는다면, 부정적인 사람들이 커뮤니티의 다른 사람들을 불편하게 만듭니다. 그들은 심지어 떠날지도 모릅니다. +이런 유형의 사람들에 대해서는 즉각적인 조치를 취해야 합니다. 그냥 넘어간다면 부정적인 사람들이 커뮤니티의 다른 사람들을 불쾌하게, 떠나게까지 만들 수 있습니다. -프로젝트의 사소한 측면에 대한 정기적인 토의는 중요한 작업에 집중하는 것을 포함하여, 다른 사람을 혼란스럽게합니다. 프로젝트에 도착한 새로운 사람들은 이러한 대화를 보고 참여하기를 원하지 않을 수 있습니다. +프로젝트의 사소한 면에 대한 반복적인 논쟁은 여러분을 포함한 구성원이 보다 중요한 일에 집중하는 것을 방해합니다. 여러분의 프로젝트에 새로 찾아온 사람들이 이런 논쟁을 보면 프로젝트에 참여하고 싶지 않을 것입니다. -프로젝트에서 부정적인 행동이 발생하면, 공개적으로 말합니다. 친절하지만 확고한 어조로 왜 그들의 행동이 용납되지 않는지 설명합니다. 문제가 지속되면, [떠날 것을 요청해야 할 수도 있습니다](../code-of-conduct/#enforcing-your-code-of-conduct). [행동 규범](../code-of-conduct/)은 이 대화를 위해 건설적인 가이드가 될겁니다. +여러분의 프로젝트에서 행해지는 옳지 않은 행동을 발견한다면, 친절하지만 완고하게 어째서 그런 행동이 용납될 수 없는지 공적으로 설명하세요. 문제가 지속된다면 [그들을 떠나보내야 할 수도 있습니다](../code-of-conduct/#행동강령을-시행하기). 프로젝트 [행동 강령](../code-of-conduct/)이 이런 대화의 적절한 지침이 될 것입니다. -### 장소에 있는 기여자를 만나기 +### 기여자에게 먼저 다가가세요 -훌륭한 문서는 커뮤니티가 성장함에 따라 중요해질 것입니다. 프로젝트에 익숙하지 않은 캐주얼 기여자는, 필요한 컨텍스트를 빨리 얻기 위해 문서를 읽습니다. +커뮤니티가 성장할수록 좋은 문서화는 더욱 중요해집니다. 여러분의 프로젝트를 잘 몰랐을 평범한 기여자들도 문서를 읽고 빠르게 필요한 맥락을 파악할 수 있기 때문입니다. -CONTRIBUTING 파일에서 새 참여자에게 시작 방법을 명시하십시오. 이러한 목적으로 전용 섹션을 만들고 싶을 수도 있습니다. [Django](https://github.com/django/django)를 예로 들어보면, 새로운 참여자를 환영 할 수 있는 특별 방문 페이지가 있습니다. +CONTRIBUTING 파일에 새 기여자들이 시작할 방법을 자세히 설명하세요. 이를 위한 파트를 따로 마련해도 좋습니다. 예컨대 [Django](https://github.com/django/django)는 새 기여자를 환영하기 위한 특별한 페이지를 가지고 있습니다. ![Django 새로운 기여자 페이지](/assets/images/building-community/django_new_contributors.png) -이슈 대기열에서, 기여자의 다른 유형에 적합한 버그 라벨을 붙이십시오: 예를 들어, [_"first timers only"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), _"good first issue"_, 혹은 _"documentation"_이 있습니다. [이 라벨들은](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) -프로젝트에 익숙하지 않은 사용자가 문제를 신속하게 스캔하고 시작하기가 쉽습니다. +이슈 목록에 다양한 유형의 기여자들을 위한 라벨을 표시하세요. [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, _"documentation"_ 같은 예가 있습니다. [이러한 라벨은](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/master/.github/contributing.md)를 시작하는 방법은 다음과 같습니다: +[Rubinius](https://github.com/rubinius/rubinius/)의 [기여 가이드](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md)는 어떻게 시작하는지 참조하세요. -> Rubinius를 사용해 주셔서 감사드립니다. 이 프로젝트는 사랑의 노동이며, 버그를 포착하고 성능을 개선하며, 문서화에 도움이 되는 모든 사용자에게 감사드립니다. 모든 기여는 의미가 있으므로, 참여해 주셔서 감사합니다. 말하지면, 우리가 귀하의 문제를 성공적으로 해결할 수 있도록 따라야 할 몇 가지 지침이 있습니다. +> Rubinius를 사용해 주시는 것에 대해 먼저 감사의 말씀을 드리고 싶습니다. 이 프로젝트는 여러분의 사랑의 산출물이며, 저희는 버그를 잡고, 성능을 개선하고, 문서화를 돕는 모든 여러분께 고마움을 느낍니다. 모든 기여는 의미가 있습니다. 프로젝트에 참여해 주셔서 감사합니다. 다만, 저희가 여러분의 이슈를 받아들이기 위해 필요로 하는 몇 가지 지침이 있으니 참고해 주세요. -### Share ownership of your project +### 프로젝트를 공동으로 소유하세요 -사람들은 소유권을 느낄 때 프로젝트에 기여하게 되어 기쁩니다. 그렇다고 해서 프로젝트의 비전을 뒤집거나 원하지 않는 기여를 받아 들일 필요가 있다는 것을 의미하지는 않습니다. 그러나 당신이 다른 사람에게 더 많은 것을 줄수록, 더 많이 붙어있게됩니다. +사람들은 프로젝트에 대한 일종의 소유감을 느낄 때 더 열심히 기여합니다. 프로젝트의 비전을 바꾸거나 원치 않는 기여를 받아들이라는 뜻이 아닙니다. 하지만 사람들에게 공적을 돌릴수록 그들은 더 오래 여러분과 함께할 것입니다. -가능한 커뮤니티와 소유권을 공유하는 방법을 찾을 수 있는지 확인하십시오. 다음은 몇 가지 아이디어입니다: +커뮤니티와 프로젝트의 소유감을 최대한 나눌 수 있는 방법에는 무엇이 있는지 알아봅시다. -* **쉬운(중요하지 않은) 버그를 수정하는 것을 방지**하는 대신, 그것들로 새로운 기부자를 모집할 기회로 사용하거나, 기여하고자 하는 사람을 멘토링하십시오. 초기에는 부자연스럽게 보일 수 있지만, 시간이 지남에 따라 투자가 이루어집니다. 예시로, @michaeljoseph가 기여자에게 직접 아래의 [Cookiecutter](https://github.com/audreyr/cookiecutter) 이슈에 대한 pull request을 제출하도록 요청했습니다. +* **(사소하고) 쉬운 버그는 직접 해결하지 말고** 새로운 기여자를 위해 남겨 두거나, 기여하려는 사람에게 멘토링하는 데 활용하세요. 처음에는 부자연스럽게 느껴질 수 있지만, 시간이 지나면서 여러분의 투자가 결실을 맺게 될 것입니다. [Cookiecutter](https://github.com/audreyr/cookiecutter)의 @michaeljoseph은 아래 이슈를 직접 고치는 대신 기여자에게 새 풀 리퀘스트를 제출해 달라고 했습니다. ![Cookiecutter 이슈](/assets/images/building-community/cookiecutter_submit_pr.png) -* 프로젝트에 기여한 사람(예를 들어, [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md))을 모두 나열하는 **프로젝트의 CONTRIBUTORS 혹은 AUTHORS 파일을 시작하십시오.** +* [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md)가 사용하는 방법처럼 **CONTRIBUTORS 혹은 AUTHORS 파일**을 만들어 모든 프로젝트 기여자를 담은 하나의 목록을 작성하세요. -* 만약 상당한 규모의 커뮤니티가 있다면, 기여자들에게 감사하는 **뉴스 레터를 보내거나 블로그 포스트를 작성하십시오**. Rust의 [This Week in Rust](https://this-week-in-rust.org/)와 Hoodie의 [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)는 두개의 좋은 예시입니다. +* 어느 정도 규모의 커뮤니티가 형성됐다면 기여자들에 대한 감사를 담은 **뉴스 레터를 보내거나 블로그 포스트를 게시하세요**. Rust의 [This Week in Rust](https://this-week-in-rust.org/)와 Hoodie의 [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)가 좋은 예입니다. -* **모든 참여자에게 커밋 접근 권한을 부여하십시오.** @felixge는 이것이 사람들로 하여금 [패치를 작성하는 것에 더 흥분하도록](http://felixge.de/2013/03/11/the-pull-request-hack.html) 만들었고, 잠시동안 일하지 않은 프로젝트에 대한 새로운 메인테이너를 발견했습니다. +* **모든 참여자에게 커밋 권한을 부여하세요.** @felixge는 이 방법이 사람들이 [더 열심히 패치를 개선하게 한다는 사실](http://felixge.de/2013/03/11/the-pull-request-hack.html)을 알았고, 그가 자리에 없는 동안 프로젝트 관리자 일을 맡아 주는 사람들을 발견하기도 했습니다. -* 만약 프로젝트가 깃허브에 있는 경우, .**프로젝트를 개인 계정에서 [조직](https://help.github.com/articles/creating-a-new-organization-account/)으로 옮기고** 하나 이상의 백업 메인테이너를 추가하십시오. 조직에서는 외부 공동 작업자와 함께 프로젝트를 보다 쉽게 ​​작업 할 수 있습니다. +* 여러분의 프로젝트가 GitHub에서 진행되고 있다면 **프로젝트를 개인 계정에서 [조직 계정](https://help.github.com/articles/creating-a-new-organization-account/)으로 옮기고** 예비 관리자를 등록하세요. 조직 계정을 활용하면 외부의 협력자들과 함께 일하기 더 쉽습니다. -실제로 [대부분의 프로젝트](https://peerj.com/preprints/1233.pdf)는 대부분의 작업을 수행하는 1 ~ 2명의 메인테이너만 있습니다. 프로젝트가 커지고, 커뮤니티가 커질수록 쉽게 도움을 얻을 수 있습니다. +현실에서 [대부분의 프로젝트](https://peerj.com/preprints/1233/)는 한두 명의 관리자가 거의 모든 일을 담당합니다. 여러분의 프로젝트와 커뮤니티가 성장할수록 위 방법이 도움을 구하기 좋습니다. -전화를 받는 사람을 항상 찾지는 못하더라도, 신호를 내보내는 것은 다른 사람들이 들어올 확률을 높입니다. 그리고 일찍 시작할수록 더 빨리 사람들이 도울 수 있습니다. +항상 도움을 줄 수 있는 사람을 찾을 수 있는 것은 아니지만, 신호를 보내는 것은 그럴 확률을 높입니다. 여러분이 일찍 시작할수록 사람들은 더 빨리 도울 수 있습니다. -## Resolving conflicts +## 갈등 해결하기 -프로젝트의 초기 단계에서, 중요한 결정을 내리는 것은 쉽습니다. 당신이 무언가를 하고 싶을 때, 그것을 하도록합니다. +프로젝트 초기에는 결정을 내리기 쉽습니다. 하고 싶은 일이 있다면, 얼마든 그렇게 하세요. -프로젝트가 인기화되면서, 더 많은 사람들이 의사 결정에 관심을 가질 것입니다. 기여자가 큰 커뮤니티에 없더라도, 프로젝트에 많은 사용자가 있는 경우 의사 결정에 중점을 두거나 자신의 문제를 제기하는 사람들을 찾을 수 있습니다. +여러분의 프로젝트가 유명해질수록 사람들은 여러분이 내리는 결정에 관심을 가지게 될 것입니다. 기여자가 많은 것이 아니더라도 유저가 많다면 사람들이 이슈 제보나 여러분의 결정을 중요하게 생각하고 있다는 것을 알 수 있습니다. -대부분, 친근하고 정중한 공동체를 육성하고, 공개적으로 프로세스를 문서화한 경우, 커뮤니티는 해결책을 찾아야합니다. 그러나 때로는 문제를 해결하기가 더 어려워집니다. +친근하면서도 정중한 커뮤니티를 일구고 작업을 공개적으로 기록하며 진행했다면 여러분의 커뮤니티는 대부분의 경우 해결책을 찾을 수 있을 것입니다. 하지만 가끔은 다루기 어려운 문제에 당면할 때도 있습니다. -### 친절에 대한 기준 설정하기 +### 친절에 대한 기준을 세우세요 -귀하의 커뮤니티가 어려운 이슈로 어려움을 겪을 때, 기분이 좋아질 수 있습니다. 사람들은 화가 나거나 좌절감을 느껴 다른 사람이나 당신이 다른 사람에게 행복을 가져갈 수 있습니다. +복잡한 이슈를 두고 접전을 벌이면 커뮤니티 분위기가 팽팽해질 수 있습니다. 사람들이 화를 내거나 실망하고 이를 다른 사람이나 여러분에게 표출할 수도 있습니다. -메인테이너로서의 당신의 임무는 이러한 상황이 악화되는 것을 막는 것입니다. 주제에 대해 강한 의견을 갖고 있다고해도, 시합에 뛰어 들고 의견을 피하는 대신 메인테이너 또는 진행자의 입장을 취하십시오. 누군가가 불친절하거나 대화를 독점한다면, 토론을 시민적이고 생산적으로 유지하기 위해 [즉시 행동하십시오](../building-community/#dont-tolerate-bad-actors). +관리자로서 상황이 심각해지지 않도록 조정하는 것이 여러분의 역할입니다. 해당 주제에 관해 뚜렷한 주장을 가지고 있더라도, 싸움에 뛰어들어 여러분의 의견을 밀어붙이지 말고 의장 혹은 사회자로서의 역할을 맡을 수 있도록 하세요. 누군가 불친절하게 행동하거나 발언권을 독차지하려 한다면 정중하고 생산성 있는 토론이 유지될 수 있도록 [즉각 대응](../building-community/#악당에게-관용을-베풀지-마세요)하세요. -다른 사람들은 당신에게 인도를 구합니다. 좋은 모범을 보입니다. 여전히 실망, 불행 또는 염려를 표현할 수 있지만 침착하게 행동하십시오. +여러분의 본보기를 기다리는 사람들도 있습니다. 모범을 보이세요. 실망감이나 불만, 걱정을 표현할 수도 있습니다. 하지만 침착함을 유지하세요. -시원하게 유지하는 것은 쉽지 않지만, 리더십을 입증하면 커뮤니티의 건강이 향상됩니다. 인터넷에게 감사합니다. +이성을 유지하는 것은 쉽지 않습니다. 하지만 리더십을 보여야 커뮤니티를 더 건전하게 유지할 수 있습니다. 온 인터넷이 여러분에게 고마워할 것입니다. -### README를 헌법으로 다루기 +### README 파일을 골자로 다루세요 -귀하의 README는 [일련의 지시 사항 이상](../starting-a-project/#writing-a-readme)입니다. 또한 목표, 제품 비전 및 로드맵에 대해 이야기 할 수 있는 장소이기도 합니다. 사람들이 특정 기능의 장점에 대해 토론하는 데 지나치게 집중한다면, README를 다시 읽고 프로젝트의 더 높은 비전에 대해 이야기하는 것이 도움이 될 수 있습니다. README에 초점을 맞추면 대화를 비 개인화하므로 건설적인 토론을 할 수 있습니다. +README 파일은 [단순한 안내서 이상](../starting-a-project/#readme-파일-작성하기)의 것입니다. 여러분의 목표, 프로젝트 비전, 로드맵에 대해서도 적을 수 있습니다. 사람들이 특정 기능의 유용성을 토론하는 데에만 과도하게 몰입해 있을 때, README 파일을 다시 읽고 프로젝트의 더 높은 비전에 대해 이야기하면 도움이 될 것입니다. 또한 README 파일에 집중하면 대화를 객관화하여 건설적인 토론을 할 수 있습니다. -### 목적지가 아닌, 여행에 집중하기 +### 목적지가 아닌 여정에 초점을 맞추세요 -일부 프로젝트는 주요 결정을 내리기 위해 투표 프로세스를 사용합니다. 언뜻보기에 합당한 반면, 투표는 서로의 의견을 경청하고 다루기보다 "대답"을 얻는 것을 강조합니다. +몇몇 프로젝트는 중요한 결정을 투표를 통해 결정합니다. 척 보기에는 실용적이지만, 투표는 '정답'을 찾는 데 집중하지 서로 의견을 교환하고 고려하는 방식으로는 적합하지 않습니다. -투표는 정치적으로 진행될 수 있으며, 커뮤니티 멤버들은 서로에게 호의를 베풀거나 특정 방식으로 투표하도록 압박을 느끼고 있습니다. 모든 사람이 투표를 하든, [다수가 침묵](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users)하든간에, 또는 사용자가 커뮤니티에서 투표를 하지 못했거나 투표를 모르는 사용자가 발생할겁니다. +투표 제도는 자칫 정치적인 성향을 띠게 될 수 있습니다. 커뮤니티 구성원들이 특정한 방향으로 투표하도록 압박감을 느낄 수 있기 떄문입니다. 모든 사람이 투표를 하는 것도 아닙니다. 커뮤니티를 [조용히 지켜보는 대다수](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users), 혹은 투표의 존재조차 모르는 사용자도 있습니다. -때로는, 투표는 필요한 동점자입니다. 그러나 합의가 아닌 당신이 할 수 있는만큼 ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)을 강조합니다. +가끔은 투표로 결정을 내려야 할 때도 있습니다. 하지만 가능한 한 합의점 자체보다 ['합의점을 찾는 과정'](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)에 강세를 두세요. -합의를 추구하는 과정에서, 커뮤니티 구성원들은 그들이 적절하게 의견을 들을 때까지 주요 관심사에 대해 논의합니다. 사소한 우려가 남아있을 때, 커뮤니티는 앞으로 나아갑니다. "Consensus seeking"는 커뮤니티가 완벽한 대답에 도달하지 못할 수도 있음을 인정합니다. 대신 듣기와 토론의 우선 순위를 정합니다. +합의점을 찾는 과정에서, 커뮤니티 구성원들은 본인의 발언이 충분히 귀담아들어졌다고 생각될 때까지 주요 의견을 피력할 것입니다. 사소한 걱정거리만 남았을 때에야 커뮤니티는 앞으로 나아갑니다. '합의점을 찾는다'는 표현은 커뮤니티가 하나의 완벽한 정답에 도달하지는 못할 수도 있다는 것을 나타냅니다. 대신 의견을 듣고 토론하는 데 집중할 뿐입니다. -실제로 프로젝트 메인테이너로서, 합의 과정을 추구하지 않더라도 사람들이 듣고 있다는 사실을 아는 것이 중요합니다. 다른 사람들이 느끼는 것을 느끼게하고, 자신의 우려를 해결하기 위해 노력하는 것은 민감한 상황을 확산시키는 데 많은 도움이됩니다. 그런 다음, 당신의 말을 행동으로 후속 조치하십시오. +반드시 합의점을 찾는 과정을 문제 해결에 적용하지 않더라도, 여러분이 프로젝트 관리자로서 모두의 이야기를 듣고 있음을 알려주는 것이 중요합니다. 사람들의 이야기를 귀담아듣고, 문제를 해결해 주기 위해 전념하는 것은 시간과 노력이 들지만 민감한 상황을 피할 수 있습니다. 여러분의 말을 행동으로 책임지세요. -결단을 내리기 위해 서두르지 마십시오. 모든 사람이 의견을 듣고 모든 정보가 공개되기 전에 공개되도록 해야합니다. +해결책을 찾으려고 섣부른 결정을 내리지 마세요. 모두의 의견을 듣고 모든 정보를 공개한 다음 해결책을 향해 나아가야 합니다. -### 대화는 행동에 초점을 맞추기 +### 행동에 중점을 둔 대화를 이어가세요 -토론은 중요하지만, 생산적 대화와 비생산적 대화의 차이점이 있습니다. +토론은 중요합니다. 하지만 생산적인 토론과 비생산적인 토론에는 차이가 있습니다. -그것이 적극적으로 결의안을 향해 움직이는 한 토론을 장려하십시오. 대화가 심해지거나 화제가 되는 것이 확실하다면, 잽이 개인적으로 달라 지거나, 사람들이 사소한 세부 사항에 대해 애매한 말을 하고 있습니다. +해결책을 향해 실질적으로 나아가는 토론을 장려하세요. 이야기가 침체되거나, 주제에서 벗어나거나, 대화에 감정이 실리기 시작하거나, 사람들이 사소한 사항으로 트집을 잡고 있다면 멈춰야 합니다. -이러한 대화를 계속하도록 허용하는 것은 당면 문제에 좋지 않을 뿐만 아니라 커뮤니티의 건강에도 좋지 않습니다. 이러한 유형의 대화가 허용되거나 심지어 권장된다는 메시지를 보내고, 사람들이 향후 문제를 제기하거나 해결하지 못하도록 막을 수 있습니다. +이런 토론이 지속되도록 내버려두는 것은 해결해야 할 이슈뿐 아니라 커뮤니티의 건강에도 나쁜 영향을 줄 수 있습니다. 사람들은 이런 식의 토론이 허락되거나 심지어 장려된다고까지 생각할 수 있으며, 장래의 이슈를 발의하거나 해결하지 못하게 될 수 있습니다. -당신이나 다른 사람들이 만든 모든 요점으로, 자신에게 _"이것이 우리를 어떻게 결의안에 더 가까이 가게 할 수 있습니까?"_라고 물어봅니다. +여러분 혹은 누군가가 만든 모든 논점에 대해 자문해 보세요. "이 대화가 어떻게 우리를 해결책으로 이끌어줄 수 있을까?" -대화가 풀리기 시작하면, 대화에 재집중하고자 _"다음 단계는 무엇입니까?"_라고 그룹에 요청하십시오. +대화가 풀리기 시작했다면 다시 집중하기 위해 사람들에게 물어보세요. "이제 어떻게 할까요?" -대화가 명확하게 어디로도 가지 않는 경우, 명확한 조치가 취해지지 않았거나 적절한 조치가 이미 취해져서, 문제를 종결하며 이유를 설명합니다. +대화가 진전되지 않는다면 마땅히 취할 조치가 없거나 이미 적절한 조치가 취해진 것입니다. 이슈를 닫고 그 이유를 설명하세요. -### 현명하게 전투를 선택하기 +### 전장은 현명하게 선택하세요 -상황이 중요합니다. 토론에 참여한 사람과 그들이 커뮤니티의 나머지 부분을 대표하는 방법을 고려하십시오. +문맥 역시 중요합니다. 토론에 누가 참여하고 있는지, 그들이 커뮤니티의 나머지를 어떻게 대표하는지 고려하세요. -커뮤니티의 모든 사람들이 이 문제에 대해 화가 나거나, 심지어 이 이슈에 관여 했습니까? 또는 트러블메이커입니까? 적극적인 목소리가 아닌 조용한 커뮤니티 회원을 고려하는 것을 잊지 마십시오. +커뮤니티의 모두가 이 이슈에 대해 관심이나 불만을 가지고 있나요? 아니면 한 명이 문제를 일으키고 있는 것인가요? 직접 발언하는 대신 지켜보고 있는 커뮤니티 구성원들이 있음을 잊지 마세요. -이 문제가 커뮤니티의 광범위한 요구를 반영하지 않는다면, 소수의 사람들의 우려를 인정할 필요가 있습니다. 명확한 해결 방법이 없는 반복되는 문제인 경우, 주제에 대한 이전 토론을 지정하고 스레드를 닫습니다. +이슈가 커뮤니티의 전반적인 수요를 충족시키지 않는 것이라면 소수의 걱정을 인정하는 것으로 충분할 수 있습니다. 해당 주제에 관한 기존 토론으로 안내하고 이슈를 닫으세요. -### 커뮤니티 동점자 식별하기 +### 커뮤니티 해결사를 선정하세요 -좋은 태도와 명확한 의사 전달을 통해, 가장 어려운 상황을 해결할 수 있습니다. 그러나 생산적인 대화에서 조차, 진행 방법에 대한 견해 차이가 있을 수 있습니다. 이러한 경우에는, 동점자 역할을 할 수 있는 개인 또는 그룹을 식별하십시오. +좋은 태도와 명확한 의사소통으로 대부분의 어려운 상황은 해결할 수 있습니다. 그러나 생산적인 대화에서도 어떻게 진행해야 하는가에 대한 의견 차이는 있을 수 있습니다. 이럴 때는 해결사 역할을 할 수 있는 개인이나 집단을 선정하세요. -tiebreaker는 프로젝트의 주요 메인테이너가 될 수도 있고, 투표를 기반으로 결정을 내릴 수 있는 소규모 그룹일 수도 있습니다. 이상적으로, 당신은 tiebreaker와 관련 프로세스를 GOVERNANCE 파일에서 식별하여 사용해야합니다. +해결사는 프로젝트 대표 관리자일 수도 있고, 투표를 기반으로 결정을 내리는 집단일 수도 있습니다. 해결사를 활용할 일이 생기기 전에 GOVERNANCE 파일에 해결사와 관련 절차를 명시해 두는 것이 이상적입니다. -당신의 tiebreaker는 최후의 수단이어야합니다. 분열적인 이슈는 커뮤니티가 성장하고 배울 수있는 기회입니다. 이러한 기회를 포용하고 협업 프로세스를 사용하여 가능하면 해결 방법으로 이동하십시오. +해결사는 마지막 방책으로서 쓰여야 합니다. 의견이 엇갈리는 이슈는 여러분의 커뮤니티가 배우고 성장할 기회입니다. 이러한 기회를 놓치지 말고 협력적인 과정을 통해 가능한 해결책을 향해 나아가세요. -## Community is the ❤️ of open source +## 커뮤니티는 오픈소스의 ❤️으로 -건강하고, 번영하는 커뮤니티는 매주 수천 시간을 오픈소스에 쏟아 붓고 있습니다. 많은 기여자가 오픈소스에서 일하는 이유 - 또는 일하지 않는 이유 - 를 다른 사람들에게 지적합니다. 그 힘을 건설적인 방법으로 활용하는 방법을 배우면, 잊지 못할 오픈소스 경험이 있는 누군가를 도울 수 있습니다. +건강하고 번성하는 커뮤니티는 매주 오픈소스에 채워지는 수천 시간의 연료가 됩니다. 많은 기여자들이 오픈소스에 기여하(거나 하지 않)는 이유로서 다른 기여자들을 꼽습니다. 커뮤니티의 힘을 건설적으로 다루는 법을 배움으로써 여러분은 누군가가 잊을 수 없는 오픈소스 경험을 가질 수 있도록 도울 것입니다. diff --git a/_articles/ko/code-of-conduct.md b/_articles/ko/code-of-conduct.md index 649900421ca..93f72e02a60 100644 --- a/_articles/ko/code-of-conduct.md +++ b/_articles/ko/code-of-conduct.md @@ -3,11 +3,6 @@ lang: ko title: 귀하의 행동강령 description: 행동강령을 채택하고 시행함으로써 건강하고 건설적인 커뮤니티 행동을 촉진하십시오. class: coc -toc: - why-do-i-need-a-code-of-conduct: "왜 행동강령이 필요합니까?" - establishing-a-code-of-conduct: "행동강령 수립하기" - deciding-how-youll-enforce-your-code-of-conduct: "행동강령을 어떻게 적용 할 것인지 결정하기" - enforcing-your-code-of-conduct: "행동강령 지키기" order: 8 image: /assets/images/cards/coc.png related: @@ -15,7 +10,7 @@ related: - leadership --- -## Why do I need a code of conduct? +## 행동강령이 왜 필요할까요? 행동강령은 프로젝트 참가자의 행동에 대한 기대치를 설정하는 문서입니다. 행동강령을 채택하고, 시행하면 커뮤니티에 긍정적인 사회적 분위기를 조성하는데 도움이 될 수 있습니다. @@ -23,7 +18,7 @@ related: 행동강령은 건강하고, 건설적인 커뮤니티 행동을 촉진할 수 있도록 해줍니다. 능동적으로 행동하면 자신이나 다른 사람들이 프로젝트에 피로를 느끼게 될 가능성을 낮추고, 누군가가 동의하지 않을 때 조치를 취할 수 있도록 도와줍니다. -## Establishing a code of conduct +## 행동강령 수립하기 가능한 빨리 행동강령을 수립하십시오: 이상적으로, 처음 프로젝트를 만들 때입니다. @@ -34,18 +29,18 @@ related: * 누군가가 행동강령을 위반하면 어떻게되는가 * 누군가가 위반 사례를 신고 할 수 있는 방법 -가능한 모든 곳에서 이전 기술을 사용하십시오. [기여자 규약](http://contributor-covenant.org/)은 Kubernetes, Rails 및 Swift를 포함하여 40,000 개 이상의 오픈소스 프로젝트에서 사용되는 행동강령입니다. +가능한 모든 곳에서 이전 기술을 사용하십시오. [기여자 규약](https://www.contributor-covenant.org/)은 Kubernetes, Rails 및 Swift를 포함하여 40,000 개 이상의 오픈소스 프로젝트에서 사용되는 행동강령입니다. -[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 파일을 놓고 CONTRIBUTING 또는 README 파일에서 링크하여 커뮤니티에 표시되게 하십시오. -## Deciding how you'll enforce your code of conduct +## 행동강령을 어떻게 시행할 것인지 결정하기 @@ -59,13 +54,13 @@ related: 행동강령을 보고하고 누가 그 보고서를 받았는지 설명하기 위해 사람들에게 사적인 (이메일 주소같은) 방법을 제공해야합니다. 메인테이너, 그룹 메인테이너 또는 행동강령 그룹이 될 수 있습니다. -누군가 그 보고서를 받는 사람에 대한 위반 사항을 보고하기를 원할 수도 있다는 것을 잊지 마십시오. 이 경우, 위반 사항을 다른 사람에게 보고 할 수있는 옵션을 제공하십시오. 예시로, @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)하고 있습니다: > 학대, 괴롭힘 또는 기타 용납 될 수없는 행동의 사례는 C.kidman Brown과 Michael R. Crusoe에게만 보내지는 **khmer-project@idyll.org** 로 이메일을 보내서 신고할 수 있습니다. 두 가지 중 하나와 관련된 문제를 신고하려면 BEACON 행동 과학 연구 센터 (NSF Center for Science and Technology)의 다양성 책임자 (Diversity Director)인 **Judi Brown Clarke 박사**에게 이메일을 보내 주시기 바랍니다 영감을 얻으려면, Django의 [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/)를 확인해봅시다(프로젝트의 크기에 따라 이 포괄적인 것을 필요로 하지 않을 수도 있습니다). -## Enforcing your code of conduct +## 행동강령을 시행하기 때로는, 최선의 노력에도 불구하고, 누군가 이 코드를 위반하는 행동을 취할 때가 있습니다. 부정적인 행동이나 유해한 행동을 해결할 수 있는 몇 가지 방법이 있습니다. @@ -104,7 +99,7 @@ related: 금지 회원은 영구적이고 회피 할 수 없는 관점의 차이를 나타나기 때문에 가볍게 생각해서는 안됩니다. 해결 방법에 도달할 수 없다는 것이 명백 할 때만 이러한 조치를 취해야합니다. -## Your responsibilities as a maintainer +## 메인테이너로서의 책임 행동강령은 임의적으로 집행되는 법이 아닙니다. 귀하는 행동강령의 집행자이며 행동강령이 정하는 규칙을 준수하는 것은 귀하의 책임입니다. @@ -114,6 +109,6 @@ _기술적인_ 행동강령을 위반하지 않는 행동 보고서는 여전히 결국, 메인테이너로서, 당신은 수용 가능한 행동에 대한 기준을 설정하고 시행합니다. 프로젝트의 커뮤니티 가치를 형성 할 수 있는 능력이 있으며, 참여자는 이러한 가치를 공정하고 균등하게 적용할 것을 기대합니다. -## Encourage the behavior you want to see in the world 🌎 +## 당신이 이 세상에서 보고 싶은 행동을 장려하기 🌎 프로젝트가 적대적이거나 환영받지 못하는 것처럼 보일 때, 다른 사람이 행동을 용인하는 사람이 한 명이라도 더 많은 기여자를 잃을 위험이 있으며, 그 중 일부는 절대 만나지 못할 수도 있습니다. 행동강령을 채택하거나 시행하는 것이 항상 쉬운 것은 아니지만, 친숙한 환경 조성은 커뮤니티 성장을 도울 것입니다. diff --git a/_articles/ko/finding-users.md b/_articles/ko/finding-users.md index 82eeb02ebc8..545394fc19b 100644 --- a/_articles/ko/finding-users.md +++ b/_articles/ko/finding-users.md @@ -1,15 +1,8 @@ --- lang: ko -title: 프로젝트에서 사람찾기 -description: 행복한 사용자의 손에 넣어져서 오픈소스 프로젝트의 성장을 도우십시오. +title: 프로젝트에 기여할 사람 찾기 +description: 당신의 오픈소스 프로젝트가 행복한 사용자들의 손길 아래 성장할 수 있게 만드세요. class: finding -toc: - spreading-the-word: "단어 확산하기" - figure-out-your-message: "메시지 이해하기" - help-people-find-and-follow-your-project: "사람들이 프로젝트를 찾고 팔로우하도록 돕기" - go-where-your-projects-audience-is-online: "프로젝트의 고객이 있는 (온라인)으로 이동하기" - go-where-your-projects-audience-is-offline: "프로젝트의 고객이 있는 (오프라인)으로 이동하기" - build-a-reputation: "평판 쌓기" order: 3 image: /assets/images/cards/finding.png related: @@ -17,149 +10,139 @@ related: - building --- -## Spreading the word +## 소문내기 -출시할 때 오픈소스 프로젝트를 홍보해야한다는 규정은 없습니다. 인기와 아무런 관련이 없는 오픈소스에서 일하는 많은 성취 이유가 있습니다. 그러나 다른 사람들이 오픈소스 프로젝트를 찾고 사용할 수 있기를 희망한다면, 이제는 모든 사람들에게 열심히 일하게 할 시간입니다! +시작할 때부터 오픈소스 프로젝트를 홍보해야 한다는 규칙은 없습니다. 오픈소스에 기여하는 데는 인기와 무관한 많은 이유가 있습니다. 사람들이 여러분의 오픈소스 프로젝트를 찾고 이용해주기를 기대하지만 말고 여러분의 노력에 대한 이야기를 퍼뜨려야 합니다! -## Figure out your message +## 메시지 생각해 내기 -프로젝트를 홍보하기 위한 실제 작업을 시작하기 전에, 프로젝트의 기능과 중요한 이유를 설명할 수 있어야합니다. +프로젝트를 홍보하기 위한 실질적인 작업을 시작하기 전에 프로젝트가 무엇을 하고 왜 중요한지 설명할 수 있어야 합니다. -무엇이 당신의 프로젝트를 다양하고 흥미롭게 만드나요? 왜 그것을 만들었습니까? 이러한 질문을 스스로 해결하면 다른 사람들을 설득하기가 더 쉬울 것입니다. +무엇이 여러분의 프로젝트를 색다르고 흥미롭게 만드나요? 왜 프로젝트를 시작했나요? 이러한 질문에 직접 답하면 프로젝트의 중요성을 알리는 데 도움이 됩니다. -사람들이 문제를 해결하기 때문에, 사용자들은 궁극적으로는 참여자로서만 참여한다는 것을 기억하십시오. 프로젝트의 메시지와 가치에 대해 생각할 때 _그들이_ 무엇을 원하는 것인지에 대한 렌즈를 통해 보도록 하십시오. +여러분의 프로젝트가 사람들의 문제를 해결해주기 때문에 사람들은 사용자가 되고 기여자가 될 것이라는 점을 기억하세요. 프로젝트의 메시지와 가치에 대해 생각할 때 사용자와 기여자의 관점으로 바라보세요. -예시로, @robb는 코드 예제를 사용하여 자신의 프로젝트인 [Cartography](https://github.com/robb/Cartography)를 효율적으로 했습니다: +예를 들어 @robb는 코드 예제를 사용해 그의 프로젝트 [Cartography](https://github.com/robb/Cartography)가 왜 유용한지 명확하게 알려줍니다. ![Cartography README](/assets/images/finding-users/cartography.jpg) -메시징에 대해 더 자세히 알고 싶으면, Mozilla의 ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) 개발자용 연습 personas를 확인하십시오. +메시지 전달에 대해 더 알아보고 싶다면 사용자 페르소나 개발을 위한 Mozilla의 ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/)를 참조하세요. -## Help people find and follow your project +## 사람들이 당신의 프로젝트를 찾고 팔로우하도록 돕기 -사람들이 단일 네임스페이스를 가리켜 프로젝트를 찾고 기억하도록 돕습니다. +정보를 한 곳에 집중시켜 사람들이 여러분의 프로젝트를 찾고 기억하기 더 쉽게 만드세요. -**작업을 홍보하기 위해 명확히 처리를 하기.** 트위터 핸들, GitHub URL 또는 IRC 채널을 통해 사람들을 프로젝트에 쉽게 안내 할 수 있습니다. 그들은 또한 귀하의 프로젝트가 성장하는 커뮤니티에 모일 장소를 제공합니다. +**여러분의 작업을 홍보하기 위한 핸들을 정하세요.** 트위터 계정, GitHub URL, IRC 채널 등은 사람들을 여러분의 프로젝트에 끌어들이는 쉬운 방법입니다. 이런 바깥 연락망은 성장하는 프로젝트 커뮤니티가 모일 장소를 제공해 줍니다. -프로젝트에 이 채널을 아직 설정하고 싶지 않다면, 자신의 모든 트위터 또는 GitHub 핸들을 홍보하십시오. 예를 들어, 만남이나 행사에서 말하는 경우, 소개 또는 슬라이드에 포함되어 있는지 확인하십시오. 그런식으로 사람들은 당신에게 연락하거나 일을 수행하는 방법을 알고 있습니다. +아직 프로젝트 계정이나 사이트 등을 만들고 싶지 않다면, 대신 여러분이 하는 모든 일에서 여러분 스스로의 트위터 혹은 GitHub 계정을 홍보하세요. 사람들이 여러분에게 연락하거나 여러분의 프로젝트에 관심을 가질 수 있게 할 것입니다. 모임이나 행사에서 발표를 한다면 약력이나 슬라이드에 꼭 연락처를 적어 두세요. -**프로젝트를 위한 웹 사이트를 만드는 것을 고려하기.** 웹 사이트는 프로젝트를 보다 편리하고 쉽게 탐색할 수 있게 해주며, 특히 명확한 문서 및 자습서와 함께 사용할 수 있습니다. 또한 프로젝트가 활성화되어있어 시청자가 더 편안하게 사용할 수 있습니다. 예시를 사용하여 사람들에게 프로젝트 사용 방법에 대한 아이디어를 제공하십시오. +**프로젝트 웹사이트 작성을 고려하세요.** 깔끔한 문서와 튜토리얼을 담은 웹사이트는 여러분의 프로젝트를 더 친근하고 탐색하기 쉽게 만듭니다. 웹사이트가 있으면 프로젝트가 더 활성화되어 있다는 느낌을 주고, 이는 방문자들이 프로젝트를 더 편한 마음으로 사용할 수 있게 할 것입니다. 사람들에게 아이디어를 주기 위해 여러분의 프로젝트를 유용하게 사용할 수 있는 예시를 제공하세요. -[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django의 협력자가 말하기를 웹사이트는 _"by far the best thing we did with Django in the early days"_이라고 했습니다. +Django의 공동 크리에이터인 [@adrianholovaty](https://news.ycombinator.com/item?id=7531689)는 웹사이트 운영이 "우리가 Django 개발 초반에 했던 일들 중 가장 잘한 일"이었다고 말했습니다. -만약 당신의 프로젝트가 깃허브에 호스팅된다면, [GitHub 페이지](https://pages.github.com/)를 통해 웹사이트를 쉽게 만드는 것을 보실 수 있습니다. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/),와 [Middleman](https://middlemanapp.com/)은 포괄적인 사이트 중, 훌륭한 [예시입니다](https://github.com/showcases/github-pages-examples). +여러분의 프로젝트가 GitHub에서 호스팅된다면 [GitHub Pages](https://pages.github.com/)를 이용해 쉽게 웹사이트를 만들 수 있습니다. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), [Middleman](https://middlemanapp.com/) 같은 포괄적 웹사이트의 훌륭한 [예시](https://github.com/showcases/github-pages-examples)를 참조하세요. ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) -이제 프로젝트에 대한 메시지와 사람들이 프로젝트를 쉽게 찾을 수 있는 방법을 얻었으므로, 거기서 나와서 고객과 대화를 나눠보십시오. +이제 여러분은 프로젝트에 대한 메시지와 사람들이 프로젝트를 쉽게 찾아올 수 있는 길을 마련했습니다. 세상으로 나가서 사람들에게 널리 알리세요! -## Go where your project's audience is (online) +## 프로젝트의 청중이 있는 곳으로 가기 (온라인) -온라인 홍보는 단어를 빠르게 공유하고 전파 할 수 있는 좋은 방법입니다. 온라인 채널을 사용하면 매우 광범위한 잠재적 고객에게 도달 할 수 있습니다. +온라인에서의 활동은 이야기를 빠르게 퍼트리는 훌륭한 방법입니다. 온라인 채널을 이용하면 아주 넓은 층의 잠재 사용자 혹은 기여자와 닿을 수 있습니다. -기존 온라인 커뮤니티 및 플랫폼을 활용하여 잠재 고객에게 도달하십시오. 만약 오픈소스 프로젝트가 소프트웨어 프로젝트라면, 아마도 [스택 오버플로우](http://stackoverflow.com/), [레딧](http://www.reddit.com), [해커 뉴스](https://news.ycombinator.com/), 또는 [Quora](https://www.quora.com/)에서 고객을 찾을 수 있을 것입니다. 사람들이 당신의 작품에 대해 가장 많은 이익을 보거나 즐거워한다고 생각하는 채널을 찾으십시오. +기존의 온라인 커뮤니티나 플랫폼을 이용해 청중에게 다가가세요. 여러분의 오픈소스 프로젝트가 소프트웨어 프로젝트라면 [Stack Overflow](http://stackoverflow.com/), [Reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), [Quora](https://www.quora.com/) 같은 곳에서 관심 있는 사람을 찾을 수 있을 것입니다. 여러분의 작품을 가장 유용하게 쓰거나 반가워할 것 같은 사람들이 모인 채널을 찾으세요. -관련 방법으로 프로젝트를 공유하는 방법을 찾을 수 있는지 확인하십시오: +어떻게 여러분의 프로젝트를 공유할 수 있을지 더 알아봅시다. -* **관련 오픈소스 프로젝트와 커뮤니티에 대해 알아보십시오.** 때로는 프로젝트를 직접 홍보할 필요가 없습니다. 프로젝트가 파이썬을 사용하는 데이터 과학자에게 완벽하면, 파이썬 데이터 과학 커뮤니티에 대해 알아보십시오. 사람들이 당신을 알게되면, 자연스런 기회가 생겨 대화를 나누고 작업을 공유하게됩니다. -* **프로젝트가 해결하는 문제를 겪고있는 사람들을 찾으십시오.** 프로젝트의 타겟층에 속한 사람들을 관련 포럼을 통해 검색하십시오. 그들의 질문에 답하고 적절한 방법으로 프로젝트를 솔루션으로 제안하십시오. -* **피드백 요청하기.** 관련성 높고 흥미로운 청중에게 자신과 자신의 작업을 소개하십시오. 프로젝트에서 누가 이익을 얻을지 생각하는 사람에 대해 구체적으로 설명합시다. 이렇게 문장을 끝내봅니다: _"누군가 Y를 하려고하면, 나는 내 프로젝트가 정말로 X를 도울 것이라고 생각합니다_".단순히 귀하의 작업을 홍보하는 것이 아니라, 다른 사람들의 의견을 경청하고 이에 응답해봅니다. +* **관련된 오픈소스 프로젝트와 커뮤니티를 찾으세요.** 프로젝트를 직접 홍보할 필요가 없을 때도 있습니다. 예컨대 여러분의 프로젝트가 파이썬을 사용하는 데이터 사이언티스트에게 딱 맞는다면 파이썬 데이터 사이언티스트 커뮤니티를 찾아가세요. 그곳의 사람들이 여러분을 잘 알게 되면, 여러분의 프로젝트에 대해 이야기할 기회도 자연스럽게 늘어날 것입니다. +* **여러분의 프로젝트가 해결할 수 있는 문제를 겪고 있는 사람을 찾으세요.** 관련 포럼에서의 검색을 통해 프로젝트의 목표 사용자층을 찾고, 그들의 질문에 답해주며 적절한 때에 재치 있게 여러분의 프로젝트를 해결책으로서 제시하는 방법도 있습니다. +* **피드백을 요청하세요.** 관심과 흥미를 가질 만한 사람들에게 여러분과 여러분의 프로젝트를 소개하세요. 프로젝트를 어떤 사람들이 유용하게 사용할 수 있을지에 대한 여러분의 생각을 구체적으로 말하세요. 문장은 이런 식으로 끝내는 것이 좋습니다. "제 프로젝트가 X를 하려는 Y 여러분들에게 분명 큰 도움이 될 거라고 생각해요." 프로젝트를 홍보하기만 하지 말고 사람들의 피드백에 귀 기울이고 답변하세요. -일반적으로 말하면, 보답하기 전에 다른 사람들을 돕는 데 집중하십시오. 누구나 온라인으로 프로젝트를 홍보하기 쉽기 때문에, 많은 소음이 발생할 것입니다. 자신이 원하는 사람이 아니라, 무리에서 눈에 띄기 위해서 자신이 누구인지를 사람들에게 알릴 수 있습니다. +사람들로부터 무언가를 받고자 한다면 그 전에 그들을 도와주는 데 집중하세요. 프로젝트를 온라인에서 홍보하는 것은 누구나 할 수 있는 쉬운 일이기 때문에 아주 많은 경쟁이 있는 셈입니다. 그 사이에서 눈에 띄려면 사람들에게 여러분이 무엇을 원하는가가 아닌 여러분이 어떤 사람인가를 알려야 합니다. -아무도 주의를 기울이지 않거나 초기 봉사 활동에 응답하지 않으면, 낙심하지 마십시오! 대부분의 프로젝트 시작은 수개월 또는 수년이 걸릴 수 있는 반복 과정입니다. 처음으로 응답을 얻지 못하면 다른 전술을 시도하거나 다른 사람들의 작품에 가치를 더하는 방법을 먼저 찾으십시오. 이러한 일에는 시간과 헌신이 필요합니다. +여러분의 노력에도 불구하고 아무도 관심을 가지지 않는다면, 너무 실망하지 마세요! 대부분의 프로젝트는 초기 단계에 수 개월부터 수 년의 시간을 필요로 합니다. 처음 시도에 반응을 얻지 못한다면, 다른 전략을 시도하거나 다른 사람의 프로젝트에 가치를 제공할 방법을 찾아보세요. 프로젝트를 홍보하고 본궤도에 올리는 데에는 충분한 시간과 노력이 필요합니다. -## Go where your project's audience is (offline) +## 프로젝트의 청중이 있는 곳으로 가기 (오프라인) ![Public speaking](/assets/images/finding-users/public_speaking.jpg) -오프라인 이벤트는 새로운 프로젝트를 홍보하는 인기있는 방법입니다. 참여한 잠재 고객에게 도달하거나, 더 깊은 인간 관계를 구축할 수 있는 좋은 방법입니다. 특히 개발자에게 다가가려는 경우 더욱 그렇습니다. +오프라인 행사는 새로운 프로젝트를 홍보하는 인기 있는 수단입니다. 오프라인 행사는 분야에서 활동 중인 사람들과 만나고 그들과 인간관계를 쌓을 절호의 기회입니다. 특히 개발자들과 친해지는 데 관심이 있다면 더욱 그렇습니다. -만약 [새로운 공개 연설](http://speaking.io/)을 한다면, 프로젝트의 언어 또는 생태계와 관련된 지역 모임을 찾아보십시오. +사람들 앞에서 [발표](http://speaking.io/)하는 것이 익숙하지 않다면 여러분의 프로젝트가 사용하는 언어나 시스템에 관련된 지역 모임을 찾는 것부터 시작하세요. -이전에 한번도 얘기 한 적이 없다면, 긴장을 하는 것이 정상입니다! 그들이 진정으로 당신의 일에 대해 듣고 싶어하기 때문에 청중이 거기 있다는 것을 기억합시다. +행사에서의 발표가 처음이라면 긴장되는 것은 당연한 일입니다! 청중들이 모인 이유는 여러분의 프로젝트에 대해 듣고 싶어서라는 사실을 기억하세요. -이야기를 할 때, 청중이 흥미롭고 가치있는 것을 얻는 것에 집중합니다. 귀하의 언어를 친절하고 친근하게 유지하십시오. 웃고, 숨 쉬고, 재미있게 보내십시오. +이야기를 풀어나가면서 청중들이 어떤 부분에 흥미를 느끼고 있는지, 그리고 어떤 부분에서 가치를 얻을 수 있을지에 집중하세요. 친절하고 상냥한 말투를 사용하세요. 미소 짓고, 호흡하고, 즐기면 됩니다. -준비가 되었다면, 프로젝트 홍보를 위해 컨퍼런스에서 말하는 것을 고려하십시오. 때로는 컨퍼런스가 전 세계에서 더 많은 사람들에게 다가갈 수 있도록 도와줄겁니다. +준비가 되었다면 프로젝트 홍보를 위해 컨퍼런스에서 발표하는 것도 고려해 보세요. 컨퍼런스는 온 세상의 다양한 사람들을 만날 기회를 제공합니다. -귀하의 언어 또는 생태계에서 특정한 회의를 찾으십시오. 대화를 제출하기 전에, 미리 컨퍼런스를 조사하여 참석자와 대화를 나누고 수용 할 확률을 높입니다. 연사를 보면서 회의의 청중을 이해할 수 있습니다. +여러분이 사용하는 언어와 시스템에 관한 컨퍼런스를 찾으세요. 발표 신청서를 제출하기 전에 컨퍼런스를 조사한 뒤, 발표 내용을 청중의 상황에 맞게 다듬어 신청이 받아들여질 가능성을 높이세요. 컨퍼런스의 발표자들에 대해 알아보면 전반적인 청중의 성향을 파악할 수 있습니다. -## Build a reputation +## 평판 쌓기 -위에서 설명한 전략 외에도, 사람들을 초대하여 프로젝트에 기여하도록하는 가장 좋은 방법은 프로젝트를 공유하고 기여하는 것입니다. +지금까지 다루어진 전략에 더해서, 여러분의 프로젝트에 기여할 사람들을 초대하는 가장 좋은 방법은 바로 그들의 프로젝트에 기여하는 것입니다. -신입 회원을 돕고, 자원을 공유하고, 다른 사람들의 일에 사려 깊은 공헌을 하는 것은 긍정적인 평판을 얻는 데 도움이 될 것입니다. 그러면 사람들은 당신의 일에 대한 맥락을 가지게 될 것이며 관심을 기울이고 자신이 하는 일을 공유할 가능성이 높아질 것입니다. - -때로는, 이러한 관계가 더 넓은 생태계와의 공식 파트너십으로 이어질 수도 있습니다. +신입을 돕고, 자원을 공유하고, 다른사람들의 프로젝트에 사려 깊은 기여를 하는 것은 긍정적인 평판을 쌓는 데 도움이 됩니다. 오픈소스 커뮤니티에서 적극적으로 활동하는 회원이 되면 다른 회원들이 여러분이 하는 일에 대한 맥락을 얻게 되고, 여러분의 프로젝트에 관심을 갖고 프로젝트를 공유해 줄 가능성이 높아집니다. 타 오픈소스 프로젝트와의 관계가 발전하면 공식적인 파트너십으로 연결될 수도 있습니다. -평판을 얻기 시작하는 것이 너무 빠르거나, 혹은 너무 늦지 않았습니다. 이미 자신의 프로젝트를 시작했더라도, 다른 사람들을 도울 수 있는 방법을 모색하십시오. - -고객을 키우는 데는 밤새도 해결책이 없습니다. 다른 사람들의 신뢰와 존경심을 얻는 데는 시간이 걸리고 명성을 쌓는 작업은 끝나지 않습니다. +어느 순간도 평판을 쌓기에는 너무 늦거나 이르지 않습니다. 이미 여러분의 프로젝트를 공개했더라도 사람들을 도울 방법을 항상 찾아 다니세요. - +하룻밤 사이에 청중을 확보하는 비법 같은 것은 없습니다. 사람들의 신뢰와 존경심을 얻는 데에는 시간이 필요하고, 평판은 아무리 오래 관리해도 그 끝이 없습니다. -## Keep at it! +## 계속해 나가세요! -때로는, 사람들이 오픈소스 프로젝트에 주목하기까지는 시간이 오래 걸립니다. 괜찮습니다! 오늘날 가장 인기있는 프로젝트 중 일부는 높은 수준의 활동에 도달하기까지 수년이 걸렸습니다. 마술 총알 대신 관계를 구축하는 데에 집중하십시오. 인내심을 갖고, 감사해하는 사람들과 일하는 결과물을 계속 공유하십시오. +사람들이 여러분의 프로젝트에 관심을 갖는 데 오랜 시간이 걸릴 수도 있지만 괜찮습니다! 유명한 프로젝트 중 몇몇은 지금의 경지에 다다르기 위해 몇 년이 들었습니다. 프로젝트가 갑자기 유명해지기를 바라는 대신 관계를 쌓는 데 집중하세요. 인내심을 가지고, 여러분의 노력에 고마워하는 사람들과 작업을 계속 공유하세요. diff --git a/_articles/ko/getting-paid.md b/_articles/ko/getting-paid.md index d0ac5b48684..ea2d74e1c9b 100644 --- a/_articles/ko/getting-paid.md +++ b/_articles/ko/getting-paid.md @@ -3,11 +3,6 @@ lang: ko title: 오픈소스 작업에 대한 비용 지불하기 description: 시간이나 프로젝트에 대한 재정적 지원을 받음으로써 오픈소스에서의 작업을 지속합니다. class: getting-paid -toc: - why-some-people-seek-financial-support: "어떤 사람들은 왜 재정 지원을 요청 하는가" - funding-your-own-time: "시간 펀딩하기" - finding-funding-for-your-project: "프로젝트 펀딩 찾기" - building-a-case-for-financial-support: "재정 지원 사례 구축하기" order: 7 image: /assets/images/cards/getting-paid.png related: @@ -15,7 +10,7 @@ related: - leadership --- -## Why some people seek financial support +## 왜 누군가는 재정적 지원을 찾을까 대부분의 오픈소스 작업은 자원봉사입니다. 예를 들어, 누군가가 사용하는 프로젝트에서 버그를 발견하고 빠른 버그픽스를 제출하거나, 여가 시간에 오픈소스 프로젝트를 사용하여 재미있는 작업을 할 수 있습니다. @@ -37,7 +32,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri avatar Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".

-— @alloy, ["우리가 왜 기여를 허락하면 안되는가"](http://blog.cocoapods.org/Why-we-dont-accept-donations/) +— @alloy, ["우리가 왜 기여를 허락하면 안되는가"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)

@@ -59,26 +54,18 @@ I was looking for a "hobby" programming project that would keep me occupied duri avatar OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.

-— @isaacs, ["현금과 오픈소스"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c#.ftnd5qez0) +— @isaacs, ["현금과 오픈소스"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)

재정 지원을 찾고 있다면, 고려해야 할 두 가지 경로가 있습니다. 기여자로서 자신의 시간을 투자하거나, 프로젝트에 대한 조직 자금을 찾을 수 있습니다. -## Funding your own time +## 당신이 들인 시간에 대한 펀딩을 받기 오늘날, 많은 사람들이 오픈소스에서 파트 타임 또는 풀 타임으로 일하기 위해 돈을 받습니다. 당신의 시간에 대한 대금을 받는 가장 일반적인 방법은 고용주와 상담하는 것입니다. 고용주가 프로젝트를 실제로 사용하고 오픈소스 작업에 대한 사례를 만드는 것이 더 쉽지만, 자신의 계획대로 창의력을 발휘하십시오. 어쩌면 고용주가 프로젝트를 사용하지 않고 파이썬을 이용한 인기있는 파이썬 프로젝트를 유지한다면, 새로운 파이썬 개발자를 유치할 수 있습니다. 어쩌면 고용주가 일반적으로 더 개발자 친화적인 것처럼 보일 수도 있습니다. - - 기존의 오픈소스 프로젝트가 없지만 현재 작업 결과물이 오픈소스인 경우, 고용주가 내부 소프트웨어의 일부를 스스로 오픈할 수 있는 사례를 작성하십시오. 많은 기업들이 브랜드를 구축하고 우수한 인재를 영입하기 위해 오픈소스 프로그램을 개발하고 있습니다. @@ -99,17 +86,17 @@ I was looking for a "hobby" programming project that would keep me occupied duri 현 고용주가 오픈소스 업무의 우선 순위를 결정할 수 없다면, 직원의 오픈소스 기여도를 높이는 새로운 고용주를 찾는 것이 좋습니다. 오픈소스 작업에 대한 헌신을 분명히 하는 회사를 찾아보십시오. 예시입니다 : -* 일부 회사는, [넷플릭스](https://netflix.github.io/)혹은 [페이팔](http://paypal.github.io/)처럼, 오픈소스에 대한 그들의 참여를 강조하는 웹 사이트를 가지고있습니다 -* [Rackspace](https://www.rackspace.com/en-us)는 직원을 위한 [오픈소스 기여 정책](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/)을 게시했습니다 +* 일부 회사는, [넷플릭스](https://netflix.github.io/), 오픈소스에 대한 그들의 참여를 강조하는 웹 사이트를 가지고있습니다 [Go](https://github.com/golang)또는 [React](https://github.com/facebook/react)와 같은 대기업에서 시작된 프로젝트도, 오픈소스 작업에 사람들을 고용 할 가능성이 높습니다. 마지막으로, 개인적인 상황에 따라, 오픈소스 작업을 위해 독립적으로 돈을 모으는 노력을 할 수 있습니다. 예시: -* @gaearon은 [Patreon crowdfunding campaign](http://redux.js.org/)을 통해 [Redux](https://github.com/reactjs/redux)에 대한 그의 작업에 펀드했습니다. +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) +* @gaearon은 [Patreon crowdfunding campaign](https://redux.js.org/)을 통해 [Redux](https://github.com/reactjs/redux)에 대한 그의 작업에 펀드했습니다. * @andrewgodwin은 Django 스키마 마이그레이션 작업을 [Kickstarter 캠페인을 통해](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 펀드했습니다. -## Finding funding for your project +## 당신의 프로젝트에 대한 펀딩을 찾기 개인 기여자를 위한 준비 외에도, 때로는 프로젝트가 회사, 개인 또는 다른 사람들로부터 지속적인 자금 마련을 위해 펀드를 모으는 경우가 있습니다. @@ -123,7 +110,6 @@ I was looking for a "hobby" programming project that would keep me occupied duri 스폰서 프로젝트의 몇 가지 예는 다음과 같습니다. * **[webpack](https://github.com/webpack)** 는 [OpenCollective를 통해](https://opencollective.com/webpack) 회사와 개인에게 돈을 모읍니다 -* **[Vue](https://github.com/vuejs/vue)** 는 [Patreon를 통해 펀드됩니다](https://github.com/open-source/stories/yyx990803) * **[Ruby Together](https://rubytogether.org/)는,** [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) 및 기타 Ruby 인프라 프로젝트에 대한 비용을 지불하는 비영리 단체입니다. ### 수입원 만들기 @@ -134,7 +120,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri * **[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)와 같은 일부 인기있는 프로젝트는, 사업 성장을 지원하기 위해 벤처 캐피탈을 조성하기까지 합니다. +[npm](https://github.com/npm/cli) 및 [Docker](https://github.com/docker/docker)와 같은 일부 인기있는 프로젝트는, 사업 성장을 지원하기 위해 벤처 캐피탈을 조성하기까지 합니다. ### 보조금 신청하기 @@ -147,7 +133,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri 보다 자세한 옵션과 사례 연구를 원할 경우, @nayafia [가이드 작성](https://github.com/nayafia/lemonade-stand)을 통해 오픈소스 저작물에 대한 대가를 받을 수 있습니다. 다른 유형의 기금에는 여러 가지 기술이 필요하기 때문에 어떤 옵션이 가장 적합한 지 알아 내려면 장점을 고려하십시오. -## Building a case for financial support +## 재정적 지원을 받기 위한 근거를 갖추기 프로젝트가 새로운 아이디어이든, 수년간 지속되어 왔든 타겟 기금 제공자를 파악하고 중요한 사건을 만드는데 중요하게 고려되야합니다. @@ -181,6 +167,6 @@ I was looking for a "hobby" programming project that would keep me occupied duri

-## Experiment and don't give up +## 시도해 보고 포기하지 마세요! 오픈소스 프로젝트, 비영리 단체, 소프트웨어 스타트업 등 많은 돈을 모으는 것은 쉽지 않습니다. 대부분의 경우 창의력을 발휘해야합니다. 어떻게 돈을 받고, 연구를 하고, 재밌는 사람의 신발에 몸을 두는지를 확인하면 자금 지원에 대한 설득력있는 사례를 구축하는 데 도움이됩니다. diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md index a7443931070..d4bea3994f4 100644 --- a/_articles/ko/how-to-contribute.md +++ b/_articles/ko/how-to-contribute.md @@ -1,15 +1,8 @@ --- lang: ko title: 오픈소스에 기여하는 방법 -description: 오픈소스에 기여하고 싶습니까? 초보자와 숙련자를 위한 오픈소스 기여에 대한 가이드입니다. +description: 오픈소스에 기여하고 싶으세요? 초보자와 숙련자를 위한 오픈소스 기여 가이드입니다. class: contribute -toc: - why-contribute-to-open-source: "왜 오픈소스에 기여 하나요?" - what-it-means-to-contribute: "기여한다는 것의 의미" - orienting-yourself-to-a-new-project: "새로운 프로젝트에 동참하기" - finding-a-project-to-contribute-to: "기여할 프로젝트 찾기" - how-to-submit-a-contribution: "기여 제출 방법" - what-happens-after-you-submit-a-contribution: "기여를 제출하면 어떻게됩니까?" order: 1 image: /assets/images/cards/contribute.png related: @@ -17,357 +10,352 @@ related: - building --- -## Why contribute to open source? +## 왜 오픈소스에 기여할까요? -오픈소스에 기여하는 것은 당신이 상상할 수 있는 모든 기술을 배우고, 가르치고, 구축하는 보람찬 방법이 될 수 있습니다. +오픈소스에 기여하는 것은 여러분이 상상할 수 있는 모든 기술을 배우고, 가르치고, 구현하는 보람찬 방법이 될 수 있습니다. -왜 사람들은 오픈소스에 기여합니까? 이에는 많은 이유가 있습니다! +왜 사람들은 오픈소스에 기여할까요? 많은 이유가 있습니다! -### 기존 기술 향상 +### 기존 기술을 향상시키세요 -코딩, 사용자 인터페이스 디자인, 그래픽 디자인, 글쓰기 또는 조직화등의 실습을 원한다면 오픈소스 프로젝트에 대한 작업이 있습니다. +코딩, 사용자 인터페이스 디자인, 그래픽 디자인, 글쓰기 또는 조직화 등의 실습을 원한다면 여러분이 맡을 수 있는 오픈소스 프로젝트 작업이 기다리고 있습니다. -### 비슷한 것에 관심이있는 사람들을 만나십시오 +### 비슷한 것에 관심 있는 사람들을 만나세요 -따뜻하고 환영하는 커뮤니티가 있는 오픈소스 프로젝트는 사람들이 수년간 돌아오도록합니다. 많은 사람들이 부리토에 관한 회의나 심야 온라인 채팅를 가지고 서로를 실행하고 있든간에 오픈소스에 참여함으로써 평생동안 우정을 나누고 있습니다. +따뜻한 커뮤니티가 있는 오픈소스 프로젝트는 사람들은 오래 머물게 합니다. 많은 사람들이 오픈소스에 참여하며 평생의 우정을 다지고 있습니다. 그게 회의에서 서로를 마주치는 것이든 한밤중에 부리토에 관해 채팅을 하는 것이든 상관없이요. -### 멘토를 찾고 다른 사람들을 가르치십시오 +### 멘토를 찾고 사람들과 배움을 주고받으세요 -공유 프로젝트에서 다른 사람들과 함께 일한다는 것은 당신이 일을 어떻게하는지 설명하고, 다른 사람들에게 도움을 요청해야 함을 의미합니다. 학습하고 가르치는 행위는 관련된 모든 사람들에게 성취감있는 활동이 될 수 있습니다. +공유 프로젝트에서 다른 사람들과 함께 일한다는 것은 여러분이 무엇을 어떻게 하는지 설명하고, 다른 사람들에게 도움을 요청해야 함을 의미합니다. 학습하고 가르치는 행위는 관련된 모든 사람들에게 성취감 있는 활동이 될 수 있습니다. -### 평판(및 경력)을 키우는 데 도움이 되는 공공 예제 만들기 +### 평판(과 경력)을 쌓는 데 도움이 되는 예제를 만드세요 -정의에 따르면, 모든 오픈소스 저작물은 공개되어 있으므로, 어디서나 할 수 있는 무료 예제를 얻을 수 있습니다. +정의에 따라 모든 오픈소스 저작물은 공개되어 있으므로, 당신이 할 수 있는 것을 보여줄 예제를 가질 수 있는 셈입니다. -### 사람들의 기술 습득 +### 사람을 대하는 기술을 습득하세요 -오픈소스는 충돌 해결, 사람들의 팀 구성 및 작업 우선순위 지정과 같은 리더십 및 관리 기술을 연습 할 수있는 기회를 제공합니다. +오픈소스는 충돌 해결, 팀 구성, 작업 우선순위 지정과 같은 리더십 및 관리 기술을 연습할 수 있는 기회를 제공합니다. -### 작은 것조차도 변경할 수 있는 힘이 있습니다 +### 작은 것조차도 바꿀 수 있는 힘이 있습니다 -오픈소스에 참여하는 것을 즐기는 평생 기여자가 될 필요는 없습니다. 웹 사이트에 오타가 있는 것을 본 적이 있고, 누군가 그것을 고치기를 바랬습니까? 오픈소스 프로젝트에서 여러분은 그렇게 할 수 있습니다. 오픈소스는 사람들이 삶에 대해 어떻게 대처하고 그들이 세상을 경험하는지를 느끼도록 도와줍니다. +오픈소스에 참여하는 것을 즐기는 평생 기여자가 될 필요는 없습니다. 웹 사이트에서 오타를 발견하고 누군가가 고쳐주길 바란 적 있나요? 오픈소스 프로젝트에서 여러분은 그렇게 할 수 있습니다. 오픈소스는 사람들이 삶에 대해 어떻게 대처하고 그들이 세상을 경험하는지를 느끼도록 도와줍니다. -## What it means to contribute +## 기여한다는 것의 의미 -새로운 오픈소스 기여자라면, 기여하는 과정이 위협적일 수 있습니다. 올바른 프로젝트를 어떻게 찾을 수 있습니까? 코딩 방법을 모르는 경우에는 어떻게 해야합니까? 뭔가 잘못되면 어떡하죠? +새로운 오픈소스 기여자라면, 기여하는 과정이 겁날 수도 있습니다. 알맞은 프로젝트를 어떻게 찾아야 할까요? 코딩을 할 줄 모른다면요? 뭔가 잘못되면 어떡하죠? 걱정 마세요! 오픈소스 프로젝트에 참여하는 데는 여러 가지 방법이 있으며, 몇 가지 팁을 통해 경험을 최대한 활용할 수 있습니다. ### 코드를 제공할 필요가 없습니다 -오픈소스에 기여하는 것에 대한 일반적인 오해는 코드를 작성해야한다는 것입니다. 실제로 대부분 프로젝트에서 [무시되거나 간과되는 부분](https://github.com/blog/2195-the-shape-of-open-source)입니다 . 이러한 유형의 기여를 제공하도록 제안함으로써 프로젝트에 큰 도움을 줄 것입니다! +오픈소스에 기여하는 것에 대한 일반적인 오해는 코드를 작성해야 한다는 것입니다. 사실, 프로젝트의 다른 부분이 [무시되거나 간과되는 경우](https://github.com/blog/2195-the-shape-of-open-source)가 더 많습니다. 이러한 유형의 기여에 동참하겠다고 제안하면 프로젝트에 큰 도움이 될 것입니다. -코드 작성을 원한다고해도, 다른 유형의 기여는 프로젝트에 참여하고 다른 커뮤니티 회원을 만날 수 있는 좋은 방법입니다. 이러한 관계를 구축하면 프로젝트의 다른 부분에서 작업 할 수있는 기회가 주어집니다. +코드를 작성하는 것을 좋아해도, 다른 유형의 기여는 프로젝트에 참여하고 다른 커뮤니티 구성원을 만날 수 있는 좋은 방법입니다. 이러한 관계를 구축하면 프로젝트의 다른 부분에서 작업할 기회를 얻을 수 있습니다. - - -### 기획 행사가 마음에 드십니까? +### 행사 계획 짜는 걸 좋아하세요? -* [@fzamperin이 NodeSchool에 대했던 것처럼](https://github.com/nodeschool/organizers/issues/406), 프로젝트에 관한 워크샵이나 모임을 조직하기 +* [NodeSchool을 위해 @fzamperin이 했던 것처럼](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), 티셔츠 혹은 새로운 로고를 위한 예슐 작품 만들기 +* [Drupal의 제안](https://www.drupal.org/community-initiatives/drupal-core/usability)처럼, 사용자 조사를 통해 프로젝트의 네비게이션 또는 메뉴를 재구성하고 개선하기 +* 프로젝트가 일관성 있는 시각적 디자인을 가질 수 있도록 스타일 가이드 작성하기 +* [hapi.js의 기여](https://github.com/hapijs/contrib/issues/68)처럼, 티셔츠 혹은 새로운 로고를 위한 예술 작품 만들기 -### 글 쓰고 싶습니까? +### 글을 쓰고 싶으신가요? -* 프로젝트의 문서 작성 및 개선하기 -* 프로젝트 사용법을 보여주는 예제 폴더를 선별하기 -* 프로젝트의 뉴스 레터를 시작하거나 메일링 리스트의 하이라이트를 관리하십시오. -* [PyPA의 기여처럼](https://github.com/pypa/python-packaging-user-guide/issues/194), 프로젝트의 튜토리얼을 작성하기. -* 프로젝트의 문서의 번역문 작성하기 +* 프로젝트 문서 작성 및 개선하기 +* 프로젝트 사용법을 보여주는 예제 폴더 선별하기 +* 프로젝트의 뉴스레터 발행을 시작하거나 메일링 리스트의 하이라이트를 관리하기 +* [PyPA의 기여처럼](https://packaging.python.org/), 프로젝트 튜토리얼 작성하기 +* 프로젝트 문서 번역 작성하기 -### 조직하는 것을 좋아합니까? +### 조직하는 것을 좋아하세요? * 중복된 이슈에 대한 링크 및 새로운 이슈 라벨 제안, 정리된 상태 유지하기 -* [@nzakas가 ESLint에 했던것처럼](https://github.com/eslint/eslint/issues/6765), 열려있는 이슈를 검토하고, 오래된 이슈를 닫을 것을 제안하기 -* 최근 열린 이슈에 대한 질문을 명확히 하여 토론으로 나아가게하기 +* [ESLint의 @nzakas](https://github.com/eslint/eslint/issues/6765)처럼, 열려있는 이슈를 검토하고 오래된 이슈를 닫을 것을 제안하기 +* 최근 열린 이슈에 대한 질문을 명확히 하여 토론으로 나아가게 하기 -### 코드 작성하고 싶습니까? +### 코드를 작성하고 싶으세요? -* [@dianjin이 Leaflet 했던것처럼](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560), 해결할 문제를 찾기 +* [Leaflet의 @dianjin처럼](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560), 해결할 문제를 찾기 * 새로운 기능을 작성하는 데 도움을 줄 수 있는지 물어보기 * 프로젝트 설정 자동화하기 * 툴링 및 테스트 개선하기 -### 사람들을 돕는 것을 좋아합니까? +### 사람들을 돕는 것을 좋아하세요? -* 예를 들어, Stack Overflow의 ([Postgres 예시](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) 혹은 Reddit과 관련된 질문에 대답해주기 -* 열린 이슈에서 사람들의 질문에 대답해주기 -* 토론 보드나 대화 채널의 관리 돕기 +* Stack Overflow([Postgres 예시](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) 혹은 Reddit에서 프로젝트에 관련된 질문에 답변하기 +* 열린 이슈에서 사람들의 질문에 답변하기 +* 토론 게시판이나 대화 채널 관리 돕기 -### 다른 사람들의 코드를 돕는 것을 좋아합니까? +### 사람들의 코드 작성을 돕고 싶으세요? -* 다른 사람들의 제출한 코드를 리뷰하기 -* 프로젝트를 어떻게 쓰는가에 대한 튜토리얼 작성하기 -* [@ereichert처럼 Rust에서 @bronzdoc을 사용하고](https://github.com/rust-lang/book/issues/123#issuecomment-238049666), 다른 기여자를 멘토로 초대하기 +* 사람들이 제출한 코드 리뷰하기 +* 프로젝트를 어떻게 이용하는가에 대한 튜토리얼 작성하기 +* [Rust의 @ereichert가 @bronzdoc에게 해준 것처럼](https://github.com/rust-lang/book/issues/123#issuecomment-238049666), 다른 기여자의 멘토가 되는 것을 제안하기 -### 소프트웨어 프로젝트만으로 작업할 필요는 없습니다! +### 꼭 소프트웨어 프로젝트에서 작업할 필요는 없습니다! -"오픈소스"는 종종 소프트웨어를 의미하지만, 무엇이든간에 거의 협력 할 수 있습니다. 오픈소스 프로젝트로 개발되는 책, 요리법, 목록 및 수업이 있습니다. +"오픈소스"는 보통 소프트웨어를 의미하지만, 무엇이든 간에 거의 협력할 수 있습니다. 오픈소스 프로젝트로 개발되는 책, 요리법, 리스트 및 수업도 있습니다. -예시로 아래와 같습니다: +예를 들면: * @sindresorhus는 [list of "awesome" lists](https://github.com/sindresorhus/awesome)를 만들었습니다 * @h5bp는 프론트엔드 개발자 후보군용 [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions)을 관리하고 있습니다 * @stuartlynn과 @nicole-a-tesla는 [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)를 만들었습니다 -비록 당신이 소프트웨어 개발자일지라도, 문서 프로젝트 작업은 오픈소스에서 시작하는 데 도움이 될 수 있습니다. 코드를 포함하지 않는 프로젝트에서 작업하는 것이 종종 위협적이지 않으며, 협업 프로세스가 자신감과 경험을 쌓을 수 있습니다. +비록 당신이 소프트웨어 개발자일지라도, 문서 프로젝트 작업은 오픈소스에서 시작하는 데 도움이 될 수 있습니다. 코드를 포함하지 않는 프로젝트에서 작업하는 것은 보통 어렵지 않으며, 협력하는 과정에서 여러분의 자신감과 경험을 쌓을 수 있을 것입니다. -## Orienting yourself to a new project +## 새 프로젝트로 향하기 -오타를 수정하는 이상의 것, 오픈소스에 기여하는 것은 파티에서 낯선 사람들에게 다가가는 것과 같습니다. 라마에 대해 이야기하기 시작하면, 금붕어에 관한 토론이 깊어지면서 아마 당신을 조금 이상하게 보게 될 것입니다. +오타를 수정하는 것 이상으로 오픈소스에 기여하는 것은 파티에서 낯선 사람들에게 다가가는 것과 같습니다. 사람들이 금붕어에 대한 깊은 토론에 빠져 있을 때 라마에 대해 이야기한다면 그들은 아마 여러분을 약간 이상하게 볼 겁니다. -자신의 제안으로 맹목적으로 뛰어 들기 전에, 먼저 방을 읽는 법을 배우십시오. 그렇게하면 아이디어가 눈에 띄고 들리게 될 확률이 높아집니다. +맹목적으로 여러분의 제안을 펼치기 전에, 방의 분위기를 읽는 법을 배우는 것부터 시작하세요. 그러면 여러분의 아이디어에 귀 기울여 줄 가능성이 높아집니다. ### 오픈소스 프로젝트의 해부학 -모든 오픈소스 커뮤니티는 다릅니다. +모든 오픈소스 커뮤니티는 서로 다릅니다. -하나의 오픈소스 프로젝트에 수년을 보내다 보면 하나의 오픈소스 프로젝트를 알게되었다는 것을 의미합니다. 다른 프로젝트로 이동하면 어휘, 규범 및 의사 소통 스타일이 완전히 다른 것을 알 수 있습니다. +여러 해 동안 한 오픈소스 프로젝트에 투자했다면 그 프로젝트를 잘 알게 됐을 것입니다. 다른 프로젝트로 넘어가면 어휘, 표준, 커뮤니케이션 스타일이 완전히 다르다는 것을 알 수 있습니다. -즉, 많은 오픈소스 프로젝트는 비슷한 조직 구조를 따릅니다. 서로 다른 커뮤니티 역할과 전반적인 프로세스를 이해하면 새로운 프로젝트를 신속하게 수행할 수 있습니다. +많은 오픈소스 프로젝트는 비슷한 조직 구조를 따릅니다. 다양한 커뮤니티 역할과 전반적인 프로세스를 이해하면 새로운 프로젝트에 빠르게 적응할 수 있습니다. -일반적인 오픈소스 프로젝트에는 다음 유형의 사람들이 있습니다: +일반적인 오픈소스 프로젝트에서 사람들은 다음과 같은 유형으로 나뉩니다. * **작성자:** 이 프로젝트를 만든 사람 혹은 조직 * **소유자:** 조직 또는 저장소에 대한 관리 권한을 가진 사람 (항상 원래 작성자와 동일하지는 않음) -* **메인테이너:** 비전을 주도하고 프로젝트의 조직 측면을 관리하는 책임이 있는 기여자. (그들은 프로젝트의 저자 또는 소유자일 수도 있습니다.) -* **기여자:** 프로젝트에 다시 기여한 모든 사람. -* **커뮤니티 맴버:** 프로젝트를 사용하는 사람들. 대화에서 적극적이거나 프로젝트 방향에 대한 의견을 표명할 수 있습니다. +* **메인테이너:** 비전을 주도하고 프로젝트의 조직 측면을 관리하는 책임이 있는 기여자 (그들은 프로젝트의 저자 또는 소유자일 수도 있습니다.) +* **기여자:** 프로젝트에 기여한 모든 사람. +* **커뮤니티 맴버:** 프로젝트를 사용하는 사람들. 적극적으로 대화에 참여하거나 프로젝트 방향에 대한 의견을 제시할 수도 있습니다. -더 큰 프로젝트에는 툴링, 선별, 커뮤니티 중재 및 이벤트 조직과 같은 다양한 업무에 초점을 둔 소위원회 또는 실무 그룹이 있을 수도 있습니다. 프로젝트 웹 사이트에서 "팀" 페이지를 찾거나 거버넌스 문서 저장소에 이 정보를 찾으십시오. +더 큰 프로젝트에는 툴링, 선별, 커뮤니티 중재 및 이벤트 조직과 같은 다양한 업무에 초점을 둔 소위원회 또는 실무 그룹이 있을 수도 있습니다. 프로젝트 웹 사이트에서 "팀" 페이지를 찾거나 거버넌스 문서 저장소에서 정보를 찾아보세요. 프로젝트에도 문서가 있습니다. 이러한 파일은 대개 저장소의 최상위 레벨에 나열됩니다. -* **라이선스:** 정의에 의하면, 모든 오픈소스 프로젝트는 반드시 [오픈소스 라이선스를 가져야 합니다](https://choosealicense.com). 만약 프로젝트가 라이선스를 가지지 않는다면, 이건 오픈소스가 아닙니다. -* **README:** README는 새로운 커뮤니티 구성원을 프로젝트에 환영하게 하는 지침서입니다. 왜 프로젝트가 유용하고 시작하는 방법을 설명합니다. -* **CONTRIBUTING:** README는 사람들이 프로젝트를 사용하는 데 도움이되지만, CONTRIBUTING 문서는 사람들이 프로젝트에 _기여_하는 데 도움이됩니다. 필요한 기여 유형과 프로세스 작동 방식을 설명합니다. 모든 프로젝트가 CONTRIBUTING 파일을 갖고있는 것은 아니지만, 공존하는 환영 프로젝트임을 알립니다. -* **CODE_OF_CONDUCT:** code of conduct는 참가자의 행동에 대한 기본 원칙을 설정하고, 친절하고 환영할만한 환경을 조성하는 데 도움이 됩니다. 모든 프로젝트가 CODE_OF_CONDUCT 파일을 가지고있는 것은 아니지만, 그 존재가 기여할 수 있는 환영 프로젝트임을 알립니다. +* **LICENSE:** 정의에 의해, 모든 오픈소스 프로젝트는 반드시 [오픈소스 라이선스를 가져야 합니다](https://choosealicense.com). 만약 프로젝트가 라이선스를 가지지 않는다면, 이건 오픈소스가 아닙니다. +* **README:** README는 새로운 커뮤니티 구성원을 프로젝트에 환영하는 지침서입니다. 왜 프로젝트가 유용한지, 어떻게 시작해야 할지 설명합니다. +* **CONTRIBUTING:** README는 사람들이 프로젝트를 사용하는 데 도움이되지만, CONTRIBUTING 문서는 사람들이 프로젝트에 _기여_하는 데 도움이 됩니다. 필요한 기여 유형과 프로세스 작동 방식을 설명합니다. 모든 프로젝트가 CONTRIBUTING 파일을 갖고 있는 것은 아니지만, 이 파일이 있다면 여러분의 기여를 환영한다는 뜻입니다. +* **CODE_OF_CONDUCT:** Code of Conduct(윤리 강령)는 참가자의 행동에 대한 기본 원칙을 정하고, 친절하고 따뜻한 환경을 조성하는 데 도움이 됩니다. 마찬가지로 모든 프로젝트가 CODE_OF_CONDUCT 파일을 가지고 있지는 않지만, 이 파일이 있다면 여러분의 기여를 환영한다는 뜻입니다. * **다른 문서:** (특히 큰 프로젝트의 경우) 튜토리얼, 연습장 또는 거버넌스 정책과 같은 추가 문서가 있을 수 있습니다. 마지막으로 오픈소스 프로젝트는 다음 도구를 사용하여 토론을 구성합니다. 기록 보관소를 읽으면 커뮤니티가 어떻게 사고하고 작동하는지 잘 알 수 있습니다. -* **Issue tracker:** 사람들이 프로젝트와 관련된 이슈를 토론하는 공간입니다. -* **Pull requests:** 사람들이 토론하고 진행중인 변경 사항을 검토합니다. -* **토론 포럼 혹은 메일링 리스트:** 일부 프로젝트는 회화 주제(ex. _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests)에 대해 이러한 채널을 사용할 수 있습니다. 다른 사람들은 모든 대화에 이슈 트래커를 사용합니다. -* **동기식 채널 채팅:** 일부 프로젝트에서는 일상 회화, 공동 작업 및 빠른 교환을 위해 채팅 채널 (예 : 슬랙 또는 IRC)을 사용합니다. +* **Issue tracker:** 프로젝트와 관련된 이슈를 토론하는 공간입니다. +* **Pull requests:** 지금 진행 중인 변경 사항에 대해 논의하고 검토하는 공간입니다. +* **토론 포럼 혹은 메일링 리스트:** 일부 프로젝트는 회화성 주제(버그 제보나 기능 요구 대신 _"...하려면 어떻게 하나요?"_ 또는 _"...에 대해 어떻게 생각하세요?"_ 같은 주제)에 대해 이러한 채널을 사용할 수 있습니다. 나머지 프로젝트는 모든 대화에 이슈 트래커를 사용합니다. +* **채팅 채널:** 일부 프로젝트에서는 일상 대화, 협업 및 빠른 의사소통을 위해 Slack이나 IRC 같은 채팅 채널을 사용합니다. -## Finding a project to contribute to +## 기여할 프로젝트 찾기 -이제 오픈소스 프로젝트가 어떻게 작동하는지 알게 되었으니, 이제는 기여할 프로젝트를 찾아야 할 때입니다! +오픈소스 프로젝트가 어떻게 작동하는지 알았으니, 이제 기여할 프로젝트를 찾아야 합니다! -이전에 오픈소스에 기여한 적이 없다면, John F. Kennedy 미국 대통령의 _"Ask not what your country can do for you - ask what you can do for your country."_ 발언에서 조언을 구하십시오. +이전에 오픈 소스에 기여한 적이 없다면, 미국 존 케네디 대통령의 명언을 떠올려보세요. +_"Ask not what your country can do for you - ask what you can do for your country."_ +_"국가가 나를 위해 무엇을 해줄 것을 바라기에 앞서, 내가 국가를 위해 무엇을 할 것인가를 생각해야 한다."_ -오픈소스에 기여하는 것은 프로젝트 전반에 걸쳐 모든 수준에서 발생합니다. 첫 번째 기여가 정확히 무엇인지 또는 어떻게 보일지를 생각할 필요가 없습니다. +오픈소스에 기여하는 것은 프로젝트 전반에 걸쳐 모든 수준에서 발생합니다. 여러분의 첫 번째 기여가 정확히 무엇이고 어떻게 보일지 생각할 필요가 없습니다. -대신, 이미 사용하고 있거나 사용하고 싶은 프로젝트에 대해 생각해보십시오. 적극적으로 기여할 프로젝트는 자신이 다시 찾아 오는 프로젝트입니다. +대신, 이미 사용하고 있거나 사용하고 싶은 프로젝트에 대해 생각하는 것으로 시작하세요. 여러분이 적극적으로 기여하게 될 프로젝트는 여러분이 계속 사용하게 되는 프로젝트입니다. -그 프로젝트 내에서, 뭔가가 더 좋거나 다를 수 있다고 생각할 때마다 본능에 따라 행동하십시오. +그 프로젝트에서, 뭔가가 더 좋거나 다를 수 있다고 생각할 때마다 본능에 따라 행동하세요. -오픈소스는 독점적인 클럽이 아닙니다; 그것은 당신 같은 사람들에 의해 만들어졌습니다. "오픈소스"는 전세계 문제를 유연하게 해결할 수 있는 멋진 용어입니다. +오픈소스는 독점적인 클럽이 아닙니다. 여러분과 같은 사람들에 의해 만들어졌습니다. "오픈소스"는 전세계의 문제들을 유연하게 해결할 수 있는 멋진 용어입니다. -README를 스캔하여 깨진 링크 또는 오타를 찾을 수 있습니다. 또는 새로운 사용자이고 무언가가 고장 났거나, 실제로 문서에 있어야한다고 생각되는 문제를 발견했습니다. 그것을 무시하고 계속 나아가거나, 다른 사람에게 그것을 고치라고 요구하는 대신, 피칭을 통해 도움을 줄 수 있는지 확인하십시오. 오픈소스가 무엇인지 알아보십시오! +README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또는 여러분이 새로운 사용자로서 제대로 동작하지 않거나 문서에서 다뤄져야 할 이슈를 발견할 수도 있습니다. 그것을 무시하거나 다른 사람에게 그것을 고쳐달라고 하는 대신, 여러분이 직접 도움을 줄 수 있는지 알아보세요. 그것이 바로 오픈소스입니다! -> [일반적인 기여의 28%](http://www.igor.pro.br/publica/papers/saner2016.pdf)는 오타 수정, 서식 재 지정 또는 번역 작성과 같은 문서입니다. +> [일반적인 기여의 28%](http://www.igor.pro.br/publica/papers/saner2016.pdf)는 오타 수정, 서식 재지정 또는 번역 작성과 같은 문서입니다. -또한 다음 리소스 중 하나를 사용하여 새 프로젝트를 찾고 기여할 수 있습니다. +다음 리소스 중 하나를 사용하여 새 프로젝트를 찾고 기여할 수 있습니다. * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) -* [First Timers Only](http://www.firsttimersonly.com/) -* [Your First PR](https://yourfirstpr.github.io/) +* [First Timers Only](https://www.firsttimersonly.com/) * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) -* [Up For Grabs](http://up-for-grabs.net/) -* [Contributor-ninja](https://contributor.ninja) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) -### A checklist before you contribute +### 기여하기 전 확인할 사항 -기여하고 싶은 프로젝트를 찾았으면, 프로젝트가 기여를 받기에 적합한 지 빠르게 확인하십시오. 그렇지 않으면, 노력이 절대로 응답을 받지 못할 수도 있습니다. +기여하고 싶은 프로젝트를 찾았으면, 프로젝트가 기여를 받기에 적합한지 빠르게 확인하세요. 그렇지 않으면, 노력이 영원히 응답을 받지 못할 수도 있습니다. -다음은 프로젝트가 새로운 기여자에게 좋은가에 대한 여부를 평가하는 편리한 체크리스트입니다. +다음은 프로젝트가 새로운 기여자에게 적합한지 평가할 수 있는 편리한 체크리스트입니다. -**오픈소스의 정의를 충족시킵니다** +**오픈소스의 정의를 충족시킬 것**
-**프로젝트가 적극적으로 기여를 받습니다** +**프로젝트가 적극적으로 기여를 받아들일 것** -마스터 브랜치에서 커밋 활동을 살펴보십시오. GitHub에서는 이 정보를 저장소의 홈페이지에서 볼 수 있습니다. +마스터 브랜치에서 커밋 활동을 살펴보세요. GitHub에서는 이 정보를 저장소의 홈페이지에서 볼 수 있습니다.
-다음으로, issues 프로젝트의 이슈를 봅시다. +다음으로, 프로젝트의 이슈를 보세요.
-이제 프로젝트의 pull requests에 대해 동일한 작업을 수행하십시오. +이번엔 프로젝트의 풀 리퀘스트(PR)를 확인하세요.
-**프로젝트가 환영합니다** +**프로젝트가 기여자를 환영할 것** -프로젝트가 친근하게 환영한다는 신호로 새로운 기여자를 받아 들일 것입니다. +친근하고 환영하는 분위기의 프로젝트는 새로운 기여자를 기꺼이 맞이합니다.
@@ -375,154 +363,154 @@ README를 스캔하여 깨진 링크 또는 오타를 찾을 수 있습니다. avatar Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.

-— @kfogel, [_OSS 생산_](http://producingoss.com/en/evaluating-oss-projects.html) +— @kfogel, [_Producing OSS_](http://producingoss.com/en/evaluating-oss-projects.html)

-## How to submit a contribution +## 기여하는 방법 -원하는 프로젝트를 찾았으면 기꺼이 기여할 준비가되었습니다. 마침내! 올바른 방법으로 기여를 받는 방법은 다음과 같습니다. +기여하고 싶은 프로젝트를 찾았나요? 드디어! 기여하는 올바른 방법은 다음과 같습니다. -### 효과적으로 의사 소통하기 +### 효과적으로 의사소통하기 -일회 기여자이든 커뮤니티에 참여하려고하든, 관계없이 다른 사람들과 협력하는 것은 오픈소스에서 개발할 가장 중요한 기술 중 하나입니다. +하나의 기여를 하든 커뮤니티에 참여하려고 하든, 관계없이 다른 사람들과 협력하는 것은 오픈소스에서 개발할 가장 중요한 기술 중 하나입니다. -이슈를 열거나 pull request를 하기 전에, 또는 채팅에서 질문을 하기 전에, 아이디어를 효과적으로 전달할 수 있도록 이러한 점을 명심하십시오. +이슈나 PR을 열거나 채팅에서 질문을 하기 전에 아이디어를 효과적으로 전달할 수 있도록 아래와 같은 사항을 명심하세요. -**context 제공하기.** 다른 사람들이 신속하게 속도를 낼 수 있도록 도와주십시오. 오류가 발생하는 경우, 수행하려는 작업과 오류를 재현하는 방법을 설명하십시오. 새로운 아이디어를 제안하는 경우, 프로젝트에 유용하다고 생각하는 이유를 설명하십시오 (귀하뿐 아니라!). +**맥락을 제공하세요.** 다른 사람들이 빨리 속도를 낼 수 있도록 도와주세요. 오류가 발생하면 수행하려는 작업과 오류를 재현하는 방법을 설명하세요. 새로운 아이디어를 제안하는 경우 그것이 (여러분이 아닌) 프로젝트에 유용하다고 생각하는 이유를 설명하세요. -> 😇 _"제가 Y를 하려면 X가 안됩니다"_ +> 😇 _"Y를 할 때 X가 안 돼요."_ > -> 😢 _"X 가 망가졌네요! 이거 고쳐주세요."_ +> 😢 _"X가 안 돼요! 이거 고쳐주세요."_ -**미리 과제하기.** 무언가 알지는 못하지만 시도한 것을 보여주십시오. 도움을 요청하기 전에 프로젝트의 README, 문서, 이슈 (공개 또는 비공개), 메일링 리스트를 확인하고 인터넷에서 답변을 검색하십시오. 사람들은 당신이 배우려고한다는 것을 증명할 때 감사해할 것입니다. +**과제를 미리 하세요.** 이해하지는 못하지만 시도해봤다는 것을 보여주세요. 도움을 요청하기 전에 프로젝트의 README, 문서, (열린 혹은 닫힌) 이슈, 메일링 리스트를 확인하고 인터넷에서 해결책을 검색해보세요. 당신이 배우려는 자세를 보이면 사람들은 존중할 것입니다. -> 😇 _"X를 구현하는 방법을 잘 모르겠네요. 도움말 문서를 확인했고 모든 멘션도 찾지 못했습니다."_ +> 😇 _"X를 구현하는 방법을 잘 모르겠어요. 도움말 문서를 확인했지만 관련 언급을 찾지 못했어요."_ > > 😢 _"X는 어떻게 해요?"_ -**요청을 짧고 직접적으로 유지하기.** 이메일을 보내는 것과 마찬가지로 모든 기여는 아무리 간단하거나 도움이된다 하더라도, 다른 사람의 검토가 필요합니다. 많은 프로젝트는 도움을 줄 수있는 사람들보다 많은 요청을 받고 있습니다. 간결하게 하십시오. 누군가가 당신을 도울 수있는 기회를 증가시킬 것입니다. +**짧고 직접적으로 요청하세요.** 이메일을 보내는 것과 마찬가지로, 모든 기여는 아무리 간단하거나 도움이 된다 하더라도 다른 사람의 검토가 필요합니다. 많은 프로젝트가 사람들이 도울 수 있는 것보다 많은 요청을 받고 있습니다. 간결하게 적으세요. 누군가 당신을 도울 가능성이 늘어날 것입니다. -> 😇 _"API 튜토리얼을 작성하고 싶습니다."_ +> 😇 _"API 튜토리얼을 작성하고 싶어요."_ > -> 😢 _"저는 다른 날 고속도로를 몰고 가스로 달려 들었어요. 그리고 나서 저는 우리가 해야 할 일에 대해 이 놀라운 생각을 가지고 있었고요. 그렇지만 제가 설명하기 전에, 님께 보여주기 위해서..."_ +> 😢 _"요전날 고속도로를 따라 차를 몰고 가다가 주유소에 들렀는데, 우리가 해야 할 일에 대한 놀라운 아이디어가 떠올랐어요. 하지만 설명해드리기 전에 보셔야 할 게 있는데요…"_ -**모든 커뮤니케이션을 공개하기.** 유혹스러운 일이긴하지만, 중요한 정보(예 : 보안 문제 또는 심각한 행동 위반)를 공유해야하는 경우가 아니면 메인테이너에게 개인적으로 연락하지 마십시오. 대화를 공개 할 때 더 많은 사람들이 귀하의 교류를 통해 배우고 이익을 얻을 수 있습니다. 토론은 그 자체로 기여할 수 있습니다. +**모든 의사소통을 공개하세요.** 매혹적이긴 하지만 보안 문제나 심각한 규칙 위반 같은 중요한 정보를 공유해야 하는 경우가 아니면 관리자에게 개인적으로 연락하지 마세요. 대화를 공개해야 더 많은 사람들이 여러분의 교류를 통해 배우고 이익을 얻을 수 있습니다. 토론은 그 자체로 기여가 됩니다. -> 😇 _(댓글로) "@-메인테이너 안녕하세요! 이 PR은 어떻게 진행되고 있나요?"_ +> 😇 _(댓글로) "@-관리자 안녕하세요! 이 PR은 어떻게 진행되고 있나요?"_ > -> 😢 _(이메일로) "안녕하세요, 이메일을 보내서 죄송합니다만.제 PR을 검토할 기회가 있었는지 궁금합니다."_ +> 😢 _(이메일로) "안녕하세요, 메일로 귀찮게 해서 죄송합니다만 제 PR을 검토해보셨는가 해서요."_ -**질문을 하는 것은 괜찮습니다(그러나 참을성 있으십시오!).** 누구나 프로젝트를 처음 접했을뿐 아니라 경험 많은 공헌자도 새로운 프로젝트를 볼 때 속도를 높여야 합니다. 마찬가지로, 오랜 기간의 메인테이너가 프로젝트의 모든 부분을 항상 잘 알고있는 것은 아닙니다. 그들에게 당신이 보여주기를 바라는 것과 같은 인내심을 보여주십시오. +**질문하는 것은 좋지만 참을성을 가지세요.** 누구나 프로젝트를 처음 접했을 때가 있으며 경험 많은 기여자도 새로운 프로젝트에는 가속이 필요합니다. 마찬가지로 오랜 관리자도 프로젝트의 모든 부분을 항상 잘 알고 있는 것은 아닙니다. 여러분이 기대하는 만큼의 인내심을 사람들에게 보여주세요. -> 😇 _"이 오류 찾아주셔서 고맙습니다. 저는 이 제안에 따를게요. 이렇게 출력되네요."_ +> 😇 _"이 오류를 알아봐 주셔서 감사합니다. 제안을 따라 고쳐 봤어요. 이렇게 출력되네요."_ > -> 😢 _"왜 내 문제를 해결할 수 없어요? 이 프로젝트는 님이 만든게 아닌가요?"_ +> 😢 _"왜 이 문제를 해결할 수 없는 거죠? 이 프로젝트는 관리자님이 만든 게 아닌가요?"_ -**커뮤니티의 의사 결정을 존중하기.** 귀하의 아이디어는 커뮤니티의 우선 순위 또는 비전과 다를 수 있습니다. 그들은 의견을 제시하거나 아이디어를 추구하지 않기로 결정할 수 있습니다. 토론하고 타협을 찾아야하지만, 메인테이너는 당신보다 더 오래 결정을 내리지 않고 살아야합니다. 당신이 그들의 방향에 동의하지 않으면, 당신은 항상 자신의 포크에서 일하거나 자신의 프로젝트를 시작할 수 있습니다. +**커뮤니티의 결정을 존중하세요.** 여러분의 아이디어는 커뮤니티의 우선순위나 비전과 다를 수 있습니다. 그들은 개선점을 제시하거나 여러분의 아이디어를 도입하지 않기로 결정할 수 있습니다. 절충안을 논의하는 동안 관리자는 여러분보다 오래 여러분의 결정을 고려해야 합니다. 여러분이 커뮤니티의 비전에 동의하지 않는다면 여러분의 포크에서 작업하거나 따로 프로젝트를 시작하는 방법도 있습니다. -> 😇 _"제 use case를 지원할 수 없다는 점에 실망했지만, 사용자의 작은 부분에만 영향을 주었다고 설명하셨으니 이해됩니다. 들어주셔서 감사합니다."_ +> 😇 _"제 유즈케이스를 지원할 수 없다는 점은 아쉽지만 일부 사용자에게만 영향을 미친다는 관리자님의 설명은 이해가 되네요. 들어주셔서 감사합니다."_ > -> 😢 _"왜 use case를 지원하지 않나요? 납득할 수 없네요!"_ +> 😢 _"왜 제 유즈케이스를 지원하지 않나요? 납득할 수가 없네요!"_ -**무엇보다도 고급스러움을 유지하기.** 오픈소스는 전 세계의 공동 작업자로 구성됩니다. 컨텍스트는 언어, 문화, 지역 및 시간대에 걸쳐 손실됩니다. 또한 서면 의사 소통을 통해 분위기 나 분위기를 전달하기가 더 어려워집니다. 이 대화에서 좋은 의도를 가정하십시오. 정중하게 생각을 뒤로 밀거나, 더 많은 맥락을 묻거나, 더 자세하게 설명하는 것은 좋습니다. 인터넷을 찾은 때보다 더 나은 곳을 떠나보십시오. +**무엇보다도 세련된 자세를 유지하세요.** 오픈소스는 전 세계의 협력자로 구성되어 있습니다. 맥락은 언어, 문화, 지역, 시간대에 걸쳐 점점 손실됩니다. 게다가 글을 통한 의사소통은 말투나 분위기를 전달하기가 어렵습니다. 대화에 좋은 의도를 가지고 참여한다고 생각하세요. 예의를 갖추면 아이디어를 밀어붙여도, 더 자세한 설명을 요구해도, 여러분의 입장을 명확히 해도 좋습니다. 다만 인터넷 세계를 여러분의 첫인상보다 좋은 곳으로 만들어 주세요. -### 컨텍스트 수집 +### 정보 수집 -어떤 일을 하기 전에, 빠른 시일내에 당신의 아이디어가 다른 곳에서 논의되지 않았는지 확인하십시오. 프로젝트의 README, 이슈(공개 및 폐쇄), 메일링 리스트 및 스택 오버플로우를 생략하십시오. 모든 것을 처리하는 데 몇 시간을 허비하지 않아도 되지만, 핵심 용어에 대한 빠른 검색은 먼 길을 가집니다. +무언가 시작하기 전에, 여러분의 아이디어가 다른 곳에서 논의되지 않았는지 빠르게 확인해 보세요. 프로젝트의 README, 이슈, 메일링 리스트 및 스택 오버플로우를 훑어보세요. 모든 것을 찾아보는 데 몇 시간을 투자할 필요는 없지만, 몇 가지 핵심 용어에 대한 검색이면 충분할 것입니다. -다른 곳에서 아이디어를 찾을 수 없다면, 움직일 준비가 된 것입니다. 프로젝트가 GitHub에 있다면, 이슈를 열거나 pull request을 열어 소통할 수 있습니다: +다른 곳에서 여러분의 아이디어를 찾을 수 없다면, 움직일 때가 되었습니다. 프로젝트가 GitHub에 있는 경우 다음과 같이 이슈나 PR을 열어 소통할 수 있습니다. -* **이슈**는 대화나 토론을 시작하는 것과 같습니다 -* **Pull requests** 는 솔루션에서 일을 시작하기 위한 것입니다 -* 명확한 질문이나 How-To 질문과 같은 **간단한 커뮤니케이션의 경우,** 프로젝트에 하나의 채팅 채널이있으면 스택 오버플로우, IRC, 슬랙 또는 다른 채팅 채널을 요청합니다 +* **이슈**는 대화나 토론을 시작하는 것과 같습니다. +* **풀 리퀘스트**는 솔루션에 대한 작업을 시작하기 위한 것입니다. +* 명확한 질문이나 방법 질문과 같은 **간단한 커뮤니케이션**은 스택 오버플로우 또는 IRC, 슬랙 같은 프로젝트 채팅 채널에 물어보세요. -이슈를 열거나 pull request을 요청하기 전에, 프로젝트의 기여 문서(일반적으로 CONTRIBUTING 또는 README 파일)를 확인하여 구체적인 내용을 포함해야하는지 확인하십시오. 예를 들어, 템플릿을 따르거나 테스트를 사용하도록 요청할 수 있습니다. +이슈나 PR을 열기 전에 프로젝트의 기여 문서(일반적으로 CONTRIBUTING 또는 README 파일)에서 뭔가 구체적인 내용을 포함해야 하는지 확인하세요. 프로젝트에서 여러분에게 특정 템플릿을 따르거나 테스트를 사용하도록 요구할 수 있습니다. -실질적인 기여를 하고 싶다면, 이슈를 열고 작업하십시오. 수락되지 않을 수 있는 일을 하기 전에(깃허브에서는, ["Watch"를 클릭](https://help.github.com/articles/watching-repositories/)하여 토론을 알림 받을 수 있습니다), 잠시동안 프로젝트를 보고 커뮤니티 멤버를 알게되면 도움이됩니다. +실질적인 기여를 하고 싶다면, 작업하기 전에 이슈를 열고 물어보세요. 승인되지 않을 수도 있는 작업을 하기 전에(깃허브에서는, ["Watch"를 클릭](https://help.github.com/articles/watching-repositories/)해서 토론을 알림 받을 수 있습니다), 커뮤니티 구성원들을 알게 되면 도움이 됩니다. ### 이슈 열기 -일반적으로 다음과 같은 상황에서 이슈를 열어야합니다: +일반적으로 다음 상황에서 이슈를 열어야 합니다. -* 스스로 해결할 수 없는 오류를 보고 -* 높은 수준의 주제 또는 아이디어 (예시. 커뮤니티, 비전, 정책) 토론 +* 스스로 해결할 수 없는 오류 보고 +* 커뮤니티, 비전, 정책 등 높은 수준의 주제 또는 아이디어 토론 * 새로운 기능이나 다른 프로젝트 아이디어 제안 -이슈에서 의사소통을 위한 팁: +이슈에서 소통할 때의 팁은 다음과 같습니다. -* **해결하려는 이슈가 공개적으로 보이면,** 사람들이 당신이 그것에 대해 알 수 있도록 이슈에 대해 의견을 말하십시오. 그렇게하면 사람들은 중복으로 작업할 가능성이 줄어 듭니다. -* **이슈가 조금 전에 열렸다면,** 다른 곳에서 해결되었거나, 이미 해결되었기 때문에 작업을 시작하기 전에 확인을 요청하십시오. -* **이슈를 열었지만 나중에 대답을 알아 낸 경우,** 사람들에게 알리고 이슈를 해결할 수 있도록 이슈에 대한 의견을 말하십시오. 그 결과를 문서화하는 것조차도 프로젝트에 대한 기여입니다. +* **열린 이슈에 대해 작업하려고 한다면** 사람들이 알 수 있게 댓글을 달아두세요. 그렇게 하면 다른 사람과 같은 부분을 작업할 가능성이 줄어듭니다. +* **이슈가 오래 전부터 열려 있었다면** 내용이 다른 곳에서 논의되고 있거나 이미 해결됐을 수도 있으므로 작업을 시작하기 전에 확인을 요청하세요. +* **이슈를 열었지만 나중에 해결법을 알아냈다면** 이슈에 댓글을 달아 사람들에게 알리고 이슈를 닫으세요. 그 결과에 대한 문서화도 프로젝트에의 기여가 됩니다. -### pull request 열기 +### PR 열기 -일반적으로 다음 상황에서 pull request를 열어야합니다: +일반적으로 다음 상황에서 PR을 열어야 합니다. -* 사소한 수정 사항 제출 (예 : 오타, 깨진 링크 또는 분명한 오류) -* 이미 이슈를 열었거나 이미 논의한 내용을 기여로 시작하기 +* 오타, 깨진 링크, 명백한 오류 등 사소한 수정 사항 제출 +* 요구되고 있거나 이슈에서 논의한 내용에 대한 작업 시작 -pull request은 완료된 작업을 나타내지 않아도됩니다. 일반적으로 초기에 pull request을 열면 다른 사람이 진행 상황을 보거나 피드백을 줄 수 있습니다. 제목 줄에 "WIP"(진행중인 작업)이라고 표시하십시오. 나중에 커밋을 더 추가 할 수 있습니다. +PR이 반드시 완료된 작업을 포함할 필요는 없습니다. 보통 다른 사람들이 여러분의 진행 상황을 확인하거나 피드백을 줄 수 있도록 PR을 일찍 여는 것이 좋습니다. 제목 줄에 "WIP"(Work In Progress; 진행 중인 작업)라고 표시하세요. 나중에 얼마든지 커밋을 더 추가해도 됩니다. -프로젝트가 GitHub에 있는 경우, pull request을 제출하는 방법은 다음과 같습니다: +프로젝트가 GitHub에 있는 경우 PR을 제출하는 방법은 다음과 같습니다. -* **[저장소를 포크하고](https://guides.github.com/activities/forking/)** 로컬에 클론합니다. 리모트로 추가하여 로컬을 원래의 "업스트림"저장소에 연결하십시오. "업스트림"의 변경 사항을 자주 가져 와서 최신 상태로 유지하면 pull request을 제출할 때, 병합 충돌이 덜 발생할 수 있습니다. ([이 곳](https://help.github.com/articles/syncing-a-fork/)에서 더 자세한 지침보기.) -* 수정을 위한 **[브랜치 생성하기](https://guides.github.com/introduction/flow/)**. -* **모든 관련있는 이슈** 혹은 PR에서 지원중인 문서 참조하기 (ex. "#37 닫음.") -* **전후의 스크린 샷 포함합니다** 변경 사항에 HTML/CSS의 차이가 포함되어있는 경우, pull request의 본문에 이미지를 끌어다 놓습니다. -* **변경점을 테스트합니다!** 기존 테스트가 있는 경우 변경 사항을 실행하고 필요한 경우 새 테스트를 작성하십시오. 테스트의 존재 여부와 상관없이 변경 사항이 기존 프로젝트를 손상시키지 않는지 확인하십시오. -* 당신의 능력을 최대한 발휘하여 **프로젝트 스타일에 기여하십시오.** 이는 들여 쓰기, 세미콜론 또는 주석을 자신의 저장소에서와 다르게 사용하는 것을 의미 할 수 있지만, 메인테이너가 병합하기 쉽고, 다른 사람들이 나중에 이해하고 유지할 수 있게 해줍니다. +* **[저장소를 포크](https://guides.github.com/activities/forking/)**하고 로컬에 복제(Clone)합니다. 리모트로 추가하여 로컬을 원래의 "업스트림" 저장소에 연결하세요. PR을 제출할 때 충돌이 발생할 가능성을 낮추기 위해 "업스트림"의 변경 사항을 자주 가져 와서 최신 상태로 유지하세요. (자세한 내용은 [여기](https://help.github.com/articles/syncing-a-fork/)를 참조하세요.) +* 수정을 위한 **[브랜치를 생성](https://guides.github.com/introduction/flow/)**하세요. +* **모든 관련 이슈** 혹은 지원 문서를 참조하세요. (ex. "Closes #37.") +* 변경 사항에 HTML/CSS가 포함되어 있는 경우 **적용 전/후 스크린샷을 첨부**하세요. PR의 본문에 이미지를 끌어다 놓으면 됩니다. +* **변경 사항을 테스트**하세요! 변경 사항에 대해 이미 있는 테스트를 수행하고 필요한 경우 새 테스트를 작성하세요. 테스트의 존재 여부와 상관없이 변경 사항이 기존 프로젝트를 손상시키지 않는지 확인하세요. +* 최선을 다해 **프로젝트 스타일에 기여**하세요. 들여쓰기, 세미콜론 또는 주석을 여러분의 평소 스타일과 다르게 사용해야 할 수도 있지만, 관리자가 PR을 병합하기 더 용이하고 향후의 유지보수가 쉬워질 것입니다. -만약 이것이 첫 pull request 라면, @kentcdodds가 무료 walkthrough 리소스로 생성한 [Make a Pull Request](http://makeapullrequest.com/)를 확인하십시오. +만약 첫 PR을 열려고 한다면 @kentcdodds가 무료 영상 튜토리얼로 공개한 [Make a Pull Request](http://makeapullrequest.com/)를 참조하세요. @Roshanjossey의 [First Contributions](https://github.com/Roshanjossey/first-contributions) 저장소에서 연습해볼 수도 있습니다. -## What happens after you submit a contribution +## 기여한 후에 일어나는 일 -훌륭합니다! 오픈소스 기여자가 되신 것을 축하드립니다. 우리는 그것이 많은 사람들 중 첫번째가 되기를 바랍니다. +해내셨군요! 오픈소스 기여자가 되신 것을 축하드립니다. 앞으로도 많이 기여하실 수 있기를 바랍니다. -기여를 제출하면 다음 중 하나가 발생합니다. +기여를 제출하면 다음 중 하나의 일이 일어날 것입니다. -### 😭 당신은 응답을 얻지 못합니다. +### 😭 답변을 받지 못했어요. -기여를 하기 전에, [활동의 징조가 있는지 프로젝트를 확인](#a-checklist-before-you-contribute)했기를 바랍니다. 그러나 활발한 프로젝트에서도 기여가 응답을 받지 못할 수도 있습니다. +기여하기 전에 [활동의 징조가 있는지 프로젝트를 확인](#기여하기-전-확인할-사항)했기를 바랍니다. 그러나 활발한 프로젝트에서도 기여가 반응을 얻지 못할 수도 있습니다. -1주일 이내에 응답을 받지 못했다면, 같은 쓰레드에서 정중하게 응답하여 누군가에게 검토를 요청하는 것이 좋습니다. 기여자를 검토할 수있는 적절한 사람의 이름을 아는 경우, 해당 스레드에서 이름을 @로 표기할 수 있습니다. +일주일 넘게 답변을 받지 못했다면 누군가에게 검토를 부탁하며 공손하게 대응하는 것이 좋습니다. 여러분의 기여를 검토할 수 있는 적절한 사람의 이름을 안다면 골뱅이표(@)를 이용한 멘션으로 리뷰를 요청할 수 있습니다. -**절대** 그 사람에게 개인적으로 연락하지 마세요; 공개적인 의사소통은 오픈소스 프로젝트에서 필수적이라는 것을 기억하십시오. +**절대** 그 사람에게 개인적으로 연락하지 마세요. 공개적인 의사소통은 오픈소스 프로젝트에서 필수적이라는 것을 기억하세요. -정중한 충돌을 하고도 아직 아무도 응답하지 않으면, 아무도 응답하지 않을 가능성이 있습니다. 그것은 큰 감정이 아니지만, 그것이 당신을 낙담하게 하지마십시오. 모두에게 일어난 일입니다! 귀하가 통제 할 수 없는 개인적 상황을 포함하여 응답을 받지 못한 이유는 여러 가지가 있을 수 있습니다. 다른 프로젝트나 기여 방법을 찾으십시오. 다른 커뮤니티 구성원들이 참여하고 반응하기 전에 기여에 많은 시간을 투자하지 않는 것이 좋은 이유입니다. +여러분이 예의 있게 행동했음에도 아무도 답변을 주지 않을 수도 있습니다. 기분이 좋지는 않겠지만 너무 낙담하지 마세요. 누구나 겪는 일입니다! 답변을 받지 못하는 데에는 어쩔 수 없는 개인적인 사정 등 다양한 이유가 있을 수 있습니다. 기여할 다른 방법이나 프로젝트를 찾아보세요. 다른 커뮤니티 구성원들이 참여하고 반응하기 전에 기여에 너무 많은 시간을 투자하지 않는 게 오히려 좋습니다. -### 🚧 누군가 기여를 변경 요청해야합니다. +### 🚧 기여에 대한 수정을 요청받았어요. -아이디어의 범위에 대한 피드백이든 코드의 변경 사항이든, 기여 내용을 변경하라는 메시지가 표시되는 것이 일반적입니다. +아이디어에 대한 피드백이든 코드의 수정이든 기여 내용을 수정해 달라는 요청을 받는 경우가 많습니다. -누군가 변경 사항을 요청하면, 반응적입니다. 그들은 당신의 기여를 검토할 시간을 가졌습니다. PR을 열고 멀리두는 것은 나쁜 형태입니다. 만약 변경 방법을 모르는 경우, 문제를 조사한 다음 필요한 경우 도움을 요청하십시오. +누군가 수정을 요청하면 적극적으로 그에 응답하세요. 그들은 여러분의 기여를 리뷰하기 위해 기꺼이 시간을 들였습니다. PR을 열고 내버려 두는 것은 좋지 않습니다. 어떻게 수정해야 할지 모르겠다면 문제에 대해 조사하고 필요한 경우 도움을 요청하세요. -만약 더 이상 문제를 해결할 시간이 없다면 (예를 들어, 대화가 몇 달 동안 계속되고 상황이 변경된 경우), 메인테이너에게 알려서 응답을 기대하지 않도록 하십시오. 다른 사람이 기꺼이 받아 들일 수 있습니다. +대화가 몇 달 동안 진행되다가 상황이 변한 경우처럼, 더 이상 문제를 해결할 시간이 없다면 관리자에게 알리세요. 누군가 다른 사람이 기꺼이 작업을 맡아줄 지도 모릅니다. -### 👎 귀하의 기여가 받아지지 않았습니다. +### 👎 기여가 받아들여지지 않았어요. -귀하의 기여는 결국 받아지거나 수락되지 않을 수도 있습니다. 다행히도 이미 너무 많은 작업을 하지 않았으면 합니다. 왜 그것이 받아들여지지 않았는지 확신할 수 없다면, 메인테이너 담당자에게 피드백과 설명을 요청하는 것이 합리적입니다. 그러나 궁극적으로 이것이 자신의 결정임을 존중해야합니다. 논쟁하거나 적대적인 태도를 취하지 마십시오. 동의하지 않으면, 항상 자신의 버전을 포크하고 작업할 수 있습니다! +여러분의 기여는 받아들여질 수도 있고 그렇지 않을 수도 있습니다. 이미 너무 많은 작업을 하지 않았으면 합니다. 왜 그것이 받아들여지지 않았는지 잘 모르겠다면 관리자에게 피드백과 설명을 요청하는 것이 합리적입니다. 그러나 궁극적으로는 이것이 그들의 결정이라는 것을 존중할 필요가 있습니다. 논쟁하거나 적대적인 태도를 취하지 마세요. 동의하지 않으면 언제든 여러분의 버전을 포크하고 따로 작업할 수 있습니다! -### 🎉 귀하의 기여가 받아졌습니다. +### 🎉 기여가 받아들여졌어요. -만세! 성공적으로 오픈소스 기여를 만들었습니다! +만세! 오픈소스에 기여하는 데 성공했습니다! -## You did it! +## 해냈어요! -처음으로 오픈소스에 기여한 사람이든, 새로운 방식으로 기여할 사람을 찾고 있든, 우리는 이 행동에 영감을 얻으시기 바랍니다. 기여가 승인되지 않더라도, 관리자가 당신을 돕기 위해 노력할 때 감사하다는 말을 잊지 마십시오. 오픈소스는 당신과 같은 사람들이 만듭니다: one issue, pull request, comment, or high-five at a time. +처음으로 오픈소스에 기여한 사람이든, 기여할 새로운 방법을 찾고 있든, 이 문서가 그것을 행동에 옮길 수 있는 계기가 되었길 바랍니다. 비록 기여가 받아들여지지 않더라도, 관리자가 당신을 도우려 할 때 감사의 말을 하는 것을 잊지 마세요. 오픈소스의 이슈, PR, 댓글 하나하나는 여러분에 의해 만들어집니다. diff --git a/_articles/ko/index.html b/_articles/ko/index.html new file mode 100644 index 00000000000..a3cbad5909a --- /dev/null +++ b/_articles/ko/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: 오픈 소스 가이드 +lang: ko +permalink: /ko/ +--- diff --git a/_articles/ko/leadership-and-governance.md b/_articles/ko/leadership-and-governance.md index 86a55c6d00c..c116dff5055 100644 --- a/_articles/ko/leadership-and-governance.md +++ b/_articles/ko/leadership-and-governance.md @@ -1,16 +1,8 @@ --- lang: ko -title: 리더십과 정치 -description: 오픈소스 프로젝트가 성장하면서 공식적인 의사 결정 규칙의 혜택을 볼 수 있습니다. +title: 리더십과 관리 +description: 결정을 위한 공식적인 규칙을 정하면 오픈소스 프로젝트의 성장에 이익을 얻을 수 있습니다. class: leadership -toc: - what-are-examples-of-formal-roles-used-in-open-source-projects: "오픈소스 프로젝트에서 사용되는 공식 역할의 예시로는 무엇입니까?" - how-do-i-formalize-these-leadership-roles: "이러한 리더십 역할을 어떻게 공식화할 수 있습니까?" - when-should-i-give-someone-commit-access: "누군가에게 언제 커밋 권한을 부여해야합니까?" - what-are-some-of-the-common-governance-structures-for-open-source-projects: "오픈소스 프로젝트의 공통적인 관리 구조에는 어떤 것들이 있습니까?" - do-i-need-governance-docs-when-i-launch-my-project: "프로젝트를 시작할 때 거버넌스 문서가 필요합니까?" - what-happens-if-corporate-employees-start-submitting-contributions: "기업 직원이 기여를 제출하기 시작하면 어떻게됩니까?" - do-i-need-a-legal-entity-to-support-my-project: "내 프로젝트를 지원하기 위해 법인이 필요합니까?" order: 6 image: /assets/images/cards/leadership.png related: @@ -18,148 +10,147 @@ related: - metrics --- -## Understanding governance for your growing project +## 성장하는 프로젝트 관리 이해하기 -프로젝트가 성장하고 있고, 사람들이 종사하고 있으며, 당신은 이 일을 계속 지키려고합니다. 이 단계에서 누군가가 프로젝트에 커밋하거나 커뮤니티 토론을 해결할 때, 정기적인 프로젝트 참여자를 워크플로우에 통합하는 방법에 대해 궁금해 할 수 있습니다. 질문이 있으시면 답변을 드리겠습니다. +프로젝트는 성장하고, 사람들은 바쁘게 활동하고, 여러분은 계속 이끌어 나가고 싶습니다. 이 단계에서 여러분은 어떻게 일의 흐름에 기여자들을 모을지 알고자 합니다. 누군가에게 커밋 권한을 주거나 커뮤니티 토론을 해결하는 식으로 말입니다. 질문이 있다면 대답해드리겠습니다. -## What are examples of formal roles used in open source projects? +## 오픈소스 프로젝트에서 공식적인 역할은 어떤 식으로 적용되나요? -많은 프로젝트가 기여자 역할과 인식을 위해 유사한 구조를 따릅니다. +대부분 프로젝트는 비슷한 기여자 역할 구조를 갖습니다. -이 역할들이 실제로 의미하는 바는 전적으로 당신에게 달렸습니다. 다음과 같은 몇 가지 유형의 역할을 인식 할 수 있습니다: +역할이 실제로 의미하는 것이 무엇인지는 전적으로 여러분에게 달렸습니다. 여러분이 이미 아실 만한 역할은 다음과 같습니다. -* **메인테이너** -* **기여자** -* **커미터** +* **관리자(Maintainer)** +* **기여자(Contributor)** +* **커미터(Committer)** -**약간의 예시로, "메인테이너"**는 커밋 권한이있는 프로젝트의 유일한 사람입니다. 다른 프로젝트에서는 단순히 README에 메인테이너로 올라온 사람들입니다. +**몇몇 프로젝트에서 "관리자"**는 커밋 권한을 가진 사람들만을 의미하지만, 어떤 프로젝트에서는 단순히 README 파일에 관리자로서 나열되어 있는 사람들을 가리킵니다. -메인테이너는 반드시 프로젝트에 코드를 작성하는 사람일 필요는 없습니다. 그것은 프로젝트를 전파하는 많은 일을 한 사람일 수도 있고, 프로젝트를 다른 사람들이 더 쉽게 이용할 수 있도록 작성한 문서일 수도 있습니다. 메인테이너가 매일 수행하는 업무와 관계없이 메인테이너는 프로젝트 방향에 대한 책임감을 느끼고, 이를 개선하기 위해 최선을 다하는 사람입니다. +관리자가 반드시 코드를 작성하는 사람일 필요는 없습니다. 프로젝트를 홍보하는 데 큰 몫을 한 사람일 수도 있고, 프로젝트 접근성을 높이기 위해 문서화를 맡은 사람일 수도 있습니다. 그들이 무슨 일을 하든, 관리자는 보통 프로젝트의 방향에 책임감을 가지고 이를 개선하고자 노력하는 사람일 것입니다. -**모든 사람이 될 수 있는 "기여자"**는 이슈 혹은 pull request에 대한 의견을 말하거나, 프로젝트에 가치를 부여하는 사람 (이슈를 다루거나, 코드 작성 혹은 이벤트 구성), 또는 병합된 pull request을 소유한 사람(아마도 기여자의 가장 좁은 정의)이 될 수 있습니다. +**"기여자"**는 이슈나 풀 리퀘스트에 댓글을 작성하는 모든 사람이라고 볼 수 있습니다. 이슈에 우선 순위를 매기는 사람, 코드를 작성하는 사람, 행사를 조율하는 사람에서부터 (가장 좁은 의미로는) 병합된 풀 리퀘스트를 가진 사람까지 모두가 기여자인 셈입니다. -**"커미터"**라는 용어는 특정 유형의 책임인 커밋 액세스를 다른 형태의 기여와 구별하는 데 사용될 수 있습니다. +**"커미터"**라는 용어는 다른 기여 유형에 대비해 커밋이라는 특정 권한과 책임을 가진 사람을 구분하고자 사용합니다. -원하는 방식으로 프로젝트 역할을 정의할 수 있지만, [보다 폭 넓은 정의를 사용하여](../how-to-contribute/#what-it-means-to-contribute) 더 많은 기여 양식을 권장하십시오. 리더십 역할을 사용하여 기술 능력에 관계없이 프로젝트에 뛰어난 기여를 한 사람을 공식적으로 인정할 수 있습니다. +프로젝트 역할은 여러분이 원하는 대로 정의할 수 있지만, 다양한 유형의 기여를 이끌어내기 위해 되도록 [넓은 정의를 사용하세요](../how-to-contribute/#기여한다는-것의-의미). 전문적인 기술 수준과 별개로 프로젝트에 대단한 기여를 한 사람들에게 리더십 역할을 부여하며 그들에게 답례를 표할 수 있습니다. -## How do I formalize these leadership roles? +## 어떻게 리더십 역할을 구성해야 할까요? -리더십 역할을 공식화하면 사람들이 소유권을 느끼게되고 도움이 필요한 다른 커뮤니티 회원에게도 도움이 됩니다. +리더십 역할을 잘 갖추고 형식화하면 사람들이 소유감을 느끼고, 다른 커뮤니티 구성원들에게 도움을 줄 수 있습니다. -소규모 프로젝트의 경우, 리더 지정은 README 또는 CONTRIBUTORS 텍스트 파일에 이름을 추가하는 것처럼 간단할 수 있습니다. +작은 프로젝트에서는 README 파일이나 CONTRIBUTORS 파일에 이름을 추가하는 것 정도로 간단하게 리더를 지정할 수 있습니다. -대규모 프로젝트의 경우,만약 웹사이트를 가지고있다면, 팀 페이지를 만들거나 거기에 프로젝트 리더를 나열하십시오. 예시로, [Postgres](https://github.com/postgres/postgres/)는 각각 기여자를 위한 짧은 프로필을 [포괄적인 팀 페이지](https://www.postgresql.org/community/contributors/)에 넣었습니다. +큰 프로젝트에서는, 웹사이트가 있다면 팀 페이지를 만들거나 프로젝트 리더들을 사이트에 나열하세요. [Postgres](https://github.com/postgres/postgres/)는 각 기여자의 짧은 프로필을 담은 [팀 페이지](https://www.postgresql.org/community/contributors/)를 가지고 있습니다. -만약 프로젝트에 매우 활발하게 기여한 커뮤니티가 있는 경우, 메인테이너 또는 다른 이슈 영역(예시. 보안, 이슈 security, 시위, 커뮤니티 행동)의 소유권을 가진 사람들의 소위원회로 "핵심 팀"을 구성 할 수 있습니다. 사람들이 자신을 할당하는 것이 아니라, 가장 흥분되는 역할에 대해 스스로 조직하고 자원 봉사하게 하십시오. +매우 활성화된 기여자 커뮤니티를 가진 프로젝트라면 관리자들이나 각 분야(보안, 이슈 분류, 커뮤니티 관리 등)의 기여자들로 "핵심 팀"을 구성하는 방법이 있습니다. 사람들에게 역할을 부여하기보다 사람들이 스스로 역할을 구성하고 자원할 수 있게 하세요. -리더십 팀은 IRC와 같이 지정된 채널을 만들거나 프로젝트를 토론하기 위해 정기적으로 (Gitter 또는 Google 행 아웃과 같은)모임을 갖기를 원할 수 있습니다. 다른 사람들이 들을 수 있도록 그 모임을 공개할 수도 있습니다. -예시로, [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)는, [매주 근무 시간에 가졌습니다](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs). +리더 팀은 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에 기록합시다. +리더십 역할을 구성한 후에는 사람들이 어떻게 그 역할을 부여받을 수 있는지 문서화하는 것을 잊지 마세요! 관리자나 특정 분야 전문 기여자가 되는 방법을 명확하게 정하고 GOVERNANCE 파일에 기록하세요. -[Vossibility](https://github.com/icecrime/vossibility-stack)와 같은 도구는 프로젝트에 기여한 사람(또는 참여하지 않은 사람)을 공개적으로 추적하는 데 도움이 될 수 있습니다. 이 정보를 문서화하면, 메인테이너가 사적인 결정을 내리는 그들만의 커뮤니티라는 인식을 피할 수 있습니다. +누가 프로젝트에 기여하고 누가 그렇지 않은지 공개적으로 파악하는 데 [Vossibility](https://github.com/icecrime/vossibility-stack) 같은 툴이 도움을 줍니다. 이런 정보를 문서화하면 관리자들이 불공평한 결정을 내린다는 인식을 피할 수 있습니다. -마지막으로, 프로젝트가 GitHub에 있을 경우, 프로젝트를 개인 계정에서 조직으로 옮기고 적어도 하나의 백업 관리자를 추가하는 것을 고려하십시오. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/)에서는 권한 및 여러 저장소를 쉽게 관리하고 [공유 소유권](../building-community/#share-ownership-of-your-project)을 통해 프로젝트의 유산을 보호합니다. +마지막으로, 여러분의 프로젝트가 GitHub에서 진행되고 있다면 프로젝트를 여러분의 개인 계정에서 조직 계정으로 이동하는 것을 고려해 보세요. [조직 계정](https://help.github.com/articles/creating-a-new-organization-account/) 기능이 여러 저장소의 권한 관리, [공동 소유](../building-community/#프로젝트를-공동으로-소유하세요)를 통한 프로젝트 정책 보호를 쉽게 만들어 줍니다. -## When should I give someone commit access? +## 커밋 권한은 언제 부여해야 하나요? -어떤 사람들은 당신이 기여하는 모든 사람에게 헌신적으로 접근해야한다고 생각합니다. 그렇게하면 더 많은 사람들이 프로젝트 소유권을 느낄 수 있습니다. +몇몇 사람들은 여러분이 모든 기여자에게 커밋 권한을 줘야 한다고 생각합니다. 그렇게 한다면 더 많은 사람들이 프로젝트 소유감을 느끼게 할 수 있을 것입니다. -반면에, 특히 더 크고 복잡한 프로젝트의 경우, 자신의 의지를 입증한 사람들에게만 커밋 액세스 권한을 부여할 수 있습니다. 그렇게하는 데 올바른 방법이 없습니다 - 당신을 가장 편안하게 만드는 것은 무엇입니까! +반면, 특히 크고 복잡한 프로젝트에서는 노력을 보인 사람들에게만 커밋 권한을 부여할 수도 있습니다. 정해진 방법은 없습니다. 가장 편한 방법을 선택하세요! -만약 GitHub에 프로젝트가 있다면, [protected branches](https://help.github.com/articles/about-protected-branches/)를 사용하여 특정 브랜치로 푸시 할 수있는 사람과 상황을 관리할 수 ​​있습니다. +여러분의 프로젝트가 GitHub에서 진행되고 있다면 [보호 브랜치](https://help.github.com/articles/about-protected-branches/) 기능을 사용해 누가 어떠한 상황에 특정 브랜치에 푸시할 수 있는지 지정할 수 있습니다. -## What are some of the common governance structures for open source projects? +## 오픈소스의 관리 구조로는 어떤 것이 있나요? -오픈소스 프로젝트와 관련된 세 가지 공통 관리 구조가 있습니다. +오픈소스 프로젝트에서 적용되는 세 가지 일반적인 관리 구조가 있습니다. -* **BDFL:** BDFL은 "생명을 위한 자비로운 독재자"(Benevolent Dictator for Life)의 약자입니다. 이 구조하에서 한 사람(보통 프로젝트의 초기 저자)은 모든 주요 프로젝트 결정에 대해 최종 결정권을 갖습니다. [파이썬](https://github.com/python)은 고전적인 예시입니다. 작은 프로젝트는 한명 또는 두명의 관리자가 있기 때문에 기본적으로 BDFL일 것입니다. 한 회사에서 시작된 프로젝트도 BDFL 범주에 속할 수도 있습니다. +* **BDFL:** BDFL은 "자비로운 종신독재자"(Benevolent Dictator for Life)의 약자입니다. 이 구조 아래에서는 (주로 프로젝트 창시자) 한 사람이 주요 사안의 최종 결정권을 갖습니다. [Python](https://github.com/python)이 그 대표적인 예입니다. 작은 프로젝트는 한두 명의 관리자만이 존재하므로 BDFL이라 할 수 있습니다. 기업에 의해 시작된 프로젝트도 보통 BDFL의 범주에 들어갑니다. -* **실력주의:** **(Note: "능력주의"라는 용어는 일부 지역 사회에 부정적인 의미를 지니며 [복잡한 사회 정치적 역사](http://geekfeminism.wikia.com/wiki/Meritocracy)를 가지고있습니다.)** 능력있는 사회에서 활동적인 프로젝트 기여가 ("공로"를 입증하는 사람들)에게 공식적인 의사 결정 역할이 부여됩니다. 결정은 일반적으로 순수한 투표 컨센서스를 기반으로합니다. 실력주의 개념은 [Apache Foundation](http://www.apache.org/)에 의해 개척되었습니다; [모든 아파치 프로젝트](http://www.apache.org/index.html#projects-list)는 장점이 있습니다. 기여는 회사가 아니라 집단을 대표하는 개인이 할 수 있습니다. +* **능력주의(Meritocracy):** **(참고: "능력주의"라는 용어는 일부 커뮤니티에서는 부정적 의미를 내포하며, [복잡한 사회·정치적 역사](http://geekfeminism.wikia.com/wiki/Meritocracy)를 가지고 있습니다.)** 능력주의 구조 아래에서는 ("능력"을 보이는) 활동적인 프로젝트 기여자들이 공식 결정권을 갖습니다. 사안 결정은 주로 투표를 통한 합의로 이루어집니다. 능력주의라는 개념은 [Apache Foundation](https://www.apache.org/)에 의해 만들어졌습니다. [모든 Apache 프로젝트](https://www.apache.org/index.html#projects-list)가 능력주의 구조입니다. 기여는 반드시 기업이 아닌 각각의 개인에 의해 이루어집니다. -* **자유주의 기여:** 자유주의 기여 모델하에서, 가장 많은 일을 하는 사람들이 가장 영향력있는 사람으로 인식되지만, 이것은 역사적인 기여가 아니라 현재의 일을 기반으로합니다. 주요 프로젝트 결정은 순수한 표결보다는 합의를 모색하는 과정(주요 불만 사항을 논의)을 토대로 이루어지며, 가능한 많은 공동체 관점을 포함하기 위해 노력합니다. 프로젝트의 인기있는 예제는 [Node.js](https://nodejs.org/en/foundation/)와 [Rust](https://www.rust-lang.org/en-US/)에 포함된 자유주의 기여 모델을 사용합니다. +* **자유주의 기여(Liberal contribution):** 자유주의 기여 구조에서는 가장 많은 일을 하는 사람이 가장 영향력 있는 사람으로 받아들여집니다. 하지만 이는 과거의 기여가 아닌 현재 작업 내용에 따라 판단합니다. 주요 사안은 투표보다는 (불만 사항에 대해 토론하는) 합의 도출 과정을 기반으로 하며, 가능한 많은 관점을 포함하려 합니다. 자유주의 기여 구조의 유명한 프로젝트로는 [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-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79) +* [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) -## Do I need governance docs when I launch my project? +## 프로젝트를 출시하려면 관리 문서가 있어야 하나요? -프로젝트 관리 방식을 작성할 적절한 시기는 없지만, 커뮤니티 역학 관계가 성립했다면 정의하는 것이 훨씬 쉽습니다. 오픈소스 관리에 대한 가장 좋은(그리고 가장 어려운) 부분은 그것이 커뮤니티에 의해 형성된다는 것입니다! +프로젝트 관리 문서를 작성하는 데에 정해진 시기는 없습니다. 하지만 커뮤니티의 역학이 작용하는 모습을 직접 보고 나서 작성하면 더 쉽습니다. 오픈소스 관리의 가장 좋은 (그리고 어려운) 점은 그것이 커뮤니티에 의해 형성된다는 점입니다! -일부 초기 문서는 필연적으로 프로젝트 관리에 기여할 것이므로, 가능하다면 글을 써내려가는 것을 시작하십시오. 예를 들어, 프로젝트 시작시에도 동작에 대한 명확한 기대치 또는 기여 프로세스가 어떻게 작동하는지 정의할 수 있습니다. +하지만 이른 문서화는 프로젝트 관리에 필연적으로 도움이 됩니다. 그러니 적을 수 있는 것부터 적으며 시작하세요. 프로젝트 출시 단계에서도 어떤 기여를 기대하는지 명시하거나 기여 과정이 어떻게 되는지 등을 정의할 수 있습니다. -오픈소스 프로젝트를 시작한 회사의 일원이라면, 회사가 앞으로 나아갈 프로젝트에 대한 결정을 유지하고 결정할 방법에 대해 공개하기 전에 내부 토론을 가질 필요가 있습니다. 귀사가 프로젝트에 참여하는 방법에 대해 공개적으로 설명하고 싶을 수도 있습니다. +여러분이 오픈소스 프로젝트를 출시하는 기업의 일원이라면, 출시 전에 앞으로 어떻게 프로젝트를 유지하고 사안을 결정할지에 대한 내부 토론 시간을 가지세요. 또한 기업이 프로젝트에 어떤 식으로 관여할지 (또는 관여하지 않을지!) 공개적으로 설명하는 것이 좋습니다. -## What happens if corporate employees start submitting contributions? +## 기업 직원들이 기여하기 시작하면 어떤 일이 일어나나요? -성공적인 오픈소스 프로젝트는 많은 사람들과 회사에서 사용되며, 결국 일부 회사는 궁극적으로 프로젝트에 묶인 수익원을 갖게 될 것입니다. 예를 들어, 회사는 상용 서비스에서 프로젝트 코드를 하나의 구성 요소로 사용할 수 있습니다. +성공적인 오픈소스 프로젝트는 많은 사람과 기업에서 사용됩니다. 그러다 보면 어떤 기업의 수익 흐름이 프로젝트와 엮이기도 합니다. 예컨대, 기업이 상업적 서비스 제공을 위한 한 요소로서 프로젝트 코드를 사용하는 경우가 있습니다. -프로젝트가 널리 사용됨에 따라 전문 지식을 보유한 사람들은 더 많은 수요가 생깁니다. - 때로는 프로젝트에서 수행하는 일에 대해 보수를 받습니다. +프로젝트가 널리 쓰이면 해당 프로젝트에 전문적인 사람들(여러분일 수도 있습니다!)의 수요도 증가합니다. 때로는 프로젝트에서 맡는 작업에 대한 보수를 받기도 합니다. -상업 활동을 평범하고 또 다른 개발 에너지 원으로 간주하는 것이 중요합니다. 유료 개발자는 물론 지불하지 않은 애플리케이션에 대해서는 특별한 대우를 받아서는 안됩니다. 각 기부금은 기술적 장점으로 평가되어야합니다. 그러나 사람들은 상업 활동에 익숙해져야하며, 특정 향상이나 기능을 선호할 때 자신의 use cases에 대해 쉽게 알 수 있어야합니다. +영리 활동을 다른 개발 원동력과 같이 평범하게 여기는 것이 중요합니다. 보수를 받는 개발자들은 그렇지 않은 개발자들에 비해 특별한 대우를 받아서는 안 됩니다. 물론 그들이 만드는 기여는 기술적인 가치에 따라 평가받아야 하겠지만 말입니다. 사람들은 영리 활동에 대해 이야기하거나, 특정 기능 개선이 필요하다고 주장하며 용례를 다루는 데 불편이 없어야 합니다. -"상용"은 "오픈소스"와 완전히 호환됩니다. "상업적"이란 말은 어딘가에 돈이 들어 있다는 의미입니다. 소프트웨어가 상용으로 사용되고 있다는 것이고, 프로젝트가 채택되면서 점점 더 많이 이용 될 가능성이 높습니다. 오픈소스 소프트웨어가 비 오픈소스 제품의 일부로 사용될 때, 전체 제품은 여전히 ​​"독점"소프트웨어이지만, 오픈소스와 마찬가지로 상업적 또는 비상업적 용도로 사용될 수 있습니다. +"영리" 또는 "상용"이라는 단어는 "오픈소스"와 완벽히 어울리는 단어입니다. "영리"는 그저 어딘가에 돈이 연관되어 있다는 뜻입니다. 소프트웨어가 시장에서 사용되면 자연스럽게 프로젝트 채용률도 오릅니다. (오픈소스 소프트웨어가 비공개 소프트웨어의 일부분에 사용된다면 전체 소프트웨어는 여전히 "독점" 소프트웨어입니다. 이는 오픈소스처럼 영리적 용도로든 비영리적 용도로든 사용될 수 있습니다.) -다른 사람들과 마찬가지로, 상업적 동기를 부여받은 개발자는 기여도의 질과 양을 통해 프로젝트에 영향력을 행사합니다. 분명히 일정한 시간동안 돈을 지불한 개발자는 돈을 지불하지 않은 사람보다 더 많은 것을 할 수 있지만, 괜찮습니다. 지불은 누군가가 얼마나 많은 영향을 줄 수 있는지에 대한 많은 요인 중 하나일뿐입니다. 사람들이 그 기여를 할 수 있게 해주는 외적 요인이 아닌, 기여에 초점을 맞춘 프로젝트 토론을 유지하십시오. +다른 누구나와 마찬가지로, 이윤을 얻는 개발자들은 기여의 양과 질을 통해 프로젝트에서 영향력을 얻습니다. 투자한 시간에 대한 보상을 받는 개발자가 그렇지 않은 이들보다 많은 일을 할 수 있는 것은 분명한 사실이지만, 괜찮습니다. 보수는 누군가의 역량에 영향을 미치는 여러 요인 중 하나일 뿐입니다. 사람들이 기여하게 만들기 위한 외적 요인이 아닌 기여 자체에 토론을 집중하세요. -## Do I need a legal entity to support my project? +## 제 프로젝트를 지원하려면 법인이 필요한가요? -돈을 처리할 필요가 없다면, 오픈소스 프로젝트를 지원하는 법인이 필요하지 않습니다. +금전을 다루는 게 아니라면 오픈소스 프로젝트를 지원하는 데 법인은 필요하지 않습니다. -예시로, 상업용 비즈니스를 만들고 싶다면 C Corp 또는 LLC(미국에 거주하는 경우)를 설정해야합니다. 오픈소스 프로젝트와 관련된 계약 업무를 수행하는 중이라면, 독점 주인으로 돈을 받거나 LLC (미국에있는 경우)를 설립할 수 있습니다. +예컨대 영리 사업을 하고 싶다면 (미국 기준) C Corp이나 LLC를 설립해야 할 것입니다. 오픈소스 프로젝트에 관한 계약만 받고 있는 것이라면 독점 대표로서 돈을 수령하거나, 역시 (미국 기준) LLC를 설립할 수 있습니다. -만약 오픈소스 프로젝트에 대한 기부를 받고 싶다면, (예를 들어 PayPal 또는 Stripe을 사용하여)기부 버튼을 설정할 수 있지만, 하지만 자격이 되는 비영리 단체(미국에 거주하는 경우 501c3)가 아닌 이상 돈은 세금 공제되지 않습니다. +오픈소스 프로젝트에 대한 기부를 받고 싶다면 PayPal이나 Stripe 등을 이용해 기부 버튼을 마련해둘 수 있습니다. 하지만 여러분이 비영리(미국 기준 501c3)를 증명하지 못한다면 세금 공제는 받지 못합니다. -많은 프로젝트가 비영리 단체를 설립하는 문제를 겪고 싶어하지 않으므로, 대신 비영리 재정 스폰서를 찾습니다. 재정 보증인은 귀하를 대신하여 기부금을 수령합니다. [Software Freedom Conservancy](https://sfconservancy.org/), [아파치 재단](http://www.apache.org/), [이클립스 재단](https://eclipse.org/org/foundation/), [리눅스 재단](https://www.linuxfoundation.org/projects) 그리고 [Open Collective](https://opencollective.com/opensource)는 오픈소스 프로젝트를 위한 회계 스폰서 역할을하는 조직의 예시입니다. +대부분 프로젝트는 비영리 단체를 설립하는 번거로운 절차를 따르고 싶어하지 않습니다. 대신 비영리 회계 스폰서를 찾는 방법을 택합니다. 회계 스폰서는 보통 기부금의 일정 비율을 대가로 여러분을 대신하여 기부금을 수령합니다. 오픈소스 프로젝트를 위한 회계 스폰서 역할을 하는 조직은 [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects), [Open Collective](https://opencollective.com/opensource) 등이 있습니다. -프로젝트가 특정 언어 또는 생태계와 밀접하게 관련되어 있다면, 함께 작업할 수 있는 관련 소프트웨어 기반이 있을겁니다. 예시로, [파이썬 소프트웨어 재단](https://www.python.org/psf/)은 파이썬 패키지 관리자인 [PyPI](https://pypi.org/)를 돕고, [Node.js 재단](https://nodejs.org/en/foundation/)은 노드 기반 프레임워크인 [Express.js](http://expressjs.com/)를 돕습니다. +여러분의 프로젝트가 특정 언어 또는 생태계와 밀접하게 관련되어 있다면 협업할 수 있는 관련 소프트웨어 재단 또한 있을 것입니다. 예를 들어 [Python Software Foundation](https://www.python.org/psf/)은 Python 패키지 관리자인 [PyPI](https://pypi.org/) 프로젝트를 지원하고, [Node.js Foundation](https://foundation.nodejs.org/)은 Node 기반 프레임워크인 [Express.js](https://expressjs.com/) 프로젝트를 지원합니다. diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md index 97b9f443878..d71c2a84193 100644 --- a/_articles/ko/legal.md +++ b/_articles/ko/legal.md @@ -3,14 +3,6 @@ lang: ko title: 오픈소스의 법적 측면 description: 오픈소스의 법적 측면과 당신이 하지 않은 몇가지 사항에 대해 궁금해하는 모든 것입니다. class: legal -toc: - why-do-people-care-so-much-about-the-legal-side-of-open-source: "왜 사람들은 오픈소스의 법적 측면에 많은 관심을 보이고 있습니까?" - are-public-github-projects-open-source: "공개 GitHub 프로젝트는 오픈소스입니까?" - just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "내 프로젝트를 보호하기 위해 필요한 DR;TL 제공해주기" - which-open-source-license-is-appropriate-for-my-project: "내 프로젝트에 적합한 오픈소스 라이선스는 무엇입니까?" - what-if-i-want-to-change-the-license-of-my-project: "프로젝트 라이선스를 변경하려면 어떻게해야합니까?" - does-my-project-need-an-additional-contributor-agreement: "내 프로젝트에 추가 기여자 계약이 필요합니까?" - what-does-my-companys-legal-team-need-to-know: "우리 회사의 법률 팀은 무엇을 알아야합니까?" order: 10 image: /assets/images/cards/legal.png related: @@ -18,37 +10,37 @@ related: - leadership --- -## Understanding the legal implications of open source +## 오픈소스의 법적 함의를 이해하기 -세계와 창의적인 작업을 공유하는 것은 흥미롭고 보람있는 경험이 될 수 있습니다. 그것은 또한 당신이 모른다고 걱정해야한다는 것을 합법적이라는 걸로 의미 할 수 있습니다. 고맙게도 처음부터 다시 시작할 필요는 없습니다. 귀하의 법적 요구 사항이 있습니다. (이 내용을 파기전에, [면책조항](/notices/)을 읽으십시오.) +세계와 창의적인 작업을 공유하는 것은 흥미롭고 보람있는 경험이 될 수 있습니다. 그것은 또한 당신이 걱정해야 했지만 잘 몰랐던 여러 법적 문제를 의미할 수도 있습니다. 고맙게도 처음부터 다시 시작할 필요는 없습니다. 귀하의 법적 요구 사항이 있습니다. (이 내용을 파기전에, [면책조항](/notices/)을 읽으십시오.) -## Why do people care so much about the legal side of open source? +## 왜 사람들은 오픈소스의 법적 측면에 신경을 많이 쓸까요? -물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권하에 있습니다. 즉, 법은 귀하의 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고있는 것으로 간주합니다. +물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권 하에 있습니다. 즉, 법은 귀하를 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고 있는 것으로 간주합니다. -일반적으로, 이는 타인이 인계, 훼손 또는 소송의 위험이 없이 작업을 사용, 복사, 배포 또는 수정할 수 있음을 의미합니다. +일반적으로, 이는 타인이 인계, 훼손 또는 소송의 위험이 없이 작업을 사용, 복사, 배포 또는 수정할 수 없음을 의미합니다. 그러나 오픈소스는 다른 사람들이 작업을 사용, 수정 및 공유하기를 기대하기 때문에 드문 경우입니다. 그러나 법적 기본값은 독점적인 저작권이므로 명시적으로 이러한 사용 권한을 명시한 사용권이 필요합니다. -오픈소스 라이선스를 신청하지 않으면, 프로젝트에 기여한 모든 사람도 자신의 저작물의 독점적인 저작권자가 됩니다. 즉, 아무도 자신의 기여를 사용, 복사, 배포 또는 수정할 수 없으며 "아무도"에서는 귀하를 포함하지 않는다는 의미입니다. +오픈소스 라이선스를 적용하지 않으면, 프로젝트에 기여한 모든 사람도 자신의 저작물의 독점적인 저작권자가 됩니다. 즉, 아무도 자신의 기여를 사용, 복사, 배포 또는 수정할 수 없으며 "아무도"에서는 귀하를 포함하지 않는다는 의미입니다. 마지막으로, 프로젝트는 사용자가 알지 못하는 라이선스 요구 사항과의 종속성을 가질 수 있습니다. 프로젝트의 커뮤니티 또는 고용주의 정책에 따라 프로젝트에서 특정 오픈소스 라이선스를 사용해야 할 수도 있습니다. 아래에서 이러한 상황을 다룰 것입니다. -## Are public GitHub projects open source? +## 깃허브의 공개 프로젝트는 오픈소스인가요? 깃허브에서 [새로운 프로젝트를 만들려고](https://help.github.com/articles/creating-a-new-repository/) 할 때, **비공개** 또는 **공개** 저장소로 만드는 옵션을 선택할 수 있습니다. ![Create repository](/assets/images/legal/repo-create-name.png) -**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership)에 명시되어 있으며, 다른 사람들이 프로젝트를 포크화할 수는 있지만, 그렇지 않은 경우에는 권한이 없습니다. +**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다. -다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게하려면, 오픈소스 라이선스를 포함해야합니다. 예를 들어, 권한을 부여하지 않는다는 조건에서는 공개적으로 GitHub 프로젝트의 일부를 코드에 명시적으로 사용할 수는 없습니다. +다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게 하려면, 오픈소스 라이선스를 포함해야 합니다. 예를 들어, GitHub 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다. -## Just give me the TL;DR on what I need to protect my project. +## 너무 기니까 그냥 내 프로젝트를 보호하는 데 필요한 점을 요약해 주세요. 운이 좋았습니다. 오늘날 오픈소스 라이선스는 표준화되어 있고 사용하기 쉽기 때문입니다. 기존 라이선스를 프로젝트에 직접 복사하여 붙여넣을 수 있습니다. -[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/)에서 이러한 라이선스의 전체 텍스트 및 사용 방법에 대한 지침을 찾을 수 있습니다. +[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/). @@ -56,74 +48,74 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할 avatar A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.

-— @benbalter, ["정부 변호인이 오픈소스 소프트웨어 라이선스에 대해 알아야할 모든 것"](http://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/) +— @benbalter, ["정부 변호인이 오픈소스 소프트웨어 라이선스에 대해 알아야할 모든 것"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)

-## Which open source license is appropriate for my project? +## 내 프로젝트에는 어떤 라이선스가 적합할까요? -빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. 짧고 이해하기 쉽기 때문에 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 아무 것도 할 수 없습니다. 필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다. +빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. MIT 라이선스는 짧고 이해하기 쉬우며, 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 모든 것을 할 수 있도록 허락합니다. 필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다. -그렇지 않으면 프로젝트에 적합한 오픈소스 라이선스를 선택하는 것이 목표에 달려 있습니다. +그렇지 않으면 프로젝트에 적합한 오픈소스 라이선스를 선택하는 것은 목적에 달려 있습니다. 프로젝트에 **의존성**이 있을 가능성이 큽니다. 예를 들어, Node.js 프로젝트를 오픈소스로 사용하는 경우 노드 패키지 관리자(npm)의 라이브러리를 사용할 수 있습니다. 의존하는 각 라이브러리에는 자체 오픈소스 라이선스가 있습니다. 각 라이선스가 "허용"(다운스트림 라이선스의 조건없이 공용 사용, 수정 및 공유할 수 있는 권한 부여)되어 있으면, 원하는 라이선스를 사용할 수 있습니다. 일반적인 허용 라이선스에는 MIT, Apache 2.0, ISC 및 BSD가 포함됩니다. -반대로, 종속성 라이선스가 "강력한 카피레프트"(동일한 라이선스를 다운스트림으로 사용하는 조건하에 공개 권한을 부여하는 경우)인 경우, 프로젝트는 동일한 라이선스를 사용해야 합니다. 일반적인 강력한 카피레프트 라이선스에는 GPLv2, GPLv3 및 AGPLv3이 포함됩니다. +반대로, 의존하는 라이선스가 "강력한 카피레프트"(동일한 라이선스를 다운스트림으로 사용하는 조건 하에 동일한 권한을 부여하는 경우)인 경우, 프로젝트는 동일한 라이선스를 사용해야 합니다. 일반적인 강력한 카피레프트 라이선스에는 GPLv2, GPLv3 및 AGPLv3이 포함됩니다. 프로젝트를 사용하고 기여할 수 있는 **커뮤니티**를 고려해보십시오: -* **프로젝트를 다른 프로젝트의 종속성으로 사용 하시겠습니까?** 관련 커뮤니티에서 가장 많이 사용되는 라이선스를 사용하는 것이 가장 좋습니다. 예시로, [MIT](https://choosealicense.com/licenses/mit/)는 [npm libraries](https://libraries.io/npm)에서 가장 인기있는 라이선스입니다. +* **프로젝트를 다른 프로젝트의 종속성으로 사용 하시겠습니까?** 관련 커뮤니티에서 가장 많이 사용되는 라이선스를 사용하는 것이 가장 좋습니다. 예시로, [MIT](https://choosealicense.com/licenses/mit/)는 [npm libraries](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/)은 잘될 것 입니다. +* **독점 소스 소프트웨어에 기여를 하고 싶지 않은 기여자에게 프로젝트를 어필하고 싶습니까?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) 혹은 (또한 독점 소스 서비스에 기여하지 않으려는 경우) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)은 잘될 것입니다. -귀하의 **회사**는 오픈소스 프로젝트에 대한 특정 라이선스 요구 사항을 가지고 있을 수 있습니다. 예를 들어, 회사에서 회사의 독점 소스 제품에서 프로젝트를 사용할 수 있도록 허용 라이선스가 필요할 수 있습니다. 또는 귀사만 독점 소스 소프트웨어에서 프로젝트를 사용할 수 있도록 강력한 카피 레프트 라이선스와 추가 기여자 계약(아래 참조)이 필요할 수 있습니다. 또는 표준, 사회적 책임 또는 투명성과 관련된 특정 요구 사항이 있을 수 있습니다. 이러한 요구 사항에는 특정 라이선스 전략이 필요할 수 있습니다. 귀하의 [회사 법률 부서](#what-does-my-companys-legal-team-need-to-know)에 이야기하십시오. +귀하의 **회사**는 오픈소스 프로젝트에 대한 특정 라이선스 요구 사항을 가지고 있을 수 있습니다. 예를 들어, 회사에서 회사의 독점 소스 제품에서 프로젝트를 사용할 수 있도록 허용 라이선스가 필요할 수 있습니다. 또는 귀사만 독점 소스 소프트웨어에서 프로젝트를 사용할 수 있도록 강력한 카피 레프트 라이선스와 추가 기여자 계약(아래 참조)이 필요할 수 있습니다. 또는 표준, 사회적 책임 또는 투명성과 관련된 특정 요구 사항이 있을 수 있습니다. 이러한 요구 사항에는 특정 라이선스 전략이 필요할 수 있습니다. 귀하의 [회사 법률 부서](#회사의-법무팀은-무엇을-알아야-할까요)에 이야기하십시오. GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 옵션이 제공됩니다. 위에서 언급한 라이선스 중 하나를 포함하면 GitHub 프로젝트가 오픈소스로 됩니다. 다른 옵션을 보려면 [choosealicense.com](https://choosealicense.com)에서 [소프트웨어가 아닌 프로젝트](https://choosealicense.com/non-software/)에 적합한 라이선스를 찾으십시오. -## What if I want to change the license of my project? +## 내 프로젝트의 라이선스를 바꾸고 싶다면 어쩌죠? 대부분의 프로젝트는 라이선스를 변경할 필요가 없습니다. 그러나 때때로 상황이 바뀝니다. -예를 들어, 프로젝트가 커짐에 따라 종속성이나 사용자가 추가되거나 회사에서 전략을 변경합니다. 전략 중 하나는 다른 라이선스를 요구하거나 원할 수 있습니다. 또한 처음부터 프로젝트 라이선스를 소홀히했다면, 라이선스를 추가하는 것은 사실상 라이선스를 변경하는 것과 같습니다. 프로젝트 라이선스를 추가하거나 변경할 때 고려해야 할 세 가지 기본 사항이 있습니다. +예를 들어, 프로젝트가 커짐에 따라 종속성이나 사용자가 추가되거나 회사에서 전략을 변경합니다. 전략 중 하나는 다른 라이선스를 요구하거나 원할 수 있습니다. 또한 처음부터 프로젝트 라이선스를 소홀히 했다면, 라이선스를 추가하는 것은 사실상 라이선스를 변경하는 것과 같습니다. 프로젝트 라이선스를 추가하거나 변경할 때 고려해야 할 세 가지 기본 사항이 있습니다. -**복잡합니다.** 라이선스 호환성 및 규정 준수 여부를 결정하고 저작권을 보유한 사람은 매우 복잡하고 혼란스러울 수 있습니다. 새로운 릴리즈 및 기여용으로 새롭지만 호환되는 라이선스로 전환하는 것은 기존 기여를 모두 재 라이선스하는 것과 다릅니다. 법률팀에 라이선스 변경 희망의 첫 번째 힌트를 포함시키십시오. 프로젝트의 저작권 소유자로부터 라이선스 변경에 대한 허가를 받았거나 취득할 수있는 경우에도 변경 사항이 프로젝트의 다른 사용자 및 제공자에게 미치는 영향을 고려하십시오. 라이선스 변경은 프로젝트의 이해 관계자와 명확한 커뮤니케이션 및 협의를 통해 원활하게 진행될 수 있는 프로젝트의 "거버넌스 이벤트"라고 생각하십시오. 프로젝트를 시작할 때부터 적절한 라이선스를 선택하여 사용하는 더 많은 이유가 있습니다! +**복잡합니다.** 라이선스 호환성 및 규정 준수 여부를 결정하고 저작권을 보유한 사람은 매우 복잡하고 혼란스러울 수 있습니다. 새로운 릴리즈 및 기여용으로 새롭지만 호환되는 라이선스로 전환하는 것은 기존 기여를 모두 재 라이선스하는 것과 다릅니다. 법률팀에 라이선스 변경 희망의 첫 번째 힌트를 포함시키십시오. 프로젝트의 저작권 소유자로부터 라이선스 변경에 대한 허가를 받았거나 취득할 수있는 경우에도 변경 사항이 프로젝트의 다른 사용자 및 제공자에게 미치는 영향을 고려하십시오. 라이선스 변경은 프로젝트의 이해 관계자와 명확한 커뮤니케이션 및 협의를 통해 원활하게 진행될 수 있는 프로젝트의 "거버넌스 이벤트"라고 생각하십시오. 프로젝트를 시작할 때부터 적절한 라이선스를 선택하여 사용하는데는 더 많은 이유가 있습니다! -**프로젝트의 기존 라이선스가 있습니다.** 프로젝트의 기존 라이선스가 변경하려는 라이선스와 호환되는 경우, 새 라이선스를 사용하기만 하면됩니다. 라이선스 A가 라이선스 B와 호환되면 B의 조건을 준수하면서 A의 조건을 준수하게됩니다(반대의 경우도 가능). 따라서 현재 MIT와 같은 허가된 라이선스를 사용하고 있다면 MIT 라이선스 사본 및 관련 저작권 고지를 보유하는 한 더 많은 조건으로 라이선스로 변경할 수 있습니다(즉, 계속해서 MIT 라이선스의 최소 조건 준수). 그러나 현재 라이선스가 허용되지 않는 경우(예:카피 레프트 또는 라이선스가 없는 경우), 저작권자가 유일하지 않은 경우, 프로젝트 라이선스를 MIT로 변경할 수 없습니다. 근본적으로 허가된 라이선스로 프로젝트의 저작권 소유자는 라이선스 변경을 사전 허가합니다. +**프로젝트의 기존 라이선스가 있습니다.** 프로젝트의 기존 라이선스가 변경하려는 라이선스와 호환되는 경우, 새 라이선스를 사용하기만 하면 됩니다. 라이선스 A가 라이선스 B와 호환되면 B의 조건을 준수하면서 A의 조건을 준수하게 됩니다(반대의 경우도 가능). 따라서 현재 MIT와 같은 허가된 라이선스를 사용하고 있다면 MIT 라이선스 사본 및 관련 저작권 고지를 보유하는 한 더 많은 조건으로 라이선스로 변경할 수 있습니다(즉, 계속해서 MIT 라이선스의 최소 조건 준수). 그러나 현재 라이선스가 허용되지 않는 경우(예:카피 레프트 또는 라이선스가 없는 경우), 저작권자가 유일하지 않은 경우, 프로젝트 라이선스를 MIT로 변경할 수 없습니다. 근본적으로 허가된 라이선스로 프로젝트의 저작권 소유자는 라이선스 변경을 사전 허가합니다. -**프로젝트의 기존 저작권 보유자가 있습니다.** 귀하가 프로젝트에 단독으로 기여한 경우, 귀하 또는 귀하의 회사는 프로젝트의 유일한 저작권자입니다. 귀하 또는 귀하의 회사에서 원하는 모든 라이선스를 추가하거나 변경할 수 있습니다. 그렇지 않으면 라이선스를 변경하기 위해 동의해야하는 다른 저작권 소유자가 있을 수 있습니다. 그들은 누구입니까? 프로젝트에 커밋을 한 사람은 시작하기 좋은 곳입니다. 그러나 어떤 경우, 저작권은 해당 사용자의 고용주가 보유하게됩니다. 어떤 경우에는 사람들이 최소한의 기여를 했을 뿐이지만, 몇 줄의 코드가 저작권의 대상이 되지않는다는 단호하고 신속한 규칙은 없습니다. 그럼 무엇을 해야합니까? 상대적으로 규모가 작고 젊은 프로젝트의 경우에는, 기존의 모든 기여자가 문제의 라이선스 변경에 동의하거나 이슈 혹은 pull request할 수 있습니다. 크고 수명이 긴 프로젝트의 경우, 많은 기여가와 소유인을 찾아야 할 수도 있습니다. 모질라는 파이어폭스, 썬더버드 및 관련 소프트웨어를 재 라이선스하기 위해 수년(2001-2006)을 보냈습니다. +**프로젝트의 기존 저작권 보유자가 있습니다.** 귀하가 프로젝트에 단독으로 기여한 경우, 귀하 또는 귀하의 회사는 프로젝트의 유일한 저작권자입니다. 귀하 또는 귀하의 회사에서 원하는 모든 라이선스를 추가하거나 변경할 수 있습니다. 그렇지 않으면 라이선스를 변경하기 위해 동의해야하는 다른 저작권 소유자가 있을 수 있습니다. 그들은 누구입니까? 프로젝트에 커밋을 한 사람은 시작하기 좋은 곳입니다. 그러나 어떤 경우, 저작권은 해당 사용자의 고용주가 보유하게 됩니다. 어떤 경우에는 사람들이 최소한의 기여를 했을 뿐이지만, 몇 줄의 코드가 저작권의 대상이 되지 않는다는 단호하고 신속한 규칙은 없습니다. 그럼 무엇을 해야합니까? 상대적으로 규모가 작고 젊은 프로젝트의 경우에는, 기존의 모든 기여자가 문제의 라이선스 변경에 동의하거나 이슈 혹은 pull request할 수 있습니다. 크고 수명이 긴 프로젝트의 경우, 많은 기여자와 상속인을 찾아야 할 수도 있습니다. 모질라는 파이어폭스, 썬더버드 및 관련 소프트웨어를 재 라이선스하기 위해 수년(2001-2006)을 보냈습니다. 또는 기여자가 기존 오픈소스 라이선스에서 허용하는 것 이상으로 특정 조건하에서 특정 라이선스 변경 사항에 대해 사전에 동의할 수 있습니다 (추가 기여자 계약 - 아래 참조). 이렇게하면 라이선스 변경의 복잡성이 조금씩 바뀝니다. 변호사의 도움이 더 필요합니다. 라이선스 변경을 수행할 때는, 프로젝트의 이해 관계자와 명확하게 의견을 나눌 수 있습니다. -## Does my project need an additional contributor agreement? +## 내 프로젝트에 추가 기여자 계약이 필요한가요? -아마도 그렇지 않습니다. 대다수의 오픈소스 프로젝트에서 공개 소스 라이선스는 인바운드(기여자)와 아웃바운드(다른 참여자 및 사용자) 라이선스로 암묵적으로 사용됩니다. 프로젝트가 GitHub에 있는 경우, GitHub 서비스 약관은 "인바운드 = 아웃 바운드"[명시적 기본값](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license)로 지정합니다. +아마도 그렇지 않습니다. 대다수의 오픈소스 프로젝트에서 공개 소스 라이선스는 인바운드(기여자)와 아웃바운드(다른 참여자 및 사용자) 라이선스로 암묵적으로 사용됩니다. 프로젝트가 GitHub에 있는 경우, GitHub 서비스 약관은 "인바운드 = 아웃 바운드" [명시적 기본값](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license)으로 지정합니다. -기여자 라이선스 계약(CLA)이라고도 부르는 추가 기여자 계약은 프로젝트 메인테이너를 위한 관리 작업을 생성할 수 있습니다. 계약서에 얼마나 많은 작업을 추가할지는 프로젝트와 구현에 달려 있습니다. 간단한 동의는 프로젝트 참여자가 프로젝트 오픈소스 라이선스하에 기여할 수 있는 권리를 클릭으로 확인해야 할 수도 있습니다. 보다 복잡한 합의는 법적 검토와 기여자 고용주의 서명을 요구할 수 있습니다. +기여자 라이선스 계약(CLA)이라고도 부르는 추가 기여자 계약은 프로젝트 메인테이너를 위한 관리 작업을 생성할 수 있습니다. 계약서에 얼마나 많은 작업을 추가할지는 프로젝트와 구현에 달려 있습니다. 간단한 동의는 프로젝트 참여자가 프로젝트 오픈소스 라이선스 하에 기여할 수 있는 권리를 클릭으로 확인해야 할 수도 있습니다. 보다 복잡한 합의는 법적 검토와 기여자 고용주의 서명을 요구할 수 있습니다. -또한 일부 사람들은 불필요하거나 이해하기 힘들거나 불공정하다고 생각되는 "서류 작업"을 추가함으로써 (계약 수령자가 프로젝트 참여자보다 더 많은 권리를 얻거나 일반인이 프로젝트의 오픈소스 라이선스를 통해 수행 할 때) 추가 기여자 계약이 프로젝트의 커뮤니티에 비우호적이라고 인식될 수 있습니다. +또한 일부 사람들은 불필요하거나 이해하기 힘들거나 불공정하다고 생각되는 "서류 작업"을 추가함으로써 (계약 수령자가 프로젝트 참여자보다 더 많은 권리를 얻거나 일반인이 프로젝트의 오픈소스 라이선스를 통해 수행 할 때) 추가 기여자 계약이 프로젝트의 커뮤니티에 비우호적이라고 인식될 수 있습니다. 프로젝트에 대한 추가 기여자 계약을 고려할 수 있는 몇 가지 상황은 다음과 같습니다: -* 변호사는 기여자가 오픈소스 라이선스 자체가 충분하지 않다고 생각하기 때문에 모든 기여자가 기여 조항을 명시적으로 (_sign_, 온라인 또는 오프라인) 받아들이기를 원합니다. 이것이 유일한 관심사라면, 프로젝트의 오픈소스 라이선스를 인정하는 기여자 계약만으로 충분할 것입니다. [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/)는 경량 추가 제공자 계약의 좋은 예입니다. 일부 프로젝트의 경우, [개발자 인증서 발급](https://github.com/probot/dco)을 사용할 수 있습니다. -* 귀하의 프로젝트는 익스프레스 특허 부여 (MIT 등)가 포함되지 않은 오픈소스 라이선스를 사용하며, 모든 기여자의 특허 보조금이 필요합니다. 그 중 일부는 귀하를 타겟으로 삼을 수있는 대규모 특허 포트폴리오를 보유한 회사 또는 프로젝트의 다른 참여자 및 사용자에서 사용할 수 있습니다. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)는 일반적으로 사용되는 추가 기여자 계약으로 Apache License 2.0에서 발견된 특허권 부여를 미러링합니다. -* 프로젝트에 카피레프트 라이선스가 있지만, 프로젝트의 독점 버전을 배포해야합니다. 모든 저작자가 저작권을 양도하거나 관할권을 부여할 수 있는 허가권을 사용자에게 부여해야합니다. [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement)는 이러한 유형의 계약입니다. +* 변호사는 기여자가 오픈소스 라이선스 자체가 충분하지 않다고 생각하기 때문에 모든 기여자가 기여 조항을 명시적으로 (_sign_, 온라인 또는 오프라인) 받아들이기를 원합니다. 이것이 유일한 관심사라면, 프로젝트의 오픈소스 라이선스를 인정하는 기여자 계약만으로 충분할 것입니다. [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/)는 경량 추가 제공자 계약의 좋은 예입니다. 일부 프로젝트의 경우, [개발자 인증서 발급](https://github.com/probot/dco)을 사용할 수 있습니다. +* 귀하의 프로젝트는 익스프레스 특허 부여 (MIT 등)가 포함되지 않은 오픈소스 라이선스를 사용하며, 모든 기여자의 특허 허여가 필요합니다. 그 중 일부는 귀하를 타겟으로 삼을 수 있는 대규모 특허 포트폴리오를 보유한 회사 또는 프로젝트의 다른 참여자 및 사용자가 사용할 수 있습니다. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf)는 일반적으로 사용되는 추가 기여자 계약으로 Apache License 2.0에서 발견된 특허권 부여를 미러링합니다. +* 프로젝트에 카피레프트 라이선스가 있지만, 프로젝트의 독점 버전을 배포해야 합니다. 모든 저작권자가 저작권을 양도하거나 관할권을 부여할 수 있는 허가권을 사용자에게 부여해야합니다. [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement)는 이러한 유형의 계약입니다. * 평생동안 프로젝트를 변경하고 기여자가 그러한 변경 사항에 동의하기를 원한다고 생각하십시오. 프로젝트에 기여자 계약을 추가로 사용해야하는 경우 기여자 산만을 최소화하기 위해 [CLA 어시스턴트](https://github.com/cla-assistant/cla-assistant)와 같은 통합 사용을 고려하십시오. -## What does my company's legal team need to know? +## 회사의 법무팀은 무엇을 알아야 할까요? -오픈소스 프로젝트를 회사 직원으로 공개하는 경우, 먼저 법률팀이 오픈소스 프로젝트임을 알고 있어야합니다. +오픈소스 프로젝트를 회사 직원으로 공개하는 경우, 먼저 법률팀이 오픈소스 프로젝트임을 알고 있어야 합니다. -더 좋든 나쁘든, 개인 프로젝트일지라도 알려주도록하십시오. 특히 회사의 비즈니스와 관련이 있거나 프로젝트를 개발하기 위해 회사 자원을 사용하는 경우, 프로젝트 관리를 제공하는 회사와 "직원 IP 계약"을 체결했을 수도 있습니다. 귀사는 귀사에게 쉽게 허가권을 부여해야하며, 직원 친화적인 IP 계약 또는 회사 방침을 이미 거쳐야 할 수도 있습니다. 그렇지 않은 경우, 협상을 통해 (예 : 프로젝트가 회사의 전문 학습 및 개발 목표를 제공한다고 설명), 또는 더 나은 회사를 찾을 때까지 프로젝트 작업을 하지 않을 수 있습니다. +더 좋든 나쁘든, 개인 프로젝트일지라도 알려주도록 하십시오. 특히 회사의 비즈니스와 관련이 있거나 프로젝트를 개발하기 위해 회사 자원을 사용하는 경우, 프로젝트 관리를 제공하는 회사와 "직원 IP 계약"을 체결했을 수도 있습니다. 귀사는 귀사에게 쉽게 허가권을 부여해야하며, 직원 친화적인 IP 계약 또는 회사 방침을 이미 거쳐야 할 수도 있습니다. 그렇지 않은 경우, 협상을 통해 (예 : 프로젝트가 회사의 전문 학습 및 개발 목표를 제공한다고 설명), 또는 더 나은 회사를 찾을 때까지 프로젝트 작업을 하지 않을 수 있습니다. **당신이 회사를 위해 프로젝트를 오픈소스화하고 있다면,** 분명히 알려주십시오. 법무팀은 이미 귀사의 비즈니스 요구 사항 및 전문성을 토대로 프로젝트가 종속성의 라이선스를 준수하는지 확인하기 위해 오픈 소스 라이선스 (및 추가로 제공되는 계약자 계약)에 대한 정책을 이미 가지고 있습니다. 그렇지 않다면, 당신과 그들은 운에 따라야 합니다! 귀하의 법률팀은 당신과 함께 이 일을 이해하기 위해 열심히 노력해야 합니다. 생각해야될 몇 가지 사항이 있습니다: @@ -133,7 +125,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 * **특허:** 귀하의 회사가 귀하의 프로젝트를 [공개](https://en.wikipedia.org/wiki/Public_disclosure)하여 특허를 신청할 계획입니까? 안타깝게도, 기다려달라는 요청을 받을 수 있습니다 (또는 회사에서 애플리케이션의 지혜를 재고 할 수도 있음). 대규모 특허 포트폴리오를 보유한 회사의 직원으로부터 프로젝트에 대한 기여가 기대되는 경우, 법무팀은 기여자(Apache 2.0 또는 GPLv3 등)의 명시적인 특허 지원 또는 추가 기부자 동의서를 사용하여 라이선스를 사용하기를 원할 수 있습니다(위 참조). -* **상표:** 프로젝트 이름이 [기존 상표와 충돌하지 않는지](../starting-a-project/#avoiding-name-conflicts) 다시 확인하십시오. 만약 프로젝트에서 자신의 회사 상표를 사용하는 경우에 충돌이 발생하지 않는지도 확인하십시오. [FOSSmarks](http://fossmarks.org/)는 무료 및 오픈소스 프로젝트의 맥락에서 상표를 이해하는 실질적인 가이드입니다. +* **상표:** 프로젝트 이름이 [기존 상표와 충돌하지 않는지](../starting-a-project/#이름-중복-피하기) 다시 확인하십시오. 만약 프로젝트에서 자신의 회사 상표를 사용하는 경우에 충돌이 발생하지 않는지도 확인하십시오. [FOSSmarks](http://fossmarks.org/)는 무료 및 오픈소스 프로젝트의 맥락에서 상표를 이해하는 실질적인 가이드입니다. * **개인 정보:** 프로젝트가 사용자에 대한 데이터를 수집합니까? 법률팀은 회사 정책 및 외부 규정을 준수하도록 도울 수 있습니다. @@ -141,18 +133,18 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 장기적으로, 법률팀은 오픈소스에 대한 참여를 통해 더 많은 것을 얻고, 안전을 유지할 수 있도록 더 많은 일을 할 수 있습니다: -* **직원 기여 정책:** 직원이 오픈소스 프로젝트에 기여하는 방법을 지정하는 기업 정책을 개발하는 것을 고려하십시오. 분명한 정책은 직원들 사이의 혼란을 줄이고 작업의 일부 또는 자유 시간에 상관없이, 회사의 이익을 최대한 활용하여 오픈소스 프로젝트에 기여할 수 있도록 지원합니다. 좋은 예시는 Rackspace의 [모델 IP 및 오픈소스 기여 정책](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)입니다. +* **직원 기여 정책:** 직원이 오픈소스 프로젝트에 기여하는 방법을 지정하는 기업 정책을 개발하는 것을 고려하십시오. 분명한 정책은 직원들 사이의 혼란을 줄이고 작업의 일부 또는 자유 시간에 상관없이, 회사의 이익을 최대한 활용하여 오픈소스 프로젝트에 기여할 수 있도록 지원합니다. 좋은 예시는 Rackspace의 [모델 IP 및 오픈소스 기여 정책](https://ospo.co/blog/crafting-your-open-source-contribution-policy/)입니다. * **공개 할 내용:** [(거의) 다?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) 귀하의 법무팀이 귀하의 회사 오픈소스 전략을 이해하고 투자한다면, 귀하의 노력을 방해하는 것보다 최선을 다 할 수 있습니다. -* **준수:** 회사가 오픈소스 프로젝트를 공개하지 않더라도, 다른 회사의 오픈 소스 소프트웨어를 사용합니다. [Awareness and process](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program)는 두통, 제품 지연 및 법적 소송을 예방할 수 있습니다. +* **준수:** 회사가 오픈소스 프로젝트를 공개하지 않더라도, 다른 회사의 오픈 소스 소프트웨어를 사용합니다. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/)는 두통, 제품 지연 및 법적 소송을 예방할 수 있습니다. * **특허:** 귀사는 회원사의 주요 오픈소스 프로젝트 사용을 보호하거나 다른 대체 특허 라이센싱을 모색하기 위해, [Open Invention Network](http://www.openinventionnetwork.com/)에 가입 할 수 있습니다. -* **가버넌스:** 특히 프로젝트를 [회사 외부의 법인](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project)으로 옮기는 것이 이치에 맞을 경우에 할 수 있습니다. +* **가버넌스:** 특히 프로젝트를 [회사 외부의 법인](../leadership-and-governance/#제-프로젝트를-지원하려면-법인이-필요한가요)으로 옮기는 것이 이치에 맞을 경우에 할 수 있습니다. diff --git a/_articles/ko/maintaining-balance-for-open-source-maintainers.md b/_articles/ko/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..3537d30a1ee --- /dev/null +++ b/_articles/ko/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,221 @@ +--- +lang: ko +title: 오픈 소스 메인테이너를 위한 균형 유지 +description: 메인테이너를 위한 자기 관리 및 번아웃 방지 팁 +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +오픈 소스 프로젝트의 인기가 높아질수록, 장기적으로 신선함과 생산성을 유지하려면 명확한 경계를 설정하는 것이 중요합니다. + +메인테이너들의 경험과 그들이 균형을 찾는 전략을 더 깊이 이해하기 위해, 우리는 메인테이너 커뮤니티의 40명과 워크숍을 진행했으며, 이를 통해 오픈 소스에서 번아웃을 경험한 사례와, 그들이 균형을 유지하는 데 도움이 된 실천 방법을 직접 배울 수 있었습니다. 여기서 개인 생태계(personal ecology)라는 개념이 중요한 역할을 합니다. + +그렇다면 개인 생태계란 무엇일까요? Rockwood Leadership Institute의 설명에 따르면, 여기에는 "우리의 에너지를 평생 동안 지속하기 위해 균형, 속도 그리고 효율성을 유지하는 것"이 포함됩니다. +이는 메인테이너들이 시간이 흐르면서 변화하는 더 큰 생태계의 일부로서 자신의 역할과 기여를 인식하는 데 도움을 주는 개념이 되었습니다. 번아웃은 [세계보건기구(WHO)가 정의](https://icd.who.int/browse/2025-01/foundation/en#129180281)한 바와 같이 만성적인 업무 스트레스로 인해 발생하는 증후군이며, 메인테이너들 사이에서도 흔히 나타납니다. 이는 종종 동기 상실, 집중력 저하, 그리고 기여자 및 커뮤니티에 대한 공감 부족으로 이어집니다. + + + +이 개인 생태계 개념을 수용함으로써, 메인테이너들은 번아웃을 사전에 방지하고, 자기 관리를 우선하며, 균형을 유지하여 최상의 작업을 수행할 수 있습니다. + +## 메인테이너를 위한 자기 관리 및 번아웃 방지 팁: + +### 오픈 소스에서 작업하는 동기(motivation)를 확인하기 + +오픈 소스 유지보수의 어떤 부분이 여러분에게 활력을 주는지 생각해 보세요. 자신의 동기를 이해하면, 지속적으로 참여하면서 새로운 도전에 대비할 수 있도록 작업의 우선순위를 정하는 데 도움이 됩니다. 사용자의 긍정적인 피드백이든, 커뮤니티와 협업하고 교제하는 기쁨이든, 코드에 깊이 몰입하는 만족감이든, 자신의 동기를 인식하는 것이 집중 방향을 설정하는 데 도움이 될 수 있습니다. + +### 균형을 잃고 스트레스 받는 원인을 되돌아보기 + +번아웃이 발생하는 원인을 이해하는 것이 중요합니다. 오픈 소스 메인테이너들 사이에서 공통적으로 나타나는 몇 가지 주요 원인은 다음과 같습니다: + +* **긍정적인 피드백 부족:** 사용자들은 불만이 있을 때 연락을 취할 가능성이 훨씬 더 높습니다. 모든 것이 원활하게 작동하면 그들은 조용히 있는 경우가 많지요. 당신의 기여가 어떤 변화를 가져오는지 보여주는 긍정적인 피드백 없이 그저 늘어나는 문제(issue) 목록을 지켜보는 것은 좌절감을 불러올 수 있습니다. + + + +* **'아니오'라고 말하지 않기:** 오픈 소스 프로젝트에서는 생각보다 많은 책임을 맡게 되기 쉽습니다. 사용자, 기여자 또는 다른 메인테이너로부터든, 우리는 항상 그들의 기대에 부응할 수는 없습니다. + + + +* **혼자 일하기:** 메인테이너가 된다는 것은 엄청나게 외로울 수 있습니다. 심지어 여러 명의 메인테이너와 함께 일하더라도 지난 몇 년 동안은 분산된 팀을 직접 소집하는 것은 어려웠습니다. + + + +* **부족한 시간 혹은 자원:** 이는 특히 프로젝트를 진행하기 위해 여가 시간을 희생해야 하는 자원봉사자 메인테이너들이 해당됩니다. + + + +* **상충되는 기대:** 오픈 소스는 서로 다른 동기를 가진 여러 그룹으로 가득 차 있어, 이를 조정하는 것이 어려울 수 있습니다. 오픈 소스를 유료로 진행하는 경우, 때때로 당신 고용주의 관심사와 커뮤니티의 이익이 충돌할 수도 있습니다. + + + +### 번아웃 징후를 주의하기 + +지금처럼 10주 동안 일을 할 수 있겠습니까? 10달은요? 10년은요? + +[@shaunagm](https://github.com/shaunagm)의 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html)와 같은 도구들이 현재 속도를 되돌아보고 조정할 부분이 있는지 확인하는 데 도움을 줄 수 있습니다. 일부 메인테이너는 웨어러블 기술을 사용해 수면 질이나 심박수 변동성 (둘 다 스트레스와 관련 있음)과 같은 지표를 추적하기도 합니다. + + + +### 자기 자신과 커뮤니티를 계속 유지하려면 무엇이 필요할까? + +이것은 각 메인테이너마다 다르게 나타나며, 인생의 단계와 다른 외부 요인에 따라 달라질 수 있습니다. 하지만 우리가 들은 몇 가지 주요 주제는 다음과 같습니다: + +* **커뮤니티에 의지하기:** 업무 위임과 기여자를 찾는 것은 업무 부담을 덜어줄 수 있습니다. 프로젝트에 여러 접점을 두면 걱정 없이 휴식을 취할 수 있습니다. 다른 메인테이너 및 더 넓은 커뮤니티와 연결하세요, [메인테이너 커뮤니티](http://maintainers.github.com/)같은 곳이요. 이는 동료 지원 및 학습을 위한 훌륭한 리소스가 될 수 있습니다. + + 사용자 커뮤니티와 소통할 수 있는 방법을 찾을 수도 있습니다. 이를 통해 정기적으로 피드백을 듣고 당신의 오픈 소스 작업의 영향을 파악할 수 있습니다. + +* **자금 확보 탐색:** 피자값 정도의 지원이든, 오픈 소스를 전업으로 하려고 하든, 도움을 위한 리소스는 있습니다! 첫 단계로 [GitHub Sponsors](https://github.com/sponsors)를 켜서 다른 사람들이 당신의 오픈 소스 작업을 후원할 수 있게 고려해보세요. 만약 전업으로 전환하려고 생각한다면, [GitHub Accelerator](http://accelerator.github.com/)의 다음 라운드에 지원하세요. + + + +* **도구 사용하기:** [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)를 설정하여 언제 일할 수 있는지를 나타내보세요! 숙면은 장기적인 노력 지속 능력에 큰 차이를 만들 수 있습니다. + + 프로젝트에서 특히 즐기는 부분이 있다면, 그 부분을 경험할 수 있도록 작업을 구성해 보세요. + + + +* **경계를 설정하기:** 모든 요청에 '예(yes)'라고 답할 수는 없습니다. "지금은 그 일을 할 수 없고, 앞으로도 할 계획이 없다"고 간단히 말하거나, README에 내가 하고 싶은 일과 하지 않을 일을 나열하는 방식으로도 충분히 할 수 있습니다. 예를 들어 다음과 같이 말할 수 있습니다: "나는 PR을 만든 이유가 명확하게 나열된 PR만 병합합니다." 또는 "나는 매주 목요일 6시부터 7시까지만 이슈를 리뷰합니다". 이렇게 하면 다른 사람들이 당신의 기대치를 알게 되고, 나중에 기여자나 사용자들이 시간에 대해 무리한 요구를 할 때, 이를 완화할 수 있는 기준을 제시할 수 있게 됩니다. + + + + 유독한(toxic) 행동과 부정적인 상호작용을 단호하게 차단하는 법을 배우세요. 관심 없는 일에 에너지를 쏟지 않아도 괜찮습니다. + + + + + + 개인 생태학은 당신의 오픈 소스 여정을 진행하면서 발전하는 지속적인 실천이라는 점을 기억하세요. 자기 관리를 우선시하고 균형 감각을 유지함으로써, 당신은 오픈 소스 커뮤니티에 효과적이고 지속 가능하게 기여할 수 있고, 이는 장기적으로 웰빙과 프로젝트의 성공을 함께 보장할 수 있습니다. + +## 추가 자료 + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid +* [Governing Open](https://governingopen.com/) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series + +## 기여자 + +이 가이드를 위해 자신의 경험과 팁을 공유해 주신 모든 메인테이너분들께 진심으로 감사드립니다! + +이 가이드는 [@abbycabs](https://github.com/abbycabs)가 작성했으며, 아래 기여자들의 기여가 있었습니다. + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + 이외의 다른 많은 사람들! diff --git a/_articles/ko/metrics.md b/_articles/ko/metrics.md index 4db7c4cb4ae..e32172b03f9 100644 --- a/_articles/ko/metrics.md +++ b/_articles/ko/metrics.md @@ -3,12 +3,6 @@ lang: ko title: 오픈소스 측정항목 description: 성공을 측정하고 추적함으로써 오픈소스 프로젝트가 성공할 수 있도록 정보에 입각한 의사 결정을 하십시오. class: metrics -toc: - why-measure-anything: "왜 무엇이든지 측정합니까?" - discovery: "발견" - usage: "사용" - retention: "보유" - maintainer-activity: "메인테이너 활동" order: 9 image: /assets/images/cards/metrics.png related: @@ -16,11 +10,11 @@ related: - best-practices --- -## Why measure anything? +## 왜 측정할까요? 데이터를 현명하게 사용하면, 오픈소스 메인테이너로서 더 나은 의사 결정을 내릴 수 있습니다. -자세한 정보를 통해 다음을 수행 할 수 있습니다: +자세한 정보를 통해 다음을 수행할 수 있습니다: * 사용자가 새로운 기능에 어떻게 반응하는지 이해하기 * 새로운 사용자가 어디서 왔는지 파악하기 @@ -29,17 +23,17 @@ related: * 프로젝트 사용 방법 이해하기 * 스폰서십과 보조금을 통해 돈을 모으기 -예시로, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md)는 Google 웹 로그 분석으로 우선 순위를 결정하는 데 도움이 되는 것으로 나타났습니다: +예시로, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md)는 Google 웹 로그 분석으로 우선순위를 결정하는 데 도움이 되는 것으로 나타났습니다: -> Homebrew는 무료로 제공되며, 여가 시간에 자원 봉사자들에 의해 전적으로 운영됩니다. 결과적으로, 우리는 미래의 기능을 설계하고 현재 작업의 우선 순위를 정하는 최선의 방법을 결정하기 위해 Homebrew 사용자에 대한 상세한 사용자 연구를 할 수 있는 자원이 없습니다. 익명 집계 사용자 분석을 사용하면 사람들이 Homebrew를 사용하는 방법, 장소 및 시기에 따라 수정 및 기능의 우선 순위를 지정할 수 있습니다. +> Homebrew는 무료로 제공되며, 여가 시간에 자원 봉사자들에 의해 전적으로 운영됩니다. 결과적으로, 우리는 미래의 기능을 설계하고 현재 작업의 우선순위를 정하는 최선의 방법을 결정하기 위해 Homebrew 사용자에 대한 상세한 사용자 연구를 할 수 있는 자원이 없습니다. 익명 집계 사용자 분석을 사용하면 사람들이 Homebrew를 사용하는 방법, 장소 및 시기에 따라 수정 및 기능의 우선순위를 지정할 수 있습니다. 인기가 모든 것이 아닙니다. 누구나 다른 이유로 오픈소스를 사용합니다. 오픈소스 메인테이너로서의 목표가 업무를 과시하거나, 코드에 대해 투명하게 표현하거나, 재미있게 만나는 것이라면, 측정이 중요하지 않을 수도 있습니다. If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity. -## Discovery +## 발견 -누구든지 프로젝트를 사용하거나 기여할 수 있게 하기전에, 이것이 존재 하는 지를 알아야합니다. 자신에게 물어보십시오: _이 프로젝트를 찾는 사람들입니까?_ +누구든지 프로젝트를 사용하거나 기여할 수 있게 하기 전에, 이것이 존재하는 지를 알아야 합니다. 자신에게 물어보십시오: _이 프로젝트를 찾는 사람들입니까?_ ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) @@ -49,56 +43,56 @@ If you _are_ interested in understanding your project on a deeper level, read on * **총 고유 방문자수:** 얼마나 많은 사람들이 프로젝트를 보았는지 알려줍니다 -* **참고한 사이트:** 방문자가 어디에서 왔는지 알려줍니다. 이 통계는 잠재 고객에게 도달할 수있는 위치와 홍보 활동의 효과를 파악하는 데 도움이됩니다. +* **참고한 사이트:** 방문자가 어디에서 왔는지 알려줍니다. 이 통계는 잠재 고객에게 도달할 수 있는 위치와 홍보 활동의 효과를 파악하는 데 도움이 됩니다. -* **인기 컨텐츠:** 방문자가 프로젝트에서 어디로 이동했는지 알려주며, 페이지 뷰와 고유 방문자별로 세분화됩니다. +* **인기 콘텐츠:** 방문자가 프로젝트에서 어디로 이동했는지 알려주며, 페이지 뷰와 고유 방문자별로 세분화됩니다. -[GitHub stars](https://help.github.com/articles/about-stars/)는 또한 인기의 기준치 측정을 제공하는 데 도움이 될 수 있습니다. GitHub star는 반드시 다운로드 및 사용량과 상관 관계가 있는 것은 아니지만, 얼마나 많은 사람들이 귀하의 작업에 주의를 기울이고 있는지 말해 줄 수 있습니다. +[GitHub stars](https://help.github.com/articles/about-stars/)는 또한 인기의 기준치 측정을 제공하는 데 도움이 될 수 있습니다. GitHub star는 반드시 다운로드 및 사용량과 상관관계가 있는 것은 아니지만, 얼마나 많은 사람들이 귀하의 작업에 주의를 기울이고 있는지 말해 줄 수 있습니다. -[특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함 할 수 있습니다. +[특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함할 수 있습니다. -## Usage +## 사용 -사람들은 우리가 인터넷이라고 부르는 이 거칠고 미친 일로 프로젝트를 찾고 있습니다. 이상적으로는, 프로젝트를 보았을 때 뭔가 할 것을 강요 당할 것입니다. 두 번째 질문은 다음과 같습니다: _이 프로젝트를 사용하는 사람들입니까?_ +사람들은 우리가 인터넷이라고 부르는 이 거칠고 미친 일로 프로젝트를 찾고 있습니다. 이상적으로는, 프로젝트를 보았을 때 뭔가 할 것을 강요당할 것입니다. 두 번째 질문은 다음과 같습니다: _이 프로젝트를 사용하는 사람들입니까?_ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝트를 배포하는 경우 프로젝트 다운로드를 추적할 수 있습니다. -각 패키지 매니저는 "다운로드"와 약간 다른 정의를 사용할 수 있으며, 다운로드가 반드시 설치 또는 사용과 관련이 있는 것은 아니지만 비교를 위한 기준을 제공합니다. [Libraries.io](https://libraries.io/)를 사용해 많은 인기있는 패키지 매니저의 사용 통계를 추적 해보십시오. +각 패키지 매니저는 "다운로드"와 약간 다른 정의를 사용할 수 있으며, 다운로드가 반드시 설치 또는 사용과 관련이 있는 것은 아니지만 비교를 위한 기준을 제공합니다. [Libraries.io](https://libraries.io/)를 사용해 많은 인기 있는 패키지 매니저의 사용 통계를 추적해보십시오. -만약 프로젝트가 깃허브에 있다면, "Traffic"페이지로 사디 이동하보십시오. [clone graph](https://github.com/blog/1873-clone-graphs)를 사용하여 주어진 날에 프로젝트가 복제 된 횟수를 전체 클론 및 클론 받은 사람으로 세분화 할 수 있습니다. +만약 프로젝트가 깃허브에 있다면, "Traffic"페이지로 다시 이동해 보십시오. [clone graph](https://github.com/blog/1873-clone-graphs)를 사용하여 주어진 날에 프로젝트가 복제된 횟수를 전체 클론 및 클론 받은 사람으로 세분화할 수 있습니다. ![Clone graph](/assets/images/metrics/clone_graph.png) -프로젝트를 발견한 사람의 수에 비해 사용량이 적을 경우, 고려해야 할 두 가지 문제가 있습니다. 어느 한 쪽으로는: +프로젝트를 발견한 사람의 수에 비해 사용량이 적을 경우, 고려해야 할 두 가지 문제가 있습니다. 어느 한쪽으로는: * 프로젝트가 잠재 고객을 성공적으로 전환하지 못했거나, 또는 * 틀린 지지자를 끌어들이고 있습니다. -예를 들어, 프로젝트가 Hacker News의 첫 페이지에있는 경우, Hacker News의 모든 사용자에게 도달했기 때문에 발견(트래픽)은 증가하지만 전환율은 낮아질 수 있습니다. 그러나 Ruby 프로젝트가 Ruby 컨퍼런스에 등장한다면 타겟 잠재 고객의 전환율이 높아질 가능성이 큽니다. +예를 들어, 프로젝트가 Hacker News의 첫 페이지에 있는 경우, Hacker News의 모든 사용자에게 도달했기 때문에 발견(트래픽)은 증가하지만 전환율은 낮아질 수 있습니다. 그러나 Ruby 프로젝트가 Ruby 컨퍼런스에 등장한다면 타겟 잠재 고객의 전환율이 높아질 가능성이 큽니다. -잠재 고객이 어디에서 왔는지 파악하고 프로젝트 페이지에서 다른 사람들에게 당신이 직면한 두가지 문제점을 파악하도록 요청하십시오. +잠재 고객이 어디에서 왔는지 파악하고 프로젝트 페이지에서 다른 사람들에게 당신이 직면한 두 가지 문제점을 파악하도록 요청하십시오. -사람들이 프로젝트를 사용하고 있다는 것을 알게되면, 사람들이 프로젝트를 통해 무엇을 하고 있는지 파악하려고 할 수 있습니다. 그들은 당신의 코드를 포크하고 기능을 추가함으로써 그것을 구축하고 있습니까? 그들은 과학이나 비즈니스를 위해 그것을 사용하고 있습니까? +사람들이 프로젝트를 사용하고 있다는 것을 알게 되면, 사람들이 프로젝트를 통해 무엇을 하고 있는지 파악하려고 할 수 있습니다. 그들은 당신의 코드를 포크하고 기능을 추가함으로써 그것을 구축하고 있습니까? 그들은 과학이나 비즈니스를 위해 그것을 사용하고 있습니까? -## Retention +## 유지 사람들이 프로젝트를 찾고 있으며 프로젝트를 사용하고 있습니다. 다음 질문은 스스로에게 물어볼 것입니다: _이 프로젝트에 다시 기여한 사람들입니까?_ -기여자를 생각하는 것은 너무 이릅니다.다른 사람이 참여하지 않으면 프로젝트가 _인기있고_(많은 사람들이 그것을 사용하지만) _지원_되지 않는(요구 사항을 충족시키는 데 필요한 유지 보수 시간이 충분하지 않음) 좋지 못한 상황에 처할 위험이 있습니다. +기여자를 생각하는 것은 너무 이릅니다. 다른 사람이 참여하지 않으면 프로젝트가 _인기 있고_(많은 사람들이 그것을 사용하지만) _지원_되지 않는(요구 사항을 충족시키는 데 필요한 유지 보수 시간이 충분하지 않음) 좋지 못한 상황에 처할 위험이 있습니다. 보유자는 이전에 활동적인 기여자가 결국 다른 것들로 이동하기 때문에 [새로운 기여자가 유입](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2)되어야합니다. 정기적으로 추적할 수 있는 커뮤니티 측정 항목의 예는 다음과 같습니다: -* **기여자 중 총 기여 수 및 커밋 수 :** 얼마나 많은 기여자가 있고, 누가 더 많이 또는 적게 활동 하는지를 알려줍니다. GitHub에서는 "Graphs"-> "Contributors"에서 볼 수 있습니다. 현재 이 그래프는 저장소의 기본 브랜치에 작성한 기여자만 계산합니다. +* **기여자 중 총 기여 수 및 커밋 수 :** 얼마나 많은 기여자가 있고, 누가 더 많이 또는 적게 활동하는지를 알려줍니다. GitHub에서는 "Graphs"-> "Contributors"에서 볼 수 있습니다. 현재 이 그래프는 저장소의 기본 브랜치에 작성한 기여자만 계산합니다. ![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) -* **처음, 캐주얼, 그리고 다시 기여한 사람:** 새로운 참여자를 얻었는지 여부와 그들이 다시 돌아 왔는지 여부를 추적하는 데 도움이됩니다. (캐주얼 기여자는 커밋 수가 적고 커밋 수가 5회 이하이거나, 또 다른 기준은 당신에게 달려 있습니다.) 새로운 참여자가 없으면 프로젝트 커뮤니티가 정체 될 수 있습니다. +* **처음, 캐주얼, 그리고 다시 기여한 사람:** 새로운 참여자를 얻었는지 여부와 그들이 다시 돌아왔는지 여부를 추적하는 데 도움이됩니다. (캐주얼 기여자는 커밋 수가 적고 커밋 수가 5회 이하이거나, 또 다른 기준은 당신에게 달려 있습니다.) 새로운 참여자가 없으면 프로젝트 커뮤니티가 정체될 수 있습니다. * **열린 이슈와 pull requests의 수:** 수치가 너무 높으면 이슈 검토 및 코드 검토에 대한 도움이 필요할 수 있습니다. -* **_열렸던_ 이슈와 _열렸던_ pull requests의 수:** 열렸던 이슈는 누군가가 프로젝트의 이슈를 열어 신청할 수 있음을 의미합니다. 그 숫자가 시간이 지남에 따라 증가하면 사람들이 귀하의 프로젝트에 관심을 보였다고 나타낼수 있습니다. +* **_열렸던_ 이슈와 _열렸던_ pull requests의 수:** 열렸던 이슈는 누군가가 프로젝트의 이슈를 열어 신청할 수 있음을 의미합니다. 그 숫자가 시간이 지남에 따라 증가하면 사람들이 귀하의 프로젝트에 관심을 보였다고 나타낼 수 있습니다. * **기여 유형:** 예시로, 커밋, 오타 혹은 버그 수정, 또는 이슈에 답변하기가 있습니다. @@ -110,23 +104,23 @@ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝

-## Maintainer activity +## 메인테이너의 활동 -마지막으로, 프로젝트 메인테이너가 받은 기여 분량을 처리 할 수 있는지 확인하여 루프를 닫으십시오. 자신에게 묻고 싶은 마지막 질문은 다음과 같습니다: _나는 (또는 우리가) 우리 커뮤니티에 반응하고 있습니까?_ +마지막으로, 프로젝트 메인테이너가 받은 기여 분량을 처리할 수 있는지 확인하여 루프를 닫으십시오. 자신에게 묻고 싶은 마지막 질문은 다음과 같습니다: _나는 (또는 우리가) 우리 커뮤니티에 반응하고 있습니까?_ 응답이 없는 메인테이너는 오픈소스 프로젝트의 병목 현상이 됩니다. 누군가 기여를 제출했지만 메인테이너가 듣지 못하면 기분이 나빠져서 떠나기도 합니다. [Mozilla의 연구](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177)는 관리자의 응답성이 반복 기여도를 장려하는 중요한 요소임을 시사합니다. -당사자(또는 다른 메인테이너)가 이슈 또는 pull request 여부에 관계없이 기여에 응답하는 데 걸리는 시간을 고려하십시오. 응답은 조치를 취할 필요가 없습니다. 다음과 같이 간단하게 말할 수 있습니다: _"제출해 주셔서 감사합니다. 저는 다음 주에 이것을 검토 할 것입니다."_ +당사자(또는 다른 메인테이너)가 이슈 또는 pull request 여부에 관계없이 기여에 응답하는 데 걸리는 시간을 고려하십시오. 응답은 조치를 취할 필요가 없습니다. 다음과 같이 간단하게 말할 수 있습니다: _"제출해 주셔서 감사합니다. 저는 다음 주에 이것을 검토할 것입니다."_ -다음과 같이 기여 프로세스의 단계간에 이동하는 데 걸리는 시간을 측정 할 수도 있습니다: +다음과 같이 기여 프로세스의 단계 간에 이동하는 데 걸리는 시간을 측정할 수도 있습니다: * 이슈가 열려있는 평균 시간 * 이슈가 PR에 의해 폐쇄되는지 여부 -* 부실 이슈가 종결 되는지 여부 +* 부실 이슈가 종결되는지 여부 * pull request을 병합하는 평균 시간 -## Use 📊 to learn about people +## 사람들에 대해 배우려면 📊를 사용하세요 -측정 기준을 이해하면 적극적으로 성장하는 오픈소스 프로젝트를 구축하는 데 도움이됩니다. 대시 보드의 모든 측정치를 추적하지 않더라도, 위의 프레임워크를 사용하여 프로젝트가 성공하는 데 도움이 되는 동작 유형에 주의를 기울이십시오. +측정 기준을 이해하면 적극적으로 성장하는 오픈소스 프로젝트를 구축하는 데 도움이 됩니다. 대시 보드의 모든 측정치를 추적하지 않더라도, 위의 프레임워크를 사용하여 프로젝트가 성공하는 데 도움이 되는 동작 유형에 주의를 기울이십시오. diff --git a/_articles/ko/security-best-practices-for-your-project.md b/_articles/ko/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..0f78244de53 --- /dev/null +++ b/_articles/ko/security-best-practices-for-your-project.md @@ -0,0 +1,157 @@ +--- +lang: ko +title: 프로젝트를 위한 보안 모범 사례 +description: MFA, 코드 스캐닝, 안전한 의존성 관리, 비공개 취약점 신고까지 — 필수적인 보안 실천을 통해 신뢰를 구축하고 프로젝트의 미래를 강화하세요. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +버그 수정과 새로운 기능도 중요하지만, 프로젝트의 장기적인 지속 가능성은 유용성뿐만 아니라 사용자로부터 얻는 신뢰에 달려 있습니다. 이 신뢰를 유지하기 위해서는 강력한 보안 조치가 중요합니다. 아래는 프로젝트의 보안 수준을 크게 향상시킬 수 있는 중요한 실천 사항들입니다. + +## 권한 있는 모든 기여자가 다중 요소 인증(MFA)을 활성화했는지 확인하세요 + +### 프로젝트의 권한 있는 기여자를 사칭하는 공격자가 발생하면 치명적인 피해를 초래할 수 있습니다. + +공격자가 권한을 획득하면, 코드에 원치 않는 동작(예: 암호화폐 채굴)을 추가하거나 사용자 인프라에 악성코드를 배포할 수 있으며, 비공개 코드 저장소에 접근해 지적 재산과 민감한 데이터(다른 서비스의 자격 증명 포함)를 탈취할 수도 있습니다. + +MFA는 계정 탈취를 방지하기 위한 추가적인 보안 계층을 제공합니다. MFA를 활성화하면 사용자 이름과 비밀번호로 로그인한 뒤, 본인만 알고 있거나 접근할 수 있는 또 다른 인증 수단을 함께 제공해야 합니다. + +## 개발 워크플로우의 일부로 코드 보안을 확보하세요 + +### 코드의 보안 취약점은 운영 환경에서 사용되기 시작한 뒤보다, 과정 초기에 발견했을 때 수정 비용이 훨씬 적게 듭니다. + +정적 애플리케이션 보안 테스트(SAST) 도구를 사용하면 코드 내 보안 취약점을 탐지할 수 있습니다. 이러한 도구는 코드 수준에서 동작하며 실행 환경이 필요 없기 때문에, 과정 초기에 실행할 수 있고 빌드 단계나 코드 리뷰 단계 등 평소 개발 워크플로우에 자연스럽게 통합할 수 있습니다. + +이는 마치 숙련된 전문가가 코드 저장소를 훑어보며, 코딩하는 동안 눈앞에 그대로 있는데도 놓치기 쉬운 일반적인 보안 취약점을 찾아주는 것과 같습니다. + +어떤 SAST 도구를 선택해야 할까요? +라이선스 확인: 일부 도구는 오픈 소스 프로젝트에 무료로 제공됩니다. 예를 들어 GitHub CodeQL이나 SemGrep이 있습니다. +사용 언어에 대한 지원 범위를 확인하세요. + +* 이미 사용 중인 도구와 기존 프로세스에 쉽게 통합되는 것을 선택하세요. 예를 들어, 경고를 확인하기 위해 다른 도구로 이동하기보다, 기존 코드 리뷰 프로세스/도구의 일부로 경고를 확인할 수 있는 편이 더 좋습니다. +* 거짓 양성(False Positive)에 주의하세요! 도구가 아무 이유 없이 작업 속도를 늦추게 하고 싶지는 않으시겠죠! +* 이런 기능들도 확인해보세요: 일부 도구는 매우 강력해 오염 추적(예: GitHub CodeQL)을 수행할 수 있고, 일부는 AI가 생성한 수정안을 제안하며, 일부는 커스텀 쿼리를 더 쉽게 작성할 수 있게 해줍니다(예: SemGrep). + +## 비밀 정보를 공유하지 마세요 + +### API 키, 토큰, 비밀번호와 같은 민감한 정보는 종종 실수로 저장소에 커밋될 수 있습니다. + +다음 상황을 상상해 보세요. 전 세계 개발자들이 기여하는 인기 오픈 소스 프로젝트의 메인테이너인 당신의 프로젝트에, 한 기여자가 제3자 서비스의 API 키를 인지하지 못한 채 커밋합니다. 며칠 뒤 누군가 이 키를 발견해 무단으로 서비스를 사용합니다. 서비스는 침해되고, 프로젝트 사용자들은 장애를 겪으며, 프로젝트의 평판은 큰 타격을 받습니다. 메인테이너로서 당신은 노출된 비밀 정보를 폐기하고, 공격자가 이 비밀 정보를 통해 어떤 악의적인 행동을 할 수 있었는지 조사하고, 영향을 받은 사용자에게 알리고, 수정 조치를 구현해야 하는 상황에 직면하게 됩니다. + +이러한 사고를 방지하기 위해 코드 내 비밀 정보를 탐지하는 "시크릿 스캐닝(secret scanning)" 솔루션이 존재합니다. GitHub Secret Scanning이나 Truffle Security의 Trufflehog 같은 도구는 비밀 정보가 원격 브랜치로 푸시되기 전에 이를 차단할 수 있으며, 일부 도구는 노출된 비밀 정보를 자동으로 폐기해 주기도 합니다. + +## 의존성을 점검하고 업데이트하세요 + +### 프로젝트의 의존성에는 프로젝트 보안을 훼손할 수 있는 취약점이 포함될 수 있습니다. 의존성을 수동으로 최신 상태로 유지하는 일은 많은 시간이 드는 작업일 수 있습니다. + +이런 상황을 생각해 보세요. 널리 사용되는 라이브러리를 튼튼한 기반으로 삼아 구축된 프로젝트가 있습니다. 이후 해당 라이브러리에서 큰 보안 문제가 발견되었지만, 이를 사용해 애플리케이션을 만든 사람들은 이를 알지 못합니다. 공격자는 이 약점을 악용해 민감한 사용자 데이터를 그대로 노출된 상태로 만들어, 그 틈을 타 데이터를 가져갑니다. 이는 가상의 이야기가 아닙니다. 2017년 Equifax에서 정확히 이런 일이 벌어졌습니다. Equifax는 심각한 취약점이 발견되었다는 통지를 받은 뒤에도 Apache Struts 의존성을 업데이트하지 않았습니다. 그 취약점은 악용되었고, 악명 높은 Equifax 침해 사고로 1억 4,400만 명 사용자 데이터가 영향을 받았습니다. + +이러한 상황을 방지하기 위해 Dependabot과 Renovate 같은 소프트웨어 구성 분석(SCA) 도구는 NVD나 GitHub Advisory Database 같은 공개 데이터베이스에 게시된 알려진 취약점을 기준으로 의존성을 자동 점검하고, 안전한 버전으로 업데이트하는 풀 리퀘스트를 생성합니다. 최신의 안전한 의존성 버전을 유지하는 것은 프로젝트를 잠재적 위험으로부터 보호합니다. + +## 오픈 소스 라이선스 위험을 이해하고 관리하세요 + +### 오픈 소스 라이선스에는 조건이 있으며, 이를 무시하면 법적·평판상의 위험으로 이어질 수 있습니다. + +오픈 소스 의존성을 사용하면 개발 속도를 높일 수 있지만, 각 패키지에는 사용, 수정, 배포 방식을 규정하는 라이선스가 포함되어 있습니다. [일부 라이선스는 허용적(permissive)](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project)인 반면, AGPL이나 SSPL처럼 프로젝트의 목표나 사용자 요구와 호환되지 않을 수 있는 제한을 부과하는 라이선스도 있습니다. + +이런 상황을 상상해 보세요. 강력한 라이브러리를 프로젝트에 추가했지만, 해당 라이브러리가 제한적인 라이선스를 사용한다는 사실을 알지 못했습니다. 이후 한 기업이 프로젝트 도입을 원하지만 라이선스 준수에 대한 우려를 제기합니다. 결과적으로 도입이 무산되고, 코드를 리팩터링해야 하며, 프로젝트의 평판도 타격을 입습니다. + +이러한 함정을 피하기 위해 개발 워크플로우의 일부로 자동화된 라이선스 검사를 포함하는 것을 고려해 보세요. 이러한 검사는 과정 초기에 호환되지 않는 라이선스를 식별해, 문제가 되는 의존성이 프로젝트에 도입되는 일을 방지할 수 있습니다. + +또 다른 강력한 접근 방식은 소프트웨어 자재 명세서(SBOM)를 생성하는 것입니다. SBOM은 모든 구성 요소와 그 메타데이터(라이선스 포함)를 표준화된 형식으로 나열합니다. 이를 통해 소프트웨어 공급망을 명확히 가시화하고, 라이선스 위험을 선제적으로 드러내는 데 도움이 됩니다. + +보안 취약점과 마찬가지로, 라이선스 문제도 과정 초기에 발견할수록 수정이 쉽습니다. 이 과정을 자동화하면 프로젝트를 건강하고 안전하게 유지할 수 있습니다. + +## 보호된 브랜치를 사용해 원치 않는 변경을 방지하세요 + +### 메인 브랜치에 대한 무제한 접근은 실수 또는 악의적인 변경으로 이어져 보안 취약점을 도입하거나 프로젝트의 안정성을 해칠 수 있습니다. + +새로운 기여자가 메인 브랜치에 쓰기 권한을 얻은 뒤, 테스트되지 않은 변경 사항을 실수로 푸시했다고 가정해 보세요. 그러면 최신 변경 사항 때문에 심각한 보안 결함이 드러날 수도 있습니다. 이러한 문제를 방지하기 위해 브랜치 보호 규칙은 리뷰를 거치고 지정된 상태 검사를 통과하기 전에는 중요한 브랜치로 변경 사항이 푸시되거나 병합되지 않도록 보장합니다. 이 추가 조치를 마련해 두면 훨씬 더 안전하며, 매번 최상의 품질을 보장할 수 있습니다. + +## 보안 이슈를 쉽고(그리고 안전하게) 신고할 수 있도록 하세요 + +### 사용자가 버그를 쉽게 신고할 수 있도록 하는 것은 좋은 관행이지만, 큰 질문은 이것입니다: 이 버그가 보안에 영향을 미칠 때, 악의적인 해커들에게 표적이 되지 않으면서 사용자가 어떻게 안전하게 신고할 수 있을까요? + +보안 연구원이 프로젝트에서 취약점을 발견했지만 이를 신고할 명확하거나 안전한 방법을 찾지 못하는 상황을 떠올려 보세요. 지정된 프로세스가 없다면, 공개 이슈를 만들거나 소셜 미디어에서 공개적으로 논의할 수도 있습니다. 선의로 수정안을 제시하더라도, 공개 풀 리퀘스트로 올리면 병합되기 전에 다른 사람들이 이를 보게 됩니다! 이런 공개는 당신이 대응할 기회를 갖기 전에 취약점을 악의적인 행위자에게 노출시키며, 잠재적으로 제로데이 익스플로잇으로 이어져 프로젝트와 사용자에게 공격이 발생할 수 있습니다. + +### 보안 정책(Security Policy) + +이를 피하려면 보안 정책을 게시하세요. `SECURITY.md` 파일에 정의되는 보안 정책은 보안 우려 사항을 신고하는 단계, 조율된 공개(coordinated disclosure)를 위한 투명한 프로세스, 그리고 보고된 이슈를 처리하기 위한 프로젝트 팀의 책임을 상세히 설명합니다. 이 보안 정책은 "공개 이슈나 PR에 상세 내용을 게시하지 말고 security@example.com으로 비공개 이메일을 보내주세요"처럼 간단할 수도 있지만, 언제쯤 답변을 받을 수 있는지 등 다른 세부 정보를 포함할 수도 있습니다. 공개 과정의 효과성과 효율성을 높이는 데 도움이 되는 내용이라면 무엇이든 좋습니다. + +### 비공개 취약점 신고(Private Vulnerability Reporting) + +일부 플랫폼에서는 비공개 이슈를 통해 접수에서 공개까지, 취약점 관리 프로세스를 간소화하고 강화할 수 있습니다. GitLab에서는 비공개 이슈로 이를 할 수 있습니다. GitHub에서는 이를 비공개 취약점 신고(PVR)라고 부릅니다. PVR을 사용하면 메인테이너는 GitHub 플랫폼 내에서 취약점 신고를 접수하고 대응할 수 있습니다. GitHub는 자동으로 수정 작업을 작성할 수 있는 비공개 포크와, 초안 보안 권고문을 생성합니다. 이 모든 것은 당신이 이슈를 공개하고 수정 사항을 릴리스하기로 결정할 때까지 기밀로 유지됩니다. 마무리로 보안 권고문이 게시되어, SCA 도구를 통해 모든 사용자를 알리고 보호하게 됩니다. + +### 범위를 이해할 수 있도록 위협 모델을 정의해 두세요 + +보안 연구원이 이슈를 효과적으로 보고하려면, 어떤 위험이 범위에 포함되는지 이해해야 합니다. 가벼운 위협 모델은 프로젝트의 경계, 예상 동작, 그리고 가정 사항을 정의하는 데 도움이 됩니다. + +위협 모델은 복잡할 필요가 없습니다. 프로젝트가 무엇을 하는지, 무엇을 신뢰하는지, 그리고 어떻게 오용될 수 있는지를 간단히 문서로 정리하는 것만으로도 큰 도움이 됩니다. 또한 메인테이너로서 잠재적인 함정과 상위 의존성으로부터 상속되는 위험을 생각해 보는 데도 도움이 됩니다. + +좋은 예시는 [Node.js 위협 모델](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model)로, 프로젝트 맥락에서 무엇이 취약점으로 간주되고 무엇이 아닌지를 명확히 정의합니다. + +처음이라면, [OWASP 위협 모델링 프로세스](https://owasp.org/www-community/Threat_Modeling_Process)가 자체 위협 모델을 구축하는 데 유용한 소개 자료가 될 것입니다. + +보안 정책과 함께 기본적인 위협 모델을 게시하면 모두에게 더 명확해집니다. + +## 간단한 사고 대응 프로세스를 준비하세요 + +### 기본적인 사고 대응 계획을 갖고 있으면 침착하게 효율적으로 대응할 수 있어, 사용자와 소비자의 안전을 보장할 수 있습니다. + +대부분의 취약점은 연구자에 의해 발견되어 비공개로 보고됩니다. 하지만 때로는 문제가 당신에게 도달하기 전에 이미 실제 환경에서 악용되고 있을 수도 있습니다. 이런 일이 발생하면 위험에 노출되는 것은 하위 소비자들이며, 가볍고 잘 정의된 사고 대응 계획을 갖고 있는 것은 결정적인 차이를 만들 수 있습니다. + + + +취약점이 비공개로 보고되었더라도, 그 다음 단계가 중요합니다. 취약점 보고를 받거나 의심스러운 활동을 감지했을 때, 그 다음에는 무엇이 일어날까요? + +기본적인 사고 대응 계획은, 심지어 간단한 체크리스트만으로도, 시간이 중요한 순간에 침착하고 효율적으로 대응하는 데 도움이 됩니다. 또한 사용자와 연구원에게 사고와 보고를 진지하게 다루고 있다는 점을 보여줍니다. + +프로세스는 복잡할 필요가 없습니다. 최소한 다음을 정의하세요: + +* 보안 보고나 경고를 검토하고 분류하는 주체 +* 심각도를 어떻게 평가하고, 완화 조치 결정을 어떻게 내리는지 +* 수정 사항을 준비하고 공개를 조율하기 위해 어떤 단계를 밟는지 +* 영향을 받은 사용자, 기여자, 하위 소비자에게 어떻게 알리는지 + +적절히 관리되지 않은 진행 중 사고는 사용자들로부터 프로젝트에 대한 신뢰를 약화시킬 수 있습니다. 이를 `SECURITY.md` 파일에 게시(또는 링크)하면 기대치를 설정하고 신뢰를 구축하는 데 도움이 됩니다. + +참고 자료로, [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md)는 간단하지만 효과적인 오픈 소스 사고 대응 계획의 예시를 제공합니다. + +이 계획은 프로젝트가 성장함에 따라 발전할 수 있지만, 지금 기본적인 프레임워크를 마련해 두는 것만으로도 실제 사고가 발생했을 때 시간을 절약하고 실수를 줄일 수 있습니다. + +## 보안을 팀의 노력으로 다루세요 + +### 보안은 혼자서 책임질 일이 아닙니다. 프로젝트 커뮤니티 전체가 함께할 때 가장 잘 작동합니다. + +도구와 정책이 필수적이긴 하지만, 강력한 보안 태세는 팀과 기여자들이 어떻게 함께 일하느냐에서 나옵니다. 공동 책임의 문화를 구축하면 취약점을 더 빠르고 효과적으로 식별하고, 분류하고, 대응할 수 있습니다. + +보안을 팀 스포츠로 만들 수 있는 몇 가지 방법은 다음과 같습니다. + +* **명확한 역할을 지정하세요**: 누가 취약점 신고를 처리하는지, 누가 의존성 업데이트를 검토하는지, 누가 보안 패치를 승인하는지 파악하세요. +* **최소 권한 원칙으로 접근을 제한하세요**: 정말로 필요한 사람에게만 쓰기 또는 관리자 권한을 부여하고, 권한을 정기적으로 검토하세요. +* **교육에 투자하세요**: 기여자들이 안전한 코딩 관행, 일반적인 취약점 유형, 그리고 SAST나 시크릿 스캐닝 같은 도구를 사용하는 방법을 학습하도록 장려하세요. +* **다양성과 협업을 장려하세요**: 이질적인 팀은 더 넓은 경험, 위협 인식, 창의적인 문제 해결 능력을 제공합니다. 또한 다른 사람들이 놓칠 수 있는 위험을 발견하는 데 도움이 됩니다. +* **상·하위 생태계와 연결하세요**: 의존성은 보안에 영향을 주고, 프로젝트는 다른 이들에게 영향을 줍니다. 상위 메인테이너와 조율된 공개에 참여하고, 취약점이 수정되면 하위 사용자에게 알리세요. + +보안은 일회성 설정이 아니라 지속적인 과정입니다. 커뮤니티를 참여시키고, 안전한 관행을 장려하며, 서로를 지원함으로써 더 강력하고 회복력 있는 프로젝트와 모두에게 더 안전한 생태계를 구축할 수 있습니다. + +## 결론: 당신에게는 몇 가지 작은 실천, 사용자에게는 큰 개선 + +이러한 단계들은 단순하거나 기본적으로 보일 수 있지만, 가장 흔한 문제로부터 보호를 제공하기 때문에 사용자에게 더 안전한 프로젝트를 제공하는 데 큰 도움이 됩니다. + +보안은 정적인 것이 아닙니다. 프로젝트가 성장함에 따라 프로세스도, 책임도, 공격 표면도 함께 커집니다. 때때로 프로세스를 다시 점검하세요. + +## 기여자 + +### 이 가이드를 위해 경험과 팁을 공유해 주신 모든 메인테이너 여러분께 감사드립니다! + +이 가이드는 [@nanzggits](https://github.com/nanzggits)와 [@xcorail](https://github.com/xcorail)이 작성했으며, 다음 분들의 기여가 있었습니다. + +[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + 이외의 다른 많은 사람들! diff --git a/_articles/ko/starting-a-project.md b/_articles/ko/starting-a-project.md index feea1b2bf06..f0f6b5f3fee 100644 --- a/_articles/ko/starting-a-project.md +++ b/_articles/ko/starting-a-project.md @@ -1,14 +1,8 @@ --- lang: ko title: 오픈소스 프로젝트 시작하기 -description: 오픈소스의 세계에 대해 자세히 알아보고 자신만의 프로젝트를 시작할 준비를 하십시오. +description: 오픈소스의 세계에 대해 자세히 알아보고 여러분의 프로젝트를 시작할 준비를 해보세요. class: beginners -toc: - the-what-and-why-of-open-source: "오픈소스의 목적 및 이유" - should-i-launch-my-own-open-source-project: "나 자신의 오픈소스 프로젝트를 시작해야합니까?" - launching-your-own-open-source-project: "나만의 오픈소스 프로젝트 시작하기" - naming-and-branding-your-project: "프로젝트 네이밍 및 브랜딩" - your-pre-launch-checklist: "출시 전 체크리스트" order: 2 image: /assets/images/cards/beginner.png related: @@ -16,287 +10,287 @@ related: - building --- -## The "what" and "why" of open source +## 오픈소스는 "무엇"이고 "왜" 하는가? -따라서 오픈소스를 시작하는 것에 대해 생각하고 있습니까? 축하합니다! 세상은 당신의 기여를 높이 평가합니다. 오픈소스란 무엇이며, 왜 사람들이 그렇게하는지 이야기해 봅시다. +오픈소스를 시작하려고 하시나요? 축하합니다! 세상이 여러분의 기여를 높이 살 것입니다. 오픈소스란 무엇이며, 왜 사람들이 오픈소스를 사용하는지 알아봅시다. -### "오픈소스"란 무엇을 의미합니까? +### "오픈소스"란 무엇인가요? -즉 **누구나 프로젝트를 보고, 사용하고, 수정하고, 배포 할 수 있습니다.** 이러한 권한은 [오픈소스 라이선스](https://opensource.org/licenses)를 통해 시행됩니다. +오픈소스 프로젝트에서는 **누구나 어떤 목적으로든 프로젝트를 보고, 사용하고, 수정하고, 배포할 수 있습니다.** 이러한 권한은 [오픈소스 라이선스](https://opensource.org/licenses)를 통해 적용됩니다. -오픈소스는 채택의 장벽을 낮추어 아이디어가 빠르게 확산될 수 있기 때문에 강력합니다. +오픈소스는 채택의 장벽을 낮춰 아이디어를 신속하게 퍼뜨릴 수 있기 때문에 강력합니다. -그것이 어떻게 작동하는지 이해하려면, 친구가 potluck을 가지고 있다고 상상해보고, 체리 파이를 가지고 오십시오. +오픈소스가 어떻게 돌아가는지 이해하기 위해, 친구가 솥밥을 먹고 있는데 여러분이 체리 파이를 가지고 간다고 생각해 보세요. -* 모두가 파이를 먹습니다 (_사용_) -* 파이가 히트를 쳤습니다! 그들은 당신에게 파이 제조법을 묻습니다 (_보기_) -* 한 친구인, 제과점 주방장 Alex는 설탕을 줄이는 것이 좋다고 조언합니다 (_수정_) -* 다른 친구인, Lisa는 다음 주 저녁 식사에 그것을 사용할 것을 요청합니다 (_배포_) +* 모두가 파이를 먹을 수 있습니다. (_사용_) +* 파이가 히트를 쳤습니다! 그들은 여러분이 만들어 공개한 파이의 레시피를 찾아봅니다. (_소스 뷰_) +* 제과점 주방장인 한 친구 알렉스가 설탕을 줄이는 게 좋겠다고 조언합니다. (_수정_) +* 다른 친구인 리사는 다음 주 저녁 식사에 그 파이를 준비하고 싶다고 요청합니다. (_배포_) -비교해 보면, 독점 소스 과정은 식당에 가서 체리 파이 한 조각을 주문할 것입니다. 당신은 파이를 먹기 위해 수수료를 지불해야하며, 레스토랑은 아마도 당신에게 요리 방법을 알려주지 않을 것입니다. 만약 파이를 정확하게 복사하여 같은 이름으로 팔면, 레스토랑이 당신을 상대로 고소할 수도 있습니다. +비교해 보면, 독점 소스 과정은 레스토랑에 가서 체리 파이 한 조각을 주문할 것과 같습니다. 여러분은 파이를 먹기 위해 요금을 지불해야 하며 레스토랑은 아마 여러분에게 레시피를 알려주지 않을 것입니다. 만약 파이를 똑같이 베껴 여러분의 이름을 달고 판다면 레스토랑에서 여러분을 고소할 지도 모르죠. -### 왜 사람들은 자신의 작업을 오픈소스로 공개합니까? +### 왜 사람들은 자기 작업을 오픈소스로 공개하나요? -사람이나 조직이 프로젝트 소스를 공개하려는 데는 [여러 가지 이유](http://ben.balter.com/2015/11/23/why-open-source/)가 있습니다. 몇 가지 예는 다음과 같습니다: +사람이나 조직이 프로젝트 소스를 공개하려는 데에는 [여러 가지 이유](http://ben.balter.com/2015/11/23/why-open-source/)가 있습니다. 몇 가지 예는 다음과 같습니다. -* **협업:** 오픈소스 프로젝트는 전 세계 누구나 변화를 수용 할 수 있습니다. [Exercism](https://github.com/exercism/)를 예시로 들면, 350명이 넘는 기여자가 참여하는 프로그래밍 연습 플랫폼입니다. +* **협업:** 오픈소스 프로젝트는 전 세계 누구에게서든 수정을 받을 수 있습니다. 예를 들어 [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)라는 기존 프로젝트의 포크로 시작되었습니다. +* **채택과 재가공:** 오픈소스 프로젝트는 거의 모든 용도로 누구나 사용할 수 있습니다. 심지어 사람들이 그 프로젝트를 기반으로 다른 프로젝트를 만들 수도 있습니다. 예컨대 [WordPress](https://github.com/WordPress)는 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md)라는 기존 프로젝트의 포크로 시작했습니다. -* **투명도:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 또는 [미국](https://sourcecode.cio.gov/)과 같은 정부, 은행 또는 건강 관리와 같은 규제 대상 산업, Let's Encrypt와 같은 보안 소프트웨어와 관련이 있습니다. +* **투명성:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)나 [미국](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) 같은 정부, 은행 또는 의료 같은 규제 대상 산업, Let's Encrypt 등의 보안 소프트웨어에는 투명성이 중요합니다. -오픈소스는 소프트웨어만을 위한 것이 아닙니다. 데이터 세트에서부터 서적에 이르기까지 모두 오픈소스할 수 있습니다. [GitHub Explore](https://github.com/explore)에서 다른 오픈소스 아이디어를 확인하십시오. +오픈소스는 소프트웨어만을 위한 것이 아닙니다. 데이터 세트에서부터 서적에 이르기까지 모두 오픈소스로 만들 수 있습니다. [GitHub Explore](https://github.com/explore)에서 다른 오픈소스 아이디어를 확인해 보세요. -### 오픈소스는 "무료"를 의미합니까? +### 오픈소스는 "무료"를 의미하나요? -오픈소스의 가장 큰 매력 중 하나는 비용이 들지 않는다는 것입니다. 그러나 "무료 비용"은 오픈소스의 전반적인 가치의 부산물입니다. +오픈소스의 가장 큰 매력 중 하나는 비용이 들지 않는다는 것입니다. 그러나 "무료"는 오픈소스의 전반적인 가치의 부산물에 불과합니다. -[오픈소스 라이선스](https://opensource.org/osd-annotated)는 누구나 거의 모든 목적으로 프로젝트를 사용, 수정 및 공유 할 수 있어야 하므로 프로젝트 자체는 무료입니다. 만약 프로젝트에 사용할 비용이 들었다면, 누구나 합법적으로 복사본을 만들어 무료 버전을 사용할 수 있습니다. +[오픈소스 라이선스](https://opensource.org/osd-annotated)는 누구나 거의 모든 목적으로 프로젝트를 사용, 수정, 공유할 수 있어야 하므로 프로젝트 자체는 무료입니다. 만약 프로젝트에서 비용을 청구한다면 누구나 합법적으로 복사본을 만들어 무료 버전을 사용할 수 있습니다. -결과적으로 대부분의 오픈소스 프로젝트는 무료이지만, "무료"는 오픈소스 정의의 일부가 아닙니다. 오픈소스의 공식적인 정의를 계속 준수하면서 이중 라이선스 또는 제한된 기능을 통해 간접적으로 오픈소스 프로젝트를 청구할 수있는 방법이 있습니다. +결론적으로 대부분의 오픈소스 프로젝트는 무료이지만, "무료"는 오픈소스 정의의 일부가 아닙니다. 오픈소스의 공식적인 정의를 계속 준수하면서도 이중 라이선스 또는 제한된 기능을 통해 간접적으로 오픈소스 프로젝트 사용에 비용을 청구할 수 있는 방법이 있습니다. -## Should I launch my own open source project? +## 내 오픈소스 프로젝트를 시작해야 할까요? -짧은 결과는 예입니다. 결과에 관계없이, 자신의 프로젝트를 시작하는 것이 오픈소스의 작동 방식을 배우기위한 훌륭한 방법이기 때문입니다. +짧게 답하자면 그렇습니다. 결과가 어떻든 여러분 자신의 프로젝트를 시작하는 것이 오픈소스가 돌아가는 방식을 배우기 위한 훌륭한 방법이 되기 때문입니다. -이전에 프로젝트의 소스를 공개 한 적이 없다면, 다른 사람이 의견을 말하지 않거나 전혀 눈치채지 못할거라고 불안해 할 수 있습니다. 이게 당신의 이야기처럼 들린다면, 당신은 혼자가 아닙니다! +이전에 프로젝트 소스를 공개해본 적이 없다면 누군가 뭐라고 하거나 소스를 보는 것 자체가 긴장될지도 모릅니다. 이게 여러분의 이야기처럼 들리나요? 여러분은 혼자가 아닙니다! -오픈소스 작품은 글쓰기나 페인팅과 비슷한 다른 창의적인 활동과 같습니다. 전세계에 당신의 작품을 공유하는 것이 무섭다는 생각이 들지만, 청중이 없는 경우에도 연습하는 것이 유일한 방법입니다. +오픈소스 작업은 글을 쓰거나 그림을 그리는 활동과 같습니다. 여러분의 작업을 세상과 공유하기가 두려울 수도 있지만, 발전하는 방법은 연습 뿐입니다. 설령 봐주는 사람이 없더라도요. -아직 확신하지 못했다면, 잠시 시간을 내어 목표가 무엇인지 생각해보십시오. +아직 확신이 서지 않는다면 여러분의 목표가 무엇인지 잠시 생각해 보세요. ### 목표 설정하기 -목표는 어떤 일을 해야할 건지, 어떤 말을 하지 않을건지, 다른 사람들에게 도움이 필요한 곳을 파악하는 것에 도움이 될 수 있습니다. 스스로에게 물어보십시오, _왜 내가 이 프로젝트를 오픈 소스로 만들었습니까?_ +목표는 여러분이 무엇을 해야 하는지, 무엇을 하지 말아야 하는지, 어디서 도움을 받아야 하는지 찾는 데 도움이 될 수 있습니다. 먼저 왜 프로젝트를 오픈소스화하려고 하는지 자문해 보세요. -이 질문에 대한 정답은 아무도 없습니다. 한 프로젝트에 대해 여러 가지 목표를 가질 수도 있고, 다른 목표를 가진 다른 프로젝트를 가질 수도 있습니다. +이 질문에 대해 정해진 정답은 없습니다. 한 프로젝트에 대해 여러 가지 목표를 가질 수도 있고, 각기 다른 목표를 가진 여러 프로젝트를 진행할 수도 있습니다. -귀하의 유일한 목표가 귀하의 업무를 과시하는 것이라면, 귀하는 README에 기여를 원한다고 말할 수 없습니다. 다른 한편으로는, 기여자를 원한다면 명확한 문서화에 시간을 투자를 통해 신규 방문자가 환영받는다고 느끼게 될 것입니다. +여러분의 유일한 목표가 여러분의 성과를 보여주는 것이라면 기여를 원하지 않을 수도 있고 README 파일에 그렇게 적어둘 수도 있습니다. 반대로 기여자를 원한다면 명확한 문서화에 시간을 투자하고 방문자들을 환영해야 합니다. -프로젝트가 성장함에 따라 커뮤니티는 단순한 코드 그 이상을 필요로 할 수 있습니다. 이슈에 대응하고, 코드를 검토하고, 프로젝트를 홍보하는 것은 오픈소스 프로젝트에서 중요한 작업입니다. +프로젝트가 성장함에 따라 커뮤니티에는 단순한 코드 이상의 것이 필요할 수 있습니다. 이슈에 대응하고, 코드를 검토하고, 프로젝트를 홍보하는 것은 오픈소스 프로젝트에서 중요한 작업입니다. -비코딩 작업에 소요되는 시간은 프로젝트의 크기와 범위에 따라 다르지만, 직접 해결하거나 도움을 줄 담당자를 준비해야합니다. +코딩이 아닌 작업에 소요되는 시간은 프로젝트의 크기와 범위에 따라 다르지만, 여러분이 직접 관리자로서 문제를 해결하거나 도움을 줄 사람을 찾아야 합니다. -**만약 프로젝트를 오픈소스화하는 회사의 일원이라면,** 프로젝트가 번창하기 위해 필요한 내부 자원이 있는지 확인하십시오. 시작한 후에 프로젝트를 유지 관리 할 책임이 있는 사람과 해당 작업을 커뮤니티와 공유하는 방법을 식별해야합니다. +**만약 프로젝트를 오픈소스화하는 회사의 일원이라면** 프로젝트의 성공을 위해 필요한 내부 자원이 있는지 확인하세요. 공개 후 누가 프로젝트 관리 책임이 있는지, 어떻게 작업들을 커뮤니티와 공유할 것인지 파악하고 정해야 합니다. -홍보, 운영 및 프로젝트 유지를 위해 전담 예산이나 인력이 필요하다면 일찍 대화를 시작하십시오. +홍보, 운영 및 프로젝트 유지를 위해 전담 예산이나 인력이 필요한 경우 이런 대화를 조기에 시작하세요. ### 다른 프로젝트에 기여하기 -다른 사람들과 협력하거나 오픈소스가 어떻게 작동하는지 이해하는 방법을 배우는 것이 목표라면, 기존 프로젝트에 기여하는 것을 고려하십시오. 이미 사용하고 사랑하는 프로젝트부터 시작하십시오. 프로젝트에 기여하는 것은 오타를 수정하거나 문서를 업데이트하는 것만큼 간단합니다. +사람들과 협업하는 방법을 배우거나 오픈소스가 어떻게 돌아가는지 이해하는 것이 목표라면 기존 프로젝트에 기여하는 것을 고려해 보세요. 여러분이 이미 애용하고 있는 프로젝트에서부터 시작하세요. 오타를 수정하거나 문서를 업데이트하는 것처럼 간단한 것으로도 기여할 수 있습니다. -기여자로 시작하는 방법을 모르는 경우에는, [오픈소스에 기여하는 방법 가이드](../how-to-contribute/)를 확인하십시오. +기여를 시작하는 법을 잘 모르겠다면 [오픈소스에 기여하는 방법 가이드](../how-to-contribute/)를 확인해 보세요. -## Launching your own open source project +## 내 오픈소스 프로젝트 시작하기 -당신의 일을 오픈 소스화 할 완벽한 시간은 없습니다. 아이디어, 진행중인 작업 또는 독점 소스가 된 이후의 수년이 지난 뒤에도 오픈소스화 할 수 있습니다. +프로젝트를 오픈소스화할 정해진 타이밍은 없습니다. 아이디어, 진행중인 작업 혹은 수년이 지난 비공개 소스도 오픈소스화할 수 있습니다. -일반적으로 말하면, 다른 사람들이 보기에 편하게 느끼고 프로젝트에 대한 피드백을 주려면 프로젝트를 오픈소스화 해야합니다. +일반적으로 다른 사람이 여러분의 작업을 보고 피드백을 제공해도 불편할 만한 점이 없을 때 프로젝트를 오픈소스화하면 됩니다. -프로젝트를 오픈소스로 결정한 단계에 관계없이, 모든 프로젝트에는 다음과 같은 문서가 포함되어야합니다: +프로젝트를 오픈소스화하기로 결정한 시점에 상관없이 모든 프로젝트에는 다음과 같은 문서가 포함되어 있어야 합니다. * [오픈소스 라이선스](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](../code-of-conduct/) +* [행동 강령](../code-of-conduct/) -메인테이너는 이러한 구성 요소를 사용하여 기대를 전달하고, 기여를 관리하고, (자신의 권리를 포함한) 모든 사람의 법적 권리를 보호 할 수 있습니다. 그들은 긍정적인 경험을 가질 기회를 상당히 증가시킵니다. +관리자는 이러한 구성 요소로 기대치를 전달하고, 기여를 관리하고, (여러분을 포함한) 모두의 법적 권리를 보호할 수 있습니다. 위 문서들은 여러분이 긍정적인 경험을 하게 될 가능성을 크게 증가시킵니다. -프로젝트가 GitHub에 있는 경우, 권장 파일 이름을 사용하여 이러한 파일을 루트 디렉토리에 저장하면 GitHub에서 해당 파일을 인식하여 자동으로 사용자에게 보여줍니다. +프로젝트가 GitHub에 있는 경우, 권장 파일 이름을 적용해 이러한 파일들을 최상위 폴더에 저장해 두면 GitHub에서 해당 파일을 인식해 자동으로 사람들에게 보여줍니다. ### 라이선스 선택하기 -오픈소스 라이선스는 타인이 영향을 주지 않고 프로젝트에서 사용, 복사, 수정 및 기여할 수 있음을 보증합니다. 또한 복잡하게 얽혀있는 법적 상황으로부터 당신을 보호합니다. **오픈소스 프로젝트를 시작할 때 라이선스를 포함해야합니다.** +오픈소스 라이선스는 사람들이 여러분의 프로젝트에 영향을 주지 않고 사용, 복사, 수정 및 기여할 수 있도록 보장합니다. 또한 복잡하게 얽혀 있는 법적 상황으로부터 당신을 보호합니다. **오픈소스 프로젝트를 시작한다면 반드시 라이선스를 포함해야 합니다.** -법률 업무는 재미 없습니다. 좋은 소식은 기존 라이선스를 복사하여 저장소에 붙여 넣을 수 있다는 것입니다. 당신의 노력을 보호하는 데 단지 1분 정도만 소요됩니다. +법률에 관한 일은 즐겁지 않습니다. 좋은 소식은 기존 라이선스를 복사해 저장소에 붙여넣을 수 있다는 것입니다. 여러분의 노력을 보호하는 데 1분이면 충분할 것입니다. -[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)도 있습니다. +[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 프로젝트를 오픈소스로 만들 수 있습니다. +GitHub에서 새 프로젝트를 만들면 라이선스를 선택할 수 있는 옵션이 제공됩니다. 오픈소스 라이선스를 포함하면 GitHub 프로젝트를 오픈소스로 만들 수 있습니다. ![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) -만약 오픈소스 프로젝트를 관리하는 법적 측면에 대해 다른 질문이나 우려 사항이 있으시면, [이 내용은 귀하를 대상으로합니다](../legal/). +오픈소스 프로젝트 관리의 법적 측면에 대해 다른 질문이나 우려되는 점이 있다면 [이 내용을 참조하세요](../legal/). -### Writing a README +### README 파일 작성하기 -README는 프로젝트 사용 방법을 설명하는 것 이상을 수행합니다. 또한 프로젝트가 중요한 이유와 사용자가 수행 할 수 있는 작업에 대해 설명합니다. +README는 프로젝트 사용 방법을 설명하는 것 이상의 일을 수행합니다. 프로젝트가 중요한 이유와 사용자가 프로젝트를 이용해 할 수 있는 작업에 대해서도 설명합니다. -README에 다음 질문에 답하십시오: +README에서 다음 질문에 답해 보세요. -* 이 프로젝트는 무엇을 합니까? -* 이 프로젝트는 왜 유용합니까? -* 어떻게 시작합니까? -* 필요할 경우, 어디에서 더 많은 도움을 받을 수 있습니까? +* 이 프로젝트는 무슨 일을 하나요? +* 이 프로젝트가 유용한 이유는 무엇인가요? +* 어떻게 시작해야 하나요? +* 필요하다면 어디에서 더 많은 도움을 받을 수 있을까요? -README를 사용하여 기여를 처리하는 방법, 프로젝트의 목표가 무엇인지, 라이선스 및 속성에 대한 정보와 같은 다른 질문에 답할 수 있습니다. 기여를 받고 싶지 않거나, 프로젝트가 아직 준비되지 않은 경우에는 이 정보를 적어 두십시오. +README를 사용하여 여러분이 기여를 받아들이는 방식, 프로젝트의 목표, 라이선스 및 속성에 대한 정보와 같은 다른 질문에 답할 수 있습니다. 기여를 받고 싶지 않거나, 프로젝트가 아직 준비되지 않았다면 그렇게 적어 두세요. -때로는, 사람들이 프로젝트가 끝나지 않았거나 기부를 원치 않기 때문에 README를 쓰지 않는 경우가 있습니다. 이것은 모두 하나를 쓰는 아주 좋은 이유입니다. +때때로 사람들은 프로젝트가 완성되지 않았거나 기여를 원치 않기 때문에 README를 작성하지 않는 경우가 있습니다. 그것도 README를 작성할 좋은 이유입니다. -더 많은 영감을 얻으려면, @18F의 ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) 혹은 @PurpleBooth의 완전한 README를 작성하는[README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2)를 사용해보십시오. +@18F의 ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/)에서 더 많은 영감을 얻거나 @PurpleBooth의 [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2)을 이용해 전체 README를 작성해 보세요. -README 파일을 루트 디렉토리에 포함시키면, GitHub가 자동으로 저장소 홈페이지에 표시합니다. +README 파일을 최상위 폴더에 포함시키면, GitHub가 자동으로 저장소 홈페이지에 내용을 표시합니다. -### Writing your contributing guidelines +### 기여 가이드라인 작성하기 -CONTRIBUTING 파일은 잠재 고객에게 프로젝트 참여 방법을 알려줍니다. 예를 들어 다음 정보를 포함 할 수 있습니다: +CONTRIBUTING 파일은 잠재 기여자들에게 프로젝트에 기여하는 방법을 알려줍니다. 예를 들어 다음 정보를 포함할 수 있습니다. -* 버그 보고서를 제출하는 방법 ([이슈와 pull request 템플릿](https://github.com/blog/2111-issue-and-pull-request-templates)을 사용해보십시오) +* 버그 보고서를 제출하는 방법 ([이슈와 PR 템플릿](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](https://github.com/activeadmin/activeadmin/)은 다음과 같이 [기여 가이드](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)를 시작합니다. -> 먼저 Active Admin에 기여 해 주셔서 감사합니다. Active Admin을 훌륭한 도구로 만드는 것은 여러분과 같은 사람들입니다. +> 먼저, Active Admin에 기여해 주셔서 감사합니다. 여러분의 기여가 Active Admin을 이렇게 훌륭한 툴로 만듭니다. -프로젝트의 가장 초기 단계에서, CONTRIBUTING 파일을 간단하게 만들 수 있습니다. 버그 또는 파일 문제를 보고하는 방법과 (테스트에 필요한) 기술적 요구 사항을 항상 설명하여 기여를 해야합니다. +프로젝트의 초기 단계에서는 CONTRIBUTING 파일이 단순할 수 있습니다. 항상 버그 또는 파일 이슈를 보고하는 방법과 기여에 필요한 테스트 등 기술적 요구 사항을 설명해야 합니다. -시간이 지나면, 다른 자주 묻는 질문을 CONTRIBUTING 파일에 추가 할 수 있습니다. 이 정보를 적어두면 같은 질문을 반복해서 하는 사람들이 줄어들 것입니다. +시간이 지나면 자주 묻는 질문을 CONTRIBUTING 파일에 추가할 수 있습니다. 이 정보를 적어두면 같은 질문을 반복해서 하는 사람들이 줄어들 것입니다. -CONTRIBUTING 파일을 작성하는 데 도움이 필요하면, check out @nayafia의 [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) 혹은 @mozilla의 ["How to Build a CONTRIBUTING.md"](http://mozillascience.github.io/working-open-workshop/contributing/)를 보십시오. +CONTRIBUTING 파일을 작성하는 데 도움이 필요하면 @nayafia의 [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) 또는 @mozilla의 ["How to Build a CONTRIBUTING.md"](http://mozillascience.github.io/working-open-workshop/contributing/)을 참조하세요. -README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 볼 수 있습니다. 만약 당신이 [CONTRIBUTING 파일을 프로젝트의 저장소에 두면](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub는 참여자가 이슈를 생성하거나 pull request를 열면 자동으로 파일에 연결됩니다. +README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할 수 있습니다. [CONTRIBUTING 파일을 프로젝트의 저장소에 두면](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) 기여자가 이슈를 생성하거나 PR를 열 때 GitHub가 자동으로 링크를 생성합니다. ![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg) -### 행동강령 세우기 +### 행동 강령 세우기 -마지막으로, 행동강령은 프로젝트 참가자의 행동에 대한 기본 규칙을 설정하는 데 도움이 됩니다. 이는 커뮤니티나 회사를 위해 오픈소스 프로젝트를 시작하는 경우 특히 유용합니다. 행동강령은 건강하고 건설적인 커뮤니티 행동을 촉진하도록 권한을 부여하며, 이는 메인테이너로서의 스트레스를 감소시킵니다. +마지막으로 행동 강령은 프로젝트 참가자의 행동에 대한 기본 규칙을 정하는 데 도움이 됩니다. 이는 커뮤니티나 회사의 오픈소스 프로젝트를 시작할 때 특히 유용합니다. 행동 강령은 건강하고 건설적인 커뮤니티 행동을 촉진할 수 있게 해 주는데, 이는 관리자 여러분의 스트레스를 줄여줄 것입니다. -자세한 정보를 확인하려면, [행동강령 가이드](../code-of-conduct/)를 보십시오. +자세한 내용은 [행동강령 가이드](../code-of-conduct/)를 참조하세요. -행동강령은 참여자가 _어떻게_ 행동 할 것으로 기대하는지 의사 소통하는 것 외에도, 이러한 기대 사항이 적용되는 대상, 적용시기, 위반이 발생할 경우 수행 할 작업을 설명하는 경향이 있습니다. +행동 강령은 참여자가 _어떻게_ 행동하기를 기대하는지 전달하는 것 외에, 이러한 기대가 누구에게 적용되는지, 언제 적용되는지, 위반할 경우 어떻게 하는지 등을 다루기도 합니다. -오픈소스 라이선스와 마찬가지로 행동강령에 대한 새로운 기준도 있으므로, 사용자가 직접 작성할 필요는 없습니다. [Contributor Covenant](http://contributor-covenant.org/)는 Kubernetes, Rails 및 Swift를 포함하여 [40,000개 이상의 오픈소스 프로젝트](http://contributor-covenant.org/adopters/)에서 사용되는 행동 강령입니다. 어떤 텍스트를 사용하든 필요에 따라 행동강령을 시행 할 준비가 되어 있어야합니다. +오픈소스 라이선스와 마찬가지로 행동 강령에 대한 새로운 표준도 있으므로 직접 작성할 필요는 없습니다. [Contributor Covenant](https://www.contributor-covenant.org/)는 Kubernetes, Rails 및 Swift를 포함한 [40,000개 이상의 오픈소스 프로젝트](https://www.contributor-covenant.org/adopters)에서 사용되는 행동 강령입니다. 어느 것을 사용하든, 필요에 따라 행동 강령을 시행할 준비가 되어 있어야 합니다. -텍스트를 저장소의 CODE_OF_CONDUCT 파일에 직접 붙여 넣으십시오. 프로젝트의 루트 디렉토리에 파일을 보관하여 찾기 쉽도록 하고, README에서 링크를 연결하십시오. +행동 강령을 저장소의 CODE_OF_CONDUCT 파일에 직접 붙여넣으세요. 파일을 쉽게 찾을 수 있게 프로젝트 최상위 폴더에 저장하고 README에 링크를 첨부하세요. -## Naming and branding your project +## 프로젝트의 네이밍과 브랜딩 -브랜딩은 화려한 로고 또는 재미있는 프로젝트 이름 이상입니다. 그것은 당신의 프로젝트에 대해 어떻게 이야기하고, 당신의 메시지를 가지고 도달했는지에 관한 것입니다. +브랜딩은 화려한 로고나 매력적인 프로젝트 이름 그 이상입니다. 브랜딩은 여러분이 프로젝트를 어떻게 생각하는지, 누구에게 여러분의 메시지를 전달하고자 하는지에 대한 것입니다. -### 올바른 이름 고르기 +### 올바른 이름 짓기 -기억하기 쉬운 이름을 골라야하며, 이상적으로 프로젝트가 하는 일에 대한 아이디어를 제공하십시오. 예시입니다: +기억하기 쉬운 이름을 짓고 프로젝트가 어떤 일을 하는지 알 수 있게 하는 것이 이상적입니다. 아래의 예시를 보세요. -* [Sentry](https://github.com/getsentry/sentry)는 충돌보고를 위해 앱을 모니터링합니다 -* [Thin](https://github.com/macournoyer/thin)은 빠르고 간단한 Ruby 웹 서버입니다 +* [Sentry](https://github.com/getsentry/sentry)는 충돌 보고를 위해 앱을 모니터링합니다. +* [Thin](https://github.com/macournoyer/thin)은 빠르고 간단한 Ruby 웹 서버입니다. -기존 프로젝트를 기반으로 하는 경우, 그 이름을 접두사로 사용하면 프로젝트가 수행하는 작업을 분명히 알 수 있습니다 (예시. [node-fetch](https://github.com/bitinn/node-fetch)는 Node.js에서 `window.fetch`를 가져옵니다). +기존 프로젝트를 기반으로 하는 경우 그 이름을 접두사로 사용하면 프로젝트가 수행하는 작업을 쉽게 파악할 수 있습니다. 예컨대 [node-fetch](https://github.com/bitinn/node-fetch)는 `window.fetch`를 Node.js에 가져옵니다. -무엇보다 명확성을 고려하십시오. 농담은 재미 있지만, 일부 농담은 다른 문화나 다른 경험을 가진 사람들로 번역되지 않을 수도 있음을 기억하십시오. 잠재적인 사용자 중 일부는 회사 직원일 수 있습니다: 그들이 직장에서 당신의 프로젝트를 설명해야 할 때 불편하게 하고 싶지는 않습니다! +무엇보다 명확성을 고려하세요. 농담은 재미있지만, 어떤 농담은 다른 문화나 다른 경험을 가진 사람들에게는 이해되지 않을 수도 있음을 기억하세요. 잠재적인 사용자 중 일부는 회사 직원일 수 있습니다. 그들이 직장에서 여러분의 프로젝트를 설명하기 어렵게 만들고 싶지는 않을 것입니다! -### Avoiding name conflicts +### 이름 중복 피하기 -[비슷한 이름의 오픈소스 프로젝트가 있는지 확인하십시오](http://ivantomic.com/projects/ospnc/), 특히 동일한 언어 또는 같은 생태계를 공유하는 경우, 이름이 기존의 인기있는 프로젝트와 겹치면 잠재적인 고객을 혼동시킬 수 있습니다. +[비슷한 이름의 오픈소스 프로젝트가 있는지 확인하세요](http://ivantomic.com/projects/ospnc/). 특히 동일한 언어 또는 같은 생태계를 공유하는 경우, 이름이 기존의 인기 있는 프로젝트와 겹치면 사람들이 헷갈려 할 것입니다. -웹 사이트, Twitter 핸들 또는 프로젝트를 나타내는 다른 속성을 원하면 원하는 이름을 가져올 수 있는지 확인하십시오. 이상적으로는, 아직 사용하지 않으려는 경우에도 마음의 평화를 위해 [지금 해당 이름을 예약하십시오](https://instantdomainsearch.com/). +웹 사이트, Twitter 핸들 또는 다른 속성이 프로젝트를 표현하기를 원한다면 원하는 이름을 사용할 수 있는지 확인하세요. 이상적으로는, 그 이름을 아직 사용할 생각이 없더라도 마음의 평화를 위해 [이름을 차지해 두는 것이 좋습니다](https://instantdomainsearch.com/). -프로젝트 이름이 상표를 침해하지 않는지 확인하십시오. 회사는 나중에 프로젝트를 중단하거나, 법적 조치를 취할 것을 요구할 수 있습니다. 위험 부담이 되지 않습니다. +프로젝트 이름이 상표를 침해하지 않는지 확인하세요. 회사 측에서 프로젝트를 중단하거나 법적 조치를 취할 것을 요구할 수 있습니다. 리스크를 부담할 가치는 없습니다. -You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/). +[WIPO Global Brand Database](http://www.wipo.int/branddb/en/) 에서 상표명이 있는지 확인할 수 있습니다. 여러분이 회사에서 일을 하고 있다면 [법률팀이 도와줄 수 있을 것입니다](../legal/). -마지막으로, 프로젝트 이름에 대한 빠른 Google 검색을 수행하십시오. 사람들이 프로젝트를 쉽게 찾을 수 있습니까? 검색 결과에 표시하고 싶지 않은 것이 있습니까? +마지막으로, 프로젝트 이름을 구글에 검색해 보세요. 사람들이 프로젝트를 쉽게 찾을 수 있을까요? 검색 결과에 여러분이 원치 않는 것이 나타나지는 않나요? -### 당신이 쓰는 방법(그리고 코드)은 당신의 브랜드에도 영향을 미칩니다! +### 당신의 글(과 코드)도 브랜드에 영향을 미칩니다! -프로젝트가 진행되는 동안, 많은 글을 쓸 것입니다: README, 튜토리얼, 커뮤니티 문서, 이슈에 대한 회신, 뉴스레터 및 메일링 리스트 등. +프로젝트가 진행되는 동안 여러분은 README, 튜토리얼, 커뮤니티 문서, 이슈에 대한 답변, 뉴스레터 및 메일링 리스트까지 많은 글을 쓸 것입니다. -그것이 공식적인 문서이건 캐주얼 이메일이건, 당신의 작문 스타일은 프로젝트의 브랜드의 일부입니다. 잠재 고객에게 도달하는 방법과 전달하려는 톤인지 여부를 고려하십시오. +그것이 공식적인 문서든 평범한 이메일이든 여러분의 글 스타일은 프로젝트 브랜드의 일부입니다. 어떻게 청중에게 다가가야 좋을지, 여러분이 전달하고자 하는 어조는 무엇인지 고려하세요. -따뜻하고 포괄적인 언어 (예를 들어 한 사람을 언급 할 때도 "그들"과 같이)를 사용하면, 이 프로젝트가 새로운 참여자에게 환영받는 느낌을 줄 수 있습니다. 많은 독자가 원어민이 아니기 때문에 간단한 언어에 충실하십시오. +따뜻하고 포괄적인 언어(한 사람을 언급 할 때도 "그들"이라고 하듯)를 사용하면 이 프로젝트가 새로운 기여자에게 환영받는 느낌을 줄 수 있습니다. 많은 독자가 영어를 모국어로 사용하지 않을 수 있으므로 간단한 언어 사용에 충실하세요. -단어 작성 방법 이외에도, 코딩 스타일이 프로젝트 브랜드의 일부가 될 수도 있습니다. [Angular](https://github.com/johnpapa/angular-styleguide)와 [jQuery](http://contribute.jquery.org/style-guide/js/)는 엄격한 코딩 스타일과 가이드 라인을 가진 프로젝트의 두 가지 예시입니다. +작문 스타일 뿐 아니라 코딩 스타일도 프로젝트 브랜드의 일부가 될 수 있습니다. [Angular](https://github.com/johnpapa/angular-styleguide)와 [jQuery](http://contribute.jquery.org/style-guide/js/)는 엄격한 코딩 스타일과 가이드라인을 가진 프로젝트의 두 가지 예입니다. -프로젝트를 시작할 때 스타일 가이드를 작성할 필요가 없으며, 어쨌든 다른 코딩 스타일을 프로젝트에 통합하는 것을 즐긴다는 것을 알 수 있습니다. 그러나 글쓰기와 코딩 스타일이 다른 유형의 사람들을 끌어 모으거나 방해 할 수있는 방법을 예상해야합니다. 프로젝트의 가장 초기 단계는 보고자하는 선례를 설정할 기회입니다. +프로젝트를 시작할 때 스타일 가이드를 작성할 필요는 없으며, 여러분은 오히려 프로젝트에 여러 코딩 스타일이 혼재하는 것을 좋아할 수도 있습니다. 하지만 글과 코딩 스타일이 서로 다른 유형의 사람들을 끌어모으거나 단념시킬 수도 있다는 점을 예상해야 합니다. 프로젝트의 가장 초기 단계는 여러분이 원하는 선례를 만들 기회입니다. -## Your pre-launch checklist +## 오픈소스 준비 체크리스트 -프로젝트를 오픈소스로 할 준비가 되셨습니까? 다음은 도움이 되는 체크리스트입니다. 모든 체크박스를 확인하시겠습니까? 이제 갈 준비가 되었습니다! ["공개"를 클릭](https://help.github.com/articles/making-a-private-repository-public/)하고 등 뒤에서 몸을 담그십시오. +프로젝트를 오픈소스화할 준비가 되셨습니까? 다음은 도움이 되는 체크리스트입니다. 모든 칸에 체크하셨나요? 이제 출발할 준비가 되었습니다! ["공개"를 클릭](https://help.github.com/articles/making-a-private-repository-public/)하고 등을 토닥이세요. **문서**
@@ -305,65 +299,65 @@ You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/)
**사람** -개인의 경우: +여러분이 개인이라면 아래를 확인하세요.
-만약 회사나 조직일 경우: +여러분이 회사나 조직이라면 아래를 확인하세요.
-## You did it! +## 해냈어요! -첫번째 프로젝트를 오픈소스화한 것을 축하합니다. 결과에 관계없이 공개적으로 일하는 것은 공동체에 대한 선물입니다. 모든 커밋, 설명 및 pull request을 풀어 쓰면, 자신과 다른 사람들이 배우고 성장할 수 있는 기회가 만들어집니다. +첫번째 프로젝트를 오픈소스화한 것을 축하합니다. 결과가 어떻든 공개적으로 작업하는 것은 커뮤니티에게 좋은 선물입니다. 모든 커밋, 댓글, PR을 통해 여러분은 여러분 스스로와 다른 사람들이 배우고 성장할 기회를 창출하고 있습니다. diff --git a/_articles/leadership-and-governance.md b/_articles/leadership-and-governance.md index e278526cc0f..0274e9a99c2 100644 --- a/_articles/leadership-and-governance.md +++ b/_articles/leadership-and-governance.md @@ -3,14 +3,6 @@ lang: en title: Leadership and Governance description: Growing open source projects can benefit from formal rules for making decisions. class: leadership -toc: - what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?" - how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?" - when-should-i-give-someone-commit-access: "When should I give someone commit access?" - what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?" - do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?" - what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?" - do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?" order: 6 image: /assets/images/cards/leadership.png related: @@ -71,11 +63,11 @@ If your project has a very active contributor community, you might form a "core -Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs). +Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md. @@ -105,15 +97,15 @@ There are three common governance structures associated with open source project * **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category. -* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](http://www.apache.org/); [all Apache projects](http://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company. +* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company. -* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://nodejs.org/en/foundation/) and [Rust](https://www.rust-lang.org/en-US/). +* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates: * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) -* [Node.js's liberal contribution policy](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) ## Do I need governance docs when I launch my project? @@ -133,7 +125,7 @@ If you're part of a company launching an open source project, it's worth having ## What happens if corporate employees start submitting contributions? -Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering. +Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams tied to the project. For example, a company may use the project's code as one component in a commercial service offering. As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project. @@ -151,14 +143,14 @@ For example, if you want to create a commercial business, you'll want to set up If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US). -Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. +Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. -If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://nodejs.org/en/foundation/) helps support [Express.js](https://expressjs.com/), a Node-based framework. +If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. diff --git a/_articles/legal.md b/_articles/legal.md index cb4f018463d..579b54a19cb 100644 --- a/_articles/legal.md +++ b/_articles/legal.md @@ -3,14 +3,6 @@ lang: en title: The Legal Side of Open Source description: Everything you've ever wondered about the legal side of open source, and a few things you didn't. class: legal -toc: - why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?" - are-public-github-projects-open-source: "Are public GitHub projects open source?" - just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project" - which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?" - what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?" - does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?" - what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?" order: 10 image: /assets/images/cards/legal.png related: @@ -20,7 +12,7 @@ related: ## Understanding the legal implications of open source -Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).) +Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).) ## Why do people care so much about the legal side of open source? @@ -28,9 +20,9 @@ Glad you asked! When you make a creative work (such as writing, graphics, or cod In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. -Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions. +Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license. -If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you. +These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions. Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. @@ -40,7 +32,7 @@ When you [create a new project](https://help.github.com/articles/creating-a-new- ![Create repository](/assets/images/legal/repo-create-name.png) -**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership), which allows others to view and fork your project, but your work otherwise comes with no permissions. +**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. @@ -48,7 +40,7 @@ If you want others to use, distribute, modify, or contribute back to your projec You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project. -[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). @@ -62,21 +54,26 @@ When you create a new project on GitHub, you'll be [asked to add a license](http ## Which open source license is appropriate for my project? -If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. +It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. Otherwise, picking the right open source license for your project depends on your objectives. -Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. +Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). -On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. +Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want. +Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify. + +Dependencies with **source-available licenses**, such as the Business Source License [BSL](https://spdx.org/licenses/BUSL-1.1.html) or the Server Side Public License [SSPL](https://en.wikipedia.org/wiki/Server_Side_Public_License), may appear to be under open source licenses but come with usage and business model restrictions. These restrictions may prevent your project from being considered Open Source as defined by the [Open Source Initiative (OSI)](https://opensource.org/). + +Projects often rely on **non-source code content**, such as images, icons, videos, fonts, data files, or other materials, which are governed by their own licenses. As with traditional software dependencies, the licenses these materials range from Commercial to permissive to Copyleft. The [Creative Commons](https://creativecommons.org/share-your-work/cclicenses/), a non-profit organization, created a series of licenses popular for non-source content. Creative Commons licenses range from very permissive [CC0](https://creativecommons.org/publicdomain/zero/1.0/deed.en) to Permissive [CC-BY](https://creativecommons.org/licenses/by/4.0/deed.en) to copyleft [CC-SA](https://creativecommons.org/licenses/by-sa/2.0/deed.en). They also can sometimes restrict commercial use by adding a non-commercial (NC) option to these licenses. You may also want to consider the **communities** you hope will use and contribute to your project: -* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/npm). -* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. +* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). +* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. * **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. -Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know). +Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance. When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). @@ -84,19 +81,19 @@ When you create a new project on GitHub, you are given the option to select a li Most projects never need to change licenses. But occasionally circumstances change. -For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing a your project's license: +For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license: -**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! +**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! **Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. -**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. +**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. -Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. +Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. ## Does my project need an additional contributor agreement? -Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license). +Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. @@ -106,15 +103,16 @@ Also, by adding "paperwork" that some believe is unnecessary, hard to understand avatar We have eliminated the CLA for Node.js. Doing this lowers the barrier to entry for Node.js contributors thereby broadening the contributor base.

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

Some situations where you may want to consider an additional contributor agreement for your project include: -* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. For some projects, a [Developer Certificate of Origin](https://github.com/probot/dco) can be an alternative. +* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. +* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). * Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. -* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. +* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example of this type of agreement. * You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. @@ -127,32 +125,35 @@ For better or worse, consider letting them know even if it's a personal project. **If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: -* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. +* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. * **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. -* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). +* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)). * **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. * **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. +* **AI:** As AI models and functionality become integral to software, it is crucial to understand licensing agreements and relevant legislation controlling their use. Even when a model or service claims to be under a standard open source license, additional terms may impose restrictions, such as preventing abuse or fraud. New legislation is also putting restrictions on the types of systems or actions that can be performed by AI-based software. +* **Software Bill of Materials:** A Software Bill of Materials (SBOM) is a comprehensive list of third-party dependencies, versions, associated licenses, and other metadata. SBOMs are legally mandated in certain countries, industries, or due to contractual obligations. A request for a SBOM often starts the license compliance journey for an organization. + If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: -* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). +* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/). * **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts. -* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program) can prevent headaches, product delays, and lawsuits. +* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. @@ -49,9 +36,9 @@ By comparison, a closed source process would be going to a restaurant and orderi * **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. @@ -59,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. @@ -75,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. @@ -85,7 +72,7 @@ If your only goal is to show off your work, you may not even want contributions, avatar At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.

-— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576#.zhwo5krlq) +— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)

@@ -101,7 +88,7 @@ If you need a dedicated budget or staffing for promotion, operations and maintai avatar As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.

-— @captainsafia, ["So you wanna open source a project, eh?"](https://writing.safia.rocks/2016/12/06/so-you-wanna-open-source-a-project-eh/) +— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)

@@ -156,16 +143,16 @@ In your README, try to answer the following questions: You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down. Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one. -For more inspiration, try using @18F's ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. +For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. When you include a README file in the root directory, GitHub will automatically display it on the repository homepage. @@ -185,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. @@ -193,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. @@ -205,7 +192,7 @@ Link to your CONTRIBUTING file from your README, so more people see it. If you [ avatar We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.

-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f#.v4qhl7t7v) +— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)

@@ -215,7 +202,7 @@ For more information, check out our [Code of Conduct guide](../code-of-conduct/) In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs. -Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](http://contributor-covenant.org/adopters/), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. +Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README. @@ -236,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. @@ -256,13 +243,13 @@ 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"](http://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)

Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers. -Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://github.com/johnpapa/angular-styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. +Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. 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 new file mode 100644 index 00000000000..c41c8e01805 --- /dev/null +++ b/_articles/ta/best-practices.md @@ -0,0 +1,276 @@ +--- +lang: ta +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 மணிநேரம் மட்டுமே செலவிடுகிறோம்"_) + +[ஜெகில்](https://github.com/jekyll/jekyll/tree/master/docs), [கோகோபாட்ஸ்](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), மற்றும் [ஹோம்புருவ்](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) பராமரிப்பாளர்களுக்கும் பங்களிப்பாளர்களுக்கும் தரவின் விதிகள் கொண்ட பல திட்டங்களுக்கான உதாரணங்கள். + +### கருத்துப்பரிமாற்றத்தை பொதுவில் வைக்கவும் + +உங்கள் கருத்துப்பரிமாற்றத்தை ஆவணப்படுத்த மறக்காதீர்கள். முடிந்தவரை திட்டப்பணி குறித்த கருத்துப்பரிமாற்றங்களை பொதுவில் வைக்கவும். ஒரு அம்ச கோரிக்கையை அல்லது ஆதரவு தேவை பற்றி விவாதிக்க தனிப்பட்ட முறையில் உங்களைத் தொடர்பு கொள்ள முயற்சித்தால், ஒரு அஞ்சல் முகவரி அல்லது சிக்கல் தடமி போன்ற பொதுத் தொடர்புத் தலையீட்டை அவர்களை அமைதியாக வழிநடத்துகிறது. + +நீங்கள் மற்ற பராமரிப்பாளர்களுடன் சந்தித்தால், அல்லது தனிப்பட்ட முறையில் ஒரு பெரிய முடிவை எடுத்தால், உங்கள் உரையை இடுகையிடும் போதும், இந்த உரையாடல்களை பொதுவில் ஆவணப்படுத்துங்கள். + +அவ்வாறே, உங்கள் சமூகத்தில் சேருகின்ற எவருக்கும் பல வருடங்களாக இருக்கின்றவருக்கு கிடைத்த அதே தகவலை அணுக முடியும். + +## இல்லை என சொல்ல கற்றல் + +நீங்கள் விஷயங்களை எழுதிவிட்டீர்கள். பெரும்பாலும், எல்லோரும் உங்கள் ஆவணங்கள் படிக்க வேண்டும், ஆனால் உண்மையில், நீங்கள் இந்த அறிவு உள்ளது என்று மற்றவர்களுக்கு ஞாபகப்படுத்த வேண்டும். + +எவ்வாறாயினும், உங்கள் விதிகளை நடைமுறைப்படுத்த வேண்டிய அவசியம் ஏற்பட்டால், சூழ்நிலைகளைத் தனிமைப்படுத்த உதவுகிறது. + +இல்லை என்று சொல்வது எளிதானது இல்லை, ஆனால் _"உங்கள் பங்களிப்பு இந்த திட்டத்தின் அளவுகோல்களுடன் பொருந்தவில்லை"_ என்பது _"உங்கள் பங்களிப்பு எனக்கு பிடிக்கவில்லை"_ என்பதைவிட தனிப்பட்டமுறையில் இல்லாமல் உள்ளது. + +ஒரு பராமரிப்பாளராக இல்லை என கூறும் பல சூழ்நிலைகளை நீங்கள் எதிர்கொள்வீர்கள்: நோக்கம் பொருந்தாத அம்ச கோரிக்கைகள், ஒருவர் கலந்துரையாடலைத் தடம்புரள செய்தல், மற்றவர்களுக்கு தேவையற்ற வேலையைச் செய்வது. + +### உரையாடலை நட்புணர்வுடன் வைத்துக் கொள்ளுங்கள் + +இடுவு மற்றும் இழு கோரிக்கை வரிசை ஆகியவை இல்லை என சொல்ல வேண்டிய இடங்களில் முக்கியமானவையாகும். ஒரு திட்ட பராமரிப்பாளராக, நீங்கள் தவிர்க்க விரும்பாத பரிந்துரைகளை பெறுவீர்கள். + +பங்களிப்பு உங்கள் திட்டத்தின் நோக்கத்தை மாற்றுகிறது அல்லது உங்கள் பார்வைக்கு பொருந்தவில்லை. ஒருவேளை நல்ல யோசனை, ஆனால் செயல்படுத்துதலில் சரியின்மை. + +காரணம் எதுவாயினும், உங்கள் திட்டத்தின் தரத்தைச் சந்திக்காத பங்களிப்புகளை சமாளிப்பதற்கு இது சாத்தியமாகும். + +நீங்கள் ஏற்றுக்கொள்ள விரும்பாத பங்களிப்பைப் பெற்றால், உங்கள் முதல் பிரதிபலிப்பு அதை புறக்கணிக்கலாம் அல்லது நீங்கள் அதைப் பார்க்கவில்லை என்று பாசாங்கு செய்யலாம். அவ்வாறு செய்வது மற்றவரின் உணர்ச்சிகளை காயப்படுத்தி, உங்கள் சமூகத்தின் பிற முக்கிய பங்களிப்பாளர்களைத் தடுக்கலாம். + + + +நீங்கள் தேவையற்ற பங்களிப்பை மூடுவதற்காக வருத்தம் கொள்ள தேவையில்லை. காலப்போக்கில், உங்கள் திட்டத்தில் பதிலளிக்கப்படாத இடுவுகள் மற்றும் இழு கோரிக்கைகள் மனஅழுத்தத்தையும், அச்சுறுத்தலையும் அதிகரிக்கிறது. + +நீங்கள் ஏற்க விரும்பாத பங்களிப்புகளை உடனடியாக மூடிவிடுதல் நல்லது. உங்கள் திட்டத்தில் ஏற்கனவே வேலைகள் நிறைய இருந்தால், [திறம்பட சிக்கல்களை எவ்வாறு தீர்க்க முடியும்](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) @steveklabnik சொல்லும் சில பரிந்துரைகள். + +இரண்டாவதாக, பங்களிப்புகளை புறக்கணிப்பது உங்கள் சமூகத்திற்கு ஒரு எதிர்மறை சமிக்ஞையை அனுப்புகிறது. ஒரு திட்டத்திற்கு பங்களிப்பது அச்சுறுத்தலாக இருக்கலாம், குறிப்பாக ஒருவரின் முதல் முறை. நீங்கள் அவர்களின் பங்களிப்பை ஏற்றுக் கொள்ளாவிட்டாலும், அதன் பின்னால் உள்ள நபரிடம் ஒப்புக்கொள்வதோடு, அவர்களின் ஆர்வத்திற்கு நன்றி தெரிவிக்கவும். இது ஒரு பெரிய பாராட்டு! + +பங்களிப்பை ஏற்றுக்கொள்ள விரும்பவில்லை எனில்: + +* **நன்றி சொல்லுங்கள்** அவர்களின் பங்களிப்புக்காக +* **திட்டத்தின் வரம்பிற்குள் ஏன் இது பொருந்தாது** என்பதை விளக்கவும், முன்னேற்றத்துக்கான தெளிவான பரிந்துரைகளை வழங்கவும். பரிவுடன் அதே சமயம் உறுதியுடன் இருங்கள். +* **தொடர்புடைய ஆவணங்களுடன் இணையுங்கள்**, உங்களிடம் இருந்தால். நீங்கள் ஏற்றுக்கொள்ள விரும்பாத விடயங்களுக்கு மீண்டும் மீண்டும் கோரிக்கைகளை நீங்கள் கண்டால், தவிர்க்கவேண்டிய ஆவணத்தில் அவற்றைச் சேர்க்கவும். +* **கோரிக்கையை மூடவும்** + +நீங்கள் பதிலளிப்பதற்கு 1-2 க்கும் மேற்பட்ட வாக்கியங்கள் தேவையில்லை. உதாரணமாக, [செலரியின்](https://github.com/celery/celery/) ஒரு பயனரின் விண்டோஸ் தொடர்பான பிழை அறிக்கைக்கு, @berkerpeksag [மறு மொழி](https://github.com/celery/celery/issues/3383): + +![Celery screenshot](/assets/images/best-practices/celery.png) + +இல்லை என கூறுவதற்கு அச்சமிருந்தால், நீங்கள் மட்டும் தனித்து இல்லை. @jessfraz [கூறுவதுபோல்](https://blog.jessfraz.com/post/the-art-of-closing/): + +> பல திறந்த மூல திட்டங்கள், மெசோஸ், குபெர்னிஸ், குரோமியம் ஆகியவற்றின் பராமரிப்பாளர்களிடம் நான் பேசியபோது, அவர்கள் அனைவருக்கும் நீங்கள் விரும்பாத இணைப்புகளை "இல்லை" என்று கூறுவது ஒரு பராமரிப்பாளரின் கடினமான பகுதிகளில் ஒன்று என்று ஓப்புக்கொண்டனர். + +ஒருவரின் பங்களிப்பை ஏற்றுக்கொள்ள விரும்பாதது பற்றி குற்றவுணர்வு கொள்ளவேண்டிய அவசியமில்லை. திறந்த மூலத்தின் முதல் விதி, @shykes [கூற்றுப்படி](https://twitter.com/solomonstre/status/715277134978113536) : _"இல்லை என்பது தற்காலிகம், ஆம் என்பது நிரந்தரம்."_ மற்றொரு நபரின் உற்சாகத்துடன் சமரசம் செய்வது ஒரு நல்ல விஷயம், ஒரு பங்களிப்பை நிராகரிப்பது என்பது பின்னால் உள்ள நபரை நிராகரிப்பது போலவே அல்ல. + +இறுதியில், ஒரு பங்களிப்பு போதுமானதாக இல்லையென்றால், அதை ஏற்றுக்கொள்வதற்கான எந்த கடமையும் இல்லை. உங்கள் திட்டத்தில் மக்கள் பங்களிக்கும் போது, தயவுசெய்து பதிலளிக்கவும், ஆனால் நீங்கள் உண்மையிலேயே நம்பும் மாற்றங்களை ஏற்கவும். இல்லை என அடிக்கடி சொல்வதால், அது எளிமையாகிறது. உண்மை. + +### செயல்திறனுடன் இருங்கள் + +முதல் இடத்தில் தேவையற்ற பங்களிப்புகளின் அளவு குறைக்க, உங்கள் பங்களிப்பு செயல்முறை உங்கள் பங்களிப்பு வழிகாட்டி பங்களிப்புகளை சமர்ப்பிக்கும் மற்றும் ஏற்றுக்கொள்வதையும் விளக்கவும். + +பல குறைந்த தரவரிசை பங்களிப்புகளைப் பெறுகிறீர்கள் என்றால், பங்களிப்பாளர்கள் பணிபுரியும் பணி செய்யும்முன் செய்யவேண்டியவைகளில் சில உள்ளன. உதாரணமாக: + +* ஒரு இடுவு அல்லது இழு கோரிக்கை வார்ப்புரு/பட்டியல் நிரப்புக +* ஒரு இழு கோரிக்கை சமர்ப்பிக்கும் முன் ஒரு இடுவு திறக்கவும் + +அவர்கள் உங்கள் விதிகள் பின்பற்றவில்லை என்றால், உடனடியாக இடுவை மூடிவிட்டு உங்கள் ஆவணத்தை சுட்டிக்காட்டவும். + +இந்த அணுகுமுறை முதலில் தவறாக உணரக்கூடும் என்றாலும், இரு கட்சிகளுக்கும் நன்மை பயக்கும். நீங்கள் ஏற்கெனவே பல மணிநேரம் வீணடிக்கப்பட்ட வேலைகளில் ஒருவரை இழுக்க வேண்டுமென்ற வாய்ப்பு குறைகிறது. அது உங்கள் பணிச்சுமையை எளிதாக நிர்வகிக்க உதவுகிறது. + + + +சில நேரங்களில், நீங்கள் இல்லை என சொல்லும்போது, உங்கள் பங்களிப்பாளருக்கு வருத்தமளிக்கலாம் அல்லது உங்கள் முடிவை விமர்சிக்கலாம். அவர்களின் நடத்தை விரோதமானது என்றால், [நிலைமையைத் தணிப்பதற்கான நடவடிக்கைகளை எடுக்கவும்](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) அல்லது ஆக்கபூர்வமாக ஒத்துழைக்க தயாராக இல்லை என்றால் அவர்களை உங்கள் சமூகத்திலிருந்து நீக்கவும். + +### வழிகாட்டுதலை அரவணையுங்கள் + +ஒருவேளை உங்கள் சமூகத்தில் உள்ளவர்கள் உங்கள் திட்டத்தின் தரத்தைச் சந்திக்காத பங்களிப்பைச் சமர்ப்பிக்கலாம். நிரந்தரமாக நிராகரிக்கப்படுவதன் மூலம் இரு கட்சிகளுக்கும் ஏமாற்றமளிக்கலாம். + +உங்கள் திட்டத்தை யாராவது ஆர்வத்துடன் பார்க்கிறார்களோ, ஆனால் சிறிது மெருகூற்றல் தேவைப்படுவதால், பொறுமையாக இருங்கள். ஒவ்வொரு சூழ்நிலையிலும் அவர்களின் பங்களிப்புகள் திட்டத்தின் எதிர்பார்ப்புகளை ஏன் பூர்த்தி செய்யவில்லை என்பதை தெளிவாக விளக்குங்கள். எளிமையான அல்லது குறைவான தெளிவற்ற பணியை சுட்டிக்காட்டும் முயற்சியில், "நல்ல முதல் பிழை" என்ற பெயரில், அவர்களுக்கு நல்ல தொடக்கத்தை ஊக்கப்படுத்தவேண்டும். உங்களிடம் நேரம் இருந்தால், அவர்கள் முதல் பங்களிப்பு மூலம் அவர்களை வழிகாட்டுதல், அல்லது உங்கள் சமூகத்தில் வழிகாட்ட வேறு யாரையேனும் ஒருவரை கண்டுபிடியுங்கள். + +## உங்கள் சமூகத்தை ஊக்குவிக்கவும் + +நீங்களே எல்லாவற்றையும் செய்ய வேண்டியதில்லை. உங்கள் திட்டத்தின் சமூகம் ஒரு காரணத்திற்காக உள்ளது! செயல்படும் பங்களிப்பாளர்களைக் கொண்டிராவிட்டாலும் கூட, நிறைய பயனர்கள் இருந்தால், அவர்களை கொண்டு வேலை செய்யுங்கள். + +### பணிச்சுமையை பகிர்ந்து கொள்ளுங்கள் + +நீங்கள் அடுத்தவர்கள் பங்களிக்க விரும்பினால், அவர்களிடம் உதவியை கேட்கவும். + +புதிய பங்களிப்பாளர்கள் மீண்டும் மீண்டும் பங்களிப்பதை நீங்கள் காணும்போது, அதிக பொறுப்புகளை வழங்குவதன் மூலம் அவர்களின் வேலைகளை அங்கீகரியுங்கள். மற்றவர்கள் தலைமைத்துவ பாத்திரங்களாக வர விரும்பினால், எவ்வாறு வளரலாம் என்பதை ஆவணப்படுத்தவும். + +[திட்டப்பணியின் முதலாளுமையை பகிர](../building-community/#share-ownership-of-your-project) அடுத்தவர்களை ஊக்கப்படுத்துவத்தின் மூலம் உங்கள் சொந்த பணிச்சுமையை பெரிதும் குறைக்க முடியும், என @lmccart தனது திட்டப்பணியில் கண்டறிந்தார், [p5.js](https://github.com/processing/p5.js?files=1). + + + +நீங்கள் உங்கள் திட்டத்திலிருந்து தற்காலிகமாகவோ அல்லது நிரந்தரமாக விலக வேண்டியிருந்தால், வேறு யாரிடமேனும் உங்கள் திட்டத்தை எடுத்துக்கொள்ளுமாறு கேட்டுக்கொள்வதில் எந்த வருத்தமும் கொள்ள தேவையில்லை. + +மற்றவர்கள் அதன் திசையைப் பற்றி ஆர்வத்துடன் இருந்தால், அவர்களுக்கு அணுகல் வழங்க அல்லது அதிகாரப்பூர்வமாக மற்றவர்களிடம் கட்டுப்பாட்டை ஒப்படைக்கவும். யாராவது உங்கள் திட்டத்தின் கிளையை, வேறு எங்காவது பராமரித்து வந்தால், உங்கள் அசல் திட்டத்திடமிருந்து பிணைப்பை இணைக்கவும். பல மக்கள் உங்கள் திட்டம் வாழ வேண்டும் என எண்ணுவது பெரிய விஷயம்! + +@progrium திட்டத்தின் நோக்கை ஆவணப்படுத்திருந்ததால், அவர் திட்டத்தில் இருந்து விலகி பின்னர் கூட [Dokku](https://github.com/dokku/dokku) அந்த இலக்குகளை வாழ உதவியது என [கண்டறிந்தார்](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) + +> நான் விரும்பியதை விவரிக்கும் ஒரு விக்கி பக்கத்தையும் நான் ஏன் விரும்பினேன் என்றும் எழுதினேன். சில காரணங்களால், பராமரிப்பாளர்கள் அந்த திசையில் திட்டத்தை நகர்த்தியதில் எனக்கு ஆச்சரியமாக இருந்தது! அது நான் நகர்த்துவதை போல இருந்ததா? எல்லா நேரத்திலும் இல்லை. ஆனால் நான் எழுதியதை நோக்கி திட்டத்தை கொண்டு சென்றது. + +### மற்றவர்களுக்குத் தேவையான தீர்வுகளை உருவாக்கவும் + +உங்களுடைய திட்டம் என்ன செய்ய வேண்டும் என்பதைப் பொறுத்து ஒரு பங்களிப்பாளருக்கு வித்தியாசமான அபிப்ராயம் இருந்தால், அவர்கள் தங்கள் சொந்த கிளையில் வேலை செய்ய மெதுவாக ஊக்குவிக்க வேண்டும். + +ஒரு திட்டத்தை நகலெடுப்பது ஒரு கெட்ட காரியம் அல்ல. திட்டங்களை நகலெடுத்து மாற்றியமைப்பது திறந்த மூலத்தில் உள்ள விஷயங்களில் ஒன்றாகும். உங்கள் சமூக உறுப்பினர்கள் தங்கள் சொந்த கிளையில் வேலை செய்ய ஊக்குவிப்பார்கள், உங்கள் திட்டத்தின் பார்வைக்கு முரணாக இல்லாமல், அவர்கள் தேவைப்படும் படைப்புக்கு வெளிச் செல்லும் வழியை வழங்க முடியும். + + + +அதேபோல், இது உங்களுக்கு அலைக்கற்றை இல்லாத பொழுது உங்கள் தீர்வை உண்மையில் விரும்பும் ஒரு பயனருக்கு இது பொருந்தும். APIகள் மற்றும் தனிப்பயனாக்குதல் கொக்கிகள் வழங்குவதன் மூலம், மற்றவர்கள் தங்கள் சொந்த தேவைகளை பூர்த்தி செய்ய முடியும், மூலத்தை நேரடியாக மாற்றியமைக்க முடியாது. கோகோபாட்களுக்கான கூடுதல் ஊக்குவிப்புகளை "மிகவும் சுவாரஸ்யமான சில கருத்துக்களுக்கு" வழிவகுத்தது என்று @orta [கண்டறிந்தார்](https://artsy.github.io/blog/2016/07/03/handling-big-projects/): + +> ஒரு திட்டம் பெரியதாகிவிட்டால், அவை புதிய குறியீட்டை அறிமுகப்படுத்துவது பற்றி மிகவும் பழமைவாதமாக இருக்க வேண்டும் என்பது கிட்டத்தட்ட தவிர்க்க முடியாதது. நீங்கள் "இல்லை" என்று சொல்வது நல்லது, ஆனால் நிறைய பேர் சட்டப்பூர்வ தேவைகளை கொண்டிருக்கிறார்கள். எனவே, அதற்கு பதிலாக நீங்கள் ஒரு கருவியாக உங்கள் மேடையாக மாற்ற முடிகிறது. + +## தானியங்கு பொறிகளை கொண்டு வாருங்கள் + +மற்றவர்கள் உங்களுக்கு உதவக்கூடிய பணிகளைச் செய்வது போலவே, எந்தவொரு மனிதனும் செய்ய வேண்டாத பணிகளும் உள்ளன. தானியங்கு பொறிகள் உங்கள் நண்பர்களே. ஒரு பராமரிப்பாளராக உங்கள் வாழ்வை எளிதாக்குவதற்கு அவற்றைப் பயன்படுத்துங்கள். + +### உங்கள் குறியீட்டின் தரத்தை மேம்படுத்துவதற்கு சோதனைகள் மற்றும் பிற சரிபார்ப்பு முறைகள் தேவை + +சோதனைகளை சேர்ப்பதன் மூலம் நீங்கள் உங்கள் திட்டத்தை தானியங்க செய்யக்கூடிய மிக முக்கியமான வழிகளில் ஒன்றாகும். + +சோதனைகள், பங்களிப்பாளர்களுக்கு அவர்கள் எதையும் உடைக்க மாட்டார்கள் என்று நம்பிக்கையை தருகிறது. விரைவாக பங்களிப்புகளை மதிப்பாய்வு செய்து ஏற்றுக்கொள்வதற்கும் அவை எளிதாக்குகின்றன. நீங்கள் துரிதமாக பதிலளிக்கிறீர்கள் என்றால், உங்கள் சமுதாயத்தை இன்னும் அதிகமாக ஈடுபடுத்தலாம். + +அனைத்து எதிர்வரும் பங்களிப்புகளை இயக்கும் தானியங்கு சோதனைகள் அமைக்கவும், உங்கள் சோதனைகளை எளிதில் பங்களிப்பவர்களால் இயக்க முடியும் என்பதை உறுதி செய்யவும். அனைத்து குறியீட்டு பங்களிப்புகளும் சமர்ப்பிக்கப்படுவதற்கு முன் உங்கள் சோதனைகளை கடக்க வேண்டும். எல்லா சமர்ப்பிப்புகளுக்குமான குறைந்தபட்ச தரமான தரத்தை அமைக்க உதவுவீர்கள். கிட்ஹப்-இல் [தேவைப்படும் நிலை சரிபார்ப்புக்கள்](https://help.github.com/articles/about-required-status-checks/) உங்கள் சோதனைகளை கடந்துசெல்லாமல் மாற்றம் எதுவும் சேர்க்கப்படாது என்பதை உறுதிப்படுத்த உதவுகிறது. + +நீங்கள் சோதனையைச் சேர்த்தால், உங்கள் பங்களிப்புக் கோப்பில் (CONTRIBUTING file) அவர்கள் எவ்வாறு வேலை செய்கின்றன என்பதை விளக்கிச் சொல்லுங்கள். + + + +### அடிப்படை பராமரிப்பு பணிகளை தானியங்குபடுத்துவதற்கு கருவிகளைப் பயன்படுத்துங்கள் + +ஒரு பிரபலமான திட்டத்தை பராமரிப்பது பற்றிய நற்செய்தி என்னவெனில் மற்ற பராமரிப்பாளர்கள் இதே போன்ற பிரச்சினைகளை எதிர்கொண்டு, அதற்காக ஒரு தீர்வை உருவாக்கினர். + +பராமரிப்பு பணியின் சில அம்சங்களை தானியங்குபடுத்துவதற்கு [பல்வேறு வகையான கருவிகள்](https://github.com/showcases/tools-for-open-source) உள்ளன. ஒரு சில உதாரணங்கள்: + +* [சொற்பொருள் வெளியீடு](https://github.com/semantic-release/semantic-release) உங்கள் வெளியீட்டை தானியங்குபடுத்துகிறது +* [குறிப்பிடு-செயலி](https://github.com/facebook/mention-bot) இழு கோரிக்கைகளுக்கு சாத்தியமான விமர்சகர்களை குறிப்பிடுகின்றது +* [இடர்](https://github.com/danger/danger) குறியீடு மதிப்பாய்வை தானியங்குபடுத்துவதற்கு உதவுகிறது + +பிழை அறிக்கைகள் மற்றும் பிற பொதுவான பங்களிப்புகளுக்கு, கித்ஹப்-இல் உள்ள [சிக்கல் வார்ப்புருக்கள் மற்றும் இழு கோரிக்கை சிக்கல் வார்ப்புருக்கள்](https://github.com/blog/2111-issue-and-pull-request-templates), நீங்கள் பெறும் தகவலை தடையின்றிப் பெருவதற்கு உதவும். @TalAter உங்கள் சிக்கல் மற்றும் PR வார்ப்புருக்கள் எழுதுவதற்கு உதவுவதற்கு [உங்கள் சொந்த சாதனை வழிகாட்டியைத் தேர்வுசெய்யவும்](https://www.talater.com/open-source-templates/#/) உருவாக்கினார். + +உங்கள் மின்னஞ்சல் அறிவிப்புகளை நிர்வகிக்க, [மின்னஞ்சல் வடிகட்டிகள்](https://github.com/blog/2203-email-updates-about-your-own-activity) மூலம் முன்னுரிமை கொடுத்து ஒழுங்குபடுத்தலாம். + +நீங்கள் இன்னும் சிறிது மேம்பட்ட பெற விரும்பினால், பாணி வழிகாட்டிகள் மற்றும் பிசிரிழை மூலம் திட்ட பங்களிப்புகளை தரப்படுத்தி அவற்றை ஆய்வு மற்றும் ஏற்க எளிதாக செய்ய முடியும். + +இருப்பினும், உங்கள் தரவுகள் மிக சிக்கலானதாக இருந்தால், அவர்கள் பங்களிப்புக்கு தடைகளை அதிகரிக்க முடியும். நீங்கள் எல்லோருடைய வாழ்க்கையையும் எளிதாக்கிக்கொள்ள போதுமான விதிகள் மட்டுமே சேர்க்கிறீர்கள் என்பதை உறுதிப்படுத்தவும். + +எந்த கருவிகளைப் பயன்படுத்துவது என்பது உங்களுக்குத் தெரியாவிட்டால், பிற பிரபலமான திட்டங்கள், குறிப்பாக உங்கள் சுற்றுச்சூழலில் உள்ளவை என்ன என்பதைப் பாருங்கள். உதாரணமாக, பங்களிப்பு செயல்முறை பிற முனை தொகுதிகள் எவ்வாறு இருக்கும்? இதேபோன்ற கருவிகள் மற்றும் அணுகுமுறைகளைப் பயன்படுத்துவதன் மூலம் உங்கள் இலக்கு பங்களிப்பாளர்களுக்கு உங்கள் செயல்முறை நன்கு அறியப்படும். + +## இடைநிறுத்தம் எடுப்பது பரவாயில்லை + +திறந்த மூல வேலை உங்களுக்கு மகிழ்ச்சியைக் கொடுத்தது. ஒருவேளை இப்போது நீங்கள் தனிமை அல்லது குற்ற உணர்வு கொள்ளலாம். + +உங்கள் திட்டங்களைப் பற்றி நீங்கள் யோசித்துக்கொண்டிருக்கும்போது ஒருவேளை நீங்கள் கவலைகள் அல்லது அச்சம் வளர்வதாக உணரலாம். இதற்கிடையில், பிரச்சினைகள் மற்றும் கோரிக்கைகளை இழுக்கின்றன. + +வெளிப்படையான மூல வேலைகளில், குறிப்பாக பராமரிப்பாளர்களிடையே, தீய்வு என்பது ஒரு உண்மையான மற்றும் பரவலான பிரச்சினையாகும். ஒரு பராமரிப்பாளராக, உங்களுடைய மகிழ்ச்சி என்பது திறந்த மூல திட்டத்தின் உயிர் பிழைப்பதற்கான ஒரு நிபந்தனையற்ற தேவையாகும். + +சொல்வதற்கு அவசியமில்லை, ஒரு இடைவெளி எடுத்துக்கொள்ளுங்கள்! ஒரு விடுமுறை எடுக்க எரிந்தொழியும் வரை நீங்கள் காத்திருக்க வேண்டியதில்லை. @brettcannon, ஒரு பைதான் உள்ளக மேம்பாட்டாளர், 14 வருடங்கள் திறந்த மூல தன்னார்வ பணிக்கு பிறகு [ஒரு மாத கால விடுமுறை](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) எடுத்து கொள்ள முடிவு செய்தார். + +வேறு எந்த வகையிலான பணிமுறையையும் போல, வழக்கமான இடைவெளிகளை எடுத்துக் கொண்டால், நீங்கள் உங்கள் வேலையைப் புதுப்பித்து, மகிழ்ச்சியுடன், உற்சாகமாக வைத்திருப்பீர்கள். + + + +சில நேரங்களில், எல்லோருக்கும் உங்கள் அவசியம் தேவைப்படுவது போல் உணர்ந்தால் திறந்த மூல வேலைகளில் இருந்து இடைவேளி எடுப்பது கடினம். நீங்கள் விலகிச் செல்லவதால் மக்கள் உங்களை குற்றவாளியாக உணர முயற்சி செய்யலாம். + +நீங்கள் ஒரு திட்டத்தில் இருந்து விலகி நிற்கையில், உங்கள் பயனர்களுக்கும் சமூகத்திற்கும் ஆதரவைக் கண்டறிய உதவுங்கள். உங்களுக்குத் தேவையான ஆதரவைக் கண்டுபிடிக்க முடியவில்லை என்றால், எப்படியாவது ஒரு இடைவெளியை எடுங்கள். நீங்கள் கிடைக்காதபோது தொடர்புகொள்வதை உறுதிப்படுத்திக் கொள்ளுங்கள், எனவே உங்கள் மறுமொழியின்மை காரணமாக மக்கள் குழப்பமடைவதில்லை. + +இடைவெளிகளை எடுத்துக்கொள்வது வெறும் விடுமுறையை விட அதிகமாகும். நீங்கள் வார இறுதிகளில் திறந்த மூல வேலை செய்ய விரும்பவில்லை என்றால், அல்லது வேலை நேரங்களில், அந்த எதிர்பார்ப்புகளை மற்றவர்களுக்கு தெரிவிக்க வேண்டும், எனவே அவர்கள் உங்களை தொந்தரவு செய்யக்கூடாது என அறிவர். + +## உங்களை முதலில் கவனித்துக் கொள்ளுங்கள்! + +ஒரு பிரபலமான திட்டத்தை பராமரிப்பது, முந்தைய வளர்ச்சியை விட வேறுபட்ட திறமைகளுக்குத் தேவை, ஆனால் அது குறைவான நன்மதிப்பும் இல்லை. ஒரு பராமரிப்பாளராக, சிலர் மட்டுமே அனுபவப்படும் தலைமை மற்றும் தனிப்பட்ட திறமைகளை நீங்கள் பயிற்சி செய்வீர்கள். நிர்வகிப்பது எப்போதும் எளிதல்ல, தெளிவான எல்லைகளை அமைத்தல் மற்றும் நீங்கள் வசதியாக உள்ளதை மட்டும் எடுத்துக்கொள்வது, மகிழ்ச்சியாக, புத்துணர்ச்சியுடனும், பயனுள்ளதாகவும் இருக்க உதவும். diff --git a/_articles/ta/building-community.md b/_articles/ta/building-community.md new file mode 100644 index 00000000000..f7e17cdb471 --- /dev/null +++ b/_articles/ta/building-community.md @@ -0,0 +1,275 @@ +--- +lang: ta +title: வரவேற்பு சமூகங்களை உருவாக்குதல் +description: உங்கள் திட்டத்தை மக்களுக்கு பயன்படுத்தவும், பங்களிக்கவும், ஊக்கப்படுத்தவும் ஒரு சமூகத்தை உருவாக்குங்கள். +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## வெற்றிக்கு உங்கள் திட்டத்தை அமைத்தல் + +நீங்கள் உங்கள் திட்டத்தைத் தொடங்கினீர்கள், நீங்கள் வார்த்தை பரப்பி வருகிறீர்கள், அதை பார்க்கிறார்கள். அற்புதம்! இப்போது, அவர்களை எப்படிக் அருகாமையில் வைத்திருப்பது? + +ஒரு வரவேற்பு சமூகம் உங்கள் திட்டத்தின் வருங்கால மற்றும் புகழ் முதலீடு ஆகும். உங்கள் திட்டம் அதன் முதல் பங்களிப்பைப் பார்க்க ஆரம்பித்தால், ஆரம்ப பங்களிப்பாளர்களுக்கு ஒரு நேர்மறையான அனுபவத்தை வழங்குவதன் மூலம் தொடங்கவும், மேலும் அவர்கள் மீண்டும் வருவதை எளிதாக்கவும் செய்யுங்கள். + +### மக்கள் வரவேற்பை உணர வேண்டும் + +உங்கள் திட்டத்தின் சமூகத்தைப் பற்றி சிந்திக்க ஒரு வழி @MikeMcQuaid [பங்களிப்பாளர் வடிகுழலி](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) என அழைக்கிறார்.: + +![பங்களிப்பாளர் வடிகுழலி](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +நீங்கள் உங்கள் சமூகத்தை உருவாக்கும்போது, வடிகுழலியின் (ஒரு சாத்தியமான பயனர்) ஒருவரை கோட்பாட்டளவில் கீழ்தளத்திற்கு (செயலூக்கமுள்ள பராமரிப்பாளராக) எப்படிக் கொண்டு வரலாம் என்று கருதுங்கள். பங்களிப்பவர் அனுபவத்தின் ஒவ்வொரு கட்டத்திலும் உராய்வுகளை குறைப்பதே உங்கள் குறிக்கோள். மக்கள் எளிதாக வெற்றி காணும்போது, அவர்கள் இன்னும் செய்ய ஊக்கமளிக்கும். + +உங்கள் ஆவணங்களுடன் தொடங்கவும்: + +* **உங்கள் திட்டத்தை யாரேனும் பயன்படுத்த எளிதாக செய்தல்.** [ஒரு தோழமையான README](../starting-a-project/#readme-எழுதுவது) மற்றும் தெளிவான குறியீடு எடுத்துக்காட்டுகள் உங்கள் திட்டத்தில் தொடங்குவதற்கு எவருக்கும் எளிதாக இருக்கும். +* [உங்களின் CONTRIBUTING கோப்பு](../starting-a-project/#உங்கள்-பங்களிப்பு-வழிமுறைகளை-எழுதுதல்) உங்கள் சிக்கல்களை புதுப்பித்த நிலையில் வைத்திருப்பதன் மூலம், **எப்படி பங்களிக்க வேண்டும் என்பதை தெளிவுபடுத்துங்கள்**. + +[கிட்ஹப் இன் 2017 திறந்த மூல கருத்தாய்வு](http://opensourcesurvey.org/2017/) மிகப்பெரிய பிரச்சனையாக முழுமையடையாத அல்லது குழப்பமான ஆவணமாக்கலைக் திறந்த மூல பயனர்களுக்கு உள்ளது என காட்டியது. நல்ல ஆவணங்கள் உங்கள் திட்டத்துடன் தொடர்புகொள்வதற்கு மக்களை வரவேற்கின்றது. இறுதியில், யாராவது ஒரு சிக்கலைத் அல்லது இழு கோரிக்கையை திறக்கலாம். இந்த பரஸ்பரங்களைப் பயன்படுத்தி அவற்றை வடிகுழலின் கீழ் வரை நகர்த்துவதற்கான வாய்ப்பாக பயன்படுத்தவும். + +* **உங்கள் திட்டத்தில் யாரேனும் புதியதாக தொடங்கினால், அவர்களுடைய ஆர்வத்திற்கு நன்றி சொல்லுங்கள்!** ஒரே ஒரு எதிர்மறை அனுபவமானது ஒருவரை மறுபடியும் திரும்பி வர விரும்பாமல் செய்துவிடும். +* **மறுமொழி கூறுங்கள்.** ஒரு மாதம் தங்கள் பிரச்சனைக்கு நீங்கள் பதிலளிக்கவில்லை என்றால் அவர்கள் ஏற்கனவே உங்கள் திட்டத்தை மறந்துவிட வாய்ப்புகள் உள்ளன. +* **நீங்கள் ஏற்றுக் கொள்ள வேண்டிய பங்களிப்புகளை பற்றி திறந்த மனதுடன் இருங்கள்.**பல பங்களிப்பாளர்கள் ஒரு பிழை அறிக்கை அல்லது சிறு பிழைத்திருத்தத்துடன் தொடங்குகின்றனர். ஒரு திட்டத்திற்கு [பங்களிக்க பல வழிகள் உள்ளன](../how-to-contribute/#பங்களிப்பதின்-அர்த்தம்-என்ன). மக்கள் எவ்வாறு உதவ விரும்புகிறார்களோ அவ்வாறே உதவட்டும். +* **நீங்கள் உடன்படாத ஒரு பங்களிப்பு இருந்தால்,** அவர்கள் கருத்திற்கு நன்றி தெரிவிக்கவும் [ஏன்](../best-practices/#இல்லை-என-சொல்ல-கற்றல்) இது திட்டத்தின் நோக்கத்திற்கு ஏன் பொருந்தவில்லை என, ஆவணத்துடன் (இருந்தால்) சுட்டிக்காட்டவும். + + + +பெரும்பாலான திறந்த மூல பங்களிப்பாளர்கள் "தற்காலிக பங்களிப்பாளர்கள்": ஒரு திட்டத்தில் பங்களித்தவர்கள் எப்போதாவது மட்டுமே. ஒரு சாதாரண பங்களிப்பாளருக்கு உங்கள் திட்டத்தின்போது வேகத்தை அதிகரிக்க நேரம் கிடைக்காமல் போகலாம், எனவே உங்கள் வேலையை எளிதில் பங்களிக்க உதவும். + +பிற பங்களிப்பாளர்களை உற்சாகப்படுத்துவது உங்களுக்கு ஒரு முதலீடு ஆகும். நீங்கள் உற்சாகமாக பணிபுரியும் உங்கள் பெரிய ரசிகர்களை அதிகப்படுத்தும்போது, எல்லாவற்றையும் நீங்களே செய்வதற்கான அழுத்தம் குறைகிறது. + +### அனைத்தையும் ஆவணப்படுத்துங்கள் + + + +நீங்கள் ஒரு புதிய திட்டத்தை தொடங்கும்போது, உங்கள் வேலையைத் தனிப்பட்ட முறையில் வைத்திருக்க இயலும். உங்கள் செயல்முறையை பொதுவில் ஆவணப்படுத்தும்போது, திறந்த மூல திட்டங்கள் செழித்தோங்கும். + +விடயங்களை எழுதும்போது, ஒவ்வொரு அடியிலும் அதிகமானவர்கள் பங்கேற்பார்கள். நீங்கள் உங்களுக்குத் தெரியாத ஒன்றில் உங்களுக்கு உதவி கிடைக்கலாம். + +விடயங்களை எழுதுவது வெறும் தொழில்நுட்ப ஆவணங்களை விட அதிகமானது. எந்த நேரத்திலும் உங்கள் திட்டத்தை விவாதித்து அல்லது தனிப்பட்ட முறையில் கலந்துரையாடுவது எப்போது வேண்டுமானாலும் நீங்கள் உணரலாம், அதை பொதுவெளியில் வைக்கலாமா என்று உங்களை நீங்களே கேளுங்கள். + +உங்கள் திட்டத்தின் திட்ட வரைபடம், நீங்கள் தேடுகிற பங்களிப்புகள், பங்களிப்புகளை மதிப்பாய்வு செய்தல் அல்லது நீங்கள் ஏன் சில முடிவுகளை எடுத்தீர்கள் என்பதை பற்றி வெளிப்படையாக இருங்கள். + +பல பயனர்கள் அதே சிக்கலில் இயங்குவதை நீங்கள் கண்டால், README இல் பதில்களை ஆவணப்படுத்தவும். + +சந்திப்புகளுக்கு, உங்கள் குறிப்புகள் அல்லது எடுத்துக்காட்டுகளை ஒரு பொருத்தமான விவகாரத்தில் வெளியிடுங்கள். வெளிப்படையான இந்த மட்டத்திலிருந்து நீங்கள் பெறும் பின்னூட்டம் உங்களுக்கு ஆச்சரியமாக இருக்கலாம். + +எல்லாவற்றையும் ஆவணப்படுத்துவது என்பது நீங்கள் செய்யும் வேலைக்கும் பொருந்தும். உங்கள் திட்டத்திற்கு ஒரு கணிசமான புதுப்பிப்பை நீங்கள் செய்திருந்தால், அதை ஒரு மிகுதிக் கோரிக்கையுடன் போட்டு, அதை பணி முன்னேற்றத்தில் (WIP) என்று குறிக்கவும். அந்த வழியில், பிற மக்கள் ஆரம்பத்தில் இருந்தே செயல்முறையில் ஈடுபட்டு உணர முடியும். + +### பதிலளிக்க வேண்டும் + +நீங்கள் [உங்கள் திட்டத்தை ஊக்குவிக்க](../finding-users), மக்கள் உங்களுக்கு கருத்து தெரிவிக்க வேண்டும். விஷயங்கள் எவ்வாறு வேலை செய்கின்றன என்பதைப் பற்றிய கேள்விகள் இருக்கலாம் அல்லது தொடங்குவதற்கு உதவி தேவைப்படலாம். + +யாராவது ஒரு சிக்கலைப் பதிவுசெய்தால், இழு கோரிக்கையை சமர்ப்பித்தால் அல்லது உங்கள் திட்டத்தைப் பற்றிய கேள்வியை கேட்டால், பதிலளிக்கும் முயற்சியை மேற்கொள்ளுங்கள். நீங்கள் விரைவாக பதிலளிக்கும்போது, அவர்கள் ஒரு உரையாடலின் பகுதியாக இருப்பதாக மக்கள் உணருவார்கள், மேலும் அவர்கள் பங்கு பெறுவதில் ஆர்வம் காட்டுவார்கள். + +நீங்கள் கோரிக்கையை உடனடியாக மதிப்பாய்வு செய்யாவிட்டாலும், ஆரம்பத்தில் அதை ஒப்புக் கொள்ளுதல் என்பது பங்களிப்பை அதிகரிக்க உதவுகிறது. [மிடில்மேன்](https://github.com/middleman/middleman/pull/1466) இழு கோரிக்கைக்கு @tdreyno இவ்வாறு பதிலளித்தார்: + +![மிடில்மேன் இழு கோரிக்கை](/assets/images/building-community/middleman_pr.png) + +[ஒரு மோசில்லா ஆய்வு](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) 48 மணி நேரத்திற்குள் குறியீட்டு மதிப்பீடுகளைப் பெற்ற பங்களிப்பாளர்கள் மிக அதிகமான எண்ணிக்கையில் திரும்பினர் மற்றும் மீண்டும் பங்களிப்பு செய்தனர் என்று கண்டறிந்தது. + +உங்கள் திட்டத்தைப் பற்றிய உரையாடல்கள், இணையம் முழுவதும் பிற இடங்களில் ஸ்டேக் ஓவர்ஃப்ளோ, ட்விட்டர் அல்லது ரெடிட் போன்றவைகளில் நடக்கலாம். இந்த இடங்களில் சில அறிவிப்புகளை நீங்கள் அமைக்கலாம், எனவே யாராவது உங்கள் திட்டத்தை குறிப்பிடுகையில் விழிப்பூட்டப்படுவீர்கள். + +### உங்கள் சமுதாயத்தைக் ஒன்று திரட்ட ஒரு இடம் கொடுங்கள் + +உங்கள் சமுதாயத்தை ஒன்று சேர்ப்பதற்கான இடம் கொடுப்பதற்கு இரண்டு காரணங்களாகும். + +முதல் காரணம் அவர்களுக்காக. ஒருவருக்கொருவர் தெரிந்துகொள்ள உதவுங்கள். பொதுவான நலன்களைக் கொண்ட மக்கள் தவிர்க்கவியலாமல் அதைப் பற்றி பேச ஒரு இடம் வேண்டும். தொடர்பு பொதுவிலும் மற்றும் அணுகத்தக்க வகையிலும் இருக்கும் போது, எவராலும் முந்தைய காப்பகங்களை படித்து வேகமாக பங்கு பெற முடியும். + +இரண்டாவது காரணம் உங்களுக்காக. உங்கள் திட்டத்தைப் பற்றி பேசுவதற்கு பொது மக்களுக்கு பொதுவெளியில் இடம் கொடுக்கவில்லை என்றால், அவர்கள் உங்களை நேரடியாக தொடர்புகொள்வார்கள். தொடக்கத்தில், இது தனிப்பட்ட செய்திகளுக்கு பதிலளிக்கும் போது "இது ஒரு முறை" மட்டுமே என எளிதானதாக தோன்றலாம். ஆனால் காலப்போக்கில், குறிப்பாக உங்கள் திட்டம் பிரபலமாகி விட்டால், நீங்கள் சோர்வாக உணருவீர்கள். தனிப்பட்ட முறையில் உங்கள் திட்டத்தைப் பற்றி மக்களுடன் தொடர்பு கொள்வதற்கான தூண்டுதலை எதிர்க்கவும். அதற்கு பதிலாக, ஒரு நியமிக்கப்பட்ட பொது அலைத்தடத்திற்கு அவர்களை வழிநடத்துங்கள். + +உங்கள் வலைப்பதிவில் நேரடியாகவோ அல்லது கருத்து தெரிவிப்பதற்கோ பதிலளிப்பதற்குப் பதிலாக, மக்களை திறந்த சிக்கலுக்கு வழிகாட்டுவதைப்போல பொது தகவல்தொடர்பு மிகவும் எளிது. நீங்கள் ஒரு அஞ்சல் பட்டியலை அமைக்கலாம் அல்லது ஒரு ட்விட்டர் கணக்கை உருவாக்கலாம், ஸ்லாக் அல்லது ஐ.ஆர்.சி சேனல் உங்கள் திட்டத்தை பற்றி பேசுவதற்கு. அல்லது மேலே கூறிய அனைத்தையும் முயற்சி செய்யலாம்! + +[குபெர்னீஸ் காப்ஸ்](https://github.com/kubernetes/kops#getting-involved) சமுதாய உறுப்பினர்களுக்கு உதவ ஒவ்வொரு வாரமும் அலுவலக நேரங்களை ஒதுக்கி வைக்கிறது: + +> சமூகத்திற்கு உதவி மற்றும் வழிநடத்துதலை வழங்குவதற்காக ஒவ்வொரு வாரமும் காப்ஸ் நேரத்தை ஒதுக்கியுள்ளது. காப்ஸ் பராமரிப்பாளர்கள் குறிப்பாக புதிதாக பணிபுரியும் பணியாளர்களுடன் பணிபுரிவதற்கு அர்ப்பணிக்கப்பட்ட நேரத்தை ஒதுக்கி, PR களுக்கு உதவுவது, புதிய அம்சங்களைப் பற்றி கலந்துரையாட ஒப்புக் கொண்டனர். + +பொது தொடர்புக்கு குறிப்பிடத்தக்க விதிவிலக்குகள்: 1) பாதுகாப்பு பிரச்சினைகள் மற்றும் 2) உணர்ச்சிமிக்க நடத்தை நெறிமுறைகளின் கட்டு மீருகைகள். இந்த சிக்கல்களைத் தனிப்பட்ட முறையில் தெரிவிக்க மக்களுக்கு எப்போதும் ஒரு வழி இருக்க வேண்டும். நீங்கள் உங்கள் தனிப்பட்ட மின்னஞ்சல் பயன்படுத்த விரும்பவில்லை என்றால், ஒரு பிரத்யேக மின்னஞ்சல் முகவரியை அமைக்கலாம். + +## உங்கள் சமூகத்தை வளர்த்தல் + +சமூகங்கள் மிகவும் சக்திவாய்ந்தவை. அந்த சக்தி உங்களுக்கு ஆசீர்வாதமாகவோ சாபமாகவோ இருக்கலாம், அதை எவ்வாறு செயலாட்சி செய்கிறோம் என்பதைப் பொறுத்து. உங்கள் திட்டத்தின் சமூகம் வளரும் போது, கட்டுமானத்திற்கு ஒரு சக்தியாக உதவுவதற்கான வழிகளாக இருக்கும், அழிக்கும் வழியாக அல்ல. + +### தீங்கு விளைவிப்பவர்களை பொறுத்துக் கொள்ளாதீர்கள் + +எந்தவொரு பிரபலமான திட்டமும் தவிர்க்க முடியாமல் தீங்கு விளைவிக்கும் நபர்களை ஈர்க்கும். அவர்கள் தேவையற்ற விவாதங்களைத் தொடங்கலாம், அற்பமான அம்சங்கள் மீது விவாதிக்கலாம் அல்லது மற்றவர்களுக்கு தொல்லை தரலாம். + +இந்த வகையான மக்களிடம் சகிப்பின்மையை கடைப்பிடிப்பது சிறந்தது. இதை தடுக்காமல் விட்டுவிட்டால், எதிர்மறையான மக்கள் உங்கள் சமூகத்தில் பிறருக்கு சங்கடத்தை ஏற்படுத்தலாம். அவர்கள் விலக கூட நேரிடலாம். + + + +உங்கள் திட்டத்தின் அற்பமான அம்சங்களைப் பற்றிய வழக்கமான விவாதங்கள் முக்கியமான விஷயங்களில் கவனம் செலுத்துவதில் இருந்து நீங்கள் உட்பட, மற்றவர்களை திசை திருப்ப கூடியவை. உங்கள் திட்டத்திற்கு வரும் புதிய நபர்கள் இந்த உரையாடல்களைக் காணலாம் மற்றும் பங்கேற்க விரும்பாமல் போகலாம். + +உங்கள் திட்டத்தில் எதிர்மறையான நடத்தை நடக்கும்போது, அதை வெளிப்படையாக அழைக்கவும். ஒரு வகையான ஆனால் உறுதியான தொனியில், அவர்களின் நடத்தை ஏற்றுக்கொள்ளத்தக்கது அல்ல என விளக்கவும். பிரச்சனை தொடர்ந்தால், நீங்கள் [அவர்களை விலகி விடுமாறு கேளுங்கள்](../code-of-conduct/#உங்கள்-நடத்தை-விதித்-தொகுப்பை-செயல்படுத்ததுதல்). உங்கள் [நடத்தை குறியீடு](../code-of-conduct/) இந்த உரையாடல்களுக்கு ஒரு ஆக்கபூர்வமான வழிகாட்டியாக இருக்கலாம். + +### பங்களிப்பவர்கள் எங்கிருந்தாலும் அவர்களை சந்திக்கவும் + +உங்கள் சமூகம் வளரும் போது நல்ல ஆவணங்கள் மிக முக்கியமானதாக மாறும். உங்கள் திட்டத்தினை நன்கு அறிந்திருக்காத சாதாரண பங்களிப்பாளர்கள், அவர்களுக்கு தேவையான சூழலை விரைவாக பெற உங்கள் ஆவணங்களைப் படிக்கவும். + +உங்கள் பங்களிப்புக் (CONTRIBUTING) கோப்பில், புதிய பங்களிப்பாளர்களை எவ்வாறு தொடங்குவது என்பதைத் தெளிவாக வெளிப்படுத்துங்கள். இந்த நோக்கத்திற்காக நீங்கள் ஒரு பிரத்யேக பிரிவை உருவாக்க விரும்பலாம்.[Django](https://github.com/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) யாராவது உங்கள் திட்டத்திற்கு புதியவர்கள் விரைவாக உங்கள் பிரச்சினைகளை பார்பதற்கும், தொடங்குவதற்கும் எளிதாக்குகின்றன. + +கடைசியாக, ஒவ்வொரு அடியிலும் மக்கள் வரவேற்பைப் பெற உங்கள் ஆவணங்களைப் பயன்படுத்தவும். + +உங்கள் திட்டத்தில் உள்ள பெரும்பாலான மக்களுடன் நீங்கள் தொடர்பு கொள்ள மாட்டீர்கள். நீங்கள் பெறாத பங்களிப்புகள் இருக்கலாம், ஏனெனில் யாரோ ஒருவர் பயமுறுத்தப்பட்டார் அல்லது எங்கு தொடங்குவது என தெரியாமல் இருக்கலாம். உங்கள் திட்டத்தை இருந்து யாரேனும் விலகுவதை உங்களின் ஒரு சில கனிவான வார்த்தைகளால் தடுக்கலாம். + +உதாரணமாக, [ரூபினிஸ்](https://github.com/rubinius/rubinius/) இங்கே எப்படி [அதன் பங்களிப்பு வழிகாட்டியை](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) தொடங்குகியது: + +> ரூபினியஸைப் பயன்படுத்துவதற்கு நன்றி தெரிவிப்பதன் மூலம் நாம் துவங்க வேண்டும். இந்த திட்டம் காதலால் உருவானது, மற்றும் பிழைகள் பிடிக்க, செயல்திறன் மேம்பாடுகள், மற்றும் ஆவணங்களை உதவி என்று அனைத்து பயனர்களையும் பாராட்டுகிறோம். ஒவ்வொரு பங்களிப்பும் அர்த்தமுள்ளது, எனவே பங்கு பெறுவதற்கு நன்றி. இதனால் கூறப்படுவதன் என்னவெனில், உங்களுடைய பிரச்சினையை வெற்றிகரமாக தீர்க்க நாங்கள் பின்பற்றும் சில வழிகாட்டு நெறிகள் நீங்கள் பின்பற்ற வேண்டும் . + +### Share ownership of your project + + + +உரிமையாளர்களாக உணர்கையில் மக்கள் திட்டங்களுக்கு பங்களிப்பதில் உற்சாகமாக உள்ளனர். நீங்கள் உங்கள் திட்டத்தின் பார்வையிலிருந்து விலக வேண்டும் அல்லது நீங்கள் விரும்பாத பங்களிப்பை ஏற்க வேண்டும் என்று அர்த்தமில்லை. ஆனால் நீங்கள் மற்றவர்களை கௌரவப்படுத்தும் பொழுது, அவர்கள் இன்னும் அதிகமாகக் பங்களிப்பார்கள். + +உங்கள் சமூகத்துடன் உரிமையை எவ்வளவு பகிர முடியுமோ அந்தளவு வழிகளை நீங்கள் கண்டுபிடிக்க முடியுமா என்பதைப் பார்க்கவும். சில யோசனைகள்: + +* **எளிதாக (அல்லாத முக்கிய) பிழைகளை சரிசெய்வதை எதிர்க்கவும்.** அதற்கு மாறாக, புதிய பங்களிப்பாளர்களைப் பணியமர்த்துவதற்கான வாய்ப்பாக அவற்றைப் பயன்படுத்துங்கள் அல்லது பங்களிக்க விரும்பும் ஒரு வழிகாட்டியாக இருக்க வேண்டும். இது முதலில் இயற்கைக்கு மாறானதாக தோன்றலாம், ஆனால் உங்கள் முதலீடு காலப்போக்கில் திரும்பிவிடும். உதாரணமாக, @michaeljoseph சிக்கலைக் குறைக்க, தானே சரிசெய்யாமல், ஒரு பங்களிப்பாளரிடம் [Cookiecutter](https://github.com/audreyr/cookiecutter) இழு கோரிக்கை எழுப்புமாறு கேட்டார். + +![Cookiecutter சிக்கல்](/assets/images/building-community/cookiecutter_submit_pr.png) + +* [சினாட்ரா](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) போன்று உங்கள் திட்டத்தில் பங்களித்த அனைவருக்கும் **உங்கள் திட்டத்தில் ஒரு பங்களிப்பாளர்கள்(CONTRIBUTORS) அல்லது நூலாசிரியர்கள்(AUTHORS) கோப்பைத் தொடங்கவும்.** + +* உங்கள் சமூகம் பெரியதாயிருந்தால், **ஒரு செய்திமடலை முடிக்க அல்லது வலைப்பதிவு இடுகையை எழுதுவதன் முலம்** பங்களிப்பாளர்களுக்கு நன்றி சொல்லுங்கள். ரஸ்ட்-ன் [இந்த வாரம் ரஸ்ட்](https://this-week-in-rust.org/) மற்றும் ஹூடி-ன் [கூச்சலிடுங்கள்](http://hood.ie/blog/shoutouts-week-24.html) இரண்டு நல்ல உதாரணங்களாகும். + +* **ஒவ்வொரு பங்களிப்பாளரும் ஒப்பவிக்கும் அனுமதி தரவும்.** இது மக்களை [அவர்களின் இணைப்புகளை மெருகூட்டுவதற்கு மிகவும் உற்சாகமாக இருக்கிறது](https://felixge.de/2013/03/11/the-pull-request-hack.html)என்று @felixge கண்டறிந்தார், மேலும் அவர் சமீபத்தில் வேலை செய்யாத திட்டங்களில் கூட புதிய பராமரிப்பாளர்களைக் கண்டார். + +* உங்கள் திட்டம் கிட்ஹப் இல் இருந்தால், **உங்கள் திட்டத்தை உங்கள் தனிப்பட்ட கணக்கிலிருந்து ஒரு [அமைப்பாக](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/ta/code-of-conduct.md b/_articles/ta/code-of-conduct.md new file mode 100644 index 00000000000..9908515abf3 --- /dev/null +++ b/_articles/ta/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: ta +title: உங்கள் நடத்தை விதி +description: நடத்தை நெறிமுறைகளை பின்பற்றுவதன் மூலம், ஆரோக்கியமான மற்றும் ஆக்கபூர்வமான சமூக நடத்தைக்கு உதவுதல். +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## எனக்கு எதற்கு ஒரு நடத்தை விதித் தொகுப்பு வேண்டும்? + +நடத்தை விதித் தொகுப்பு என்பது உங்கள் திட்டத்தின் பங்கேற்பாளர்களுக்கு நடத்தைக்கான எதிர்பார்ப்புகளை நிர்ணயிக்கும் ஆவணம். ஏற்றுக்கொள்வதும், நடைமுறைப்படுத்துவதும், உங்கள் சமூகத்திற்கான ஒரு நேர்மறையான சமூக சூழ்நிலையை உருவாக்க ஒரு நடத்தை விதித் தொகுப்பு உதவும். + +நடத்தை விதித் தொகுப்பு உங்கள் பங்கேற்பாளர்களை மட்டுமல்ல, உங்களையும் பாதுகாக்கும். நீங்கள் ஒரு திட்டத்தை பராமரித்து வந்தால், பிற பங்கேற்பாளர்களிடமிருந்து உற்பத்தியைப் பெறாத மனப்பான்மை, காலப்போக்கில் உங்கள் வேலையைப் பற்றி நீங்கள் வெறுமையாக அல்லது மகிழ்ச்சியற்றதாக உணரலாம். + +நடத்தை விதித் தொகுப்பு ஆரோக்கியமான, ஆக்கபூர்வமான சமூக நடத்தைக்கு உதவுகிறது. உங்கள் செயல்திட்டத்துடன் நீங்கள் அல்லது பிறர் சோர்வடைந்தால், நீங்கள் ஏற்றுக்கொள்ளாத ஒன்றை எவரேனும் செய்தால், நடவடிக்கை எடுக்க உதவுகிறது. + +## நடத்தை விதித் தொகுப்பு உருவாக்குதல் + +ஆரம்பத்தில் ஒரு நடத்தை விதித் தொகுப்பு உருவாக்க முயற்சிக்கவும்: இதனை நீங்கள் முதலில் உங்கள் திட்டத்தை உருவாக்கும் போது சிறந்தது. + +உங்கள் எதிர்பார்ப்புகளைத் தெரிவிப்பதோடு மட்டுமல்லாமல், ஒரு நடத்தை விதித் தொகுப்பு பின்வருமாறு விவரிக்கிறது: + +* நடத்தை விதித் தொகுப்பு நடைமுறைக்கு வந்தால் _(சிக்கல்களிலும் இழு கோரிக்கைகளிலும், அல்லது நிகழ்வுகள் போன்ற சமூக நடவடிக்கைகளிலோ மட்டுமே)_ +* யாரைப் பின்பற்றுகிறீர்கள் _(சமூக உறுப்பினர்கள் மற்றும் பராமரிப்பாளர்கள், ஆனால் ஆதரவாளர்கள்?)_ +* ஒருவர் நடத்தை விதிகளை மீறுவதால் என்ன நிகழும் +* ஒருவர் மீறல்களை எப்படி அறிவிக்க முடியும் + +நீங்கள் எங்கு வேண்டுமானாலும், முந்தைய உபாயத்தை பயன்படுத்தவும். [பங்களிப்பாளரின் உடன்படிக்கை](https://contributor-covenant.org/) என்பது ஒரு நடத்தை விதியாகும், இது குபெர்னீஸ், ரெயில்ஸ் மற்றும் ஸ்விஃப்ட் உள்ளிட்ட 40,000 திறந்த மூல திட்டங்களில் பயன்படுத்தப்படுகிறது. + +[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும். + +உங்கள் திட்டத்தின் மூலம் கோப்பகத்தில் CODE_OF_CONDUCT கோப்பை வைக்கவும், மேலும் உங்கள் CONTRIBUTING அல்லது README கோப்பில் இருந்து அதை இணைப்பதன் மூலம் அதை உங்கள் சமூகத்திற்குத் தெரியப்படுத்தவும். + +## உங்கள் நடத்தை விதித் தொகுப்பு எவ்வாறு செயல்படுவது என்பதை நீங்கள் தீர்மானிப்பீர்கள் + + + +உங்களுடைய நடத்தை எவ்வாறு நடைமுறைப்படுத்தப்படும் என்பதை ஒரு மீறல் ஏற்படும் **_முன்பு_** நீங்கள் விளக்க வேண்டும். அவ்வாறு செய்ய பல காரணங்கள் உள்ளன: + +* தேவைப்படும்போது நீங்கள் நடவடிக்கை எடுப்பது பற்றி தீவிரமாக இருப்பதை இது காட்டுகிறது. + +* புகார்கள் உண்மையில் மறுபரிசீலனை செய்யப்படுமென உங்கள் சமூகம் இன்னும் உறுதி கொள்ளும். + +* ஒரு மீறலுக்காகத் விசாரிக்கப்படும்பொழுது, மீளாய்வு செயல்முறை நியாயமானது மற்றும் வெளிப்படையானதாக இருக்கும் என்று உங்கள் சமூகத்திற்கு உறுதிப்படுத்துங்கள். + +நடத்தை மீறல்களை மக்கள் தனிப்பட்ட முறையில் புகாரளிக்க (மின்னஞ்சல் முகவரியைப் போன்ற) கொடுக்க வேண்டும், மற்றும் அந்த அறிக்கையை யார் பெறுகிறார்கள் என்பதை விளக்கவும். இது ஒரு பராமரிப்பாளர், பராமரிப்பாளர்களின் குழு, அல்லது நடத்தை விதி குழுவாக இருக்கலாம். + +அந்த அறிக்கையைப் பெறும் நபரைப் பற்றி ஒருவர் மீறல் குறித்து புகாரளிக்க விரும்புவதை மறந்துவிடாதீர்கள். இந்த வழக்கில், வேறு யாரிடாமவது மீறல்களைப் புகாரளிக்க அவர்களுக்கு விருப்பத்தெரிவு கொடுங்கள். உதாரணத்திற்கு, @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 மையம்.* + +உத்வேகத்திற்கு, ஜான்கோவின் [அமலாக்க கையேடை](https://www.djangoproject.com/conduct/enforcement-manual/) பார்க்கவும் (உங்கள் திட்டத்தின் அளவைப் பொறுத்து, இவ்வளவு விரிவானது தேவைப்படாமல் இருக்கலாம்). + +## உங்கள் நடத்தை விதித் தொகுப்பை செயல்படுத்ததுதல் + +சில நேரங்களில், உங்கள் சிறந்த முயற்சிகள் இருந்தபோதிலும், யாரோ ஒருவர் இந்த குறியீட்டை மீறுகிறார்கள். இப்படியாகும் பொழுது எதிர்மறையான அல்லது தீங்கு விளைவிக்கும் தன்மையை எதிர்கொள்ள பல வழிகள் உள்ளன. + +### நிலைமையைப் பற்றிய தகவல்களை சேகரிக்கவும் + +ஒவ்வொரு சமூக உறுப்பினரின் குரலையும் உங்கள் சொந்தமாக குரலைப்போல முக்கியமாக கருதுங்கள். யாராவது நடத்தை விதிமுறைகளை மீறுவதாக ஒரு அறிக்கையைப் பெற்றால், அது தீவிரமாக எடுத்து, அந்த நபருடன் உங்கள் சொந்த அனுபவத்திற்கு பொருந்தவில்லை என்றாலும், அதைப் பற்றி விசாரிக்கவும். இப்படி நீங்கள் செய்தால், உங்கள் சமுதாயத்திற்கு அவர்களின் கண்ணோட்டத்தை நீங்கள் மதிக்கிறீர்கள், அவர்களின் தீர்ப்பை நம்புகிறீர்கள் என சமிக்ஞை அனுப்புகிறது. + +கேள்விக்குரிய சமூக உறுப்பினர்கள் மீண்டும் மீண்டும் குற்றவாளியாக இருக்கலாம், மற்றவர்கள் தொடர்ந்து சங்கடப்படுவார்கள், அல்லது அவர்கள் ஒருமுறை சொல்லியோ அல்லது ஏதாவது செய்திருக்கலாம். இரண்டுமே சூழலைப் பொறுத்து, நடவடிக்கை எடுப்பதற்கு அடித்தளமாக இருக்கலாம். + +நீங்கள் பதிலளிக்கும் முன், என்ன நடந்தது என்பதை புரிந்துகொள்ள நேரம் எடுத்துக்கொள்ளுங்கள். நபரின் கடந்தகால கருத்துகள் மற்றும் உரையாடல்களால் அவர்கள் யார் என்பதை நன்கு புரிந்து கொள்ளவும், ஏன் அவர்கள் அப்படி செயல்பட்டிருக்கலாம் என்பதைப் புரிந்து கொள்ளவும். இந்த நபர் மற்றும் அவற்றின் நடத்தை பற்றி உங்களுடைய சொந்தக் காட்சிகளைத் தவிர்ப்பதற்கு முயற்சிக்கவும். + + + +### தகுந்த நடவடிக்கை எடுக்கவும் + +போதுமான தகவலை சேகரித்து செயலாக்குவதன் பிறகு, என்ன செய்ய வேண்டும் என்பதை நீங்கள் தீர்மானிக்க வேண்டும். உங்கள் அடுத்த நடவடிக்கை குறித்து நீங்கள் கருத்தில் கொள்ளும்போது, ஒரு மதிப்பீட்டாளராக உங்கள் குறிக்கோள் பாதுகாப்பான, மரியாதைக்குரிய மற்றும் ஒத்துழைப்புள்ள சூழலை ஊக்குவிப்பதாக நினைவில் கொள்ளுங்கள். சந்தர்ப்ப சூழ்நிலையை எவ்வாறு சமாளிப்பது என்பது மட்டுமல்லாமல், உங்கள் பதிலின் மீதும் உங்கள் சமூகத்தின் நடத்தையையும் எதிர்பார்ப்புகளையும் முன்னெடுத்துச் செல்வதையும் எப்படிப் பாதிக்கும் என்றும் கவனியுங்கள். + +யாராவது நடத்தை மீறல் புகாரளிக்கும் போது, அதை கையாள வேண்டியது உங்கள் வேலை, அவர்களுடையது அல்ல. சில நேரங்களில், தகவல் தருபவர் தங்கள் வாழ்க்கை, புகழ், அல்லது உடல் பாதுகாப்பிற்கு பெரும் ஆபத்தில் தகவல் வெளிப்படுத்துகிறார். அவர்களது துன்புறுத்தலை எதிர்கொள்ள அவர்கள் ஒரு கட்டாய நிலைக்கு தகவல் தருபவரை அனுப்ப முடியும். தகவல் தருபவர் வெளிப்படையாக கோரிக்கை விடுக்காவிட்டால், கேள்விக்குரிய நபருடன் நேரடியாக தொடர்பு கொள்ள வேண்டும். + +நடத்தை மீறலுக்கு நீங்கள் பதிலளிக்கக்கூடிய சில வழிகள் உள்ளன: + +* **கேள்விக்குரிய நபருக்கு ஒரு பகிரங்க எச்சரிக்கையை கொடுங்கள்** மேலும் அவர்களின் நடத்தை மற்றவர்களுக்கு எவ்வாறு தாக்கத்தை ஏற்படுத்துகிறது என்பதை விளக்குங்கள், முன்னர் அது ஏற்பட்ட அலைவரிசையில். சாத்தியமானால், பொதுத்தொடர்பு நீங்கள் நடத்தை நெறியை தீவிரமாக எடுத்துக் கொள்வதை சமூகத்தின் ஏனைய பகுதிகளுக்கு தெரிவிக்கின்றது. பரிவுடன், ஆனால் உங்கள் தொடர்பில் உறுதியாக இருங்கள். + +* கேள்விக்குரிய நபரிடம் அவர்களின் நடத்தை எவ்வாறு மற்றவர்களை பாதிக்கின்றது என்பதை விளக்கும் வகையில் **தனிப்பட்ட முறையில் தொடர்பு கொள்ளுங்கள்**. சூழ்நிலை தனிப்பட்ட தகவலை உள்ளடக்கியிருந்தால், நீங்கள் ஒரு தனிப்பட்ட தொடர்பு அலைவரிசையை பயன்படுத்த விரும்பலாம். நீங்கள் தனிப்பட்ட முறையில் யாரோடேனும் தொடர்பு கொண்டால், முதலில் நிலைமையை அறிக்கை செய்தவர்களை CC(தட்டச்சுப் படி) செய்வது நல்லது, எனவே நீங்கள் நடவடிக்கை எடுத்ததை அவர்கள் அறிவார்கள். புகாரளிக்கும் நபரை CC(தட்டச்சுப் படி) செய்வதற்கு முன் சம்மதம் கேளுங்கள். + +சில நேரங்களில், ஒரு தீர்மானத்தை எட்ட முடியாது. கேள்விக்குரிய நபர் எதிர்படும் பொழுது ஆக்ரோஷமாக அல்லது விரோதமாக மாறலாம் அல்லது மாற்றமடையாமல் போகலாம். இந்த சூழ்நிலையில், நீங்கள் வலுவான நடவடிக்கை எடுக்க வேண்டும். உதாரணத்திற்கு: + +* இந்த திட்டத்தின் எந்தவொரு அம்சத்திலும் பங்கு பெறும் தற்காலிக தடையின் மூலம், **கேள்விக்குரிய நபரை திட்டத்தில் இருந்து தற்காலிகமாக நிறுத்தி வைக்கவும்**. + +* திட்டத்தில் இருந்து **நபரை நிரந்தரமாக தடை செய்யவும்**. + +தடைசெய்யப்பட்ட உறுப்பினர்களை இலகுவாக எடுத்துக் கொள்ளக்கூடாது மற்றும் நிரந்தரமான மற்றும் சமரசமற்ற வேறுபாடுகளின் தோற்றத்தை பிரதிபலிக்க வேண்டும். ஒரு தீர்மானத்தை எட்ட முடியவில்லையே என்று தெளிவாகத் தெரிந்தால் மட்டுமே நீங்கள் இந்த நடவடிக்கைகளை எடுக்க வேண்டும். + +## பராமரிப்பாளராக உங்கள் பொறுப்புகள் + +தன்னிச்சையாக நடைமுறைப்படுத்த, நடத்தை நெறிமுறை ஒரு சட்டம் அல்ல. நடத்தை விதித் தொகுப்பு செயல்படுத்துபவது மற்றும் நடத்தை நெறிமுறை நிறுவும் விதிகளை பின்பற்றவது உங்கள் பொறுப்பு. + +ஒரு பராமரிப்பாளராக உங்கள் சமூகத்தின் வழிகாட்டுதல்களை நீங்கள் நிறுவுவதோடு, உங்கள் வழிகாட்டு நெறிமுறையின் விதிமுறைகளின் படி அந்த வழிமுறைகளை நடைமுறைப்படுத்தவும். அதாவது நடத்தை விதி மீறல் குறித்த எந்தவொரு அறிக்கையையும் தீவிரமாக எடுத்துக்கொள்வதாகும். புகாரளிக்கும் நபர், தங்கள் புகாரை ஒரு முழுமையான மற்றும் நியாயமான மறு ஆய்வு கடன் பட்டிருக்கிறார். அவர்கள் புகார் அளித்த நடத்தை மீறல் அல்ல என்பதை நீங்கள் தீர்மானித்தால், அவர்களுக்குத் தெளிவாகத் தொடர்பு கொண்டு, நீங்கள் ஏன் நடவடிக்கை எடுக்கப் போவதில்லை என்பதை விளக்கவும். அவர்கள் என்ன செய்கிறார்கள் என்பது அவர்களை பொருத்தது: அவர்கள் ஒரு சிக்கல் உள்ள நடத்தை சகித்துக் கொள்ளலாம் அல்லது சமூகத்தில் பங்கு பெறுவதை நிறுத்தலாம். + +நடத்தை முறையை _technically_ மீறாத நடத்தை பற்றிய அறிக்கை உங்கள் சமூகத்தில் ஒரு சிக்கல் இருக்கிறது என்பதைக் குறிக்கலாம், மேலும் இந்த சிக்கலைப் பற்றி விசாரித்து அதன்படி செயல்பட வேண்டும். இது உங்கள் நடத்தையின் விதித் தொகுப்பை மறுசீரமைக்க மற்றும் ஏற்றுக்கொள்ளக்கூடிய நடத்தையை தெளிவுபடுத்தும் மற்றும்/அல்லது கேள்விக்குரிய நபருடன் பேசுவதோடு, அவர்கள் நடத்தை விதிகளை மீறும் போது, அவர்கள் எதிர்பார்ப்பது என்ன என்று விளிம்பில் சாய்வது, பங்கேற்பாளர்கள் சங்கடமாக உணர்கிறார்கள். + +முடிவில், ஒரு பராமரிப்பாளராக, ஏற்றுக்கொள்ளத்தக்க நடத்தைக்கான தரங்களை நீங்கள் அமைத்து நிர்வகிக்கிறீர்கள். உங்களுக்கு திட்டத்தின் சமூக மதிப்புகள் வடிவமைக்கும் திறன் உள்ளது, மற்றும் பங்கேற்பாளர்கள் நீங்கள் ஒரு நியாயமான மற்றும் பாரபட்சமற்ற வழியில் அந்த மதிப்புகளை செயல்படுத்த வேண்டும் என்று எதிர்பார்க்கிறார்கள். + +## நீங்கள் உலகில் பார்க்க விரும்பும் நடத்தை ஊக்குவிக்கவும் 🌎 + +ஒரு திட்டம் விரோதமானதாகவோ அல்லது அசைக்கமுடியாததாகவோ தோன்றினால், மற்றவர்களின் நடத்தை சகித்துக்கொள்ளும் ஒரே ஒரு நபராக இருந்தாலும், நீங்கள் இன்னும் பல பங்களிப்பாளர்களை இழக்க நேரிடும், நீங்கள் சந்திக்காத சிலர் உட்பட. நடத்தை நெறிமுறைகளை பின்பற்றுவது அல்லது நடைமுறைப்படுத்துவது எப்போதும் எளிதல்ல, ஆனால் வரவேற்புமிக்க சூழல் உங்கள் சமூகத்தை வளர்க்க உதவும். diff --git a/_articles/ta/finding-users.md b/_articles/ta/finding-users.md new file mode 100644 index 00000000000..e58820e1e1e --- /dev/null +++ b/_articles/ta/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: ta +title: உங்கள் திட்டத்திற்கான பயனர்களைக் கண்டறிதல் +description: மகிழ்ச்சியான பயனர்களின் கைகளில் தருவதன் மூலம் உங்கள் திறந்த மூல திட்டத்தை வளர உதவுங்கள். +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## வார்த்தை பரப்புதல் + +நீங்கள் ஒரு திறந்த மூல திட்டத்தை தொடங்கும் பொழுதே ஊக்குவிக்க வேண்டும் என்று எந்த விதியும் இல்லை. திறந்த மூலத்தில் பணியாற்றுவதற்கு பல முழுமையடைக்கூடுய காரணங்கள் உள்ளன, அவை பிரபலத்துவத்திற்காக இல்லை. உங்கள் திறந்த மூல திட்டத்தை கண்டுபிடித்துப் பயன்படுத்துவதற்கு மற்றவர்களை நம்புவதற்குப் பதிலாக, உங்களின் கடின உழைப்பைப் பற்றி வார்த்தைகளைப் பரப்ப வேண்டும்! + +## உங்கள் செய்தியைக் கண்டறியவும் + +உங்கள் திட்டத்தை ஊக்குவிப்பதற்கான உண்மையான பணியைத் தொடங்குவதற்கு முன், நீங்கள் என்ன செய்ய வேண்டும் என்பதை விளக்கவும், ஏன் முக்கியம் என்பதை விளக்கவும் முடியும். + +உங்கள் திட்டம் வித்தியாசமானதா அல்லது சுவாரஸ்யமானதா? நீங்கள் ஏன் அதை உருவாக்கினீர்கள்? இந்த கேள்விகளுக்கு பதில் அளிப்பது, உங்கள் திட்டத்தின் முக்கியத்துவத்தை நீங்கள் பரப்புவதற்கு உதவும். + +பயனர்கள் பயனர்களாக ஈடுபடுவதை நினைவில் கொள்ளுங்கள், இறுதியில் பங்களிப்பாளர்களாகி விடுகிறார்கள், ஏனென்றால் உங்கள் திட்டம் அவர்களுக்கு ஒரு சிக்கலை தீர்க்கிறது. உங்கள் திட்டத்தின் செய்தி மற்றும் மதிப்பைப் பற்றி நீங்கள் சிந்திக்கும்போது, _பயனர்கள் மற்றும் பங்களிப்பாளர்கள்_ விரும்பும் கண்ணாடி வில்லை மூலம் அவற்றைப் பார்க்க முயற்சி செய்யுங்கள். + +எடுத்துக்காட்டாக, @robb [வரைபடவியல்](https://github.com/robb/Cartography), ஏன் பயனுள்ளதாக இருக்கும் என்பதைப் பற்றிய தெளிவான குறியீடுகளைப் பயன்படுத்துகிறார்: + +![வரைபடவியல் README](/assets/images/finding-users/cartography.jpg) + +ஒரு ஆழமான செய்திக்கு, மொஸில்லாவின்["ஆளுமை மற்றும் பாதைகள்"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) பயனர் நபர்களை உருவாக்குவதற்கான பயிற்சியைப் பார்க்கவும். + +## மக்கள் உங்கள் திட்டத்தை கண்டுபிடித்து பின்பற்ற உதவுங்கள் + + + +ஒரு பெயரைக் குறிப்பிடுவதன் மூலம் மக்கள் உங்கள் திட்டத்தை கண்டுபிடித்து, நினைவில் வைக்க உதவுங்கள். + +**உங்கள் வேலையை ஊக்குவிக்க ஒரு தெளிவான கைப்பிடி வேண்டும்.** ஒரு கீச்சர் கைப்பிடி, கிட்ஹப் URL, அல்லது IRC சேனல் உங்கள் திட்டத்தை மக்கள் சுட்டிக்காட்ட ஒரு சுலபமான வழி. Tஇந்த நிலையங்கள் உங்கள் திட்டத்தின் வளர்ந்து வரும் சமூகத்தை கூட்டுவதற்கு ஒரு இடத்தையும் கொடுக்கின்றன. + +இன்னும் உங்கள் திட்டத்திற்கான நிலையங்கள் அமைக்க விரும்பவில்லை என்றால், நீங்கள் செய்யும் அனைத்தையும் உங்கள் சொந்த கீச்சர் அல்லது கிட்ஹப் கைப்பிடிகளை விளம்பரப்படுத்தவும். உங்கள் கீச்சர் அல்லது கிட்ஹப் கைப்பிடிகளை மேம்படுத்துவது, உங்களை தொடர்புகொள்வது அல்லது உங்கள் வேலையை எவ்வாறு பின்பற்றுவது என்பதை மக்கள் அறிவர். ஒரு சந்திப்பு அல்லது நிகழ்வில் நீங்கள் பேசினால், உங்கள் தொடர்பு தகவல்கள் உங்கள் ஆளுமைக் குறிப்பு அல்லது விளக்கக்காட்சிகளில் சேர்க்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். + + + +**உங்கள் திட்டத்திற்கான வலைத்தளத்தை உருவாக்குங்கள்.** தெளிவான ஆவணங்கள் மற்றும் பயிற்சிகளுடன் இணைந்திருக்கும் போது, ஒரு வலைத்தளம் உங்கள் திட்டத்தை நட்பு ரீதியாகவும் எளிதாகவும் செல்லவும் செய்கிறது. ஒரு வலைத்தளம் இருப்பதால், உங்கள் திட்டம் செயலில் இருப்பதைக் குறிக்கிறது, இது உங்கள் பார்வையாளர்களை மிகவும் வசதியாக உணர வைக்கும். உங்கள் திட்டத்தை எவ்வாறு பயன்படுத்துவது என்பது குறித்த யோசனைகளை வழங்குவதற்கு உதாரணங்கள் வழங்கவும். + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), டிஜாங்கோவின் இணை-படைப்பாளி, ஒரு வலைத்தளம் _"நாங்கள் ஆரம்ப நாட்களில் டிஜாங்கோவில் செய்த சிறந்த விஷயம்"_ என்று கூறினார். + +கிட்ஹப் இல் உங்கள் திட்டம் host செய்யப்பட்டிருந்தால், எளிதாக ஒரு வலைத்தளத்தை உருவாக்க [கிட்ஹப் பக்கங்கள்](https://pages.github.com/) பயன்படுத்தலாம். [யோமன்](http://yeoman.io/), [வேக்ரன்ட்](https://www.vagrantup.com/), மற்றும் [மிடில்மேன்](https://middlemanapp.com/) சிறப்பான, விரிவான வலைத்தளங்களின் [சில உதாரணங்கள்](https://github.com/showcases/github-pages-examples) ஆகும். + +![வேக்ரன்ட் முகப்புப்பக்கம்](/assets/images/finding-users/vagrant_homepage.png) + +இப்போது உங்கள் திட்டத்திற்கான செய்தியைக் கொண்டிருக்கிறோம், உங்கள் திட்டத்தை மக்கள் கண்டுபிடிக்க எளிய வழி, அங்கு சென்று, உங்கள் பார்வையாளர்களுடன் பேசவும்! + +## உங்கள் திட்டத்தின் பார்வையாளர்களிடம் (இயங்கலை) செல்லுங்கள் + +இயங்கலை விஞ்சியிறுப்பு விரைவில் வார்த்தையை பகிர மற்றும் பரவ ஒரு சிறந்த வழி. இயங்கலை தடங்களைப் பயன்படுத்தி, மிக அதிகமான பார்வையாளர்களை அடைய உங்களுக்கு வாய்ப்பு உள்ளது. + +உங்கள் பார்வையாளர்களை அடைய, ஏற்கனவே இருக்கும் இயங்கலை சமூகங்களையும் தளங்களையும் பயன்படுத்தி கொள்ளுங்கள். உங்கள் திறந்த மூல திட்டம் ஒரு மென்பொருள் திட்டமாக இருந்தால், உங்கள் பார்வையாளர்களை ஒருவேளை [ஸ்டாக் ஓவர்ஃப்ளோ](https://stackoverflow.com/), [ரெட்டிட்](https://www.reddit.com), [ஹாக்கர் நியூஸ்](https://news.ycombinator.com/), or [கோரா](https://www.quora.com/) ஆகியவற்றில் நீங்கள் காணலாம். உங்கள் வேலையினால் மக்கள் மிகவும் பயன் அடையும் அல்லது உற்சாகமாக இருக்க வேண்டும் என நினைக்கும் தடங்களை கண்டறியுங்கள். + + + +உங்கள் திட்டத்தை பொருத்தமான வழிகளில் பகிர்ந்து கொள்ள வழிகளைக் காண முடியுமா என்பதைக் காணவும்: + +* **பொருத்தமான திறந்த மூல திட்டங்கள் மற்றும் சமூகங்களை அறிந்து கொள்ளுங்கள்.** சில நேரங்களில், நீங்கள் நேரடியாக உங்கள் திட்டத்தை ஊக்குவிக்க வேண்டியதில்லை. உங்கள் திட்டமானது பைத்தானைப் பயன்படுத்தும் தரவு விஞ்ஞானிகளுக்கு சரியானது என்றால், பைத்தான் தரவு அறிவியலாளரை அறிந்து கொள்ளுங்கள். மக்கள் உங்களுக்குத் தெரிந்தால், உங்கள் வேலையைப் பற்றி பேசுவதற்கும், பகிர்ந்து கொள்வதற்கும் வாய்ப்புகள் இயற்கையாக எழும். +* **உங்கள் திட்டத்தை சரிசெய்யும் சிக்கலை எதிர்கொள்ளும் நபர்களைக் கண்டறியவும்.** உங்கள் திட்டத்தின் இலக்கு பார்வையாளர்களில் விழும் நபர்களை தொடர்புடைய கருத்துக்களம் மூலம் தேடலாம். அவர்களின் கேள்விக்கு பதில் மற்றும் உத்தமமான வழியை கண்டுபிடிக்கவும், தக்க சமயத்தில் ஒரு தீர்வாக உங்கள் திட்டத்தை பரிந்துரைக்கவும். +* **கருத்துக்களைக் கேட்கவும்.** உங்களையும் உங்கள் வேலையும் ஒரு பார்வையாளருக்கு, அதனுடன் தொடர்புடையதாகவும் சுவாரசியமாகவும் இருக்கும்படி அறிமுகப்படுத்தவும். உங்கள் திட்டத்தில் இருந்து யார் பயனடையலாம் என நீங்கள் நினைப்பதைப் பற்றி குறிப்பிடவும். Tவாக்கியத்தை முடிக்க முயற்சிக்கும் போது: _"என் திட்டம் உண்மையில் Y- ஐ செய்ய முயற்சிக்கும் X-க்கு உதவும் என்று நினைக்கிறேன்_". வெறுமனே உங்கள் வேலையை ஊக்குவிப்பதை விட, மற்றவர்களின் கருத்துக்களைக் கேட்டு மறுமொழி கூறுங்கள். + +பொதுவாக, மற்றவர்களிடம் எதிர் உதவி கேட்கும் முன்பு, உதவுவதில் கவனம் செலுத்துங்கள். யாரும் எளிதாக ஒரு திட்டத்தை இயங்கலையில் ஊக்குவிக்க முடியும் என்பதால், கூச்சல் நிறைய இருக்கும். கூட்டத்தில் இருந்து தனித்து நிற்க, மக்களிடம் நீங்கள் எதை விரும்புகிறீர்கள் என்று மட்டுமல்லாமல், நீங்கள் யார் என்பதையும் கூறவும். + +யாரும் கவனத்தை ஈர்க்காவிட்டால் அல்லது உங்கள் ஆரம்ப முயற்சிகளுக்கு பதிலளிக்காவிட்டால், மனந்தளர வேண்டாம்! பெரும்பாலான திட்டங்களை அறிமுகப்படுத்த மாதங்கள் அல்லது ஆண்டுகள் ஆகலாம். நீங்கள் முதல் முறையாக பதிலைப் பெறவில்லையெனில், வேறு தந்திரோபாயத்தை முயற்சிக்கவும் அல்லது மற்றவர்களின் வேலைக்கு மதிப்பு சேர்க்க வழிகளைத் தேடுங்கள். உங்கள் திட்டத்தை மேம்படுத்த மற்றும் துவக்க நேரம் மற்றும் அர்ப்பணிப்பு ஆகியவற்றை எடுக்கும். + +## உங்கள் திட்டத்தின் பார்வையாளர்களிடம் (முடக்கலை) செல்லுங்கள் + +![பொது பேச்சு](/assets/images/finding-users/public_speaking.jpg) + +முடக்கலை நிகழ்வுகள் பார்வையாளர்களுக்கு புதிய திட்டங்களை மேம்படுத்துவதற்கான ஒரு பிரபலமான வழியாகும். ஈடுபட்டுள்ள பார்வையாளர்களை அடைய மற்றும் ஆழமான மனித இணைப்புகளை உருவாக்க அது ஒரு சிறந்த வழி, குறிப்பாக நீங்கள் நிரலாளர்களை அடைவதில் ஆர்வமாக இருந்தால். + +நீங்கள் [பொது பேச்சிற்கு புதிது](https://speaking.io/) என்றால், உங்கள் திட்டத்தின் மொழி அல்லது சுற்றுச்சூழல் தொடர்பான உள்ளூர் சந்திப்பைக் கண்டுபிடிப்பதன் மூலம் தொடங்கவும். + + + +நீங்கள் முன்பு ஒரு நிகழ்வில் பேசிய அனுபவம் இல்லையென்றால், பதற்ற உணர்வு முற்றிலும் சாதாரணமானது! உங்கள் வேலையைப் பற்றி உண்மையிலேயே கேட்க விரும்புவதால் உங்கள் பார்வையாளர்கள் அங்கு இருப்பதை நினைவில் வையுங்கள். + +உங்கள் பேச்சை எழுதும்போது, உங்கள் பார்வையாளர்களுக்கு சுவாரசியமானவற்றையும், மதிப்பை கொடுப்பதையும் கவனத்தில் கொள்ளவும். உங்கள் மொழி நட்பு மற்றும் அணுகக்கூடியதாக வையுங்கள். புன்னகையுங்கள், சுவாசியுங்கள், கேளிக்கை கொள்ளுங்கள். + + + +நீங்கள் தயாராக இருந்தால், உங்கள் திட்டத்தை மேம்படுத்த மாநாட்டில் பேசுங்கள். மாநாடுகள் பலரைச் சென்றடைய உதவும், சில நேரங்களில் உலகம் முழுவதும். + +உங்கள் மொழி அல்லது சுற்றுச்சூழல் தொடர்பான குறிப்பிட்ட மாநாடுகளைப் பாருங்கள். உங்கள் பேச்சுக்கு முன், மாநாட்டில் கலந்துரையாடலைப் பேசுவதற்கு உங்கள் உரையைச் சுருக்கமாக ஆராயுங்கள், மாநாட்டில் பேசுவதற்கான வாய்ப்புகள் அதிகரிக்கும். மாநாட்டின் பேச்சாளர்களைப் பார்த்து நீங்கள் உங்கள் பார்வையாளர்களை உணர்வீர்கள். + + + +## நற்பெயர் உருவாக்கவும் + +மேலே கோடிட்டுள்ள உத்திகளைத் தவிர்த்து, உங்கள் திட்டத்தில் பங்கெடுக்க மற்றும் பங்களிக்க மக்களை அழைப்பதற்கான சிறந்த வழி அவர்களின் திட்டங்களை பகிர்ந்து மற்றும் பங்களிக்க வேண்டும். + +புதியவர்களுக்கு உதவி, வளங்களை பகிர்தல், மற்றவர்களின் திட்டங்களுக்கு சிந்தனைக்குரிய பங்களிப்புகளை செய்வது ஆகியவை நேர்மறையான நற்பெயரை உருவாக்க உதவும். திறந்த மூல சமுதாயத்தில் செயலில் உள்ள உறுப்பினராக இருப்பதால், உங்கள் வேலைக்கு மக்கள் சூழலைக் கொண்டிருப்பார்கள், மேலும் உங்கள் திட்டத்தை கவனத்தில் எடுத்து, பகிர்ந்து கொள்ளலாம். மற்ற திறந்த மூல திட்டங்களுடனான உறவை வளர்ப்பதன் மூலம் உத்தியோகபூர்வ கூட்டுக்களுக்கு வழிவகுக்கலாம். + + + +உங்கள் நற்பெயரைத் தொடங்குவதற்கு என்றும் முன்னதாகவோ அல்லது மிகவும் தாமதமாக இல்லை. நீங்கள் ஏற்கனவே உங்கள் சொந்த திட்டத்தை ஆரம்பித்திருந்தாலும், மற்றவர்களுக்கு உதவ வழிகளைத் தேடுங்கள். + +பார்வையாளர்களை உருவாக்குவதற்கு ஒரே இரவில் தீர்வு இல்லை. நம்பிக்கையையும் மற்றவர்களுடைய மரியாதையையும் பெற்றுக்கொள்வது நேரம் எடுக்கும், உங்கள் நற்பெயரைக் கட்டி முடிக்காது. + +## பொறுமை காக்கவும் + +உங்கள் திறந்த மூல திட்டத்தை மக்கள் கவனிக்க முன் நீண்ட நேரம் எடுக்கலாம். பரவாயில்லை! மிக பிரபலமான சில திட்டங்கள் இன்று அதிக அளவில் நடவடிக்கைகளை எட்டுவதற்கு பல ஆண்டுகள் எடுத்தன. உங்கள் திட்டம் தன்னிச்சையாக புகழ் பெறும் என்று நம்புவதற்குப் பதிலாக உறவுகளை மேம்படுத்தவதில் கவனம் செலுத்துங்கள். பொறுமையாக இருங்கள், உங்கள் வேலையைப் பாராட்டுபவர்களுடன் பகிர்ந்து கொள்ளுங்கள். diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md new file mode 100644 index 00000000000..6b2b9a9775f --- /dev/null +++ b/_articles/ta/getting-paid.md @@ -0,0 +1,172 @@ +--- +lang: ta +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, உதாரணமாக, [வால்மார்ட்டின் திறந்த மூலதன முதலீட்டை](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html) நியாயப்படுத்த நிதி காரணங்களைக் கண்டறிந்துள்ளனர். மற்றும் ஃபேஸ்புக்கின் திறந்த மூல நிரல் ஆட்சேர்ப்பில் [வேறுபாட்டை உருவாக்கியதை](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) @jamesgpearce கண்டறிந்தார்: + +> இது எங்கள் கொந்தர் கலாச்சாரத்துடன் நெருக்கமாக உள்ளது, எங்கள் அமைப்பு எவ்வாறு உணரப்பட்டது. நாங்கள் எங்கள் ஊழியர்களிடம் கேட்டோம், "முகநூலில் திறந்த மூல மென்பொருள் திட்டம் பற்றி நீங்கள் அறிந்திருக்கிறீர்களா?". மூன்றில் இரண்டு பங்கு "ஆம்" என்றார். ஒரு பாதிபேர் அந்த செயல்முறைத் திட்டம் எங்களுக்கு வேலை செய்யத் தீர்மானித்தது. இவை குறுகலான எண்களாக இல்லை, மேலும் தொடர்கின்ற ஒரு போக்கு. + +உங்கள் நிறுவனம் இந்த வழியில் செல்லும்பொழுது, சமூகம் மற்றும் பெருநிறுவன செயல்பாடுகளுக்கு இடையில் எல்லைகளை வைத்திருக்க வேண்டியது அவசியம்.இறுதியாக, திறந்த மூலமானது உலகெங்கிலும் உள்ள மக்களிடமிருந்து நன்கொடைகள் மூலம் தன்னைத் தக்கவைத்துக்கொள்வதோடு, எந்த ஒரு நிறுவனத்தையும் அல்லது இடத்தையும் விட இது பெரியதாகும். + + + +திறந்த மூல வேலைக்கு முன்னுரிமை கொடுக்க உங்கள் தற்போதைய பணியாளரை நீங்கள் சமாதானப்படுத்த முடியாவிட்டால், ஒரு புதிய முதலாளி கண்டுபிடிப்பதை கருத்தில் கொள்க. திறந்த மூல வேலை வெளிப்படையான அர்ப்பணிப்பு செய்யும் நிறுவனங்களைக் கவனியுங்கள். உதாரணத்திற்கு: + +* சில நிறுவனங்கள், [நெட்ஃபிக்ஸ்](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) மூலம் திரட்டினார். + +## உங்கள் திட்டத்திற்கான நிதிகளைக் கண்டறிதல் + +தனிப்பட்ட பங்களிப்பாளர்களுக்கான ஏற்பாடுகளுக்கு அப்பால், சில நேரங்களில் திட்டங்கள் நிறுவனங்கள், தனிநபர்கள் அல்லது மற்றவர்களிடம் இருந்து பணத்தை திரட்டுகின்றன. + +நிறுவன நிதியளிப்பு நடப்பு பங்களிப்பாளர்களுக்கு செலுத்துவதை நோக்கி செல்லலாம், திட்டத்தை இயங்கும் செலவுகள் (ஹோஸ்டிங் கட்டணங்கள் போன்றவை) அல்லது புதிய அம்சங்கள் அல்லது யோசனைகளை முதலீடு செய்தல் ஆகியவற்றை உள்ளடக்கும். + +திறந்த மூலத்தின் புகழ் அதிகரிக்கும்போது, திட்டங்களுக்கான நிதிகளைக் கண்டறிவது இன்னும் பரிசோதனையாகும், ஆனால் சில பொதுவான விருப்பத்தெரிவுகள் உள்ளன. + +### பிரச்சாரங்களை அல்லது விளம்பரதாரர்கள் மூலம் உங்கள் பணிக்கான பணம் திரட்டவும் + +உங்களிடம் வலுவான பார்வையாளர்களோ அல்லது நற்பெயரைப் பெற்றிருந்தால், உங்கள் திட்டம் மிகவும் பிரபலமாக இருந்தால், நிதியுதவிகளை கண்டறிவது நல்லது. +நிதியளிக்கும் திட்டங்களின் சில உதாரணங்கள் பின்வருமாறு: + +* **[வெப்பேக்](https://github.com/webpack)** நிறுவனங்கள் மற்றும் தனிநபர்களிடமிருந்து [OpenCollective மூலம்](https://opencollective.com/webpack) நிதி திரட்டுகிறது +* **[ரூபி டுகேதர்](https://rubytogether.org/),** [பண்ட்லர்](https://github.com/bundler/bundler), [ரூபிஜெம்ஸ்](https://github.com/rubygems/rubygems), மற்றும் பிற ரூபி உள்கட்டமைப்பு திட்டங்களுக்கு பணிக்கு பணம் செலுத்துகின்ற ஒரு இலாப நோக்கமற்ற அமைப்பு + +### வருவாய் நீரோடை உருவாக்கவும் + +உங்கள் திட்டத்தை பொறுத்து, நீங்கள் வணிக ஆதரவு, ஹோஸ்ட் செய்யப்பட்ட விருப்பங்கள், அல்லது கூடுதல் அம்சங்களுக்கு கட்டணம் வசூலிக்கலாம். ஒரு சில உதாரணங்கள் பின்வருமாறு: + +* **[சைட்கிக்](https://github.com/mperham/sidekiq)** கூடுதல் ஆதரவுக்கான கட்டண பதிப்புகள் வழங்குகிறது +* **[டிராவிஸ் சிஐ](https://github.com/travis-ci)** அதன் தயாரிப்பின் கட்டண பதிப்புகள் வழங்குகிறது +* **[கோஸ்ட்](https://github.com/TryGhost/Ghost)** ஒரு இலாப நோக்கமற்றத பணம் செலுத்திய நிர்வகிக்கப்பட்ட சேவை + +[என்பிஎம்](https://github.com/npm/cli) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன. + +### மானிய நிதிக்கு விண்ணப்பிக்கவும் + +சில மென்பொருள் அடித்தளங்கள் மற்றும் நிறுவனங்கள் திறந்த மூல வேலைகளுக்கு மானியங்களை வழங்குகின்றன. சில நேரங்களில், திட்டத்திற்கான ஒரு சட்ட நிறுவனம் ஒன்றை அமைக்காமல் தனிநபர்களுக்கு மானியங்கள் வழங்கப்படலாம். + +* **[ரீட் த டாக்ஸ்](https://github.com/rtfd/readthedocs.org)** [மோசில்லா திறந்த மூல ஆதரவு](https://www.mozilla.org/en-US/grants/) மூலம் கொடை பெற்றது +* **[ஓபன்எம்ஆர்எஸ்](https://github.com/openmrs)** பணி [Stripe's திறந்த மூல ரிட்ரேட்](https://stripe.com/blog/open-source-retreat-2016-grantees) மூலம் நிதி பெற்றது +* **[லைப்பிரரி.ஐஓ](https://github.com/librariesio)** [ஸ்லோன் அறக்கட்டளை](https://sloan.org/programs/digital-technology) மூலம் கொடை பெற்றது +* **[பைத்தான் மென்பொருள் அறக்கட்டளை](https://www.python.org/psf/grants/)** பைத்தான் தொடர்பான பணிக்கு மானியங்களை வழங்குகிறது + +மேலும் விரிவான விருப்ப தெரிவுகள் மற்றும் வழக்கு ஆய்வுகளுக்கு, திறந்த மூல வேலைக்கு பணம் சம்பாதிக்க @nayafia [ஒரு வழிகாட்டி எழுதினார்](https://github.com/nayafia/lemonade-stand). வெவ்வேறு விதமான நிதியுதவி பல்வேறு திறமைகளுக்குத் தேவைப்படுகிறது, எனவே உங்கள் விருப்பங்களை நீங்கள் சிறப்பாகச் செயல்படுத்துவதை கண்டுபிடிக்க உங்கள் பலத்தை கருத்தில் கொள்ளுங்கள். + +## நிதியுதவிக்கு ஒரு வகை செய்தல் + +உங்கள் திட்டம் ஒரு புதிய யோசனையாக இருந்தாலும் அல்லது பல ஆண்டுகளாக இருந்தாலும் சரி, உங்கள் இலக்கு அனுபவத்தை அடையாளம் காண்பதில் குறிப்பிடத்தக்க சிந்தனை வைக்க வேண்டும் மற்றும் ஒரு கட்டாய வழக்கு ஒன்றை உருவாக்கும். + +நீங்கள் உங்கள் சொந்த நேரத்திற்காக அல்லது ஒரு திட்டத்திற்கான நிதி திரட்ட, நீங்கள் பின்வரும் கேள்விகளுக்கு பதிலளிக்க வேண்டும். + +### தாக்கம் + +ஏன் இந்த திட்டம் பயனுள்ளதாக இருக்கும்? ஏன் உங்கள் பயனர்கள், அல்லது சாத்தியமான பயனர்கள் அதை விரும்புகிறார்கள்? இது ஐந்து ஆண்டுகளில் எங்கு இருக்கும்? + +### இழுவை + +உங்கள் திட்டம் முக்கியம் என்பதற்கான அளவீடுகள், நிகழ்வுகள், அல்லது சான்றுகள் ஆதாரங்களாக சேகரிக்க முயற்சிக்கவும். இப்போது உங்கள் திட்டத்தை பயன்படுத்தி வரும் நிறுவனங்கள் அல்லது குறிப்பிடத்தக்க மக்கள் இருக்கிறீர்களா? இல்லையென்றால், ஒரு முக்கிய நபர் அதை ஆதரித்தாரா? + +### முதலீட்டாளர்களுக்கு மதிப்பு + +முதலீட்டாளர்கள், உங்களுடைய முதலாளிகளோ அல்லது மானிய நிதியளிப்பு நிறுவனமோ அடிக்கடி வாய்ப்புகளை சந்திக்கிறார்கள். வேறு எந்த சந்தர்ப்பத்திலும் உங்கள் திட்டத்தை ஏன் அவர்கள் ஆதரிக்க வேண்டும்? அவர்கள் எப்படி தனிப்பட்ட முறையில் பயனடைகிறார்கள்? + +### நிதிகளைப் பயன்படுத்துதல் + +முன்மொழியப்பட்ட நிதிக்கு என்ன, சரியாக, நீங்கள் சாதிக்க வேண்டும்? ஊதியத்தை செலுத்துவதற்கு பதிலாக திட்ட மைல்கற்கள் அல்லது விளைவுகளை கவனம் செலுத்துங்கள். + +### எவ்வாறு நீங்கள் நிதிகளைப் பெறுவீர்கள் + +முதலீட்டாளர்களுக்கு பிரித்துவழங்குதல் குறித்து ஏதேனும் தேவைகள் உள்ளனவா? எடுத்துக்காட்டாக, நீங்கள் ஒரு இலாப நோக்கமற்றவராக அல்லது லாபமற்ற நிதிய நிதியளிப்பாளராக இருக்க வேண்டும். Oஅல்லது ஒருவேளை நிதி ஒரு நிறுவனத்திற்கு பதிலாக தனிப்பட்ட ஒப்பந்தக்காரருக்கு கொடுக்கப்பட வேண்டும். இந்த தேவைகள் நிதிதாரர்களிடையே வேறுபடுகின்றன, எனவே உங்கள் ஆராய்ச்சி முன்னதாகவே செய்ய வேண்டும். + + + +## பரிசோதனை செய்யுங்கள் மற்றும் தளர்ந்துவிடாதீர்கள் + +பணத்தை உயர்த்துவது எளிதானது அல்ல, நீங்கள் ஒரு திறந்த மூல திட்டம், ஒரு இலாப நோக்கமற்ற அல்லது ஒரு மென்பொருள் துளிர் நிறுவனம், மற்றும் பெரும்பாலான சந்தர்ப்பங்களில் நீங்கள் படைப்பாற்றல் பெற்றிருக்க வேண்டும். நீங்கள் எப்படி பணம் சம்பாதிக்க வேண்டும், ஆராய்ச்சி செய்து, உங்கள் முதலீட்டாளர்களுடைய காலணிகளில் உங்களை வைத்துக் கொள்ளுதல், நிதிக்கு உறுதியான ஒரு சூழ்நிலையை உருவாக்கும். diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md new file mode 100644 index 00000000000..745102a6bef --- /dev/null +++ b/_articles/ta/how-to-contribute.md @@ -0,0 +1,515 @@ +--- +lang: ta +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's பங்களிப்பாளர்கள் செய்ததைப்போல](https://github.com/hapijs/contrib/issues/68) + +### நீங்கள் எழுத விரும்புகிறீர்களா? + +* திட்டத்தின் ஆவணங்களை எழுதுவது மற்றும் மேம்படுத்துவது +* திட்டம் எவ்வாறு பயன்படுத்தப்படுகிறது என்பதை காட்டும் உதாரணங்கள் ஒரு கோப்புறையை தொகுத்தல் +* திட்டத்திற்கான ஒரு செய்திமடலைத் தொடங்கவும் அல்லது அஞ்சல் பட்டியலிலிருந்த சிறப்பம்சங்களைக் தொகுக்கவும் +* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](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 [puffins-பெரிய அலகுடைய கடற்பறவைகள் பற்றி வேடிக்கை உண்மைகள் சேகரிப்பு](https://github.com/stuartlynn/puffin_facts) செய்தனர் + +நீங்கள் ஒரு மென்பொருள் உருவாக்குநராக இருந்தாலும்கூட, ஆவணங்கள் திட்டத்தில் பணிபுரியும் திறந்த மூலத்தில் நீங்கள் தொடங்குவதற்கு உதவலாம். இது குறியீட்டை உள்ளடக்கிய திட்டங்களில் பணிபுரியும் அளவுக்கு குறைவான அச்சுறுத்தலாகும், மற்றும் ஒத்துழைப்பு செயல்முறை உங்களுக்கு நம்பிக்கையும் அனுபவத்தையும் உருவாக்கும். + +## ஒரு புதிய திட்டத்திற்காக உங்களை நெறிப்படுத்துதல் + + + +ஒரு தட்டச்சுப் பிழையை சரி செய்வதை விட அதிகம், ஓப்பன் சோர்ஸ் பங்களிப்பு என்பது அந்நியர்களின் கொண்டாட்டத்தில் ஒரு குழுவினருடன் நடப்பது போலாகும். அவர்கள் தங்கமீன் பற்றி ஒரு விவாதத்தில் ஆழமாக இருந்தபோது, நீங்கள் இலாமா (கம்பள ஒட்டக இனம்) பற்றி பேச ஆரம்பித்தால், அவர்கள் ஒருவேளை உங்களை ஒரு வித்தியாசமான முறையில் பார்ப்பார்கள். + +உங்கள் சொந்த ஆலோசனையுடன் கண்மூடித்தனமாக குதிக்கும்முன், அறையை படிக்க எப்படி கற்பது என்பதிலிருந்து தொடங்கவும். அவ்வாறு செய்யும்போது, உங்கள் கருத்துக்கள் கவனிக்கப்பட்டு, கேட்கப்படும் வாய்ப்புகளை அதிகரிக்கிறது. + +### திறந்த மூல திட்டத்தின் உடற்கூறியல் + +ஒவ்வொரு திறந்த மூல சமூகமும் மாறுபட்டவை. + +ஒரு திறந்த மூல திட்டத்தில் ஆண்டுகள் செலவழித்து நீங்கள் ஒரு திறந்த மூல திட்டத்தை அறிந்து கொள்ள முடிந்தது. வேறொரு திட்டத்திற்கு செல்லும் பொழுது, சொல்லகராதி, நெறிமுறைகள் மற்றும் தகவல்தொடர்பு பாணிகள் முற்றிலும் வேறுபட்டதாக காணலாம். + +பல திறந்த மூல திட்டங்கள் இதே அமைப்பு முறையை பின்பற்றின. வெவ்வேறு சமூகப் பணிகளைப் புரிந்துகொள்வது மற்றும் மொத்த செயல்முறை ஆகியவை எந்தவொரு புதிய திட்டத்திற்கும் விரைவாகப் பெற உதவும். + +ஒரு பொதுவான திறந்த மூல திட்டம் பின்வரும் வகையான மக்களைக் கொண்டுள்ளது: + +* **படைப்பாளர்:** திட்டத்தை உருவாக்கிய நபர்/கள் அல்லது அமைப்பு +* **உரிமையாளர்:** அமைப்பு அல்லது களஞ்சியத்தில் நிர்வாக உரிமையுள்ள நபர்/கள்(எப்போதும் அசல் படைப்பாளர் அல்ல) +* **பராமரிப்பாளர்கள்:** திட்டத்தின் நோக்கம் மற்றும் நிறுவன அம்சங்களை நிர்வகிப்பதற்கும் பொறுப்புள்ள பங்களிப்பாளர்கள். (அவர்கள் திட்டத்தின் படைப்பாளர்கள் அல்லது உரிமையாளர்களாக இருக்கலாம்.) +* **பங்களிப்பாளர்கள்:** திட்டத்திற்கு ஏதேனும் பங்களித்த அனைவருக்கும். +* **சமூக உறுப்பினர்கள்:** திட்டத்தை பயன்படுத்தும் மக்கள். அவர்கள் உரையாடலில், செயலில் அல்லது திட்டத்தின் திசையைப் பற்றி தங்கள் கருத்தை தெரிவிக்கலாம். + +பெரிய திட்டங்கள், உபகாரம், சமுதாயம் மிதமிடுதல் மற்றும் நிகழ்வு ஏற்பாடு போன்ற பல்வேறு பணிகளைக் கருத்தில் கொண்ட உப குழு அல்லது பணிக்குழுக்கள் இருக்கலாம். இந்தத் தகவலைக் கண்டறிய, ஒரு "குழு" பக்கத்திற்கான ஒரு திட்டத்தின் வலைத்தளத்தைப் பார்க்கவும், அல்லது ஆட்சி ஆவணத்திற்கான களஞ்சியத்தில் பாருங்கள். + +ஒரு திட்டத்தில் ஆவணங்களும் உள்ளன. இந்த கோப்புகள் வழக்கமாக ஒரு களஞ்சியத்தின் மேல் மட்டத்தில் பட்டியலிடப்பட்டுள்ளன. + +* **உரிமம்(LICENSE):** வரையறையின்படி, ஒவ்வொரு திறந்த மூல திட்டமும் [திறந்த மூல உரிமத்தை](https://choosealicense.com) கொண்டிருக்க வேண்டும். திட்டத்திற்கு ஒரு உரிமம் இல்லை என்றால், அது திறந்த மூலம் அல்ல. +* **என்னைவாசி(README):** README என்பது புதிய சமூக உறுப்பினர்களை திட்டத்திற்கு வரவேற்கும் வழிமுறை கையேடு ஆகும். ஏன் திட்டம் பயனுள்ளதாக இருக்கும் மற்றும் எப்படி தொடங்குவது என இது விளக்குகிறது. +* **பங்களிப்பு(CONTRIBUTING):** READMEs மக்கள் உதவுகிறது திட்டத்தை _பயன்படுத்த_ உதவுகிறது, CONTRIBUTING ஆவணங்கள் திட்டத்திற்கு மக்கள் _பங்களிக்க_ உதவுகிறது. இது எவ்விதமான பங்களிப்புகள் தேவைப்படுகின்றன மற்றும் செயல்முறை எவ்வாறு செயல்படுகிறது என்பதையும் இது விளக்குகிறது. ஒவ்வொரு திட்டமும் ஒரு பங்களிப்புக் கோப்பில் இல்லை என்றாலும், அதன் இருப்பு சமிக்ஞைகள் இது பங்களிக்க ஒரு வரவேற்புத் திட்டம் ஆகும். +* **நடத்தை_குறியீடு(CODE_OF_CONDUCT):** நடத்தை குறியீடு தொடர்புடைய பங்கேற்பாளர்கள் நடத்தை தர விதிகள் அமைக்கிறது மற்றும் ஒரு நட்பு, வரவேற்பு சூழலை எளிதாக்கும் உதவுகிறது. ஒவ்வொரு திட்டமும் CODE_OF_CONDUCT கோப்பைக் கொண்டிருக்கவில்லை என்றாலும், இது பங்களிப்பு செய்வதற்கான வரவேற்புத் திட்டம் என்று அதன் இருப்பு சமிக்ஞைகள் உள்ளன. +* **பிற ஆவணங்கள்:** பயிற்சிகள், மேலோட்டப்பார்வைகள் அல்லது ஆளுமைக் கொள்கை போன்ற கூடுதல் ஆவணங்கள் இருக்கலாம், குறிப்பாக பெரிய திட்டங்களில். + +இறுதியாக, திறந்த மூல திட்டங்கள் விவாதத்தை ஒழுங்கமைக்க பின்வரும் கருவிகளைப் பயன்படுத்துகின்றன. ஆவணக்கிடங்குகளை படித்தல் மூலம் சமூகம் எப்படி சிந்திக்கிறது மற்றும் வேலை செய்கிறது என அறிய முடியும். + +* **சிக்கல் தடமி(Issue tracker):** திட்டப்பணியுடன் தொடர்புடைய பிரச்சினைகளை மக்கள் விவாதிக்கும் இடம். +* **இழு கோரிக்கைகள்(Pull requests):** முன்னேற்றத்தில் இருக்கும் மாற்றங்களை விவாதிக்கும் மற்றும் மதிப்பாய்வு செய்யுமிடம். +* **கலந்துரையாடல் மன்றங்கள் அல்லது அஞ்சல் பட்டியல்கள்:** சில திட்டங்கள் இந்த உரையாடல்களை உரையாடல் தலைப்புகளில் பயன்படுத்தலாம் (எடுத்துக்காட்டாக, _"நான் எப்படி ..."_ அல்லது _"என்ன நினைக்கிறீர்கள் ..."_ பிழை அறிக்கைகள் அல்லது அம்ச கோரிக்கைகளுக்கு பதிலாக). மற்றவர்கள் எல்லா உரையாடல்களுக்கும் சிக்கல் தடமியை பயன்படுத்துகின்றனர். +* **ஒத்திசைவு அரட்டை அலைத்தடம்:** சில திட்டங்கள் சாதாரண உரையாடல், ஒத்துழைப்பு, மற்றும் விரைவான பரிமாற்றங்களுக்கான அரட்டைத் தடங்களை (Slack அல்லது IRC போன்றவற்றை) பயன்படுத்துகின்றன. + +## பங்களிக்க ஒரு திட்டத்தை கண்டறிதல் + +இப்பொழுது திறந்த மூல திட்டங்கள் எப்படி இயங்குகின்றன என்பதை நீங்கள் அறிந்தீர்கள், இது பங்களிக்க ஒரு திட்டத்தை கண்டறியும் நேரம்! + +நீங்கள் இதற்கு முன்னர் திறந்த மூலத்திற்கு பங்களித்திருக்கவில்லை எனில், அமெரிக்க ஜனாதிபதி ஜான் எஃப். கென்னடி சில ஆலோசனையை எடுத்துக் கொண்டால், "நாடு உங்களுக்கு என்ன செய்தது என்று கேட்காதீர்கள் - நீங்கள் நாட்டிற்கு என்ன செய்ய முடியும் என்று கேளுங்கள்." + +திறந்த மூலத்திற்கான பங்களிப்பு, அனைத்து மட்டங்களிலும் திட்டங்கள்தோறும் நடக்கிறது. உங்களுடைய முதல் பங்களிப்பு என்னவாக இருக்கும், அல்லது அது எப்படி இருக்கும் என்பதை நீங்கள் அதிகம் ஆலோசனை செய்ய வேண்டியதில்லை. + +அதற்கு பதிலாக, நீங்கள் ஏற்கனவே பயன்படுத்திய, அல்லது பயன்படுத்த விரும்பும் திட்டங்களை பற்றி யோசித்து தொடங்கவும். நீங்கள் தீவிரமாக பங்களித்த திட்டங்களை நீங்கள் திரும்பி வருகிறீர்கள். + +அந்த திட்டங்களுள், எப்போதாவது நீங்கள் ஏதாவது ஒன்றை சிறப்பாக அல்லது வித்தியாசமாக இருந்திருக்கலாம் என கருதுவீர்கள், உங்கள் உள்ளுணர்வு சொல்வதைக் கேட்டு செயல்படுங்கள். + +திறந்த மூலமானது ஒரு பிரத்யேக சங்கம் அல்ல; இது உங்களைப் போன்ற மக்கள் உருவாக்கியது. உலகின் பிரச்சினைகளை சரிசெய்யக்கூடிய வகையில் "திறந்த மூல" என்பது ஒரு கற்பனையான சொல். + +நீங்கள் ஒரு README ஐ ஸ்கேன் செய்து உடைந்த இணைப்பு அல்லது ஒரு தட்டச்சுப் பிழையை காணலாம். அல்லது நீங்கள் புதிய பயனராக இருக்கின்றீர்கள், நீங்கள் ஏதாவது உடைந்துவிட்டதா என்று கவனித்தீர்களா அல்லது ஒரு சிக்கல் ஆவணத்தில் இருக்க வேண்டும் என்று நீங்கள் நினைக்கிறீர்களா . அதை புறக்கணித்துவிட்டு, நகர்த்துவதற்கு அல்லது வேறு யாராவது அதை சரிசெய்வதற்குப் பதிலாக, நீங்கள் உந்துதல் மூலம் உதவ முடியுமா என்பதைப் பார்க்கவும். + +> திறந்த மூலத்திற்கான [28% தற்காலிக பங்களிப்புகள்](https://www.igor.pro.br/publica/papers/saner2016.pdf) ஒரு தட்டச்சுப் பிழை சரி செய்வது, மறுசீரமைப்பு அல்லது மொழிபெயர்ப்பு எழுதுதல் போன்ற ஆவணங்கள் ஆகும். + +நீங்கள் புதிய திட்டங்களை கண்டறிய மற்றும் பங்களிக்க உதவுவதற்கு பின்வரும் வளங்களில் ஒன்றைப் பயன்படுத்தலாம்: + +* [கிட்ஹப் ஆராய்தல்](https://github.com/explore/) +* [திறந்த மூல வெள்ளிக்கிழமை](https://opensourcefriday.com) +* [முதல் முறையாளர்கள் மட்டுமே](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 இழு கோரிக்கைகள்](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [பங்களிப்பாளர்-நிஞ்ஜா](https://contributor.ninja) +* [முதல் பங்களிப்புகள்](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### பங்களிக்கும் முன் ஒரு சரிபார்ப்புப் பட்டியல் + +நீங்கள் பங்களிக்க விரும்பும் ஒரு திட்டத்தை நீங்கள் கண்டறிந்தால், பங்களிப்புகளை ஏற்றுக்கொள்வதற்கு திட்டம் பொருத்தமானதா என்பதை உறுதிப்படுத்த விரைவான ஆய்வு செய்யுங்கள். இல்லையெனில், உங்களுடைய கடின உழைப்பு ஒரு மறு மொழியை பெறாது. + +ஒரு திட்டம் புதிய பங்களிப்பாளர்களுக்கு பொருத்தமானதா என்பதை மதிப்பீடு செய்வதற்கான ஒரு கையேடு பட்டியல். + +**திறந்த மூலத்தின் வரையறைகளை சந்திக்கிறது** + +
+ + +
+ +**திட்டம் தீவிரமாக பங்களிப்பை ஏற்றுக்கொள்கிறது** + +master கிளையில் ஒப்படைப்பு செயல்களை பாருங்கள். கிட்ஹப்பில், இந்த தகவலை ஒரு களஞ்சியத்தின் முகப்புப்பக்கத்தில் காணலாம். + +
+ + +
+ +
+ + +
+ +
+ + +
+ +அடுத்து, திட்டத்தின் சிக்கல்களை பாருங்கள். + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +இப்போது இதையே திட்டத்தின் இழு கோரிக்கைகளுக்கு செய்யுங்கள். + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**திட்டம் வரவேற்க்கக்கூடியது** + +நட்பு மற்றும் வரவேற்பு சமிக்ஞைகள் உள்ள ஒரு திட்டம், புதிய பங்களிப்பாளர்களுக்கு வரவேற்கும் பண்புடையதாகும். + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## பங்களிப்பை எப்படி சமர்ப்பிக்க வேண்டும் + +நீங்கள் விரும்பும் ஒரு திட்டத்தை நீங்கள் கண்டுபிடித்து, பங்களிப்பு செய்யத் தயாராக உள்ளீர்கள். இறுதியாக! இங்கே சரியான வழியில் உங்கள் பங்களிப்பு பெறுவது எப்படி. + +### திறம்பட தொடர்பு கொள்ளுதல் + +நீங்கள் ஒரு முறை பங்களிப்பாளராகவோ அல்லது சமூகத்தில் சேர முயற்சிக்கிறோமா, மற்றவர்களுடன் சேர்ந்து செயல்படுவது திறந்த மூலத்தில் நீங்கள் வளர்த்துக்கொள்ளும் மிக முக்கியமான திறமைகளில் ஒன்றாகும். + + + +நீங்கள் ஒரு சிக்கலைத் திறக்க அல்லது கோரிக்கையை முன்வைக்க அல்லது அரட்டையில் ஒரு கேள்வியைக் கேட்க முன், இந்த நுட்பங்களை உங்கள் கருத்துக்களுக்கு திறம்பட உதவுவதற்காக மனதில் வைத்துக் கொள்ளுங்கள். + +**சூழ்நிலையை கொடுங்கள்.** விரைவாக மற்றவர்கள் வேகத்திற்கு வர உதவுங்கள். நீங்கள் ஒரு பிழையை கண்டீர்கள் என்றால், நீங்கள் என்ன செய்ய முயற்சிக்கிறீர்கள் என்பதை விளக்கவும், அதை எப்படி மீண்டும் செய்யலாம் என்பதை விளக்கவும். நீங்கள் ஒரு புதிய கருத்தை தெரிவித்திருந்தால், திட்டத்திற்கு பயனுள்ளதாக இருக்கும் என்று நீங்கள் ஏன் நினைக்கிறீர்கள் என்பதை விளக்குங்கள் (உங்களுக்கு மட்டுமல்ல!). + +> 😇 _"நான் X செய்யும் போது Y நடக்கவில்லை"_ +> +> 😢 _"X உடைந்ததுள்ளது! தயவுசெய்து அதை சரிசெய்யவும்."_ + +**முன்னதாக உங்களின் வீட்டுப்பாடம் செய்யுங்கள்.** விஷயங்களைத் தெரியாமல் இருப்பது தவறல்ல, ஆனால் நீங்கள் முயற்சித்ததைக் காட்டுங்கள். உதவி கேட்டு முன், ஒரு திட்டத்தின் README, ஆவணங்கள், சிக்கல்கள் (திறந்ததுள்ள அல்லது மூடப்பட்ட), அஞ்சல் பட்டியல், மற்றும் ஒரு பதிலை இணையத்தில் தேடுங்கள். நீங்கள் கற்றுக்கொள்ள முயற்சிக்கிறீர்கள் என்பதை நீங்கள் நிரூபிக்கும் போது மக்கள் பாராட்டுவார்கள். + +> 😇 _"X ஐ எவ்வாறு நடைமுறைப்படுத்துவது என்பது எனக்குத் தெரியவில்லை. உதவி ஆவணங்களை நான் சரிபார்த்தேன், எந்த குறிப்பும் இல்லை."_ +> +> 😢 _"X ஐ எப்படி செய்வது??"_ + +**கோரிக்கைகளை சிறிது மற்றும் நேரடியாக வைத்திருங்கள்.** ஒரு மின்னஞ்சலை அனுப்புவது போல, ஒவ்வொரு பங்களிப்பும், எவ்வளவு எளிய அல்லது உதவிகரமாக இருந்தாலும், வேறொருவருடைய மதிப்பாய்வு தேவைப்படுகிறது. உதவக்கூடிய மக்களை விட பல திட்டங்கள் இன்னும் உள்வரும் கோரிக்கைகளை கொண்டிருக்கின்றன. சுருக்கமாக இருங்கள். மற்றவர்கள் யாராவது உங்களுக்கு உதவ முடியும் என்ற வாய்ப்பை அதிகரிக்க முடியும். + +> 😇 _"நான் ஒரு API பயிற்சி எழுத விரும்புகிறேன்."_ +> +> 😢 _"நான் ஒரு நாள் நெடுஞ்சாலையில் வாகனம் ஓட்டி சென்று எரிவாயு நிறுத்தியபோது, பின்னர் நாம் செய்ய வேண்டும் என்ற இந்த அற்புதமான யோசனை இருந்தது, ஆனால் நான் அதை விளக்க முன், நான் உங்களுக்கு காண்பிக்க..."_ + +**எல்லா தகவல்தொடர்புகளையும் பொதுவில் வைக்கவும்.** Aஇது ஆவலைத் தூண்டும் என்றாலும், முக்கியமான தகவலை (பாதுகாப்புப் பிரச்சினை அல்லது கடுமையான நடத்தை மீறல் போன்றவை) பகிர்ந்து கொள்ளாதவரை தனிப்பட்ட முறையில் பராமரிப்பாளர்களை அடைய வேண்டாம். நீங்கள் உரையாடலை பொதுவில் வைத்திருக்கும்போது, அதிகமான மக்கள் உங்கள் பரிமாற்றத்திலிருந்து கற்றுக் கொள்ளலாம் மற்றும் நன்மை அடையலாம். கலந்துரையாடல்கள்கூட, பங்களிப்புகளாக இருக்கும். + +> 😇 _(ஒரு கருத்துரையாக) "@-maintainer ஹாய்! இந்த PR- ஐ எவ்வாறு தொடர வேண்டும்?"_ +> +> 😢 _(ஒரு மின்னஞ்சலாக) "ஹாய், உங்களை மின்னஞ்சலில் தொந்தரவு செய்ய மன்னிக்கவும், ஆனால் என் PR ஐ மறுபரிசீலனை செய்வதற்கான வாய்ப்பைப் பெற்றிருக்கிறதா என அறிய ஆவலாய் இருக்கிறேன்"_ + +**கேள்விகளைக் கேட்பது பரவாயில்லை (ஆனால் பொறுமையாக இருங்கள்).** எல்லோரும் ஒரு கட்டத்தில் திட்டத்திற்கு புதியவர்களாவர், மேலும் அனுபவமிக்க பங்களிப்பாளர்கள் கூட ஒரு புதிய திட்டத்தை பார்க்கும்போது வேகத்தை அதிகரிக்க வேண்டும். அதே அறிகுறி மூலம், நீண்டகால பராமரிப்பாளர்கள் எப்போதும் திட்டத்தின் ஒவ்வொரு பகுதியையும் நன்கு அறிந்திருப்பதில்லை. அவர்களுக்கு நீங்கள் காட்ட விரும்பும் அதே பொறுமையைக் காட்டுங்கள். + +> 😇 _"இந்த பிழையை பார்த்ததற்கு நன்றி. நான் உங்கள் பரிந்துரைகளை பின்தொடர்ந்தேன். அதன் வெளிப்பாடு."_ +> +> 😢 _"என் பிரச்சனையை நீங்கள் ஏன் சரிசெய்ய முடியாது? இது உங்கள் திட்டம்தானே?"_ + +**சமூகத்தின் முடிவுகளை மதித்தல்.** சமூகத்தின் முன்னுரிமைகள் அல்லது பார்வைகளில் இருந்து உங்கள் கருத்து வேறுபடலாம். அவர்கள் பின்னூட்டம் வழங்கலாம் அல்லது உங்கள் கருத்தைத் தொடரக்கூடாது என்று முடிவு செய்யலாம். நீங்கள் விவாதிக்க மற்றும் சமரசத்திற்குத் தேடும்போது, பராமரிப்பாளர்கள் உங்களுடைய முடிவைக் காட்டிலும் நீண்ட காலம் வாழ வேண்டும். நீங்கள் அவர்களின் திசையில் கருத்து வேறுபாடு கொண்டால், நீங்கள் எப்போதும் உங்கள் சொந்த கவையில் வேலை செய்யலாம் அல்லது உங்கள் சொந்த திட்டத்தை தொடங்கலாம். + +> 😇 _"நீங்கள் என் பயன்பாடு வழக்கை ஆதரிக்க முடியாது என்பது எனக்கு ஏமாற்றம் தான், ஆனால் நீங்கள் விளக்கிய பின்னர் அது ஒரு சிறிய பகுதியை பயனர்களையே பாதிக்கும், நான் ஏன் என்று புரிந்து கொண்டேன். கவனித்தமைக்கு நன்றி."_ +> +> 😢 _"என் பயன்பாடு வழக்கு ஏன் நீங்கள் ஆதரிக்கவில்லை? இது ஏற்றுக்கொள்ள முடியாதது!"_ + +**எல்லாவற்றிற்கும் மேலாக, அது கம்பீரமானதாக வைத்துக்கொள்ளுங்கள்.** திறந்த மூல உலகம் முழுவதும் இருந்து கூட்டுப்பணியாளர்களால் உருவாக்கப்பட்டது. மொழிகள், கலாச்சாரங்கள், புவியியல், மற்றும் நேர மண்டலங்கள் ஆகியவற்றில் சூழல் தொலைந்து போகிறது. கூடுதலாக, எழுதப்பட்ட தொடர்பு ஒரு தொனியை அல்லது மனநிலையை வெளிப்படுத்த கடினமாக்குகிறது. இந்த உரையாடல்களில் நல்ல எண்ணங்களைக் கொள்ளுங்கள். ஒரு யோசனையை மனதுக்குள் தள்ளுவதே நல்லது, மேலும் சூழலைக் கேட்கவும் அல்லது உங்கள் நிலைப்பாட்டை மேலும் தெளிவுபடுத்தவும். இணையத்தை நீங்கள் கண்டறிந்ததைவிட சிறந்த இடத்தை விட்டு விட முயற்சி செய்யுங்கள். + +### சூழல் சேகரித்தல் + +எதையும் செய்வதற்கு முன், உங்கள் யோசனை பிற இடங்களில் விவாதிக்கப்படவில்லை என்பதை உறுதிப்படுத்த விரைவாகச் சரிபார்த்துக் கொள்ளுங்கள். திட்டத்தின் README, சிக்கல்கள் (திறந்த மற்றும் மூடியது), அஞ்சல் பட்டியல் மற்றும் ஸ்டாக் ஓவர்ஃப்ளோ நீங்கள் எல்லாவற்றையும் நேரத்திற்கு செலவழிக்க வேண்டிய அவசியமில்லை, ஆனால் சில முக்கிய சொற்களுக்கு ஒரு விரைவான தேடல் நீண்ட தூரம் செல்கிறது. + +வேறு எங்காவது உங்கள் யோசனை கண்டுபிடிக்க முடியாவிட்டால், நீங்கள் ஒரு நகர்வு செய்ய தயாராக இருக்கிறோம். திட்டம் கிட்ஹப்பில் இருந்தால், நீங்கள் ஒரு சிக்கலைத் திறப்பதன் மூலம்; + +* **சிக்கல்கள்** ஒரு உரையாடல் அல்லது கலந்துரையாடலைத் தொடங்குகிறது +* **இழு கோரிக்கைகள்** ஒரு தீர்வைத் தொடங்குவதற்கான வேலைகள் +* **இலகுரக தகவல்கள்,** என்பது ஒரு தெளிவு பெறுவதோ அல்லது எப்படி கேள்வி கேட்கிறது என்று, திட்டத்தில் ஒன்று இருந்தால், ஸ்டேக் ஓவர்ஃப்ளோ, ஐஆர்சி, ஸ்லேக் அல்லது பிற அரட்டை சேனல்களை கேட்டு முயற்சி செய்யுங்கள் + +நீங்கள் ஒரு சிக்கலைத் திறக்க அல்லது கோரிக்கையை முன்வைக்கும் முன், திட்டத்தின் பங்களிப்பு ஆவணங்களை (வழக்கமாக கோப்பினைக் குறிக்கும் CONTRIBUTING அல்லது README இல்) பார்க்கவும். உதாரணமாக, நீங்கள் ஒரு வார்ப்புருவை பின்தொடர வேண்டுமென அவர்கள் கேட்கலாம் அல்லது நீங்கள் சோதனையைப் பயன்படுத்த வேண்டும். + +நீங்கள் கணிசமான பங்களிப்பைச் செய்ய விரும்பினால், அதைத் தொடங்குவதற்கு முன் ஒரு சிக்கலைத் திறக்கவும். இது சிறிது நேரம் திட்டத்தைக் கவனிக்க உதவுகிறது (கிட்ஹப்பில், [நீங்கள் "கவனி" என்பதை கிளிக் செய்யலாம்](https://help.github.com/articles/watching-repositories/) அனைத்து உரையாடல்களையும் தெரியப்படுத்த வேண்டும்), மற்றும் சமுதாய உறுப்பினர்களை தெரிந்துகொள்ளுங்கள், ஏற்றுக்கொள்ள முடியாத வேலைகளை செய்வதற்கு முன். + + + +### ஒரு சிக்கலைத் திறப்பது + +பின்வரும் சூழ்நிலைகளில் நீங்கள் பொதுவாக ஒரு சிக்கலைத் திறக்க வேண்டும்: + +* உங்களால் தீர்த்துவிடாத ஒரு பிழையை அறிக்கையிடவும் +* உயர்-நிலை தலைப்பு அல்லது கருத்தை (எடுத்துக்காட்டாக, சமூகம், பார்வை அல்லது கொள்கைகள்) +* ஒரு புதிய அம்சம் அல்லது பிற யோசனையை முன்மொழியுங்கள் + +சிக்கல்கள் தொடர்பாக உதவிக்குறிப்புகள்: + +* **நீங்கள் சமாளிக்க விரும்பும் திறந்த சிக்கலைக் கண்டால்,** நீங்கள் அதைப் பற்றி கருத்துரை கூறினால் மக்கள் நீங்கள் பணியாற்றுவதை அறிவர் . அந்த வழியில், உங்கள் வேலையை நகல் எடுப்பதற்கு மக்கள் குறைவாகவே இருப்பர். +* **சிறிது காலமாக முன்பு ஒரு சிக்கல் திறந்திருந்தால்,** இது வேறு எங்காவது உரையாடப்பட்டிருக்கலாம் அல்லது ஏற்கெனவே தீர்மானிக்கப்பட்டுவிட்டது, எனவே வேலை செய்யத் தொடங்குவதற்கு முன் உறுதிப்படுத்திக்கொள்ளவும். +* **நீங்கள் ஒரு சிக்கலைத் திறந்துவிட்டால், அதற்கு விடையை அறிந்திருந்தால்,** பிரச்சனையைப் பற்றி கருத்து தெரிவித்து, மக்களுக்குத் தெரியப்படுத்துங்கள். அந்த விளைவை ஆவணப்படுத்தியதும் கூட திட்டத்திற்கான பங்களிப்பாகும். + +### ஒரு இழு கோரிக்கையைத் திறத்தல் + +வழக்கமாக பின்வரும் சூழல்களில் ஒரு இழு கோரிக்கை திறக்க வேண்டும்: + +* எளிதான மாற்றங்களை சமர்ப்பிக்கவும் (எடுத்துக்காட்டாக, ஒரு தட்டச்சுப் பிழை, உடைந்த இணைப்பு அல்லது ஒரு வெளிப்படையான பிழை) +* ஏற்கெனவே கேட்டிருந்த ஒரு பங்களிப்பைத் தொடங்கவும் அல்லது ஒரு விவாதத்தில் ஏற்கனவே விவாதித்திருக்கவும் + +ஒரு இழுப்பு கோரிக்கை முடிக்கப்பட்ட பணியை பிரதிநிதித்துவப்படுத்த வேண்டிய அவசியமில்லை. பொதுவாக ஒரு மிகுதிக் கோரிக்கையை திறக்க இது மிகவும் சிறந்தது, எனவே உங்கள் முன்னேற்றம் குறித்து மற்றவர்கள் பார்க்க அல்லது கருத்து தெரிவிக்கலாம். அதை ஒரு வரியில் "WIP" (செயலில் உள்ள வேலை) குறிக்கவும். நீங்கள் எப்போது வேண்டுமானாலும் சேர்க்கலாம். + +திட்டம் கிட்ஹப்பில் இருந்தால், இங்கே எப்படி ஒரு இழு கோரிக்கை சமர்ப்பிக்க வேண்டும்: + +* **[களங்சியத்தை கவர்வழி](https://guides.github.com/activities/forking/)** மற்றும் அதை உள்நாட்டில் நகலெடுக்கவும். அசல் "பாய்வு மேற்புறம்(upstream)" களஞ்சியத்தை தொலைதூரமாக சேர்ப்பதன் மூலம் உங்கள் உள்ளூர் இணைப்பை இணைக்கவும். "பாய்வு மேற்புறத்தில்" இருந்து மாற்றங்களை இழுக்கவும், அதனால் நீங்கள் புதுப்பித்த நிலையில் இருப்பீர்கள், உங்கள் குறைநிரப்புக் கோரிக்கையைச் சமர்ப்பிக்கும் போது, மோதல்கள் குறைவாக இருக்கும். (மேலும் விரிவான விவரங்களுக்கு [இங்கே](https://help.github.com/articles/syncing-a-fork/) பார்க்கவும்.) +* **[கிளை ஒன்றை உருவாக்கவும்](https://guides.github.com/introduction/flow/)** உங்கள் திருத்தங்களுக்கு. +* **எந்தவொரு தொடர்படைய விடயங்களையும்** அல்லது ஆதரிக்கும் ஆவணங்களை உங்கள் PR இல் குறிப்பிடவும்(எடுத்துக்காட்டாக, "# 37 மூடுகிறது.") +* உங்கள் மாற்றங்கள் HTML / CSS இல் உள்ள வேறுபாடுகளை உள்ளடக்கியிருந்தால்,**அதற்கு முன்பும் பின்பும் திரைக்காட்சிகளையும் சேர்க்கவும்**. உங்கள் இழு கோரிக்கையின் உடலில் படங்களை இழுத்து விடுங்கள். +* **உங்கள் மாற்றங்களைச் சோதிக்கவும்!** Rதேவைப்பட்டால் இருக்கும் எந்தவொரு சோதனைகளிலும் உங்கள் மாற்றங்களை இயக்கவும், புதியவற்றை உருவாக்கவும். சோதனைகள் இல்லையா அல்லது இல்லாவிட்டாலும், உங்கள் மாற்றங்கள் ஏற்கனவே இருக்கும் திட்டத்தை உடைக்கவில்லை என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். +* **திட்டத்தின் பாணியில் பங்களிக்கவும்** உங்கள் சிறந்த திறமைகளை கொண்டு. இது உங்கள் சொந்த களஞ்சியத்தில் நீங்கள் விரும்பும் விடயங்களை விட வித்தியாசமாக உள்தள்ளல்கள், அரை-கோல்கன்கள் அல்லது கருத்துக்களைப் பயன்படுத்துவதாகும். ஆனால் எதிர்காலத்தில் மற்றவர்கள் புரிந்து கொள்ளவும், பராமரிக்கவும் பராமரிப்பாளரை எளிதாக்குகிறது. + +இது உங்கள் முதல் இழு கோரிக்கை என்றால், [ஒரு இழு கோரிக்கை செய்ய](http://makeapullrequest.com/) பாருங்கள், ஒரு ஒத்திகையும் கற்றல் காணொலியும் @kentcdodds உருவாக்கியுள்ளார். நீங்கள் முதலில் [First Contributions](https://github.com/Roshanjossey/first-contributions) களஞ்சியத்தில் ஒரு இழுப்பு கோரிக்கையை உருவாக்கலாம், @Roshanjossey உருவாக்கியது. + +## ஒரு பங்களிப்பை சமர்ப்பித்தபின் என்ன நடக்கிறது + +நீங்கள் செய்தீர்கள்! திறந்த மூல பங்களிப்பாளராக வாழ்த்துக்கள். இது பலவற்றில் முதன்மையானது என்று நாங்கள் நம்புகிறோம். + +நீங்கள் ஒரு பங்களிப்பைச் சமர்ப்பித்த பின், பின்வரும் ஒன்று நடக்கும்: + +### 😭 உங்களுக்கு பதில் கிடைக்கவில்லை. + +ஒரு பங்களிப்பைச் செய்வதற்கு முன்னர் [செயற்பாட்டு அறிகுறிகளுக்கான திட்டத்தை சரிபார்க்க](#பங்களிக்கும்-முன்-ஒரு-சரிபார்ப்புப்-பட்டியல்). ஒரு செயல்கபடக்கூடுய திட்டத்தில் கூட, உங்கள் பங்களிப்பு ஒரு பதிலை பெறாது. + +நீங்கள் ஒரு வாரத்திற்குள் பதிலைப் பெறவில்லை என்றால், மறுபரிசீலனைக்காக யாராவது கேட்டு, அதே பிரியில் மரியாதையுடன் பதிலளிப்பது நியாயமானது. உங்கள் பங்களிப்பை மதிப்பாய்வு செய்ய சரியான நபரின் பெயரை உங்களுக்குத் தெரிந்தால், நீங்கள் பிரியில் அவரை @-குறியிடலாம். + +** தனிப்பட்ட முறையில் அந்த நபரிடம் அடைய வேண்டாம்; பொதுத் தகவல்தொடர்பு மூலங்களை திறக்க முக்கியம் என்பதை நினைவில் கொள்ளுங்கள். + +நீங்கள் ஒரு கண்ணியமான கோரிக்கை செய்தால், இன்னும் யாரும் பதிலளிக்கவில்லை என்றால், எப்போதும் யாரும் பதிலளிக்க மாட்டார்கள். இது ஒரு பெரிய உணர்வு அல்ல, ஆனால் அதை நீங்கள் ஊக்கப்படுத்த வேண்டாம். இது அனைவருக்கும் நடந்தது! உங்கள் கட்டுப்பாட்டிலிரு ந்து வெளியேறக்கூடிய தனிப்பட்ட சூழ்நிலைகள் உட்பட, பதிலைப் பெறாததற்கு பல காரணங்கள் உள்ளன. பங்களிக்க மற்றொரு திட்டம் அல்லது வழி கண்டுபிடிக்க முயற்சி. ஏதாவது இருந்தால், இது மற்ற சமூக உறுப்பினர்கள் ஈடுபாடு மற்றும் பதிலளிக்கும் முன் ஒரு பங்களிப்பு செய்வதற்கு அதிக நேரத்தை முதலீடு செய்ய ஒரு நல்ல காரணம். + +### 🚧 உங்கள் பங்களிப்பில் யாரோ ஒருவர் மாற்றங்களைக் கோருகிறார். + +உங்கள் பங்களிப்புக்கு மாற்றங்களை செய்யும்படி கேட்கப்படும், இது உங்கள் யோசனையின் நோக்கம் பற்றிய கருத்து அல்லது உங்கள் குறியீட்டில் மாற்றம் கோரப்பபடபடலாம். + +யாராவது மாற்றங்களை கோரினால், பதிலளிக்க வேண்டும். உங்கள் பங்களிப்பை மதிப்பாய்வு செய்ய அவர்கள் நேரம் எடுத்துள்ளனர். ஒரு PR திறந்துவிட்டு பின்பு விட்டு விலகுவது மோசமானதாகும். மாற்றங்களைச் செய்ய உங்களுக்குத் தெரியாவிட்டால், சிக்கலை ஆராயுங்கள், உங்களுக்கு உதவி தேவைப்பட்டால் கேட்கவும். + +இனி பிரச்சினையில் வேலை செய்ய நேரம் இல்லை என்றால் (எடுத்துக்காட்டாக, உரையாடல் மாதங்களுக்கு நடக்கிறது என்றால், உங்கள் சூழ்நிலைகள் மாறிவிட்டன), பராமரிப்பாளர் அவர்கள் ஒரு பதிலை எதிர்நோக்குவதில்லை என்று தெரிந்து கொள்ளட்டும். வேறு யாராவது எடுத்துக்கொள்ள தயாராக இருக்கலாம். + +### 👎 உங்கள் பங்களிப்பு ஏற்றுக்கொள்ளப்படாது. + +உங்கள் பங்களிப்பு இறுதியில் ஏற்றுக்கொள்ளப்படலாம் அல்லது ஏற்றுக்கொள்ளப்படாமல் இருக்கலாம். நீங்கள் ஏற்கனவே அதில் அதிக வேலை செய்யவில்லை. இது ஏன் ஏற்றுக்கொள்ளப்படவில்லை என்பதை உறுதியாக தெரியாவிட்டால், கருத்துரை மற்றும் தெளிவுபடுத்துதலுக்கான பராமரிப்பாளரைக் கேட்பது நியாயமானது. ஆனால் இறுதியில், இது அவர்களின் முடிவு என்று நீங்கள் மதிக்க வேண்டும். வாதிடாதீர்கள் அல்லது விரோதம் கொள்ள வேண்டாம். நீங்கள் கருத்து தெரிவிக்கிறீர்கள் என்றால், நீங்கள் எப்போது வேண்டுமானாலும் வரவேற்பைப் பெறுவீர்கள். + +### 🎉 உங்கள் பங்களிப்பு ஏற்றுக்கொள்ளப்பட்டது.. + +ஓஹோ! திறந்த மூல பங்களிப்பை வெற்றிகரமாகச் செய்துள்ளீர்கள்! + +## நீங்கள் செய்தீர்கள்! + +உங்கள் முதல் திறந்த மூல பங்களிப்பை நீங்கள் செய்திருந்தாலும் அல்லது பங்களிக்க புதிய வழிகளைத் தேடுகிறீர்களோ இல்லையோ,நீங்கள் நடவடிக்கை எடுக்க ஈர்க்கப்பட்டிருப்பதாக நம்புகிறோம். உங்கள் பங்களிப்பு ஏற்றுக்கொள்ளப்படவில்லை என்றால், ஒரு பராமரிப்பாளர் உங்களுக்கு உதவ முயற்சிக்கும் போது நன்றி சொல்ல மறக்காதீர்கள். திறந்த மூல உங்களைப் போன்ற நபர்களால் செய்யப்படுகிறது: ஒரு சிக்கல், கோரிக்கையை, கருத்துரை அல்லது high-five (வெற்றியைக் கொண்டாட இருவர், தங்கள் உள்ளங்கைகளை மேலே தூக்கித் தட்டிக்கொள்ளுதல்). diff --git a/_articles/ta/index.html b/_articles/ta/index.html new file mode 100644 index 00000000000..f22f4323a11 --- /dev/null +++ b/_articles/ta/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: திறந்த மூல வழிகாட்டிகள் +lang: ta +permalink: /ta/ +--- diff --git a/_articles/ta/leadership-and-governance.md b/_articles/ta/leadership-and-governance.md new file mode 100644 index 00000000000..79826735efd --- /dev/null +++ b/_articles/ta/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: ta +title: தலைமை மற்றும் ஆளுமை +description: வளர்ந்து வரும் திறந்த மூல திட்டங்கள் முடிவுகளை எடுக்க முறையான விதிகளால் நன்மை அடைய முடியும். +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## உங்கள் வளரும் திட்டத்திற்கான ஆளுமையை புரிந்துகொள்ளுதல் + +உங்கள் திட்டம் வளர்ந்து வருகிறது, மக்கள் ஈடுபட்டுள்ளனர், நீங்கள் இந்த காரியத்தை வைத்துக் கொள்ள கடமைப்பட்டுள்ளீர்கள். Aஇந்த கட்டத்தில், உங்கள் பணிப்பகுதிக்கு வழக்கமான திட்ட பங்களிப்பாளர்களை எவ்வாறு இணைப்பது என்பது குறித்து நீங்கள் யோசித்து இருக்கலாம், யாரோ ஒருவருக்கு அணுகல் வழங்குவது அல்லது சமூக விவாதங்களை தீர்த்து வைப்பதாக இருக்கலாம். உங்களிடம் கேள்விகள் இருந்தால், எங்களிடம் பதில்கள் உள்ளன. + +## திறந்த மூல திட்டங்களில் பயன்படுத்தப்படும் முறையான பாத்திரங்களுக்கு எடுத்துக்காட்டுகள் என்ன? + +பல திட்டங்கள் பங்களிப்பவருக்கும் அங்கீகாரத்திற்கும் ஒத்த கட்டமைப்பைப் பின்பற்றுகின்றன. + +உண்மையில் இந்த பாத்திரங்களுக்கு என்ன அர்த்தம் என்பது உங்களை சார்ந்தது. நீங்கள் அடையாளம் காணக்கூடிய சில வகை பாத்திரங்கள் இங்கே: + +* **பராமரிப்பாளர்** +* **பங்களிப்பாளர்** +* **ஒப்புவிப்பவர்** + +**சில திட்டங்களில், "பராமரிப்பாளர்கள்"** மட்டுமே ஒப்புவி அணுகல் உள்ள மக்கள். மற்ற திட்டங்களில், README இல் பராமரிப்பாளர்களாக பட்டியலிடப்பட்ட நபர்கள் தான். + +ஒரு பராமரிப்பாளர் உங்கள் திட்டத்திற்கான குறியீட்டை எழுதுபவராக இருக்க அவசியம் இல்லை. இவர் உங்கள் திட்டத்தை மேம்படுத்துவதற்காக நிறைய வேலைகளை செய்திருக்கலாம், அல்லது மற்றவர்களுக்கு திட்டத்தை அணுகக்கூடிய ஆவணமாக்கல் செய்திருக்கலாம். அவர்கள் தினமும் என்ன செய்தாலும், ஒரு பராமரிப்பாளர் திட்டத்தின் திசைக்கு பொறுப்பாளராக இருப்பார், அதை மேம்படுத்துவதற்கு கடமைப்பட்டுள்ளார். + +**ஒரு "பங்களிப்பாளர்" என்பவர்** ஒரு சிக்கல் அல்லது இழு கோரிக்கையைப் பற்றி கருத்துத் தெரிவிக்கும், திட்டத்திற்கு மதிப்பைச் சேர்க்கும் நபர்கள் (இது சிக்கல்களை உயர்த்துவது, குறியீடு எழுதுதல், அல்லது நிகழ்வுகளை ஒழுங்குபடுத்துதல்) அல்லது இணைக்கப்பட்ட இழு கோரிக்கையுடன் (ஒருவேளை மிகக் குறுகிய ஒரு பங்களிப்பாளரின் வரையறை). + + + +**"ஒப்புவிப்பவர்" என்ற சொல்** மற்ற வகையான பங்களிப்புகளிலிருந்து பொறுப்பான ஒரு குறிப்பிட்ட வகையிலான பொறுப்பை ஒப்புக் கொள்ளுதல் ஆகியவற்றுக்கு பயன்படுத்தலாம். + +உங்கள் திட்டப்பணியை நீங்கள் விரும்பும் எந்த வழியையும் வரையறுக்க முடியும், மேலும் பங்களிப்பு வடிவங்களை ஊக்குவிக்க [பரந்த வரையறைகளைப் பயன்படுத்துங்கள்](../how-to-contribute/#பங்களிப்பதின்-அர்த்தம்-என்ன). உங்கள் தொழில்நுட்ப திறமையைப் பொருட்படுத்தாமல், உங்கள் திட்டத்தில் சிறந்த பங்களிப்பை செய்தவர்களை அங்கீகரிக்க நீங்கள் தலைமைப் பாத்திரங்களைப் பயன்படுத்தலாம். + + + +## இந்த தலைமைப் பாத்திரங்களை நான் எப்படி ஒழுங்கமைப்பது? + +உங்கள் தலைமைத்துவ பாத்திரங்களை ஒழுங்குபடுத்துவது மக்களுக்கு உரிமையைக் காட்ட உதவுகிறது, மேலும் உதவியைப் பார்க்க மற்ற சமூக உறுப்பினர்களைக் கூறுகிறது. + +ஒரு சிறிய திட்டம், தலைவர்கள் நியமனம் என்பது உங்கள் என்னைவாசி(README) அல்லது ஒரு பங்களிப்பாளர்கள்(CONTRIBUTORS) உரை கோப்பில் தங்கள் பெயர்களை சேர்ப்பது போன்ற எளிமையாக இருக்க முடியும். + +ஒரு பெரிய திட்டத்திற்கு, உங்களுக்கு ஒரு வலைத்தளம் இருந்தால், ஒரு குழு பக்கத்தை உருவாக்கவும் அல்லது உங்கள் திட்டத் தலைவர்களை பட்டியலிடவும். உதாரணமாக, [போஸ்கிரஸ்](https://github.com/postgres/postgres/) ஒவ்வொரு பங்களிப்பாளருக்கும் குறுகிய சுயவிவரங்களுடன் [விரிவான குழு பக்கம்](https://www.postgresql.org/community/contributors/) கொண்டு உள்ளது. + +உங்கள் திட்டம் மிகவும் சுறுசுறுப்பான பங்களிப்புச் சமுதாயத்தைக் கொண்டிருந்தால், நீங்கள் பராமரிப்பாளர்களின் ஒரு "உள்ளக குழு" அல்லது வெவ்வேறு சிக்கல் பகுதிகளை (எடுத்துக்காட்டாக, பாதுகாப்பு, சிக்கல் மிக்கது, அல்லது சமூக நடத்தை) உரிமையாளர்களாக எடுத்துக் கொள்ளும் உபகுழுக்களாக இருக்கலாம். மக்களுக்கு சுய ஒழுங்கமைப்பையும், தன்னார்வத் தொண்டுகளையும் அவர்கள் மிகவும் உற்சாகமாக அளித்து விட வேண்டும், மாறாக அவர்களை ஒதுக்குவதை விட. + + + +தலைமை குழுக்கள் நியமிக்கப்பட்ட சேனலை (ஐஆர்சி போன்றவை) உருவாக்குவதற்கு அல்லது திட்டத்தை (கிட்டர் அல்லது கூகுள் ஹாங்க் அவுட் போன்றவை) விவாதிப்பதற்கு எண்ணலாம். அந்த கூட்டங்களைப் பொதுவில் வைப்பபதபதால் மற்றவர்கள் கேட்கலாம். உதாரணத்திற்கு [கூக்கூம்பர்-ரூபி](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) போன்ற கருவிகள் திட்டத்திற்கு யார் பங்களிப்புகளை தருகிறார் (அல்லது தரவில்லை) என்பதைத் தெரிந்துகொள்ள உதவும். இந்த தகவலை ஆவணப்படுத்துவது, பராமரிப்பாளர்கள் தனிப்பட்ட முறையில் அதன் முடிவுகளை எடுக்கும் ஒரு குழு என்று சமூக அக்கறை தவிர்க்கிறது. + +இறுதியாக, உங்கள் திட்டம் கிட்ஹப்பில் இருந்தால், உங்கள் திட்டத்தை உங்கள் தனிப்பட்ட கணக்கிலிருந்து ஒரு நிறுவனத்திற்கு நகர்த்துவதைக் கருத்தில் கொண்டு, குறைந்தது ஒரு காப்பு நிர்வாகி ஒன்றைச் சேர்ப்பதை கருத்தில் கொள்ளுங்கள். [கிட்ஹப் நிறுவனங்கள்](https://help.github.com/articles/creating-a-new-organization-account/) அனுமதிகள் மற்றும் பல களஞ்சியங்களை நிர்வகிக்க எளிதாக்குகின்றன, மேலும் உங்கள் திட்டத்தின் மரபுரிமைகளை [பகிரப்பட்ட உரிமையாளர்](../building-community/#share-ownership-of-your-project) மூலம் பாதுகாக்கின்றன. + +## எப்போது யாருக்கு ஒப்புவிக்கும் அணுகல் கொடுக்க வேண்டும்? + +சிலர் நீங்கள் ஒரு பங்களிப்பை செய்கிற அனைவருக்கும் அனுமதி வழங்க வேண்டும் என்று நினைக்கிறார்கள். அவ்வாறு செய்வது உங்கள் திட்டத்தின் உரிமையை உணர இன்னும் பலரை ஊக்குவிக்கும். + +மறுபுறம், குறிப்பாக பெரிய, மிகவும் சிக்கலான செயல்திட்டங்களுக்கான, நீங்கள் அவர்களின் அர்ப்பணிப்பை நிரூபிக்கியுள்ள மக்களுக்கு மட்டுமே அனுமதி வழங்க வேண்டும். அதை செய்ய எந்த ஒரு சரியான வழி இல்லை - உங்களுக்கு மிகவும் வசதியாக உள்ள வழியில் செய்க! + +உங்கள் திட்டம் கிட்ஹப்பில் இருந்தால், ஒரு குறிப்பிட்ட கிளைக்கு யார் தள்ள முடியும், எந்த சூழ்நிலையிலும் நிர்வகிக்க நீங்கள் [பாதுகாக்கப்பட்ட கிளைகள்](https://help.github.com/articles/about-protected-branches/) பயன்படுத்தலாம். + + + +## திறந்த மூல திட்டங்களுக்கான பொது ஆளுமை கட்டமைப்புகள் சில யாவை? + +திறந்த மூல திட்டங்களுடனான மூன்று பொது ஆளுமை கட்டமைப்புகள் உள்ளன. + +* **BDFL:** BDFL "வாழ்வாதாரத்திற்கான சர்வாதிகாரி". இந்த கட்டமைப்பின் கீழ், ஒரு நபர் (பொதுவாக திட்டத்தின் ஆரம்ப எழுத்தாளர்) அனைத்து முக்கிய திட்ட முடிவுகளிலும் இறுதி சொல் உள்ளவரார். [பைதான்](https://github.com/python) ஒரு உன்னதமான உதாரணம். ஒன்று அல்லது இரண்டு பராமரிப்பாளர்கள் இருப்பதால் சிறிய திட்டங்கள் பெரும்பாலும் இயல்பான BDFL ஆகும். ஒரு நிறுவனம் தோற்றுவிக்கப்பட்ட ஒரு திட்டம் BDFL பிரிவில் விழக்கூடும். + +* **தகுதி முறை:** **(குறிப்பு: "தகுதி" என்ற வார்த்தை சில சமூகங்களுக்கு எதிர்மறையான கருத்துகளை கொண்டுள்ளது, மேலும் [சிக்கலான சமூக மற்றும் அரசியல் வரலாறு](http://geekfeminism.wikia.com/wiki/Meritocracy).)** ஒரு தகுதித்துவத்தின் கீழ், செயலில் உள்ள திட்ட பங்களிப்பாளர்கள் ("தகுதியை" நிரூபிப்பவர்கள்) முறையான முடிவு எடுக்கும் பங்கை வழங்கியுள்ளனர். தூய வாக்களிப்பு கருத்தை அடிப்படையாக கொண்ட முடிவுகள் பொதுவாக செய்யப்படுகின்றன. தகுதி முறை கருத்துப் படிவம் [அப்பாச்சி அறக்கட்டளையின்](https://www.apache.org/) முன்னோடியாக இருந்தது; [அனைத்து அப்பாச்சி திட்டங்கள்](https://www.apache.org/index.html#projects-list) தகுதி முறை உள்ளவை. தனிநபர்கள் தங்களைக் குறிக்கும் நபர்களால் மட்டுமே பங்களிப்பு செய்ய முடியும், நிறுவனத்தால் அல்ல. + +* **தாராளவாத பங்களிப்பு:** Uதாராளமான பங்களிப்பு மாதிரியின் கீழ், அதிக வேலை செய்யும் மக்கள் மிகவும் செல்வாக்காளர்களாக அங்கீகரிக்கப்படுகின்றனர், ஆனால் இது நடப்பு வேலைகளை அடிப்படையாகக் கொண்டது, வரலாற்று பங்களிப்பு அல்ல. முக்கிய திட்ட முடிவுகள், முழுமையான வாக்கெடுப்புக்கு பதிலாக ஒரு கருத்தொன்றைத் தேடும் செயல்முறையை அடிப்படையாகக் கொண்டு (பெரும் கவலையைப் பற்றிக் கொள்ளுதல்), மற்றும் சாத்தியமான பல சமூக முன்னோக்குகளை உள்ளடக்கியது. தாராளவாத பங்களிப்பு மாதிரி பயன்படுத்தும் திட்டங்களின் பிரபலமான உதாரணங்கள் [Node.js](https://foundation.nodejs.org/) and [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) + +## நான் என் திட்டத்தை தொடங்கும்போது ஆளுகை ஆவணங்கள் தேவையா? + +உங்கள் திட்டத்தின் நிர்வாகத்தை எழுதி வைக்க சரியான நேரம் என்று எதுவுமில்லை, ஆனால் உங்கள் சமூக இயக்கவியலை பார்த்தபின்பு, அதை வரையறுப்பது மிகவும் எளிது. Tதிறந்த மூல ஆளுமை பற்றி சிறந்த (மற்றும் கடினமான) பகுதியாக இது சமூகத்தால் வடிவமைக்கப்பட்டது! + +சில ஆரம்ப ஆவணங்கள் தவிர்க்க முடியாமல் உங்கள் திட்டத்தின் ஆளுமைக்கு பங்களிக்கின்றன, இருப்பினும், நீங்கள் என்ன செய்ய முடியுமென்பதை எழுதுங்கள். உதாரணமாக, நடத்தைக்கான தெளிவான எதிர்பார்ப்புகளை நீங்கள் வரையறுக்கலாம் அல்லது உங்கள் திட்டத்தின் தொடக்கத்தில் கூட, உங்கள் பங்களிப்பாளரின் செயல் எவ்வாறு இயங்குகிறது என்பதை நீங்கள் வரையறுக்கலாம். + +நீங்கள் ஒரு திறந்த மூல திட்டத்தை துவக்கும் நிறுவனத்தின் ஒரு அங்கமாக இருந்தால், உங்கள் நிறுவனமானது எவ்வாறு பராமரிப்பது மற்றும் திட்டத்தை முன்னோக்கி நகர்த்துவதற்கான முடிவுகளை எடுப்பது பற்றி அறிமுகப்படுத்துவதற்கு முன்பாக ஒரு உள் விவாதத்தை வைத்திருப்பது நன்று. திட்டத்தில் உங்கள் நிறுவனம் எப்படி ஈடுபடுவது (அல்லது முடியாது!) என்பது குறித்த அனைத்தையும் பகிரங்கமாக விளக்க விரும்பலாம். + + + +## பெருநிறுவன ஊழியர்கள் பங்களிப்புகளை சமர்ப்பிக்க ஆரம்பித்தால் என்ன நடக்கும்? + +வெற்றிகரமான திறந்த மூல திட்டங்கள் பல மக்களாலும் நிறுவனங்களாலும் பயன்படுத்தப்படுகின்றன, மேலும் சில நிறுவனங்களில் வருவாய் நீரோடைகள் திட்டத்தில் இணைந்திருக்கலாம். உதாரணமாக, ஒரு நிறுவனம் ஒரு வணிகச் சேவை வழங்கும் திட்டத்தின் ஒரு பகுதியாக திட்டத்தின் குறியீட்டைப் பயன்படுத்தலாம். + +திட்டம் மிகவும் பரவலாக பயன்படுத்தப்படும் பொழுது, நிபுணத்துவம் கொண்ட மக்கள் தேவை அதிகலாம்- நீங்கள் ஒருவராக இருக்கலாம்! - மற்றும் சில நேரங்களில் அவர்கள் திட்டத்தில் வேலை செய்ய பணம் கிடைக்கும். + +சாதாரணமாக வணிக ரீதியிலான செயல்பாடு மற்றும் அபிவிருத்தி ஆற்றலை மற்றொரு ஆதாரமாகக் கருதுவது முக்கியம். Pபணம் பெறும் நிரலாளர்கள் நிச்சயமாக செலுத்தப்படாதவர்களைவிட சிறப்பு சிகிச்சை பெறக்கூடாது; ஒவ்வொரு பங்களிப்பும் அதன் தொழில்நுட்ப தகுதிகளில் மதிப்பீடு செய்யப்பட வேண்டும். இருப்பினும், வணிக செயல்பாடுகளில் வசதியாக ஈடுபடுவதை உணர வேண்டும், மேலும் ஒரு குறிப்பிட்ட மேம்பாட்டிற்கோ அல்லது அம்சத்திற்கோ ஆதரவாக வாதிடும்போது, அவற்றின் பயன்பாடு வழக்குகள் குறித்து வசதியாக இருக்கும். + +"வணிகம்" என்பது "திறந்த மூலத்திற்கு" ஏற்புடையது. "வணிகம்" என்பது எங்காவது பணத்தை வைத்திருப்பது என்பது பொருள் - மென்பொருளானது வர்த்தகத்தில் பயன்படுத்தப்படுகிறது, இது ஒரு திட்டத்தை வெற்றிகரமாக ஏற்றுக்கொள்வது போன்றது. (திறந்த மூல மென்பொருளானது அல்லாத திறந்த மூல தயாரிப்புகளின் ஒரு பகுதியாக பயன்படுத்தப்படும்போது, மொத்த தயாரிப்பு இன்னும் "தனியுரிமை" மென்பொருளாகும், இருப்பினும், திறந்த மூலத்தைப் போல, இது வணிக ரீதியான அல்லது வணிகரீதியான நோக்கங்களுக்காக பயன்படுத்தப்படலாம்.) + +மற்றவர்களைப் போல, வணிக ரீதியாக ஊக்கமளிக்கும் நிரலாளர்கள் தங்கள் பங்களிப்புகளின் தரம் மற்றும் அளவு மூலம் திட்டத்தில் செல்வாக்கைப் பெறுகின்றனர். வெளிப்படையாக, பணம் பெறும் ஒரு நிரலாளர் பணம் இல்லாத ஒருவரைவிட அதிகமாகச் செய்யலாம், ஆனால் அது பரவாயில்லை: பணம் ஒருவர் எவ்வளவு செய்யலாம் என்பதை . பாதிக்கக்கூடிய பல காரணிகளில் ஒன்றாகும்.. உங்கள் திட்ட விவாதங்களை பங்களிப்புகளில் கவனம் செலுத்துங்கள், மக்களுக்கு அந்த பங்களிப்பை வழங்குவதற்கு வெளிப்புற காரணிகளில் அல்ல. + +## எனது திட்டத்தை ஆதரிக்க எனக்கு ஒரு சட்ட நிறுவனம் தேவைதானா? + +பணத்தை கையாளும் வரை உங்கள் திறந்த மூல திட்டத்தை ஆதரிக்க உங்களுக்கு ஒரு சட்ட நிறுவனம் தேவையில்லை. + +உதாரணமாக, நீங்கள் ஒரு வணிக வணிகத்தை உருவாக்க விரும்பினால், நீங்கள் ஒரு சி கார்ப் அல்லது எல்எல்சி ஒன்றை (நீங்கள் அமெரிக்க அடிப்படையிலேயே இருந்தால்) அமைக்க வேண்டும். உங்களுடைய திறந்த மூல திட்டத்துடன் தொடர்புடைய ஒப்பந்த வேலைகளை நீங்கள் செய்தால், நீங்கள் ஒரு தனி உரிமையாளராக பணத்தை ஏற்றுக்கொள்ளலாம் அல்லது எல்.எல்.சி (நீங்கள் அமெரிக்க அடிப்படையிலேயே இருந்தால்) ஒன்றை அமைக்கலாம். + +உங்கள் திறந்த மூல திட்டத்திற்கான நன்கொடைகளை நீங்கள் ஏற்றுக் கொள்ள விரும்பினால், நீங்கள் நன்கொடை பொத்தானை (உதாரணமாக பேபால் அல்லது ஸ்டரைப் பயன்படுத்தி) அமைத்துக்கொள்ளலாம், ஆனால் நீங்கள் தகுதியற்ற இலாப நோக்கில் இல்லாதபட்சத்தில் வரி விதிக்கப்படாது (ஒரு 501c3, நீங்கள் அமெரிக்காவில் இருந்தால்). + +பல திட்டங்கள் ஒரு இலாப நோக்கமற்ற அமைப்பை உருவாக்கும் சிக்கல் மூலம் செல்ல விரும்பவில்லை, எனவே அவர்கள் அதற்கு பதிலாக ஒரு லாப நோக்கற்ற நிதி ஆதரவாளரைக் காண்கிறார்கள். ஒரு நிதியளிப்பவர் உங்கள் சார்பில் நன்கொடைகளை ஏற்றுக்கொள்கிறார், வழக்கமாக நன்கொடையின் ஒரு சதவீதத்திற்கு பதிலாக. [மென்பொருள் சுதந்திர பாதுகாப்பு](https://sfconservancy.org/), [அப்பாச்சி அறக்கட்டளை](https://www.apache.org/), [எக்லிப்ஸ் அறக்கட்டளை](https://eclipse.org/org/), [லினக்ஸ் அறக்கட்டளை](https://www.linuxfoundation.org/projects) மற்றும் [திறந்த கூட்டு](https://opencollective.com/opensource) திறந்த மூல திட்டங்களுக்கு நிதி ஆதரவாளர்களாக செயல்படும் நிறுவனங்களின் எடுத்துக்காட்டுகள் ஆகும். + + + +உங்கள் திட்டம் ஒரு குறிப்பிட்ட மொழியோ அல்லது சுற்றுச்சூழலுக்கோ நெருங்கிய தொடர்புடையதாக இருந்தால், நீங்கள் வேலை செய்யக்கூடிய தொடர்புடைய மென்பொருள் அடித்தளம் இருக்கலாம். உதாரணமாக, [பைத்தான் மென்பொருள் அறக்கட்டளை](https://www.python.org/psf/) [PyPI](https://pypi.python.org/pypi) பைத்தான் தொகுப்பு மேலாளரை, மற்றும் [Node.js அறக்கட்டளை](https://foundation.nodejs.org/) [Express.js](https://expressjs.com/), a ஒரு நோட் Node-சார்ந்த கட்டமைப்பை ஆதரிக்க உதவுகிறது. diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md new file mode 100644 index 00000000000..9076b80168e --- /dev/null +++ b/_articles/ta/legal.md @@ -0,0 +1,157 @@ +--- +lang: ta +title: திறந்த மூல சட்டப் பிரிவு +description: திறந்த மூலத்தின் சட்ட பக்கத்தைப் பற்றி நீங்கள் எப்போதாவது யோசித்ததுண்டா, மற்றும் நீங்கள் யோசிக்காத சில விடயங்கள். +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## திறந்த மூலத்தின் சட்ட உட்குறிப்புகளை புரிந்துகொள்வது + +உலகம் முழுவதும் உங்கள் படைப்பு பணி பகிர்வது என்பது ஒரு அற்புதமான மற்றும் வெகுமதி உள்ள அனுபவமாக இருக்க முடியும். உங்களுக்குத் தெரியாத சட்ட விஷயங்களைக் குறித்து நீங்கள் கவலைப்பட வேண்டிய அவசியம் இருக்கும். Tஅதிர்ஷ்டவசமாக, நீங்கள் முதலில் இருந்து தொடங்க வேண்டும் என்றில்லை. உங்கள் சட்டப்பூர்வ தேவைகளை விளக்க நாங்கள் இருக்கிறோம். நீங்கள் தோண்டுவதற்கு முன், எங்கள் [மறுப்பை](/notices/) வாசிக்கவும்.) + +## திறந்த மூலத்தின் சட்ட பக்கத்தைப் பற்றி மக்கள் ஏன் அதிகம் கவலைப்படுகிறார்கள்? + +நீங்கள் கேட்டது மகிழ்ச்சி! நீங்கள் ஒரு படைப்பாற்றல் வேலை (எழுத்து, வரைகலை அல்லது குறியீடு போன்றவை) செய்யும்போது, அந்த வேலை இயல்பாகவே பிரத்யேக பதிப்புரிமையின் கீழ் உள்ளது. அதாவது, உங்கள் வேலையின் ஆசிரியராக, மற்றவர்களுடன் என்ன செய்யலாம் என்று ஒரு சொல் உள்ளது என்று சட்டம் கூறுகிறது. + +பொதுவாக, வேறு எவரும் பயன்படுத்த முடியாது, நகலெடுக்கலாம், விநியோகிக்கவோ அல்லது மாற்றவோ உங்கள் வேலையை எடுத்துக்கொள்வதன் மூலம், வீழ்ச்சி, மறுசீரமைப்பு அல்லது வழக்கு அபாயங்கள் ஆகியவை இல்லாமல் இருக்கலாம். + +திறந்த மூலம் ஒரு அசாதாரண சூழ்நிலையாகும், ஏனென்றால் மற்றவர்கள் பயன்படுத்துவதை, மாற்ற, மற்றும் பகிர்வைப் பகிர்ந்து கொள்வார்கள் என ஆசிரியர் எதிர்பார்க்கிறார். ஆனால் இயல்பான சட்டப்பூர்வ தனிப்பட்ட பதிப்புரிமை உடையது என்பதால், இந்த அனுமதிகளை வெளிப்படையாகக் குறிப்பிடும் உரிமம் உங்களுக்குத் தேவை. + +திறந்த மூல உரிமத்தை நீங்கள் பயன்படுத்தவில்லை என்றால், உங்கள் திட்டத்தில் பங்களிப்பவர்கள் எல்லோரும் தங்கள் வேலையின் ஒரு பிரத்தியேக பதிப்புரிமை வைத்திருப்பார்கள். இதன் பொருள் யாரும் தங்கள் பங்களிப்புகளை பயன்படுத்தவோ, நகலெடுக்கவோ, விநியோகிக்கவோ, மாற்றவோ முடியாது - மற்றும் "யாரும்" நீங்கள் உட்பட. + +இறுதியாக, உங்களுடைய திட்டம் உங்களுக்குத் தெரியாத உரிமத் தேவைகளை சார்ந்திருக்கும். உங்கள் திட்டத்தின் சமூகம், அல்லது உங்கள் முதலாளியின் கொள்கைகள், உங்கள் திட்டத்தில் குறிப்பிட்ட திறந்த மூல உரிமங்களைப் பயன்படுத்த வேண்டியிருக்கும். கீழே உள்ள சூழ்நிலைகளை நாங்கள் பாதுகாக்கிறோம். + +## கிட்ஹப்பில் உள்ள பொது திட்டங்கள் திறந்த மூலமா? + +கிட்ஹப்பில் நீங்கள் [புதிய திட்டம் ஒன்றை உருவாக்கும்](https://help.github.com/articles/creating-a-new-repository/) போது, **தனிப்பட்ட** அல்லது **பகிரங்கமான** களஞ்சியமாக உருவாக்க விருப்பத்தேர்வுகள் உள்ளன. + +![களஞ்சியத்தை உருவாக்கவும்](/assets/images/legal/repo-create-name.png) + +**உங்கள் கிட்ஹப் திட்டப்பணியை பொதுவில் வைப்பது என்பது உங்கள் திட்டத்திற்கு உரிமம் அளிப்பதை போல் அல்ல.** பொது திட்டங்கள் [கிட்ஹப் இன் சேவை விதிமுறைகளால்](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) பாதுகாக்கப்படுகின்றது,இது உங்கள் திட்டத்தை மற்றவர்களுக்குக் காண்பிப்பதற்கு மற்றும் கவைய அனுமதிக்கிறது, ஆனால் உங்கள் வேலை அனுமதி இன்றி வருகிறது. + +மற்றவர்கள் பயன்படுத்த விரும்பினால், விநியோகிக்கவும், மாற்றவும் அல்லது உங்கள் திட்டத்திற்கு பங்களிக்கவும் விரும்பினால், நீங்கள் திறந்த மூல உரிமத்தை சேர்க்க வேண்டும். எடுத்துக்காட்டுக்கு, உங்கள் கிட்ஹப் திட்டத்தின் எந்தவொரு பகுதியையும் அவர்கள் குறியீட்டில் சட்டபூர்வமாகப் பயன்படுத்த முடியாது, பொதுவில் இருந்தாலும், அவற்றை வெளிப்படையாக வழங்குவதற்கு உரிமை இல்லை. + +## என் திட்டத்தை நான் பாதுகாக்க வேண்டும் என்பதற்காக டி.எல்;டி.ஆர் தாருங்கள் + +உங்கள் அதிர்ஷ்டம், இன்று திறந்த மூல உரிமங்கள் தரநிலையானது மற்றும் பயன்படுத்த எளிதானது. ஏற்கனவே உள்ள உரிமத்தை நேரடியாக உங்கள் திட்டத்தில் நகலெடுக்கலாம். + +[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/) காணலாம். + +நீங்கள் கிட்ஹப்பில் ஒரு புதிய திட்டத்தை உருவாக்கும்போது, நீங்கள் [உரிமத்தைச் சேர்க்கும்படி கேட்கப்படும்](https://help.github.com/articles/open-source-licensing/). + + + +## எனது திட்டத்திற்கு எந்த திறந்த மூல உரிமம் பொருத்தமானது? + +நீங்கள் ஒரு வெற்று கற்பலகையில் தொடங்கி இருந்தால், [MIT உரிமத்துடன்](https://choosealicense.com/licenses/mit/) செல்வதில் தவறிருக்காது. இது சிறியது, புரிந்து கொள்ள மிகவும் எளிது, உங்கள் காப்புரிமை அறிவிப்பு உள்ளிட்ட உரிமத்தின் நகல் ஒன்றை வைத்திருக்கும் வரை யாரும் எதையாவது செய்ய அனுமதிக்கிறார்கள். Yஉங்களுக்கு எப்போது வேண்டுமானாலும் நீங்கள் வேறு உரிமத்தின் கீழ் இந்த திட்டத்தை வெளியிட முடியும். + +இல்லையெனில், உங்கள் திட்டத்திற்கான சரியான திறந்த மூல உரிமத்தை தேர்ந்தெடுப்பது உங்கள் நோக்கங்களைப் பொறுத்தது. + +Yஉங்கள் திட்டம் **சார்புகள்** கொண்டிருக்க (அல்லது கொள்ள) மிகவும் சாத்தியம் உள்ளது. உதாரணமாக, நீங்கள் ஒரு Node.js திட்டத்தை திறந்தால், ஒருவேளை நீங்கள் Node தொகுப்பு மேலாளர் (npm) இலிருந்து நூலகங்களைப் பயன்படுத்துவீர்கள். நீங்கள் சார்ந்துள்ள அந்த நூலகங்களில் ஒவ்வொன்றும் அதன் சொந்த திறந்த மூல உரிமம் பெற்றிருக்கும். அவற்றின் உரிமங்களில் ஒவ்வொன்றும் "அனுமதி" (கீழ்நிலை உரிமத்திற்கான எந்தவொரு நிபந்தனையும் இல்லாமல், பயன்படுத்த, மாற்ற, மற்றும் பகிர்வதற்கு பொது அனுமதி அளிக்கிறது), நீங்கள் விரும்பும் உரிமத்தை நீங்கள் பயன்படுத்தலாம். MIT, Apache 2.0, ISC, மற்றும் BSD.q ஆகியவை பொதுவான அனுமதிப்பத்திர உரிமங்களாகும். + +மறுபுறம், உங்கள் சார்பற்ற உரிமங்களில் ஏதேனும் "வலுவான நகல்" (அதே பொது உரிமத்தை கீழ்க்கண்ட உரிமத்தைப் பயன்படுத்தி நிபந்தனைக்கு உட்படுத்தலாம்), உங்கள் திட்டம் அதே உரிமத்தைப் பயன்படுத்த வேண்டும். GPLv2, GPLv3, மற்றும் AGPLv3 ஆகியவை பொது வலுவான அளிப்புரிமை உரிமங்களாகும். + +மேலும் நீங்கள் உங்கள் திட்டத்தினைப் பயன்படுத்தம் மற்றும் பங்களிக்கும் **சமூகங்களை** கருத்தில் கொள்ள வேண்டும். + +* **மற்ற திட்டங்களின் சார்பாக உங்கள் திட்டம் பயன்படுத்தப்பட வேண்டுமா?** உங்கள் தொடர்புடைய சமூகத்தில் மிகவும் பிரபலமான உரிமையைப் பயன்படுத்த சிறந்தது. உதாரணமாக, [எம்ஐடி] (https://choosealicense.com/licenses/mit/) என்பது [npm நூலகங்களுக்கு](https://libraries.io/npm) மிகவும் பிரபலமான உரிமம். +* **உங்கள் திட்டம் பெரிய வணிகங்களுக்கு மேல் முறையிட வேண்டுமா?** ஒரு பெரிய வணிக வாய்ப்பு அனைத்து பங்களிப்பாளர்கள் ஒரு வெளிப்படையான காப்புரிமை உரிமம் வேண்டும். இந்த வழக்கில், [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) உங்களை (மற்றும் அவற்றை) பாதுகாக்கும். +* **மூடப்பட்ட மூல மென்பொருள் தங்கள் பங்களிப்புகளை பயன்படுத்த விரும்பாத பங்களிப்பாளர்களுக்கு உங்கள் திட்டம் மேல்முறையீடு செய்ய விரும்புகிறீர்களா?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (அவர்கள் மூடிய மூல சேவைகள் பங்களிக்க விரும்பவில்லை என்றால்) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) நன்றாக இருக்கும். + +உங்கள் **நிறுவனம்** அதன் திறந்த மூல திட்டங்களுக்கான குறிப்பிட்ட உரிமத் தேவைகளைக் கொண்டிருக்கலாம். உதாரணமாக, நிறுவனத்தின் மூடப்பட்ட மூல தயாரிப்புகளில் உங்கள் திட்டத்தை நிறுவனம் பயன்படுத்த முடியும் என்பதற்கு ஒரு அனுமதிக்கப்பட்ட உரிமம் தேவைப்படலாம். அல்லது உங்களுடைய நிறுவனம் ஒரு வலுவான கோப்பாய் உரிமம் மற்றும் கூடுதலான பங்களிப்பு ஒப்பந்தம் (கீழே பார்க்கவும்) தேவைப்படலாம், அதனால் உங்கள் நிறுவனம் மட்டுமே மூல மென்பொருள் உங்கள் திட்டத்தை மட்டுமே பயன்படுத்த முடியும், வேறு யாரும் பயன்படுத்த முடியாது. அல்லது உங்களுடைய நிறுவனம் தரநிலைகள், சமூக பொறுப்புக்கள் அல்லது வெளிப்படைத்தன்மை தொடர்பான சில தேவைகளைக் கொண்டிருக்கலாம், அதில் எந்தவொரு குறிப்பிட்ட உரிம மூலோபாயம் தேவைப்படும். உங்கள் [நிறுவனத்தின் சட்ட துறையிடம்](#எனது-நிறுவனத்தின்-சட்ட-குழு-என்ன-அறிந்து-கொள்ள-வேண்டும்) பேசுங்கள். + +நீங்கள் கிட்ஹப்பில் புதிய திட்டத்தை உருவாக்கும்போது, உரிமம் ஒன்றைத் தேர்ந்தெடுக்க உங்களுக்கு விருப்பத்தேர்வு உள்ளது. மேலே குறிப்பிட்ட உரிமங்களில் ஒன்று உங்கள் கிட்ஹப் திட்டத்தின் திறந்த மூலத்தை உருவாக்கும். பிற விருப்பங்களை நீங்கள் காண விரும்பினால், உங்கள் திட்டத்திற்கு சரியான உரிமம் கண்டுபிடிக்க [choosealicense.com](https://choosealicense.com), அது [மென்பொருள் இல்லையென்றாலும்](https://choosealicense.com/non-software/). + +## எனது திட்டத்தின் உரிமத்தை மாற்ற விரும்பினால் என்ன செய்வது? + +பெரும்பாலான திட்டங்கள் உரிமங்களை மாற்ற வேண்டியதில்லை. ஆனால் எப்போதாவது சூழ்நிலைகள் மாறுகின்றன. + +உதாரணமாக, உங்கள் திட்டம் வளர்ந்தால், சார்புகள் அல்லது பயனர்களை சேர்க்கிறது அல்லது உங்கள் நிறுவனத்தின் உத்திகளில் மாற்றங்கள், அவற்றில் ஏதேனும் வேறு உரிமம் தேவைப்படலாம் அல்லது விரும்பும். மேலும், உங்கள் திட்டத்தை தொடக்கத்திலிருந்து உரிமையாக்குவதற்கு நீங்கள் புறக்கணிக்கப்பட்டால், ஒரு உரிமத்தைச் சேர்ப்பது உரிமங்களை மாற்றுவது போலவே. உங்கள் திட்டத்தின் உரிமத்தை சேர்ப்பது அல்லது மாற்றியமைக்கும் போது மூன்று அடிப்படை விஷயங்கள் உள்ளன: + +**இது சிக்கலானது.** உரிமம் பொருந்தக்கூடிய தன்மை மற்றும் இணக்கத்தைத் தீர்மானித்தல் மற்றும் பதிப்புரிமை வைத்திருப்பவர் சிக்கலையும் மற்றும் மிக விரைவாக குழப்பத்தை ஏற்படுத்தும். புதிய வெளியீடுகள் மற்றும் பங்களிப்புகளுக்கான புதிய ஆனால் இணக்கமான உரிமத்திற்கு மாறுதல் என்பது ஏற்கனவே உள்ள அனைத்து பங்களிப்புகளையும் மறுசீரமைப்பதில் இருந்து வேறுபட்டதாகும். உரிமங்களை மாற்ற விரும்பும் எந்தவொரு விருப்பத்திற்கும் உங்கள் சட்டக் குழுவை ஈடுபடுத்தவும். உங்களுடைய திட்டத்தின் காப்புரிமை வைத்திருப்பவர்களிடமிருந்து உரிமம் மாற்றத்திற்கான அனுமதி கிடைத்திருந்தாலும் அல்லது உங்கள் திட்டத்தின் மற்ற பயனர்கள் மற்றும் பங்களிப்பாளர்களின் மாற்றத்தின் தாக்கத்தை கருத்தில் கொள்ளுங்கள். உங்கள் திட்டத்தின் ஒரு "ஆளுமை நிகழ்வு" என உரிம மாற்றத்தை பற்றி யோசிக்கவும், இது உங்கள் திட்டத்தின் பங்குதாரர்களுடன் தெளிவான தகவல்தொடர்பு மற்றும் ஆலோசனைகளுடன் மென்மையாக செல்லலாம். உங்கள் திட்டத்திற்கான சரியான உரிமம் ஒன்றைத் தேர்வுசெய்து அதைப் பயன்படுத்துவதற்கான அனைத்து காரணங்களும் அதன் துவக்கத்திலிருந்து! + +**உங்கள் திட்டத்தின் தற்போதைய உரிமம்.** உங்கள் திட்டத்தின் தற்போதைய உரிமம் நீங்கள் மாற்ற விரும்பும் அனுமதிப்பத்திரத்துடன் இணக்கமாக இருந்தால், புதிய உரிமத்தைப் பயன்படுத்த ஆரம்பிக்கலாம். ஏனெனில் உரிமம் A உரிமம் B உடன் இணக்கமாக இருந்தால், நீங்கள் B இன் விதிமுறைகளை கடைப்பிடிப்பதன் மூலம் (ஆனால் மறுதலையாக அல்லாமல்) இணங்குவீர்கள். எனவே, நீங்கள் தற்போது அனுமதிப்பத்திர அனுமதிப்பத்திரத்தை (எ.கா., MIT) பயன்படுத்துகிறீர்கள் என்றால், MIT உரிமத்தின் நகல் மற்றும் தொடர்புடைய பதிப்புரிமை அறிவிப்புகளை (அதாவது, MIT உரிமத்தின் குறைந்தபட்ச நிலைமைகளுக்கு இணங்குதல்). ஆனால் உங்கள் தற்போதைய உரிமம் அனுமதி இல்லை என்றால் (எ.கா., நகலெடுப்பு அல்லது உங்களுக்கு உரிமம் இல்லை) மற்றும் நீங்கள் ஒரே பதிப்புரிமை வைத்திருப்பவர் அல்ல, உங்கள் திட்டத்தின் உரிமத்தை MITஐ மாற்ற முடியாது. அடிப்படையில், அனுமதிப்பத்திர உரிமம், திட்டத்தின் பதிப்புரிமை வைத்திருப்பவர்கள் உரிமங்களை மாற்ற முன்கூட்டியே அனுமதியளித்தனர். + +**உங்கள் திட்டத்தின் தற்போதைய பதிப்புரிமை வைத்திருப்பவர்கள்.** நீங்கள் உங்கள் திட்டத்திற்கு ஒரே பங்களிப்பாளராக இருந்தால், நீங்கள் அல்லது உங்கள் நிறுவனம் திட்டத்தின் ஒரே பதிப்புரிமை வைத்திருப்பவர். நீங்கள் அல்லது உங்களுடைய நிறுவனம் விரும்பும் உரிமையை நீங்கள் சேர்க்கலாம் அல்லது மாற்றலாம். இல்லையெனில் உரிமங்களை மாற்றுவதற்கு உங்களிடம் உடன்பாடு தேவை என்று பிற பதிப்புரிமை வைத்திருப்பவர்கள் இருக்கலாம். அவர்கள் யார்? உங்கள் திட்டத்தில் ஈடுபடும் மக்கள் தொடங்க ஒரு நல்ல இடம். ஆனால் சில சந்தர்ப்பங்களில் அந்த நபர்களின் முதலாளிகளின் பதிப்புரிமை வைத்திருப்பர். சில சந்தர்ப்பங்களில் மக்கள் குறைந்த பட்ச பங்களிப்புகளை மட்டுமே செய்துள்ளனர், ஆனால் சில வரிகளின் கீழ் பதிப்புரிமைக்கு உட்பட்ட பங்களிப்பு இல்லை என்பதற்கு கடுமையான மற்றும் வேகமான விதி இல்லை. என்ன செய்ய? அது சார்ந்துள்ளது. ஒப்பீட்டளவில் சிறிய மற்றும் இளம் திட்டத்திற்காக, ஒரு சிக்கலில் உள்ள அனைத்து உரிமையாளர்களுக்கும் உரிமம் மாற்றத்தை ஏற்றுக்கொள்ள அல்லது இழு கோரிக்கையை ஏற்றுக்கொள்வது சாத்தியமானதாக இருக்கலாம். பெரிய மற்றும் நீண்ட கால திட்டங்களுக்கு, நீங்கள் பல பங்களிப்பாளர்கள் மற்றும் அவர்களது வாரிசுகளைத் தேட வேண்டும். பயர்பாக்ஸ், தண்டர்பேர்ட் மற்றும் அதனுடன் தொடர்புடைய மென்பொருட்களை மேம்படுத்த மொசில்லாவிற்கு ஆண்டுகள் (2001-2006) எடுத்தது. + +மாற்றாக, உங்கள் தற்போதைய திறந்த மூல உரிமத்தால் அனுமதிக்கப்படும் சில நிபந்தனைகளின் கீழ், சில உரிமங்களில் சில உரிம மாற்றங்களுக்கு முன்கூட்டியே நீங்கள் பங்களிப்பாளர்கள் (கூடுதல் பங்களிப்பு ஒப்பந்தம் வழியாக - பார்க்கவும்) ஒப்புக் கொள்ள முடியும். இது சிறிதளவு உரிமங்களை மாற்றியமைக்கும் சிக்கலான மாற்றத்தை மாற்றுகிறது. உங்களுடைய வழக்கறிஞர்களின் உதவியுடன் உங்களுக்கு அதிக உதவி தேவைப்படலாம், மேலும் உங்கள் திட்டத்தின் உரிமையாளரின் உரிமையாளர் மாற்றத்தை நிறைவேற்றும்போது நீங்கள் தெளிவாகத் தெரிவிக்க வேண்டும். + +## எனது திட்டத்திற்கு கூடுதல் பங்களிப்பு ஒப்பந்தம் வேண்டுமா? + +அநேகமாக இல்லை. பெரும்பாலான திறந்த மூல திட்டங்களுக்கு,திறந்த மூல உரிமம் உட்குறிப்பாக (பங்களிப்பாளர்களிடமிருந்து) மற்றும் வெளியில் (மற்ற பங்களிப்பாளர்களுக்கும் பயனர்களுக்கும்) உரிமம் வழங்கப்படுகிறது. உங்கள் திட்டம் கிட்ஹப்பில் இருந்தால், கிட்ஹப் சேவை விதிமுறைகள் "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://github.com/probot/dco) ஒரு மாற்று இருக்க முடியும். +* உங்கள் திட்டம் ஒரு வெளிப்படையான ஆதார உரிமையைப் பயன்படுத்துகிறது, இது ஒரு வெளிப்படையான காப்புரிமை வழங்கலை (MIT போன்றவை) உள்ளடக்குவதில்லை, மேலும் அனைத்து பங்களிப்பாளர்களிடமிருந்தும் ஒரு காப்புரிமை வழங்கல் உங்களுக்கு தேவைப்படுகிறது, அவர்களில் சிலர் உங்களிடமுள்ள பெரிய காப்புரிமை பிரிவில் உள்ள நிறுவனங்களுக்கு வேலை செய்யலாம், உங்களை அல்லது திட்டத்தின் மற்ற பங்களிப்பாளர்கள் மற்றும் பயனர்கள் குறி வைக்கலாம். [அப்பாச்சி உரிமையாளர் உரிம ஒப்பந்தம்](https://www.apache.org/licenses/icla.pdf) பொதுவாகப் பயன்படுத்தப்படும் கூடுதலான பங்களிப்பு ஒப்பந்தம் ஆகும், இது அப்பாச்சி உரிமம் 2.0 இல் காணப்பட்ட ஒரு காப்புரிமை மானியத்தை பிரதிபலிக்கிறது. +* உங்கள் திட்டம் நகலெடுப்பு உரிமத்தின் கீழ் உள்ளது, ஆனால் நீங்கள் திட்டத்தின் தனியுரிம பதிப்புகளை விநியோகிக்க வேண்டும். உங்களிடம் பதிப்புரிமையை வழங்குவதற்கு அல்லது பங்களிப்பு உரிமத்தை உங்களுக்கு வழங்க (ஆனால் பொதுமக்கள் அல்ல) உங்களுக்கு ஒவ்வொரு பங்காளருக்கும் தேவைப்படும். [மாங்கோ பங்களிப்பாளர் ஒப்பந்தம்](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/) இலவச மற்றும் திறந்த மூல திட்டங்களின் சூழலில் வணிக முத்திரைகளை புரிந்து கொள்ள நடைமுறை வழிகாட்டியாகும். + +* **தனியுரிமை:** பயனர்கள் குறித்த தரவுகளை உங்கள் திட்டம் சேகரிக்கிறதா? நிறுவனம் சேவையகங்களுக்கு "தொலைபேசி வீடு"? நிறுவன சட்டங்கள் மற்றும் புற ஒழுங்குமுறைகளுடன் இணங்குமாறு உங்கள் சட்ட குழு உங்களுக்கு உதவும். + +உங்கள் நிறுவனத்தின் முதல் திறந்த மூல திட்டத்தை வெளியிடுகிறீர்கள் என்றால், மேலே உள்ளதை விட அதிகமானதை விட அதிகமாக உள்ளது (ஆனால் கவலை வேண்டாம், பெரும்பாலான திட்டங்கள் எந்த முக்கிய கவலையும் எழுப்பக்கூடாது). + +நீண்ட காலமாக, உங்கள் சட்ட குழு நிறுவனம், திறந்த மூலத்தில் அதன் ஈடுபாட்டிலிருந்து நிறுவனத்தின் உதவியை அதிகரிக்க உதவ முடியும், மேலும் பாதுகாப்பாக இருக்கவும்: + +* **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/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/ta/maintaining-balance-for-open-source-maintainers.md b/_articles/ta/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..43cd8312dee --- /dev/null +++ b/_articles/ta/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,219 @@ +--- +lang: ta +title: திறந்த மூல பராமரிப்பாளர்களுக்கு சமநிலையை பராமரித்தல் +description: சுய பராமரிப்புக்கான உதவிக்குறிப்புகள் மற்றும் ஒரு பராமரிப்பாளராக எரிவதைத் தவிர்ப்பது. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +ஒரு திறந்த மூல திட்டம் பிரபலமடைந்து வருவதால், நீண்ட காலத்திற்கு புத்துணர்ச்சியுடனும், உற்பத்தித்திறனாகவும் இருக்க சமநிலையை பராமரிக்க உங்களுக்கு உதவ தெளிவான எல்லைகளை அமைப்பது முக்கியம். + +பராமரிப்பாளர்களின் அனுபவங்கள் மற்றும் சமநிலையைக் கண்டுபிடிப்பதற்கான அவர்களின் உத்திகள் பற்றிய நுண்ணறிவுகளைப் பெற, பராமரிப்பாளர் சமூகம் இன் 40 உறுப்பினர்களுடன் நாங்கள் ஒரு பட்டறையை நடத்தினோம், இது திறந்த மூலத்தில் எரியும் மற்றும் அவர்களின் பணிகளைத் தக்கவைத்துக் கொள்ள உதவிய நடைமுறைகளுடனான அவர்களின் மோசமான அனுபவங்களிலிருந்து கற்றுக்கொள்ள அனுமதிக்கிறது. தனிப்பட்ட சூழலியல் கருத்து நடைமுறைக்கு வருகிறது. + +தனிப்பட்ட சூழலியல் என்றால் என்ன? ராக்வுட் தலைமைத்துவ நிறுவனத்தால் விவரிக்கப்பட்ட, இது "வாழ்நாள் முழுவதும் நமது ஆற்றலைத் தக்கவைக்க சமநிலை, வேகம் மற்றும் செயல்திறனைப் பராமரித்தல்" ஆகியவற்றை உள்ளடக்கியது. இது எங்கள் உரையாடல்களை வடிவமைத்து, பராமரிப்பாளர்கள் தங்கள் செயல்களையும் பங்களிப்புகளையும் காலப்போக்கில் உருவாகும் ஒரு பெரிய சுற்றுச்சூழல் அமைப்பின் பகுதிகளாக அங்கீகரிக்க உதவுகிறது. [WHO ஆல் வரையறுக்கப்பட்டுள்ளது](https://icd.who.int/browse/2025-01/foundation/en#129180281) நாள்பட்ட பணியிட மன அழுத்தத்தின் விளைவாக ஏற்படும் ஒரு நோய்க்குறியான எரிதல், பராமரிப்பாளர்களிடையே அசாதாரணமானது அல்ல. இது பெரும்பாலும் உந்துதல் இழப்பு, கவனம் செலுத்த இயலாமை மற்றும் நீங்கள் பணிபுரியும் பங்களிப்பாளர்கள் மற்றும் சமூகத்தின் மீது பச்சாதாபம் இல்லாததற்கு வழிவகுக்கிறது. + + + +தனிப்பட்ட சூழலியல் கருத்தை ஏற்றுக்கொள்வதன் மூலம், பராமரிப்பாளர்கள் எரியைத் தவிர்க்கலாம், சுய பாதுகாப்புக்கு முன்னுரிமை அளிக்கலாம், மேலும் அவர்களின் சிறந்த வேலையைச் செய்ய சமநிலை உணர்வை நிலைநிறுத்தலாம். + +## சுய பராமரிப்புக்கான உதவிக்குறிப்புகள் மற்றும் ஒரு பராமரிப்பாளராக எரிவதைத் தவிர்ப்பது: + +### திறந்த மூலத்தில் பணியாற்றுவதற்கான உங்கள் உந்துதல்களை அடையாளம் காணவும் + +திறந்த மூல பராமரிப்பின் எந்த பகுதிகள் உங்களை உற்சாகப்படுத்துகின்றன என்பதைப் பிரதிபலிக்க நேரம் ஒதுக்குங்கள். உங்கள் உந்துதல்களைப் புரிந்துகொள்வது, உங்கள் ஈடுபாட்டையும் புதிய சவால்களுக்கும் தயாராக இருக்கும் வகையில் வேலைக்கு முன்னுரிமை அளிக்க உதவும். இது பயனர்களிடமிருந்து நேர்மறையான பின்னூட்டமாக இருந்தாலும், சமூகத்துடன் ஒத்துழைப்பதற்கும் சமூகமயமாக்குவதன் மகிழ்ச்சியும் அல்லது குறியீட்டில் டைவிங் செய்வதன் திருப்தி, உங்கள் உந்துதல்களை அங்கீகரிப்பது உங்கள் கவனத்தை வழிநடத்த உதவும். + +### நீங்கள் சமநிலையிலிருந்து வெளியேறவும், வலியுறுத்தவும் என்ன காரணம் என்பதைப் பற்றி சிந்தியுங்கள் + +நாம் எரிக்கப்படுவதற்கு என்ன காரணம் என்பதைப் புரிந்துகொள்வது முக்கியம். திறந்த மூல பராமரிப்பாளர்களிடையே நாங்கள் கண்ட சில பொதுவான கருப்பொருள்கள் இங்கே: + +* **நேர்மறையான கருத்துக்கள் இல்லாதது:** பயனர்கள் புகார் இருக்கும்போது அடைய அதிக வாய்ப்புள்ளது. எல்லாம் நன்றாக வேலை செய்தால், அவர்கள் அமைதியாக இருக்க முனைகிறார்கள். உங்கள் பங்களிப்புகள் எவ்வாறு வித்தியாசத்தை ஏற்படுத்துகின்றன என்பதைக் காட்டும் நேர்மறையான பின்னூட்டமின்றி வளர்ந்து வரும் சிக்கல்களின் பட்டியலைக் காண்பது ஊக்கமளிக்கும். + + + +* **'இல்லை' என்று சொல்லவில்லை:** திறந்த மூல திட்டத்தில் நீங்கள் செய்ய வேண்டியதை விட அதிக பொறுப்புகளை ஏற்றுக்கொள்வது எளிதானது. இது பயனர்கள், பங்களிப்பாளர்கள் அல்லது பிற பராமரிப்பாளர்களிடமிருந்து வந்தாலும் - நாங்கள் எப்போதும் அவர்களின் எதிர்பார்ப்புகளுக்கு ஏற்ப வாழ முடியாது. + + + +* **தனியாக வேலை செய்வது:** ஒரு பராமரிப்பாளராக இருப்பது முற்றிலும் தனிமையாக உணர முடியும். நீங்கள் பராமரிப்பாளர்களின் குழுவுடன் பணிபுரிந்திருந்தாலும், கடந்த சில ஆண்டுகளில் விநியோகிக்கப்பட்ட அணிகளை ஒன்றிணைப்பது கடினம். + + + +* **போதுமான நேரம் அல்லது வளங்கள் இல்லை:** ஒரு திட்டத்தில் பணியாற்ற தங்கள் இலவச நேரத்தை தியாகம் செய்ய வேண்டிய தன்னார்வ பராமரிப்பாளர்களுக்கு இது குறிப்பாக உண்மை. + + + +* **முரண்பட்ட கோரிக்கைகள்:** திறந்த மூலக் குழுக்கள் பல்வேறு நோக்கங்களைக் கொண்ட குழுக்களால் நிறைந்துள்ளன, அவற்றை வழிநடத்துவது கடினமாக இருக்கலாம். திறந்த மூலக் குழுவில் பணியாற்ற உங்களுக்கு பணம் வழங்கப்பட்டால், உங்கள் முதலாளியின் நலன்கள் சில நேரங்களில் சமூகத்துடன் முரண்படக்கூடும். + + + +### சோர்வு அறிகுறிகளைக் கவனியுங்கள் + +உங்களால் 10 வாரங்களா? 10 மாதங்களா? 10 வருடங்களா? உங்கள் வேகத்தைத் தொடர முடியுமா? + +[@shaunagm](https://github.com/shaunagm) இல் உள்ள [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) போன்ற கருவிகள் உங்கள் தற்போதைய வேகத்தைப் பற்றி சிந்திக்கவும், நீங்கள் செய்யக்கூடிய ஏதேனும் மாற்றங்கள் உள்ளதா என்பதைப் பார்க்கவும் உதவும். சில பராமரிப்பாளர்கள் தூக்கத்தின் தரம் மற்றும் இதயத் துடிப்பு மாறுபாடு (இரண்டும் மன அழுத்தத்துடன் தொடர்புடையது) போன்ற அளவீடுகளைக் கண்காணிக்க அணியக்கூடிய தொழில்நுட்பத்தையும் பயன்படுத்துகின்றனர். + + + +### உங்களையும் உங்கள் சமூகத்தையும் தொடர்ந்து நிலைநிறுத்த உங்களுக்கு என்ன தேவை? + +இது ஒவ்வொரு பராமரிப்பாளருக்கும் வித்தியாசமாகத் தோன்றும், மேலும் உங்கள் வாழ்க்கையின் கட்டம் மற்றும் பிற வெளிப்புற காரணிகளைப் பொறுத்து மாறும். ஆனால் நாங்கள் கேள்விப்பட்ட சில கருப்பொருள்கள் இங்கே: + +* **சமூகத்தின் மீது சாய்ந்து கொள்ளுங்கள்.:** பங்களிப்பாளர்களையும் பிரதிநிதித்துவத்தையும் கண்டுபிடிப்பது, இதனால் பணிச்சுமையைக் குறைக்க முடியும். ஒரு திட்டத்திற்காக பல தொடர்பு புள்ளிகள் இருப்பது கவலைப்படாமல் ஓய்வு எடுக்க உதவும். [Maintainer Community](http://maintainers.github.com/) போன்ற குழுக்களில் பிற பராமரிப்பாளர்களுடனும் பரந்த சமூகத்துடனும் இணையுங்கள். சகாக்களின் ஆதரவு மற்றும் கற்றலுக்கு இது ஒரு சிறந்த ஆதாரமாக இருக்கும். + + பயனர் சமூகத்துடன் ஈடுபடுவதற்கான வழிகளையும் நீங்கள் தேடலாம், இதன் மூலம் நீங்கள் தொடர்ந்து கருத்துக்களைக் கேட்கவும், உங்கள் திறந்த மூலப் பணியின் தாக்கத்தைப் புரிந்துகொள்ளவும் முடியும். + +* **நிதி தேடுங்கள்:** நீங்கள் பீட்சாவிற்கு ஸ்பான்சர் செய்ய யாரையாவது தேடினாலும் சரி, அல்லது முழுநேர ஓப்பன் சோர்ஸுக்கு மாற முயற்சித்தாலும் சரி, உதவ பல ஆதாரங்கள் உள்ளன! முதல் படியாக, உங்கள் ஓப்பன் சோர்ஸ் வேலையை மற்றவர்கள் ஸ்பான்சர் செய்ய அனுமதிக்க [GitHub ஸ்பான்சர்கள்](https://github.com/sponsors) ஐ இயக்குவதைக் கருத்தில் கொள்ளுங்கள். முழுநேரத்திற்கு முன்னேறுவது பற்றி நீங்கள் யோசித்தால், [GitHub Accelerator](http://accelerator.github.com/) இன் அடுத்த சுற்றுக்கு விண்ணப்பிக்கவும். + + + +* **கருவிகளைப் பயன்படுத்துங்கள்:** [GitHub Copilot](https://github.com/features/copilot/) மற்றும் [GitHub Actions](https://github.com/features/actions) போன்ற கருவிகளைப் பயன்படுத்தி சாதாரணமான பணிகளை தானியக்கமாக்கி, அர்த்தமுள்ள பங்களிப்புகளுக்கு உங்கள் நேரத்தை மிச்சப்படுத்துங்கள். + + + +* **ஓய்வெடுத்து புத்துணர்ச்சி பெறுங்கள்:** திறந்த மூலத்தைத் தவிர்த்து உங்கள் பொழுதுபோக்குகள் மற்றும் ஆர்வங்களுக்கு நேரம் ஒதுக்குங்கள். வார இறுதி நாட்களில் ஓய்வெடுக்கவும் புத்துணர்ச்சி பெறவும் விடுமுறை எடுத்துக் கொள்ளுங்கள் - மேலும் உங்கள் கிடைக்கும் தன்மையை பிரதிபலிக்கும் வகையில் உங்கள் [GitHub நிலையை](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) அமைக்கவும்! ஒரு நல்ல இரவு தூக்கம் உங்கள் முயற்சிகளை நீண்ட காலத்திற்குத் தக்கவைத்துக்கொள்ளும் திறனில் பெரிய வித்தியாசத்தை ஏற்படுத்தும். + + உங்கள் திட்டத்தின் சில அம்சங்கள் குறிப்பாக சுவாரஸ்யமாக இருந்தால், உங்கள் வேலையை நாள் முழுவதும் அனுபவிக்கும் வகையில் கட்டமைக்க முயற்சிக்கவும். + + + +* **எல்லைகளை அமைக்கவும்:** ஒவ்வொரு கோரிக்கைக்கும் நீங்கள் ஆம் என்று சொல்ல முடியாது. இது, "இப்போது என்னால் அதை அடைய முடியாது, எதிர்காலத்தில் எனக்கு எந்த திட்டமும் இல்லை" என்று சொல்வது போலவோ அல்லது README இல் நீங்கள் என்ன செய்ய விரும்புகிறீர்கள், என்ன செய்யக்கூடாது என்பதை பட்டியலிடுவது போலவோ எளிமையாக இருக்கலாம். உதாரணமாக, நீங்கள் இவ்வாறு கூறலாம்: "அவை ஏன் செய்யப்பட்டன என்பதற்கான காரணங்களை தெளிவாக பட்டியலிட்ட PRகளை மட்டுமே நான் ஒன்றிணைக்கிறேன்" அல்லது "மாற்று வியாழக்கிழமைகளில் மாலை 6 - 7 மணி வரை மட்டுமே நான் சிக்கல்களை மதிப்பாய்வு செய்கிறேன்." இது மற்றவர்களுக்கான எதிர்பார்ப்புகளை அமைக்கிறது, மேலும் உங்கள் நேரத்தில் பங்களிப்பாளர்கள் அல்லது பயனர்களிடமிருந்து வரும் தேவைகளைத் தணிக்க உதவும் வகையில் மற்ற நேரங்களில் சுட்டிக்காட்ட ஏதாவது ஒன்றை உங்களுக்கு வழங்குகிறது. + + + + நச்சு நடத்தை மற்றும் எதிர்மறை தொடர்புகளை நிறுத்துவதில் உறுதியாக இருக்க கற்றுக்கொள்ளுங்கள். நீங்கள் அக்கறை கொள்ளாத விஷயங்களுக்கு முயற்சி செய்யாமல் இருப்பது சரி. + + + + + +நினைவில் கொள்ளுங்கள், தனிப்பட்ட சூழலியல் என்பது உங்கள் திறந்த மூல பயணத்தில் நீங்கள் முன்னேறும்போது உருவாகும் ஒரு தொடர்ச்சியான நடைமுறையாகும். சுய பாதுகாப்புக்கு முன்னுரிமை அளித்து சமநிலை உணர்வைப் பேணுவதன் மூலம், திறந்த மூல சமூகத்திற்கு நீங்கள் திறம்பட மற்றும் நிலையான முறையில் பங்களிக்க முடியும், இது உங்கள் நல்வாழ்வையும் நீண்ட காலத்திற்கு உங்கள் திட்டங்களின் வெற்றியையும் உறுதி செய்கிறது. + +## கூடுதல் வளங்கள் + +* [பராமரிப்பாளர் சமூகம்](http://maintainers.github.com/) +* [திறந்த மூல சமூக ஒப்பந்தம்](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [நச்சுத்தன்மையுள்ளவர்களை எப்படி கையாள்வது](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [ராக்வுட்டின் தலைமைத்துவக் கலை](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid +* [Governing Open](https://governingopen.com/) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series + +## பங்களிப்பாளர்கள் + +இந்த வழிகாட்டிக்காக தங்கள் அனுபவங்களையும், உதவிக்குறிப்புகளையும் எங்களுடன் பகிர்ந்து கொண்ட அனைத்து பராமரிப்பாளர்களுக்கும் மிக்க நன்றி! + +இந்த வழிகாட்டியை எழுதியவர் [@abbycabs](https://github.com/abbycabs), மேலும் [@balamt](https://github.com/balamt) மொழிபெயர்த்துள்ளனர், பங்களிப்புகளுடன்: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + இன்னும் பலர்! diff --git a/_articles/ta/metrics.md b/_articles/ta/metrics.md new file mode 100644 index 00000000000..df0cebdcaa1 --- /dev/null +++ b/_articles/ta/metrics.md @@ -0,0 +1,126 @@ +--- +lang: ta +title: திறந்த மூல அளவீடுகள் +description: உங்கள் திறந்த மூல திட்டத்தை வெற்றிகரமாக அளவிட்டு, அதன் வெற்றியை கண்காணிப்பதன் மூலம் அறிவுறுத்தப்பட்ட முடிவுகளை எடுங்கள். +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## ஏன் எதையும் அளவிட வேண்டுமா? + +திறந்த மூல பராமரிப்பாளராக சிறந்த தீர்மானங்களை எடுக்க உதவுவதற்கு, தரவு உங்களுக்கு பயனுள்ளதாக இருக்கும். + +கூடுதலான தகவலுடன், நீங்கள்: + +* புதிய அம்சத்திற்கு பயனர்கள் எவ்வாறு பதிலளிக்கிறார்கள் என்பதைப் புரிந்து கொள்ளுங்கள் +* புதிய பயனர்கள் எங்கிருந்து வருகிறார்கள் என்பதைக் கண்டறியவும் +* அடையாளம் கண்டறிந்து, ஆதரவளிப்பீர்களா, வெளிப்படையான பயன்பாடு வழக்கு அல்லது செயல்பாடு என்பதை முடிவு செய்யுங்கள் +* உங்கள் திட்டத்தின் புகழை அளவிடுங்கள் +* உங்கள் திட்டம் எவ்வாறு பயன்படுத்தப்படுகிறது என்பதை புரிந்து கொள்ளுங்கள் +* நிதியுதவி மற்றும் மானியங்கள் மூலம் பணம் திரட்டவும் + +உதாரணத்திற்கு, [ஹோம்புருவ்](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) கூகுள் பகுப்பாய்வியல் வேலைக்கு முன்னுரிமை கொடுக்க உதவுகிறது: + +> ஹோம்புருவ் இலவசமாக வழங்கப்படுகிறது மற்றும் முழுமையாக தன்னார்வலர்களால் தங்கள் ஓய்வு நேரத்தில் இயக்கப்படுகிறது. இதன் விளைவாக எதிர்கால அம்சங்களை எவ்வாறு வடிவமைப்பது மற்றும் தற்போதைய பணியை முன்னுரிமைப்படுத்துவது ஆகியவற்றை எவ்வாறு தீர்மானிப்பது என்பதைத் தீர்மானிக்க வீட்டு ஹோம்புருவ் பயனர்களின் விரிவான பயனர் ஆய்வுகள் செய்ய எங்களிடம் ஆதாரங்கள் இல்லை. பெயர் அறியப்படாத ஒருங்கிணைந்த பயனர் பகுப்பாய்வு, எங்கு, எங்கு, எப்போது மக்கள் ஹோம்புருவ்-ஐ பயன்படுத்துவது என்ற அடிப்படையில் திருத்தங்கள் மற்றும் அம்சங்களை முன்னுரிமை செய்ய அனுமதிக்கிறது. + +புகழ் மட்டுமே எல்லாம் இல்லை. எல்லோரும் வெவ்வேறு காரணங்களுக்காக திறந்த மூலத்தை அடைவார்கள். திறந்த மூல பராமரிப்பாளராக உங்கள் குறிக்கோள் உங்கள் வேலையை காட்ட வேண்டும் என்றால், உங்கள் குறியீட்டு பற்றி வெளிப்படையானதாக இருக்க வேண்டும், அல்லது கேளிக்கையாக இருந்தால், அளவீடு உங்களுக்கு முக்கியமானதாக இருக்காது. + +நீங்கள் உங்கள் திட்டத்தை ஒரு ஆழமான மட்டத்தில் புரிந்து கொள்ள ஆர்வமாக இருந்தால், உங்கள் திட்டத்தின் செயல்பாட்டை ஆராய்வதற்கான வழிகளைப் படிக்கவும். + +## கண்டுபிடித்தல் + +யாராவது உங்கள் திட்டத்திற்கு மீண்டும் பயன்படுத்த அல்லது பங்களிக்க முன்பு, அவர்கள் அது இருப்பதை தெரிந்து கொள்ள வேண்டும். உங்களை நீங்களே கேட்டுக்கொள்ளுங்கள்: _மக்கள் இந்த திட்டத்தை கண்டுபிடிக்கிறார்களா?_ + +![போக்குவரத்து வரைபடம்](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +உங்கள் திட்டம் கிட்ஹப் இல் வழங்கப்பட்டிருந்தால், உங்கள் திட்டத்திற்கு எத்தனை பேர் வருகிறார்கள் மற்றும் எங்கிருந்து வருகிறார்கள் என்பதை [நீங்கள் காணலாம்](https://help.github.com/articles/about-repository-graphs/#traffic). உங்கள் திட்டத்தின் பக்கத்திலிருந்து, "நுண்ணறிவு" என்பதைக் கிளிக் செய்து, பின்னர் "போக்குவரத்து" என்பதைக் கிளிக் செய்யவும். இந்த பக்கத்தில், நீங்கள் பார்க்க கூடியது: + +* **மொத்த பக்கம் நோக்குகள்:** எத்தனை முறை உங்கள் திட்டம் பார்க்கப்பட்டது என்று உங்களுக்கு சொல்கிறது + +* **மொத்த தனித்துவமான பார்வையாளர்கள்:** உங்கள் திட்டத்தை எத்தனை பேர் பார்த்தார்கள் என்று உங்களுக்கு சொல்கிறது + +* **குறிப்பிடு தளங்கள்:** பார்வையாளர்கள் எங்கிருந்து வந்தார்கள் என்று உங்களுக்கு சொல்கிறது. உங்கள் பார்வையாளர்களை எங்கு சென்று அடைவது, உங்கள் ஊக்குவிப்பு முயற்சிகள் உழைக்கிறதா என்பதையும் இந்த அளவீடு உங்களுக்கு உதவும். + +* **பிரபலமான உள்ளடக்கம்:** பார்வையாளர்கள் உங்கள் திட்டத்தில் எங்கு செல்கிறார்கள், பக்கம் நோக்குகள் மற்றும் தனித்துவமான பார்வையாளர்களால் பிரிக்கப்பட்டு உங்களுக்குத் தெரிவிக்கும். + +[கிட்ஹப் நட்சத்திரங்கள்](https://help.github.com/articles/about-stars/) பிரபலத்தின் அடிப்படை அளவை வழங்க உதவுகிறது. கிட்ஹப் நட்சத்திரங்கள் பதிவிறக்கங்கள் மற்றும் பயன்பாட்டுடன் அவசியம் தொடர்பில்லை என்றாலும், உங்கள் வேலையை எத்தனை பேர் கவனிக்கிறார்களென அவை உங்களுக்கு சொல்ல முடியும். + +நீங்கள் [குறிப்பிட்ட இடங்களில் கண்டுபிடிப்பதை கண்டறியலாம்](https://opensource.com/business/16/6/pirate-metrics): எடுத்துக்காட்டாக, கூகுள் பக்க தரவரிசை, உங்கள் திட்டத்தின் வலைத்தளத்திலிருந்து பரிந்துரைத்த போக்குவரத்து, அல்லது பிற திறந்த மூல திட்டங்கள் அல்லது வலைத்தளங்களில் இருந்து பரிந்துரைகளை வழங்குகிறது. + +## பயன்பாடு + +இந்த கட்டுப்பாடற்ற இடத்திலும் மக்கள் இந்த திட்டத்தை கண்டுபிடிப்பதை இணையம் என நாங்கள் அழைக்கிறோம். வெறுமனே, அவர்கள் உங்கள் திட்டம் பார்க்கும் போது, அவர்கள் ஏதாவது செய்ய கட்டாயம் உணர வேண்டும். நீங்கள் கேட்க விரும்பும் இரண்டாவது கேள்வி என்னவென்றால்: _இந்த திட்டத்தை மக்கள் பயன்படுத்துகிறார்களா?_ + +உங்கள் திட்டத்தை விநியோகிக்க, நீங்கள் npm அல்லது RubyGems.org போன்ற ஒரு தொகுப்பு நிர்வாகியைப் பயன்படுத்தினால், நீங்கள் உங்கள் திட்டத்தின் பதிவிறக்கங்களைக் கண்காணிக்க முடியும். + +ஒவ்வொரு தொகுப்பு மேலாளரும் "பதிவிறக்க" என்ற சற்று வித்தியாசமான வரையறையைப் பயன்படுத்தலாம், மற்றும் பதிவிறக்கங்கள் அவசியம் நிறுவ அல்லது பயன்படுத்தத் தேவை இல்லை, ஆனால் அது ஒப்பீட்டளவில் சில அடிப்படைகளை வழங்குகிறது. பல பிரபலமான தொகுப்பு மேலாளர்களுக்கிடையே பயன்பாட்டு புள்ளிவிவரங்களைக் கண்காணிக்க [Libraries.io](https://libraries.io/) ஐப் பயன்படுத்தி முயற்சிக்கவும். + +உங்கள் திட்டம் கிட்ஹப் இல் இருந்தால், "போக்குவரத்து" பக்கம் மீண்டும் செல்லவும். உங்கள் திட்டத்தை ஒரு குறிப்பிட்ட நாளில் எத்தனை முறை நகலி எடுக்கப்படுகிறது, மொத்த நகலிகள் மற்றும் தனிப்பட்ட நகலி எடுத்தவர்கள் என பிரித்து பார்க்க [நகலி வரைபடம்](https://github.com/blog/1873-clone-graphs) பயன்படுத்த முடியும். + +![நகலி வரைபடம்](/assets/images/metrics/clone_graph.png) + +உங்கள் திட்டத்தை கண்டுபிடிப்பவர்களின் எண்ணிக்கை ஒப்பிடும்போது பயன்பாடு குறைவாக இருந்தால், கருத்தில் கொள்ள இரண்டு சிக்கல்கள் உள்ளன. இரண்டில் ஒன்று: + +* உங்கள் திட்டம் வெற்றிகரமாக உங்கள் பார்வையாளர்களை மாற்றவில்லை, அல்லது +* நீங்கள் தவறான பார்வையாளர்களை ஈர்க்கிறீர்கள் + +உதாரணமாக, ஹேக்கர் நியூஸ் முன் பக்கத்தில் உங்கள் திட்டம் தரையிறங்கி இருந்தால், நீங்கள் ஹேக்கர் நியூஸ் அனைவரையும் அடைந்து கொண்டிருப்பதால், ஒருவேளை திட்டத்தை கண்டுபிடிப்பதில் (போக்குவரத்தில்) ஒரு உச்சமடைதலை காணலாம், ஆனால் குறைந்த மாற்று விகிதமே இருக்கும். உங்கள் ரூபி திட்டம் ஒரு ரூபி மாநாட்டில் இடம்பெற்றிருந்தால், நீங்கள் உங்கள் இலக்கு பார்வையாளர்களிடமிருந்து அதிக மாற்று விகிதத்தைக் காணலாம். + +உங்களுடைய பார்வையாளர்கள் எங்கிருந்து வருகிறார்கள் என்பதைக் கண்டுபிடிக்க முயற்சிக்கவும் மற்றும் நீங்கள் எதிர்கொள்ளும் இந்த இரண்டு சிக்கல்களில் எது கண்டுபிடிக்கப்பட வேண்டும் என்பதை உங்கள் திட்டப்பக்கத்தில் கருத்துத் கேட்கவும். + +உங்கள் திட்டத்தை மக்கள் பயன்படுத்தி வருகின்றனர் என்பதை நீங்கள் அறிந்தவுடன், அவர்கள் என்ன செய்கிறார்கள் என்பதை நீங்கள் கண்டுபிடிக்க முயற்சி செய்யலாம். உங்கள் குறியீட்டின் கவையை கொண்டு, அம்சங்களைச் சேர்ப்பதன் மூலம் அவர்கள் அதை உருவாக்கிக் கொண்டிருக்கிறார்களா? அவர்கள் அதை அறிவியல் அல்லது வணிகத்திற்கு பயன்படுத்துகிறார்களா? + +## தக்கவைத்தல் + +மக்கள் உங்கள் திட்டத்தை கண்டுபிடித்து அதை பயன்படுத்துகின்றனர். உங்களை நீங்களே கேட்க வேண்டிய அடுத்த கேள்வி: _இந்த திட்டத்திற்கு மக்கள் பங்களிப்பு செய்கிறார்களா?_ + +பங்களிப்பாளர்களைப் பற்றி சிந்திக்கத் தொடங்குவதற்கு இது மிகவும் முற்போக்கானது அல்ல. மற்றவர்கள் தூக்கி எறியவில்லையென்றாலும், உங்கள் திட்டம் _புகழ்பெற்றது_ (பலர் இதைப் பயன்படுத்துகிறார்கள்) ஆனால் _ஆதரிக்கவில்லை_ (தேவைப்பாட்டை சந்திக்க போதுமான பராமரிப்பாளர் நேரம் இல்லை) என்றால் ஆரோக்கியமற்ற சூழ்நிலையில் உங்களை ஈடுபடுத்திக் கொள்கிறீர்கள். + +தக்கவைத்தலுக்கு [புதிய பங்களிப்பாளர்களிடம் செல்வதற்கு](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) தேவைப்படுகிறது, இதற்கு முன்பு செயலில் பங்களிப்பவர்கள் இறுதியில் மற்ற விஷயங்களுக்கு நகர்வார்கள். + +நீங்கள் தொடர்ந்து கண்காணிக்க விரும்பும் சமூக அளவீடுகளின் எடுத்துக்காட்டுகளில் பின்வருவன அடங்கும்: + +* **பங்களிப்பாளர்களின் மொத்த எண்ணிக்கை மற்றும் பங்களிப்பு தொகைகளின் எண்ணிக்கை:** உங்களுக்கு எத்தனை பங்களிப்பாளர்கள் உள்ளனர் என கூறுகிறது, மேலும் அவர்களில் அதிக அல்லது குறைவான செயலில் உள்ளவர் யார். கிட்ஹப் மீது, நீங்கள் இதை "நுண்ணறிவு" -> "பங்களிப்பாளர்கள்" என்பதில் காணலாம். இப்போது, இந்த வரைபடம் களஞ்சியத்தின் இயல்புநிலை கிளைக்கு பங்களித்த பங்களிப்பாளர்களை மட்டுமே கணக்கிடுகிறது. + +![பங்களிப்பாளர் வரைபடம்](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **முதல் முறை, சாதாரண, மற்றும் திரும்ப வரும் பங்களிப்பாளர்கள்:** புதிய பங்களிப்பாளர்கள் வருகிறார்களா, அவர்கள் திரும்பி வருகிறார்களா என்பதை நீங்கள் கண்காணிக்க உதவுகிறது. (குறைந்த பங்களிப்புடன் சாதாரண பங்களிப்பாளர்கள் பங்களிப்பவர்கள். அது ஒன்றே ஒன்று தான், ஐந்து ஒப்புவிப்புகளுக்கு குறைவாகவோ அல்லது வேறு ஏதாவது என்பது உங்களை பொறுத்தது.) புதிய பங்களிப்பாளர்கள் இல்லாமல், உங்கள் திட்டத்தின் சமூகம் தேக்கமுற்றதாகிவிடும். + +* **திறந்த சிக்கல்கள் மற்றும் திறந்த இழு கோரிக்கைகளின் எண்ணிக்கை:** இந்த எண்கள் மிக அதிகமானதாக இருந்தால், உங்களுக்கு சிக்கல் மற்றும் குறியீட்டு மதிப்பீடுகளுடன் உதவி தேவைப்படலாம். + +* **_திறந்துள்ள_ சிக்கல்கள் மற்றும் _திறந்துள்ள_ இழு கோரிக்கைகளின் எண்ணிக்கை:** Oதிறந்த சிக்கல்கள் என்பது ஒரு சிக்கலைத் திறக்க உங்கள் திட்டம் பற்றி யாராவது அக்கறை காட்டுகிறார்கள். காலப்போக்கில் அந்த எண்ணிக்கை அதிகரிக்கிறது என்றால், உங்கள் திட்டத்தில் மக்கள் அக்கறை காட்டுகிறார்கள். + +* **பங்களிப்பு வகைகள்:** உதாரணமாக, எழுத்துப்பிழைகள் அல்லது பிழைகளை சரிசெய்து, அல்லது சிக்கலில் கருத்து தெரிவித்தல். + + + +## பராமரிப்பாளர் செயல்பாடு + +இறுதியாக, உங்கள் திட்டத்தின் பராமரிப்பாளர்கள் பெறப்பட்ட பங்களிப்புகளின் அளவைக் கையாள முடியும் என்பதை உறுதிப்படுத்துவதன் மூலம் வட்டத்தை மூடுவதை நீங்கள் விரும்புவீர்கள். உங்களை நீங்களே கேட்க வேண்டிய கடைசி கேள்வி: _நான் (அல்லது நாம்) நமது சமூகத்திற்கு மறுமொழி கூறுகிறோமா?_ + +செயற்படாத பராமரிப்பாளர்கள் திறந்த மூல திட்டங்களுக்கான ஒரு சிக்கல். யாராவது ஒரு பங்களிப்பைச் சமர்ப்பித்திருந்து, ஒரு பராமரிப்பாளரிடமிருந்து ஒருபோதும் மறுமொழி வரவில்லையென்றால், அவர்கள் சோர்வடைந்து விடுவார்கள். + +[மோசில்லாவிலிருந்து ஆராய்ச்சி](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) பராமரிப்பாளர் எதிர்க் குறிப்பு உணர்த்துதல் மீண்டும் பங்களிப்புகளை ஊக்குவிப்பதில் ஒரு முக்கிய காரணி என்று கூறுகிறது. + +ஒரு சிக்கல் அல்லது இழு கோரிக்கை நீங்கள் எவ்வளவு நேரம் எடுத்துக்கொள்கிறீர்கள் (அல்லது இன்னுமொரு பராமரிப்பாளர்) எடுத்துக்கொள்வதைக் கவனியுங்கள். மறுமொழி கூற நடவடிக்கை தேவையில்லை. எளியதாக கூறுவதென்றால்: _"உங்கள் சமர்ப்பிப்பிற்கு நன்றி! நான் அடுத்த வாரத்திற்குள் இதை மதிப்பாய்வு செய்வேன்."_ + +நீங்கள் பங்களிப்பு செயல்முறை நிலைகளில் இடையே நகர்த்த எடுக்கும் நேரத்தை அளவிட முடியும், அதாவது: + +* ஒரு சிக்கல் திறந்த நிலையில் உள்ள சராசரி நேரம் +* சிக்கல்கள் PRக்கள் மூலம் மூடப்பட்டனவா +* பழைய பிரச்சினைகள் மூடப்பட்டனவா +* இழு கோரிக்கையை ஒன்றாக்க சராசரி நேரம் + +## மக்களைப் பற்றி அறிய 📊 பயன்படுத்தவும் + +அளவீடுகளை புரிந்துகொள்ளுவது செயலில் உள்ள, வளர்ந்து வரும் திறந்த மூல திட்டத்தை உருவாக்க உதவும். நீங்கள் முகப்புப்பெட்டி ஒவ்வொரு அளவீடு பகுதியையும் கண்காணிக்கவில்லை என்றால், உங்கள் திட்டத்தை வளர்த்துக் கொள்ள உதவும் நடத்தை வகையின் மீது உங்கள் கவனத்தை ஒருமுகப்படுத்த மேலே உள்ள கட்டமைப்பைப் பயன்படுத்தவும். diff --git a/_articles/ta/security-best-practices-for-your-project.md b/_articles/ta/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..a6fa1939ad4 --- /dev/null +++ b/_articles/ta/security-best-practices-for-your-project.md @@ -0,0 +1,83 @@ +--- +lang: ta +title: உங்கள் திட்டத்திற்கான சிறந்த பாதுகாப்பு நடைமுறைகள் +description: சார்புநிலை மற்றும் தனியார் பாதிப்பு அறிக்கையிடலைப் பாதுகாக்க அத்தியாவசிய பாதுகாப்பு நடைமுறைகள், MFA மற்றும் குறியீடு ஸ்கேனிங் மூலம் நம்பிக்கையை வளர்ப்பதன் மூலம் உங்கள் திட்டத்தின் எதிர்காலத்தை பலப்படுத்துங்கள். +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +பிழைகள் மற்றும் புதிய அம்சங்கள் ஒருபுறம் இருக்க, ஒரு திட்டத்தின் நீண்ட ஆயுள் அதன் பயனை மட்டுமல்ல, அதன் பயனர்களிடமிருந்து அது சம்பாதிக்கும் நம்பிக்கையையும் சார்ந்துள்ளது. இந்த நம்பிக்கையை உயிர்ப்புடன் வைத்திருக்க வலுவான பாதுகாப்பு நடவடிக்கைகள் முக்கியம். உங்கள் திட்டத்தின் பாதுகாப்பை கணிசமாக மேம்படுத்த நீங்கள் எடுக்கக்கூடிய சில முக்கியமான நடவடிக்கைகள் இங்கே. + +## அனைத்து சலுகை பெற்ற பங்களிப்பாளர்களும் Multi-Factor Authentication (MFA) இயக்கப்பட்டிருப்பதை உறுதிசெய்யவும். + +### உங்கள் திட்டத்திற்கு சலுகை பெற்ற பங்களிப்பாளராக ஆள்மாறாட்டம் செய்யும் ஒரு தீங்கிழைக்கும் நபர், பேரழிவு தரும் சேதங்களை ஏற்படுத்துவார். + +சலுகை பெற்ற அணுகலைப் பெற்றவுடன், இந்த நபர் உங்கள் குறியீட்டை தேவையற்ற செயல்களைச் செய்ய மாற்றியமைக்கலாம் (எடுத்துக்காட்டு: கிரிப்டோகரன்சியை சுரங்கப்படுத்துதல்), அல்லது உங்கள் பயனர்களின் உள்கட்டமைப்பிற்கு தீம்பொருளை விநியோகிக்கலாம் அல்லது அறிவுசார் சொத்து மற்றும் முக்கியமான தரவை, பிற சேவைகளுக்கு வெளியேற்ற தனியார் குறியீடு களஞ்சியங்களை அணுகலாம். + +கணக்கு கையகப்படுத்தலுக்கு எதிராக MFA கூடுதல் பாதுகாப்பை வழங்குகிறது. இயக்கப்பட்டதும், உங்கள் பயனர்பெயர் மற்றும் கடவுச்சொல்லுடன் உள்நுழைந்து, உங்களுக்கு மட்டுமே தெரிந்த அல்லது அணுகக்கூடிய மற்றொரு வகையான அங்கீகாரத்தை வழங்க வேண்டும். + +## உங்கள் மேம்பாட்டின் ஒரு பகுதியாக உங்கள் குறியீட்டைப் பாதுகாக்கவும். + +### உங்கள் குறியீட்டில் உள்ள பாதுகாப்பு பாதிப்புகளை, பின்னர் உற்பத்தியில் பயன்படுத்துவதை விட, செயல்பாட்டின் ஆரம்பத்தில் கண்டறியப்பட்டால் சரிசெய்வது மலிவானது. + +உங்கள் குறியீட்டில் உள்ள பாதுகாப்பு பாதிப்புகளைக் கண்டறிய நிலையான பயன்பாட்டு பாதுகாப்பு சோதனை (SAST - Static Application Security Testing) கருவியைப் பயன்படுத்தவும். இந்த கருவிகள் குறியீடு மட்டத்தில் இயங்குகின்றன, மேலும் செயல்படுத்தும் சூழல் தேவையில்லை, எனவே செயல்பாட்டின் ஆரம்பத்தில் செயல்படுத்தப்படலாம், மேலும் உருவாக்கத்தின் போது அல்லது குறியீடு மதிப்பாய்வு கட்டங்களின் போது உங்கள் வழக்கமான மேம்பாட்டு பணிப்பாய்வில் தடையின்றி ஒருங்கிணைக்கப்படலாம். + +இது உங்கள் குறியீட்டை ஒரு திறமையான நிபுணர் பார்ப்பது போன்றது, இது வெளிப்படையான பார்வையில் மறைந்திருக்கக்கூடிய பொதுவான பாதுகாப்பு பாதிப்புகளைக் கண்டறிய உதவுகிறது. + +உங்கள் SAST கருவியை எவ்வாறு தேர்வு செய்வது? +உரிமத்தைச் சரிபார்க்கவும்: சில கருவிகள் திறந்த மூல திட்டங்களுக்கு இலவசம். உதாரணமாக GitHub CodeQL அல்லது SemGrep. +உங்கள் மொழிகளுக்கான கவரேஜைச் சரிபார்க்கவும். + +* நீங்கள் ஏற்கனவே பயன்படுத்தும் கருவிகளுடன், உங்கள் தற்போதைய செயல்முறையுடன் எளிதாக ஒருங்கிணைக்கக்கூடிய ஒன்றைத் தேர்ந்தெடுக்கவும். எடுத்துக்காட்டாக, விழிப்பூட்டல்களைப் பார்க்க வேறொரு கருவிக்குச் செல்வதற்குப் பதிலாக, உங்கள் தற்போதைய குறியீடு மதிப்பாய்வு செயல்முறை மற்றும் கருவியின் ஒரு பகுதியாக அவை கிடைத்தால் நல்லது. +* தவறான நேர்மறைகளைப் பற்றி எச்சரிக்கையாக இருங்கள்! எந்த காரணமும் இல்லாமல் கருவி உங்களை மெதுவாக்குவதை நீங்கள் விரும்பவில்லை! +* அம்சங்களைச் சரிபார்க்கவும்: சில கருவிகள் மிகவும் சக்திவாய்ந்தவை மற்றும் கறை கண்காணிப்பைச் செய்ய முடியும் (எடுத்துக்காட்டு: GitHub CodeQL), சில செயற்கை நுண்ணறிவு (AI) உருவாக்கிய சரிசெய்தல் பரிந்துரைகளை முன்மொழிகின்றன, சில தனிப்பயன் வினவல்களை எழுதுவதை எளிதாக்குகின்றன (எடுத்துக்காட்டு: SemGrep). + +## உங்கள் ரகசியங்களைப் பகிர்ந்து கொள்ளாதீர்கள். + +### API விசைகள், டோக்கன்கள் மற்றும் கடவுச்சொற்கள் போன்ற முக்கியமான தகவல்கள் சில நேரங்களில் தற்செயலாக உங்கள் களஞ்சியத்தில் கவரப்படலாம். + +இந்தக் காட்சியை கற்பனை செய்து பாருங்கள்: உலகெங்கிலும் உள்ள டெவலப்பர்களின் பங்களிப்புகளுடன் கூடிய பிரபலமான திறந்த மூல திட்டத்தின் பராமரிப்பாளராக நீங்கள் இருக்கிறீர்கள். ஒரு நாள், ஒரு பங்களிப்பாளர் அறியாமல் ஒரு மூன்றாம் தரப்பு சேவையின் சில API விசைகளை களஞ்சியத்தில் ஒப்படைப்பார். சில நாட்களுக்குப் பிறகு, யாரோ ஒருவர் இந்த விசைகளைக் கண்டுபிடித்து, அனுமதியின்றி சேவையில் நுழைய அவற்றைப் பயன்படுத்துகிறார். சேவை சமரசம் செய்யப்படுகிறது, உங்கள் திட்டத்தின் பயனர்கள் செயலிழப்பு நேரத்தை அனுபவிக்கிறார்கள், மேலும் உங்கள் திட்டத்தின் நற்பெயர் பாதிக்கப்படுகிறது. பராமரிப்பாளராக, சமரசம் செய்யப்பட்ட ரகசியங்களைத் திரும்பப் பெறுதல், தாக்குபவர் இந்த ரகசியத்தைக் கொண்டு என்ன தீங்கிழைக்கும் செயல்களைச் செய்திருக்க முடியும் என்பதை ஆராய்தல், பாதிக்கப்பட்ட பயனர்களுக்குத் தெரிவித்தல் மற்றும் திருத்தங்களைச் செயல்படுத்துதல் போன்ற கடினமான பணிகளை நீங்கள் இப்போது எதிர்கொள்கிறீர்கள். + +இதுபோன்ற சம்பவங்களைத் தடுக்க, உங்கள் குறியீட்டில் உள்ள அந்த ரகசியங்களைக் கண்டறிய உதவும் "ரகசிய ஸ்கேனிங்" தீர்வுகள் உள்ளன. GitHub Secret Scanning, மற்றும் Truffle Security-இன் Trufflehog போன்ற சில கருவிகள், அவற்றை முதலில் தொலைதூர கிளைகளுக்குத் தள்ளுவதைத் தடுக்கலாம், மேலும் சில கருவிகள் உங்களுக்காக சில ரகசியங்களைத் தானாகவே ரத்து செய்யும். + +## உங்கள் சார்புகளைச் சரிபார்த்து புதுப்பிக்கவும். + +### உங்கள் திட்டத்தில் உள்ள சார்புநிலைகள் உங்கள் திட்டத்தின் பாதுகாப்பை சமரசம் செய்யும் பாதிப்புகளைக் கொண்டிருக்கலாம். சார்புநிலைகளை கைமுறையாகப் புதுப்பித்த நிலையில் வைத்திருப்பது நேரத்தை எடுத்துக்கொள்ளும் பணியாக இருக்கலாம். + +இதைப் பற்றி யோசித்துப் பாருங்கள்: பரவலாகப் பயன்படுத்தப்படும் நூலகத்தின் உறுதியான அடித்தளத்தில் கட்டமைக்கப்பட்ட ஒரு திட்டம். நூலகம் பின்னர் ஒரு பெரிய பாதுகாப்பு சிக்கலைக் காண்கிறது, ஆனால் அதைப் பயன்படுத்தி பயன்பாட்டை உருவாக்கியவர்களுக்கு இது பற்றித் தெரியாது. ஒரு தாக்குபவர் இந்த பலவீனத்தைப் பயன்படுத்தி, அதைப் பிடிக்க பாய்ந்து வரும்போது, முக்கியமான பயனர் தரவு அம்பலப்படுத்தப்படுகிறது. இது ஒரு தத்துவார்த்த வழக்கு அல்ல. 2017 இல் Equifax க்கு இதுதான் நடந்தது: கடுமையான பாதிப்பு கண்டறியப்பட்டதாக அறிவிக்கப்பட்ட பிறகு அவர்கள் தங்கள் Apache Struts சார்புநிலையைப் புதுப்பிக்கத் தவறிவிட்டனர். இது சுரண்டப்பட்டது, மேலும் பிரபலமற்ற Equifax மீறல் 144 மில்லியன் பயனர்களின் தரவைப் பாதித்தது. + +இதுபோன்ற சூழ்நிலைகளைத் தடுக்க, Dependabot மற்றும் Renovate போன்ற மென்பொருள் கலவை பகுப்பாய்வு (SCA - Software Composition Analysis ) கருவிகள், NVD அல்லது GitHub ஆலோசனை தரவுத்தளம் போன்ற பொது தரவுத்தளங்களில் வெளியிடப்பட்ட அறியப்பட்ட பாதிப்புகளுக்கு உங்கள் சார்புகளை தானாகவே சரிபார்த்து, பின்னர் அவற்றை பாதுகாப்பான பதிப்புகளுக்குப் புதுப்பிக்க இழுப்பு கோரிக்கைகளை உருவாக்குகின்றன. சமீபத்திய பாதுகாப்பான சார்பு பதிப்புகளுடன் புதுப்பித்த நிலையில் இருப்பது உங்கள் திட்டத்தை சாத்தியமான ஆபத்துகளிலிருந்து பாதுகாக்கிறது. + +## பாதுகாக்கப்பட்ட கிளைகளுடன் தேவையற்ற மாற்றங்களைத் தவிர்க்கவும். + +### உங்கள் முக்கிய கிளைகளுக்கான கட்டுப்பாடற்ற அணுகல் தற்செயலான அல்லது தீங்கிழைக்கும் மாற்றங்களுக்கு வழிவகுக்கும், அவை பாதிப்புகளை அறிமுகப்படுத்தலாம் அல்லது உங்கள் திட்டத்தின் நிலைத்தன்மையை சீர்குலைக்கலாம். + +ஒரு புதிய பங்களிப்பாளர் பிரதான கிளைக்கு எழுதும் அணுகலைப் பெறுகிறார், மேலும் தற்செயலாக சோதிக்கப்படாத மாற்றங்களைத் தள்ளுகிறார். சமீபத்திய மாற்றங்களின் காரணமாக, ஒரு கடுமையான பாதுகாப்பு குறைபாடு பின்னர் கண்டறியப்படுகிறது. இதுபோன்ற சிக்கல்களைத் தடுக்க, கிளை பாதுகாப்பு விதிகள் மாற்றங்களை முதலில் மதிப்பாய்வுகளுக்கு உட்படுத்தாமல் மற்றும் குறிப்பிட்ட நிலை சோதனைகளில் தேர்ச்சி பெறாமல் முக்கியமான கிளைகளில் தள்ளவோ அல்லது இணைக்கவோ முடியாது என்பதை உறுதி செய்கின்றன. இந்த கூடுதல் நடவடிக்கை நடைமுறையில் இருப்பதால் நீங்கள் பாதுகாப்பாகவும் சிறப்பாகவும் இருக்கிறீர்கள், ஒவ்வொரு முறையும் உயர்தர தரத்தை உறுதி செய்கிறீர்கள். + +## பாதிப்பு அறிக்கையிடலுக்கான உட்கொள்ளும் பொறிமுறையை அமைக்கவும். + +### உங்கள் பயனர்கள் பிழைகளைப் புகாரளிப்பதை எளிதாக்குவது ஒரு நல்ல நடைமுறைதான், ஆனால் பெரிய கேள்வி என்னவென்றால்: இந்தப் பிழை பாதுகாப்பு தாக்கத்தை ஏற்படுத்தும் போது, தீங்கிழைக்கும் ஹேக்கர்களுக்கு உங்கள் மீது இலக்கு வைக்காமல் அவர்கள் அதை எவ்வாறு பாதுகாப்பாக உங்களிடம் புகாரளிக்க முடியும்? + +இதைப் பற்றி யோசித்துப் பாருங்கள்: ஒரு பாதுகாப்பு ஆராய்ச்சியாளர் உங்கள் திட்டத்தில் ஒரு பாதிப்பைக் கண்டறிந்தாலும், அதைப் புகாரளிக்க தெளிவான அல்லது பாதுகாப்பான வழியைக் கண்டுபிடிக்கவில்லை. நியமிக்கப்பட்ட செயல்முறை இல்லாமல், அவர்கள் ஒரு பொதுப் பிரச்சினையை உருவாக்கலாம் அல்லது சமூக ஊடகங்களில் வெளிப்படையாக விவாதிக்கலாம். அவர்கள் நல்ல நோக்கத்துடன் ஒரு தீர்வை வழங்கினாலும், அவர்கள் அதை ஒரு பொது இழுப்பு கோரிக்கையுடன் செய்தால், அது இணைக்கப்படுவதற்கு முன்பு மற்றவர்கள் அதைப் பார்ப்பார்கள்! இந்த பொது வெளிப்படுத்தல், நீங்கள் அதை நிவர்த்தி செய்ய வாய்ப்பு கிடைக்கும் முன்பே தீங்கிழைக்கும் நடிகர்களுக்கு பாதிப்பை வெளிப்படுத்தும், இது பூஜ்ஜிய நாள் (Zero-day) சுரண்டலுக்கு வழிவகுக்கும், உங்கள் திட்டத்தையும் அதன் பயனர்களையும் தாக்கும். + +### பாதுகாப்புக் கொள்கை + +இதைத் தவிர்க்க, ஒரு பாதுகாப்புக் கொள்கையை வெளியிடுங்கள். `SECURITY.md` கோப்பில் வரையறுக்கப்பட்ட ஒரு பாதுகாப்புக் கொள்கை, பாதுகாப்புக் கவலைகளைப் புகாரளிப்பதற்கான படிகளை விவரிக்கிறது, ஒருங்கிணைந்த வெளிப்படுத்தலுக்கான வெளிப்படையான செயல்முறையை உருவாக்குகிறது மற்றும் புகாரளிக்கப்பட்ட சிக்கல்களைத் தீர்ப்பதற்கான திட்டக் குழுவின் பொறுப்புகளை நிறுவுகிறது. இந்தப் பாதுகாப்புக் கொள்கை "பொதுப் பிரச்சினை அல்லது மக்கள் தொடர்புத் தகவலில் விவரங்களை வெளியிட வேண்டாம், security@example.com இல் எங்களுக்கு ஒரு தனிப்பட்ட மின்னஞ்சலை அனுப்பவும்" என்பது போல எளிமையாக இருக்கலாம், ஆனால் அவர்கள் உங்களிடமிருந்து எப்போது பதிலைப் பெறுவார்கள் என்பது போன்ற பிற விவரங்களையும் கொண்டிருக்கலாம். வெளிப்படுத்தல் செயல்முறையின் செயல்திறன் மற்றும் செயல்திறனுக்கு உதவும் எதையும். + +### தனியார் பாதிப்பு அறிக்கையிடல் + +சில தளங்களில், தனிப்பட்ட சிக்கல்கள் இருந்தால், உட்கொள்ளல் முதல் ஒளிபரப்பு வரை, உங்கள் பாதிப்பு மேலாண்மை செயல்முறையை நீங்கள் நெறிப்படுத்தலாம் மற்றும் வலுப்படுத்தலாம். GitLab இல், இது தனிப்பட்ட சிக்கல்களுடன் செய்யப்படலாம். GitHub இல், இது தனியார் பாதிப்பு அறிக்கையிடல் (PVR - private vulnerability reporting) என்று அழைக்கப்படுகிறது. PVR பராமரிப்பாளர்கள் பாதிப்பு அறிக்கைகளைப் பெறவும், நிவர்த்தி செய்யவும் உதவுகிறது, இவை அனைத்தும் GitHub தளத்திற்குள் உள்ளன. GitHub தானாகவே திருத்தங்களை எழுத ஒரு தனியார் ஃபோர்க்கையும், ஒரு வரைவு பாதுகாப்பு ஆலோசனையையும் உருவாக்கும். சிக்கல்களை வெளிப்படுத்தவும், திருத்தங்களை வெளியிடவும் நீங்கள் முடிவு செய்யும் வரை இவை அனைத்தும் ரகசியமாகவே இருக்கும். வளையத்தை மூட, பாதுகாப்பு ஆலோசனைகள் வெளியிடப்படும், மேலும் உங்கள் அனைத்து பயனர்களுக்கும் அவர்களின் SCA கருவி மூலம் தகவல் அளித்து பாதுகாக்கும். + +## முடிவு: உங்களுக்காக ஒரு சில படிகள், உங்கள் பயனர்களுக்கு ஒரு பெரிய முன்னேற்றம். + +இந்த சில படிகள் உங்களுக்கு எளிதானதாகவோ அல்லது அடிப்படையானதாகவோ தோன்றலாம், ஆனால் அவை உங்கள் திட்டத்தை அதன் பயனர்களுக்கு மிகவும் பாதுகாப்பானதாக மாற்றுவதற்கு நீண்ட தூரம் செல்கின்றன, ஏனெனில் அவை மிகவும் பொதுவான சிக்கல்களுக்கு எதிராக பாதுகாப்பை வழங்கும். + +## பங்களிப்பாளர்கள் + +### இந்த வழிகாட்டிக்காக தங்கள் அனுபவங்களையும் உதவிக்குறிப்புகளையும் எங்களுடன் பகிர்ந்து கொண்ட அனைத்து பராமரிப்பாளர்களுக்கும் மிக்க நன்றி! + +இந்த வழிகாட்டியை [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) எழுதியுள்ளனர், மேலும் [@balamt](https://github.com/balamt) மொழிபெயர்த்துள்ளனர், பங்களிப்புகள்: + +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + இன்னும் பலர்! diff --git a/_articles/ta/starting-a-project.md b/_articles/ta/starting-a-project.md new file mode 100644 index 00000000000..c6dfb4b8c02 --- /dev/null +++ b/_articles/ta/starting-a-project.md @@ -0,0 +1,363 @@ +--- +lang: ta +title: திறந்த மூல திட்டத்தைத் தொடங்குவது +description: திறந்த மூல உலகத்தைப் பற்றி மேலும் அறிந்து உங்கள் சொந்த திட்டத்தைத் தொடங்க தயாராகுங்கள். +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## திறந்த மூலத்தின் "என்ன" மற்றும் "ஏன்" + +எனவே திறந்த மூலத்துடன் தொடங்குவது பற்றி நீங்கள் யோசித்துக் கொண்டிருக்கிறீர்களா? வாழ்த்துக்கள்! உங்கள் பங்களிப்பை உலகம் பாராட்டுகிறது. திறந்த மூலத்தின் என்ன, அதை ஏன் மக்கள் செய்வது பற்றி பேசலாம். + +### "திறந்த மூலம்" என்றால் என்ன? + +ஒரு திட்டம் திறந்த மூலமாக இருக்கும்போது, அதாவது **உங்கள் திட்டத்தை எந்தவொரு நோக்கத்திற்காகவும் காணலாம், பயன்படுத்தலாம், மாற்றலாம் மற்றும் விநியோகிக்க முடியும்.** இந்த அனுமதிகள் [திறந்த மூல உரிமம்](https://opensource.org/licenses) மூலமாக செயல்படுத்தப்படும். + +திறந்த மூலம் சக்திவாய்ந்தது, ஏனெனில் இது தத்தெடுப்புக்கு தடைகளை குறைக்கிறது, கருத்துக்களை விரைவில் பரப்ப அனுமதிக்கிறது. + +இது எவ்வாறு வேலை செய்கிறது என்பதைப் புரிந்துகொள்வதற்கு, உங்கள் நண்பர் ஒரு உணவருந்த அழைக்கும் பொழுது நீங்கள் ஒரு செர்ரி பை(பழ அப்பம்) கொண்டுவருகிறீர்கள் என கற்பனை செய்து பாருங்கள் + +* எல்லோரும் பழ அப்பம் சுவைக்கின்றனர் (_உபயோகித்தல்_) +* பை ஒரு வெற்றி! நீங்கள் வழங்கிய செய்முறையை அவர்கள் கேட்கிறார்கள் (_நோக்குதல்_) +* ஒரு நண்பர், அலெக்ஸ், ஒரு இனிய மாவுப்பண்டம் சமையற்காரர், சர்க்கரையை குறைக்க யோசனை சொன்னார் (_மாற்று_) +* மற்றொரு நண்பர், லிசா, அடுத்த வாரம் ஒரு விருந்துக்கு அதை உபயோகிக்க கேட்கிறார் (_பகிர்தல்_) + +ஒப்பீட்டளவில், ஒரு மூடிய மூல செயல்முறை ஒரு உணவகத்திற்கு சென்று செர்ரி பழ அப்பம் ஒரு துண்டு உத்தரவிடுதல். நீங்கள் பழ அப்பம் சாப்பிட ஒரு கட்டணம் செலுத்த வேண்டும், மற்றும் உணவகம் ஒருவேளை நீங்கள் அவர்களின் செய்முறையை கொடுக்காமல் போகலாம். நீங்கள் அவர்களின் பழ அப்பத்தை சரியாக நகலெடுத்து அதை உங்கள் சொந்த பெயரில் விற்பனை செய்தால், உணவகம் உங்களுக்கு எதிராக நடவடிக்கை எடுக்கலாம். + +### ஏன் மக்கள் தங்கள் வேலையை திறந்த மூலமாக்கிறார்கள்? + + + +ஒரு நபர் அல்லது அமைப்பு திட்ட மூலத்தை ஏன் திறக்க வேண்டும் என்பதற்கு [பல காரணங்கள் உள்ளன](https://ben.balter.com/2015/11/23/why-open-source/). சில உதாரணங்கள் பின்வருமாறு: + +* **கூட்டு முயற்சி:** திறந்த மூல திட்டங்கள் உலகில் யாரிடமிருந்தும் மாற்றங்களை ஏற்கலாம். உதாரணமாக, [Exercism](https://github.com/exercism/) என்பது, 350 பங்களிப்பாளர்களுடன் உள்ள ஒரு நிரலாக்க பயிற்சிபாட தளமாகும். + +* **ஏற்றல் மற்றும் மறுகலப்பு செய்தல்:** திறந்த மூல திட்டங்களை ஏறக்குறைய எந்த நோக்கத்திற்காகவும் பயன்படுத்தலாம். மற்ற விஷயங்களை உருவாக்க மக்கள் அதை பயன்படுத்தலாம். உதாரணமாக, [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) என்று அழைக்கப்படும் ஒரு திட்டத்தின் ஒரு முனையாகத் துவங்கியது [வேர்ட்பிரஸ்](https://github.com/WordPress). + +* **வெளிப்படைத்தன்மை:** தவறுகள் அல்லது முரண்பாடுகளுக்கு எவரும் திறந்த மூல திட்டத்தை ஆய்வு செய்ய முடியும். [பல்கேரியா](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-source-98bf626cf70a) அல்லது [ஐக்கிய நாடுகள்](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) போன்ற அரசாங்கங்களுக்கு, வங்கி அல்லது சுகாதாரம் போன்ற ஒழுங்குபடுத்தப்பட்ட தொழிற்சாலைகள், மற்றும் பாதுகாப்பு மென்பொருள் [Let's Encrypt](https://github.com/letsencrypt) போன்றவற்றிற்கு வெளிப்படைத்தன்மை முக்கியமானது. + +திறந்த மூலம் மென்பொருளுக்கு மட்டும் அல்ல. தரவு தொகுப்புகளிலிருந்து புத்தகங்கள் வரை அனைத்தையும் திறக்கலாம். நீங்கள் மூலத்தைத் திறக்க முடியும் என்பதில் கருத்துக்களுக்கு [கிட்ஹப் Explore](https://github.com/explore) என்பதைப் பார்க்கவும். + +### திறந்த மூலம் என்றால் "இலவசம்" என்றா அர்த்தம்? + +திறந்த மூலத்தின் மிகப்பெரிய சமநிலைகளில் ஒன்று, பணம் செலவாகாது என்பதுதான். "இருப்பினும், "இலவசம்" என்பது திறந்த மூலத்தின் மொத்த மதிப்பின் ஒரு இடை விளைவுப் பொருள் ஆகும். + +[திறந்த மூல உரிமம்](https://opensource.org/osd-annotated) யாராலும் எந்த நோக்கத்திற்காகவும் உங்கள் திட்டத்தை பயன்படுத்தலாம், மாற்றலாம் மற்றும் பகிர்ந்து கொள்ளலாம் என்பதால், திட்டங்கள் தானாகவே கட்டணமின்றி இருக்கின்றன. Iதிட்டத்தை பயன்படுத்த பணம் செலவு என்றால், யாரோனும் சட்டபூர்வமாக ஒரு நகல் எடுத்து அதற்கு பதிலாக இலவச பதிப்பை பயன்படுத்த முடியும். + +இதன் விளைவாக, பெரும்பாலான திறந்த மூல திட்டங்கள் இலவசம், ஆனால் "கட்டணமின்றி" என்பது திறந்த மூல வரையறையின் பகுதியாக இல்லை. திறந்த மூல திட்டங்களளின் வரையறைக்கு உட்பட்டு, திறந்த மூல திட்டங்களுக்கு மறைமுக வழிகாட்டுதல் வழிகாட்டுதல்கள் அல்லது இரட்டை உரிமம் அல்லது வரையறுக்கப்பட்ட அம்சங்கள் மூலம் கட்டணம் வசூலிக்க வழிகள் உள்ளன. + +## எனது சொந்த திறந்த மூல திட்டத்தை நான் தொடங்க வேண்டுமா? + +குறுகிய பதில், ஆம், பலன் எதுவாயினும் உங்கள் சொந்த திட்டத்தை தொடங்குவது எப்படி திறந்த மூல வேலை என்பதை அறிய ஒரு சிறந்த வழியாகும். + +நீங்கள் முன்பு ஒரு திட்டத்தை ஆதரிக்கவில்லை என்றால், மக்கள் என்ன சொல்கிறார்களோ, அல்லது யாரிடமாவது கவனிக்கிறார்களா என நீங்கள் கவலைப்படலாம். இது போன்று உங்களுக்கு தோன்றினால், நீங்கள் தனியாக இல்லை! + +திறந்த மூல வேலை என்பது மற்ற படைப்பாற்றல் செயல்பாடுகளைப் போலவே, அது எழுதுவது அல்லது ஓவியமாக இருந்தாலும். உங்கள் வேலையை உலகத்துடன் பகிர்ந்து கொள்ள பயமாக இருக்கலாம், ஆனால் சிறந்த விளங்க ஒரே வழி பயிற்சியின் மூலம் மட்டுமே - உங்களுக்கு ஒரு பார்வையாளர் இல்லையென்றாலும் கூட. + +நீங்கள் இன்னும் நம்பவில்லை என்றால், உங்கள் குறிக்கோள்களைப் பற்றி சிந்திக்க சிறிது நேரம் ஒதுக்குங்கள். + +### உங்கள் இலக்குகளை அமைத்தல் + +இலக்குகள் எதைப் பற்றி வேலை செய்ய வேண்டும், எதைப் பற்றி சொல்ல வேண்டும், மற்றவர்களிடமிருந்து உங்களுக்கு உதவி தேவை என்பவற்றைக் கண்டுபிடிக்க உதவுகிறது. உங்களை நீங்களே கேட்டுக் கொள்ளுங்கள், _நான் இந்த திட்டத்தை திறக்க வேண்டும்?_ + +இந்த கேள்விக்கு ஒரு சரியான பதில் இல்லை. நீங்கள் ஒரு திட்டத்திற்கு பல இலக்குகளை அல்லது பல்வேறு இலக்குகளுடன் வெவ்வேறு திட்டங்களைக் கொண்டிருக்கலாம். + +உங்களுடைய ஒரே குறிக்கோள் உங்கள் வேலையை காட்ட விரும்பினால், நீங்கள் பங்களிப்புகளை விரும்பக்கூடாது, மேலும் உங்கள் 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/) + +ஒரு பராமரிப்பாளராக, இந்த கூறுகள் எதிர்பார்ப்புகளைத் தொடர்புகொள்வதற்கும், பங்களிப்புகளை நிர்வகிப்பதற்கும், எல்லோருடைய சட்ட உரிமைகளையும் (உங்கள் சொந்த உள்ளடங்கலாக) பாதுகாக்கும். அவர்கள் நேர்மறையான அனுபவத்தைப் பெற்றிருப்பதற்கான வாய்ப்புகளை கணிசமாக அதிகரிக்கிறார்கள். + +உங்கள் திட்டம் கிட்ஹப் இல் இருந்தால், உங்கள் கோப்பகத்தை உங்கள் மூல அடைவில் பரிந்துரைக்கப்படும் கோப்புப்பெயர்கள் மூலம் கிட்ஹப் அங்கீகரிக்கவும், தானாக உங்கள் வாசகர்களுக்கு அவற்றைப் பரப்பவும் உதவும். + +### உரிமம் தெரிவு செய்தல் + +திறந்த மூல உரிமம் மற்றவர்கள் பயன்படுத்தலாம், நகலெடுக்கலாம், மாற்றலாம், மற்றும் விளைவுகள் இல்லாமல் உங்கள் திட்டத்திற்கு மீண்டும் பங்களிக்கலாம் என உத்திரவாதம் அளிக்கிறது. இது ஒட்டக்கூடிய சட்டப்பூர்வ சூழ்நிலைகளிலிருந்து உங்களை பாதுகாக்கிறது. **திறந்த மூல திட்டத்தை நீங்கள் தொடங்கும்போது உரிமம் சேர்க்கப்பட வேண்டும்.** + +சட்ட வேலை வேடிக்கை இல்லை. நல்ல செய்தி என்னவெனில் உங்கள் களஞ்சியத்தில் ஏற்கனவே உரிமம் நகலெடுத்து ஒட்டலாம். உங்கள் கடின உழைப்பைப் பாதுகாக்க இது ஒரு நிமிடம் மட்டுமே ஆகும். + +[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). + +நீங்கள் கிட்ஹப் இல் புதிய திட்டத்தை உருவாக்கும்போது, உரிமம் ஒன்றைத் தேர்ந்தெடுக்கும் உரிமை உங்களுக்கு உள்ளது. ஒரு திறந்த மூல உரிமத்தை உட்படுத்துவது உங்கள் கிட்ஹப் திட்டத்தை திறந்த மூலமாக்கும். + +![உரிமம் தேர்ந்தெடு](/assets/images/starting-a-project/repository-license-picker.png) + +ஒரு திறந்த மூல திட்டத்தை நிர்வகிப்பதற்கான சட்ட அம்சங்களைப் பற்றி நீங்கள் மற்ற கேள்விகளை அல்லது கவலையைப் பெற்றிருக்கிறீர்கள் என்றால், [நாங்கள் உங்கள் பாதுகாப்பிற்கு உள்ளோம்](../legal/). + +### README எழுதுவது + +README கள் உங்கள் திட்டத்தை எவ்வாறு பயன்படுத்துவது என்பதை விளக்கவும். உங்கள் திட்டப்பணிகளுக்கான காரணத்தையும் உங்கள் பயனர்கள் என்ன செய்யலாம் என்பதையும் அவை விளக்கும். + +உங்கள் README இல் பின்வரும் கேள்விகளுக்கு பதிலளிக்க முயற்சி செய்க: + +* இந்த திட்டம் என்ன செய்கிறது? +* ஏன் இந்த திட்டம் பயனுள்ளதாக இருக்கும்? +* நான் எப்படி தொடங்குவது? +* எனக்கு உதவி தேவைப்பட்டால், எங்கிருந்து உதவி கிடைக்கும்? + +நீங்கள் பங்களிப்புகளை எவ்வாறு கையாளுகிறீர்கள், திட்டத்தின் இலக்குகள் என்ன, உரிமங்கள் மற்றும் பண்புக்கூறு பற்றிய தகவல்கள் போன்ற மற்ற கேள்விகளுக்கு பதிலளிக்க உங்கள் README ஐ பயன்படுத்தலாம். பங்களிப்புகளை ஏற்றுக்கொள்ள விரும்பவில்லை என்றால், அல்லது உங்கள் திட்டம் இன்னும் தயாரிப்புக்கு தயாராக இல்லை என்றால், இந்த தகவலை கீழே எழுதவும். + + + +சில நேரங்களில், மக்கள் ஒரு README எழுதுவதைத் தவிர்ப்பதால், திட்டம் முடிவடையாததுபோல் அவர்கள் உணர்கிறார்கள் அல்லது பங்களிப்புகளை விரும்பவில்லை. இவை ஒவ்வொன்றும் எழுத மிகவும் நல்ல காரணங்கள். + +மேலும் உத்வேகம் பெறுவதற்காக, @18F இன் ["README களை வாசிக்கக்கூடியதாக செய்தல்"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) or @PurpleBooth's [README வார்ப்புரு](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) முழுமையான README எழுதுவதற்கு பயன்படுத்தவும். + +நீங்கள் மூல அடைவில் ஒரு README கோப்பை சேர்க்கும்போது, கிட்ஹப் தானாக களஞ்சியத்தின் முகப்பு பக்கத்தில் காண்பிக்கும். + +### உங்கள் பங்களிப்பு வழிமுறைகளை எழுதுதல் + +உங்கள் திட்டத்தில் பங்கெடுக்க எப்படி உங்கள் பார்வையாளர்களுக்கு ஒரு CONTRIBUTING கோப்பு சொல்கிறது. உதாரணமாக, நீங்கள் இதில் பின்வரும் தகவல்களைக் கொண்டிருக்கலாம்: + +* ஒரு பிழை அறிக்கையை எவ்வாறு பதிவு செய்யலாம் ([சிக்கல் மற்றும் இழு கோரிக்கை வார்ப்புருக்களை](https://github.com/blog/2111-issue-and-pull-request-templates) பயன்படுத்தி முயற்சி செய்யுங்கள்) +* ஒரு புதிய அம்சத்தை எப்படி பரிந்துரைப்பது +* எப்படி உங்கள் சூழலை அமைப்பது மற்றும் சோதனைகள் ஓட்டுவது + +தொழில்நுட்ப விவரங்களுடன் கூடுதலாக, பங்களிப்பிற்கான உங்கள் எதிர்பார்ப்புகளை தொடர்புகொள்வதற்கான ஒரு வாய்ப்பாக உள்ளது: + +* நீங்கள் தேடும் பங்களிப்பு வகைகள் +* திட்டத்திற்கான உங்கள் செயல் திட்டம் அல்லது பார்வை +* எப்படி பங்களிப்பாளர்கள் உங்களுடன் தொடர்பு கொள்ள வேண்டும் (அல்லது கூடாது) + +ஒரு இரக்கம் உள்ள, நட்புரீதியான தொனியைப் பயன்படுத்தி, பங்களிப்பிற்கான குறிப்பிட்ட பரிந்துரைகளை வழங்குதல் (ஆவணங்கள் எழுதுதல் அல்லது வலைத்தளமாக்குதல் போன்றவை) புதுமுகங்கள் வரவேற்பு மற்றும் பங்கேற்க ஆர்வமுடையவையாக இருப்பதால் நீண்ட தூரம் செல்லலாம். + +உதாரணமாக, [ஆக்டிவ் அட்மின்](https://github.com/activeadmin/activeadmin/) [அதன் பங்களிப்பு வழிகாட்டி](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) உடன் தொடங்குகிறது: + +> முதலில், ஆக்டிவ் அட்மினுக்கு பங்களிக்க கருதியதற்கு நன்றி. ஆக்டிவ் அட்மின் போன்ற ஒரு பெரிய கருவியை உருவாக்கியது உங்களை போன்ற மக்கள் தான். + +உங்கள் திட்டத்தின் ஆரம்ப கட்டங்களில், உங்கள் CONTRIBUTING கோப்பு எளியதாக இருக்கலாம். பிழைகள் அல்லது கோப்புப் பிரச்சினைகள், மற்றும் எந்த ஒரு தொழில்நுட்ப தேவைகள் (சோதனைகள் போன்றவை) பங்களிப்பைச் செய்வது குறித்து புகாரளிப்பது எப்போது என்பதை நீங்கள் எப்பொழுதும் விளக்க வேண்டும். + +காலப்போக்கில், உங்கள் பங்களிப்புக் கோப்பில் நீங்கள் அடிக்கடி கேட்கப்படும் கேள்விகள் சேர்க்கப்படலாம். இந்த தகவலை எழுதுவது குறைவான மக்கள் உங்களை மீண்டும் அதே கேள்விகளை கேட்க வேண்டும் என்பதாகும். + +உங்கள் பங்களிப்புக் கோப்பை எழுதுவதற்கு அதிக உதவிக்காக, @nayafia இன் [பங்களிப்பு வழிகாட்டி வார்ப்புரு](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) அல்லது @mozilla's ["எப்படி ஒரு CONTRIBUTING.md உருவாக்கவும்"](Https://mozillascience.github.io/working-open-workshop/contributing/) என பார்க்கவும். + +உங்கள் README லிருந்து உங்கள் பங்களிப்பு கோப்பினை இணைக்க, அதிகமானோர் அதைப் பார்க்கிறார்கள். நீங்கள் ஒரு [பங்களிப்பு கோப்பு உங்கள் திட்டத்தின் களஞ்சியத்தில் வைக்கும்போது](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), உங்கள் பங்களிப்பாளர் ஒரு சிக்கல் உருவாக்கும் போது அல்லது ஒரு மிகுதிக் கோரிக்கையைத் திறக்கும் போது கிட்ஹப் தானாகவே கோப்பில் இணைக்கப்படும் + +![பங்களிப்பு நெறிமுறைகள்](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### நடத்தை குறியீடு நிலைநாட்டுதல் + + + +இறுதியாக, உங்கள் திட்டத்தின் பங்கேற்பாளர்களுக்கு நடத்தைக்கான விதிகளை அமைப்பதற்கு ஒரு நடத்தை நெறிமுறை உதவுகிறது. ஒரு சமூகம் அல்லது நிறுவனத்திற்கான திறந்த மூல திட்டத்தை நீங்கள் தொடங்கினால், இது குறிப்பாக மதிப்புமிக்கது. பராமரிப்பாளராக உங்கள் அழுத்தத்தை குறைக்கும் ஆரோக்கியமான, ஆக்கபூர்வமான சமூக நடத்தைக்கு ஒரு நடத்தை நெறிமுறை உங்களுக்கு உதவுகிறது. + +மேலும் தகவலுக்கு, எங்கள் [நடத்தை வழிகாட்டி](../code-of-conduct/). + +கூடுதலாக பங்கேற்பாளர்கள் _எப்படி_ நடந்து கொள்ள வேண்டும் என நீங்கள் எதிர்பார்க்கிறீர்கள், ஒரு நெறிமுறை குறியீடு கூட இந்த எதிர்பார்ப்புகளை யாருக்கு எப்போது உபயோகிக்கப்படும், மற்றும் ஒரு மீறல் ஏற்படுமானால் என்ன செய்ய வேண்டும் என்பதை விவரிக்க முனைகிறது. + +திறந்த மூல உரிமங்களைப் போலவே, நடத்தை நெறிமுறைகளுக்கான தரநிலைகளும் உள்ளன, எனவே நீங்கள் சொந்தமாக எழுத வேண்டியதில்லை. [பங்களிப்பாளரின் உடன்படிக்கை](https://contributor-covenant.org/) என்பது, [40,000 திறந்த மூல திட்டங்களுக்கு](https://contributor-covenant.org/adopters/) பயன்படுத்துகின்ற ஒரு நெறிமுறை குறியீடாகும், குபெர்னீஸ், ரெயில்ஸ் மற்றும் ஸ்விஃப்ட் உட்பட. நீங்கள் பயன்படுத்தும் உரை எதுவாக இருந்தாலும், தேவையான போது உங்கள் நடத்தை நெறிமுறை செயல்படுத்துவதற்கு நீங்கள் தயாராக இருக்க வேண்டும். + +உரையை நேரடியாக உங்கள் களஞ்சியத்தில் CODE_OF_CONDUCT கோப்பில் ஒட்டுக. உங்கள் திட்டத்தின் கோப்பகத்தில் மூல அடைவில் கோப்பை வைத்திருங்கள், அதை எளிதாக கண்டுபிடிக்கலாம், மேலும் அதை README இலிருந்து இணைக்கவும். + +## உங்கள் திட்டத்திற்கான பெயரிடுதல் மற்றும் முத்திரை பதித்தல் + +வணிகச் சின்னம் என்பது ஒரு கவர்ச்சியுள்ள முத்திரை அல்லது திட்டப்பணி பெயரை விட அதிகம். நீங்கள் உங்கள் திட்டத்தைப் பற்றி என்ன பேசுகிறீர்கள், மற்றும் நீங்கள் உங்கள் செய்தியுடன் யாரை சென்றடைகிறீர்கள் என்பது தான். + +### சரியான பெயரைத் தேர்ந்தெடுப்பது + +நினைவில் எளிதான ஒரு பெயரைத் தேர்ந்தெடுத்து, திட்டம் என்ன செய்வதென்று சில யோசனைகள் தெரிவியிங்கள். உதாரணத்திற்கு: + +* [சென்ட்ரி](https://github.com/getsentry/sentry) தகர்வொலி அறிக்கைக்காக செயலிகளை கண்காணிக்கிறது +* [தின்](https://github.com/macournoyer/thin) ஒரு வேகமான மற்றும் எளிமையான ரூபி வலை சேவையகம் + +ஏற்கனவே இருக்கும் திட்டத்தின் மீது நீங்கள் கட்டியெழுப்பினால், முன்னொட்டாக தங்கள் பெயரைப் பயன்படுத்தி உங்கள் திட்டம் என்ன என்பதை தெளிவுபடுத்துவதற்கு உதவலாம் (எடுத்துக்காட்டாக, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` ஐ Node.js க்கு கொண்டு வருகிறது). + +தெளிவு எல்லாவற்றிற்கும் மேலானது. சிலேடை பேச்சு வேடிக்கையானது, ஆனால் சில நகைச்சுவைகளை நீங்கள் வேறுபட்ட கலாச்சாரங்களுடன் அல்லது வேறுபட்ட அனுபவங்களுடன் மக்களுக்கு மொழிபெயர்க்க முடியாது என்பதை நினைவில் கொள்க. உங்கள் சாத்தியமான சில பயனர்கள் நிறுவன ஊழியர்களாக இருக்கலாம்: வேலையில் உங்கள் திட்டத்தை விளக்க அவர்களுக்கு நீங்கள் சங்கடத்தை உண்டாக்க வேண்டாம்! + +### பெயர் முரண்பாடுகளைத் தவிர்த்தல் + +[இதே போன்ற பெயரில் திறந்த மூல திட்டங்களுக்கான சரிபார்க்கவும்](http://ivantomic.com/projects/ospnc/), குறிப்பாக நீங்கள் ஒரே மொழியை அல்லது சுற்றுச்சூழலைப் பகிர்ந்து கொள்ளும் பொழுது. பிரபலமான ஒரு திட்டத்தினுடன் உங்கள் பெயர் மேற்பொருந்துதல் இருந்தால், உங்கள் பார்வையாளர்களை குழப்பக்கூடும். + +வலைத்தளம், கீச்சு கைப்பிடி அல்லது உங்கள் திட்டத்தை பிரதிநிதித்துவப்படுத்தும் பிற பண்புகளை நீங்கள் விரும்பினால், நீங்கள் விரும்பும் பெயர்களை பெறலாம் என்பதை உறுதிப்படுத்தவும். நீங்கள் இன்னும் அவற்றை பயன்படுத்த விரும்பவில்லை என்றால் கூட, மன அமைதிக்காக [இப்போது அந்த பெயர்களை வைத்திருக்கவும்](https://instantdomainsearch.com/). + +உங்கள் திட்டத்தின் பெயர் எந்த வர்த்தக முத்திரைகளிலும் மீறவில்லை என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். ஒரு நிறுவனம் பின்னர் உங்கள் திட்டத்தை நீக்குமாறு கேட்கலாம் அல்லது உங்களுக்கு எதிரான சட்ட நடவடிக்கை எடுக்கலாம். அது ஆபத்துக்கு மதிப்பு இல்லை. + +வர்த்தக முத்திரை மோதல்களுக்கு [WIPO குளோபல் பிராண்ட் டேட்டாபேஸ்](http://www.wipo.int/branddb/en/) சரிபார்க்கலாம். நீங்கள் ஒரு நிறுவனத்தில் இருந்தால், இதில் உங்கள் [சட்ட குழு உங்களுக்கு உதவும்](../legal/). + +இறுதியாக, உங்கள் திட்டத்தின் பெயரை கூகுளில் தேடுங்கள். மக்கள் உங்கள் திட்டத்தை எளிதில் கண்டுபிடிக்க முடியுமா? வேறு எதையாவது நீங்கள் காண விரும்பாதவை தேடல் முடிவுகளில் தோன்றுகிறதா? + +### எப்படி எழுதுவது (மற்றும் நிரலாக்குதல்) உங்கள் நிறுவனஅடையாளத்தை பாதிக்கிறது! + +உங்கள் திட்டத்தின் வாழ்நாள் முழுவதிலும், நீங்கள் நிறைய எழுதுவீர்கள்: README கள், பயிற்சிகள், சமூகம் ஆவணங்கள், சிக்கல்களுக்கு பதிலளித்தல், சில வேளைகளில் செய்திமடல்கள் மற்றும் அஞ்சல் பட்டியல்கள். + +இது உத்தியோகபூர்வ ஆவணமாக்கல் அல்லது ஒரு தற்காலிக மின்னஞ்சலாக இருந்தாலும், உங்கள் எழுத்து பாணி உங்கள் திட்டத்தின் நிறுவனஅடையாளத்தின் ஒரு பகுதியாகும். உங்கள் பார்வையாளர்களிடம் நீங்கள் எப்படி நடந்துகொள்வீர்கள் என்பதையும், நீங்கள் அறிவிக்க விரும்பும் தொனி அதுதானா என்பதையும் கவனியுங்கள். + + + +கனிவான, உள்ளடக்கிய மொழி (ஒற்றை நபரைக் குறிப்பிடும் போதும் "அவர்கள்" போன்றவை) உங்கள் திட்டத்தை புதிய பங்களிப்பாளர்களுக்கு வரவேற்பதாக உணர வைக்கும். எளிமையான மொழியை கடைபிடியுங்கள், உங்கள் வாசகர்களில் பலருக்கு ஆங்கிலம் தாய்மொழியாக இல்லாமலிருக்கலாம். + +நீங்கள் வார்த்தைகளை எப்படி எழுதுகிறீர்களோ அப்படியே, உங்கள் குறியீட்டு பாணி உங்கள் திட்டத்தின் நிலையக அடையாள பகுதியாகவும் மாறும். [Angular](https://github.com/johnpapa/angular-styleguide) மற்றும் [jQuery](https://contribute.jquery.org/style-guide/js/) இரண்டும் கடுமையான குறியீட்டு முறை மற்றும் வழிகாட்டுதல்கள் உள்ள திட்டங்களுக்கான உதாரணங்களாகும். + +நீங்கள் தொடங்கும் பொழுதே, உங்கள் திட்டத்திற்கு ஒரு பாணி வழிகாட்டி எழுத தேவையில்லை, மற்றும் நீங்கள் எப்படியும் உங்கள் திட்டத்தில் வேறு குறியீட்டு பாணியை ஒருங்கிணைத்து அனுபவிக்கலாம். ஆனால் உங்கள் எழுத்து மற்றும் குறியீட்டு நடை எப்படி பல்வேறு வகையான மக்களை கவர்ந்திழுக்க அல்லது ஊக்கப்படுத்தலாம் என்பதை நீங்கள் எதிர்பார்க்க வேண்டும். உங்கள் திட்டத்தின் ஆரம்ப கட்டங்கள் நீங்கள் பார்க்க விரும்பும் முன்னோடிகளை அமைக்கும் வாய்ப்பாக இருக்கும். + +## உங்கள் முன்-வெளியீட்டு பட்டியல் + +உங்கள் திட்டத்தைத் திறக்க தயாரா? உதவிக்கு ஒரு பட்டியல் இங்கே. அனைத்து பெட்டிகளையும் சரிபார்க்கவும்? நீங்கள் செல்ல தயாராக உள்ளீர்கள்! ["வெளியிடு" என்பதைக் சொடுக்கவும்](https://help.github.com/articles/making-a-private-repository-public/) பின்பு உங்களை நீங்களே தட்டிக்கொடுத்து கொள்ளவும். + +**ஆவணப்படுத்தல்** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Code** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**மக்கள்** + +நீங்கள் ஒரு தனிநபர் என்றால்: + +
+ + +
+ +நீங்கள் ஒரு நிறுவனம் அல்லது அமைப்பாக இருந்தால்: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## நீங்கள் செய்தீர்கள்! + +உங்களுடைய முதல் திட்டத்தை திறந்து வைப்பதில் வாழ்த்துக்கள். பலன் எதுவாயினும், பொதுவில் வேலை செய்வது சமுதாயத்திற்கு ஒரு பரிசு. ஒவ்வொரு அணுகலும், கருத்து தெரிவிக்கவும், கோரிக்கை விடுக்கவும், நீங்களாகவும், மற்றவர்களுக்காகவும் கற்றுக்கொள்ளவும் வளரவும் வாய்ப்புகளை உருவாக்குகிறீர்கள். diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md new file mode 100644 index 00000000000..8f25c0418ff --- /dev/null +++ b/_articles/tr/best-practices.md @@ -0,0 +1,280 @@ +--- +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 +order: 5 +image: /assets/images/cards/best-practices.png +related: +- metrics +- leadership +--- + +## Geliştirici olmak ne demektir? + +Birçok insanın kullandığı açık kaynak bir projeyi sürdürürseniz, daha az kodladığınızı ve sorunlara daha fazla cevap verdiğinizi fark etmiş olabilirsiniz. + +Bir projenin ilk aşamalarında, yeni fikirleri deniyor ve istediğinizi temel alan kararlar alıyorsunuz. Projeniz popülerlik arttıkça, kendinizi kullanıcılar ve katkıda bulunanlarla daha fazla çalışırken bulabilirsiniz. + +Bir projeyi sürdürmek kod yazmaktan daha fazlasını gerektirir. Bu görevler genellikle beklenmedik bir durum değildir, ancak büyümekte olan bir proje için son derece önemlidir. Yaşamınızı kolaylaştırmak için, belgeleme işlemlerinden topluluğunuzu güçlendirmeye kadar birkaç yol yöntemi derledik. + +## İşlemlerinizi belgeleme + +Her şeyi yazı hale getirmek, geliştirici olarak yapabileceğiniz en önemli şeylerden biridir. + +Dokümantasyon sadece kendi düşüncelerinizi netleştirmekle kalmaz, diğer kişilerin size sormadan önce neye ihtiyacınız olduğunu veya ne beklediğinizi anlamalarına yardımcı olur. + +Bir şeyler yazmak, bir şey sizin kapsamınıza uymadığında hayır demeyi kolaylaştırır. Ayrıca insanların girip yardım etmesini kolaylaştırır. Projenizi kimlerin okuyup kullanabileceğini asla bilemezsiniz. + +Geniş paragraflar kullanmasanız da, madde imleri kullanarak not almak bile, yazmaktan daha iyidir. + +Belgelerinizi güncel tutmayı unutmayın. Bunu her zaman yapamıyorsanız, eski belgelerinizi silin veya eski olduğunu belirtin; böylece katkıda bulunanlar güncellemelerin memnuniyetle karşılandığını bilir. + +### Projenizin vizyonunu yazın + +Projenizin hedeflerini yazarak başlayın. Bunları README'nize ekleyin veya VISION adlı ayrı bir dosya oluşturun. Proje yol haritası gibi, yardımcı olabilecek başka çıktılar varsa, bunları da yayınlayabilirsiniz. + +Net ve belgelenmiş bir vizyona sahip olmanız odaklanmanızı sağlar ve başkalarının katkılarından "kapsamın sürünmesini" önlemenize yardımcı olur. + +Örneğin, @lord, proje vizyonuna sahip olmanın, hangi ihtiyaç için zaman harcamaya ihtiyaç duyulacağını belirlemesine yardımcı olduğunu keşfetti. Yeni bir geliştirici olarak, [Slate](https://github.com/lord/slate) için ilk uzun metraj talebini aldığında, projesinin kapsamına uymadığı için pişmanlık duydu. + + + +### Beklentilerinizi iletin + +Kurallar yazmak için sinir bozucu olabilir. Bazen başkalarının davranışlarına göz attığınızı ya da tüm eğlenceyi öldürdüğünüzü hissedebilirsiniz. + +Ancak, adil bir şekilde yazılmış ve uygulanmış olduğunda, iyi kurallar geliştiricileri güçlendirir. Yapmak istemediğiniz şeyleri yapmaya sürüklenmenizi önlerler. + +Projenize rastlayan çoğu kişi sizin hakkınızda veya durumunuz hakkında hiçbir şey bilmiyor olabilir. Üzerinde çalışmak için para aldığınızı varsayabilirler, özellikle düzenli olarak kullandıkları ve güvendikleri bir şeyse. Belki bir noktada projenize çok zaman ayırıyorsunuz, ancak şimdi yeni bir iş veya aile üyesiyle meşgulsünüz. + +Bunların hepsi olabilir! Sadece başkalarının da bildiğinden emin ol. + +Projenizi yarı zamanlı veya tamamen gönüllü olarak sürdürmekteyseniz, ne kadar vaktiniz olduğu konusunda dürüst olun. Bu, projenin ne kadar zaman gerektirdiğini düşündüğünüzle veya başkalarının ne kadar zaman harcamanızı istediği ile aynı değildir. + +Yazmaya değer birkaç kural: + +* Bir katkı nasıl gözden geçirilir ve kabul edilir ( _Testlere ihtiyaçları var mı? Bir sorun şablonu var mı?_ ) +* Kabul edeceğiniz katkı türleri ( _Kodunuzun yalnızca belirli bir bölümünde yardım mı istiyorsunuz?_ ) +* 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/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 + +Sizin de etkileşimlerinizi belgelemeyi unutmayın. Nerede olursanız olun, projeniz hakkında iletişimi halka açık tutun. Birisi bir özellik isteğini veya destek ihtiyacını tartışmak için sizinle özel olarak iletişim kurmaya çalışırsa, kibarca onları bir posta listesi veya sorun izleyici gibi bir kamu iletişim kanalına yönlendirin. + +Diğer geliştiricilerle tanışırsanız veya özel olarak büyük bir karar verirseniz, bu konuşmaları halka açıklayın, yalnızca notlarınızı gönderiyor olsanız bile. + +Bu şekilde, topluluğunuza yeni katılan herhangi biri, yıllardır orada olan biriyle aynı bilgilere erişebilecektir. + +## Hayır demeyi öğrenme + +Her şeyi yazdınız. İdeal olarak, herkes belgelerinizi okur, ancak gerçekte, bu bilginin var olduğunu başkalarına hatırlatmanız gerekecek. + +Bununla birlikte, her şeyin yazılı olması, kurallarınızı uygulamanız gerektiğinde durumları kişisellikten uzaklaştırmanıza yardımcı olur. + +Hayır demenin eğlenceli olmadığı kesin, ancak "_Katkınız bu projenin ölçütlerine uymuyor_" cevabı "_Katkınızı beğenmedim_" cevabından daha kurumsal hissettiriyor. + +Bir geliştirici olarak karşılaşacağınız birçok durum için hayır demek uygundur: Örneğin, kapsama uygun olmayan özellik talepleri, tartışmanın rayından çıkması durumunda, başkaları için gereksiz işler yapılması durumunda. + +### Sohbeti dostane tutun + +Hayır demeyi uygulayacağınız en önemli yerlerden biri de, sorun ve istek sıralarıdır. Bir proje sorumlusu olarak, çoğunlukla kabul etmek istemediğiniz öneriler alırsınız. + +Belki yapılan katkı projenizin kapsamını değiştiriyor veya vizyonunuza uymuyor. Belki fikir iyidir, ancak uygulama zayıftır. + +Sebep ne olursa olsun, projenizin standartlarına uymayan katkıları titizlikle ele almak mümkündür. + +Kabul etmek istemediğiniz bir katkı alırsanız, ilk tepkiniz bunu görmezden gelmek veya görmemiş gibi yapmak olabilir. Bunu yapmak, diğer kişinin duygularına zarar verebilir ve hatta topluluğunuzdaki diğer potansiyel katılımcıların cesaretini kırabilir. + + + +Kendinizi suçlu hissettiğiniz için veya iyi davranmak istediğiniz için, istenmeyen bir katkıyı açık bırakmayın. Zaman içinde, cevaplanmayan sorunlar ve birleştirme istekleri projeniz üzerinde çalışmayı çok daha stresli ve korkutucu hissettirecektir. + +Kabul etmek istemediğinizi bildiğiniz katkıları derhal kapatmak daha iyidir. Projeniz zaten büyük bir birikimden etkilenmişse, @steveklabnik, [sorunların verimli bir şekilde nasıl sıralanacağı](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) konusunda verdiği önerilere bakabilirsiniz. + +İkincisi, katkıları görmezden gelmek, topluluğunuz için olumsuz bir sinyal gönderir. Bir projeye katkıda bulunmak, özellikle birinin ilk defa olması durumunda korkutucu olabilir. Katkısını kabul etmeseniz bile, arkasındaki kişiyi kabul edin ve ilgileri için teşekkür ederiz. Onlar için bu büyük bir iltifat olur! + +Bir katkıyı kabul etmek istemiyorsanız: + +* Katkıdan dolayı **teşekkür edin**. +* **Neden proje kapsamına girmediğini açıklayın** ve mümkünse iyileştirme için net önerilerde bulunun. Nazik ama kararlı olun. +* 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, [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) + +Eğer hayır deme düşüncesi sizi korkutuyorsa, yalnız değilsiniz. @Jessfraz'ın [söylediği gibi](https://blog.jessfraz.com/post/the-art-of-closing/): + +> Birkaç farklı açık kaynaklı projeden, Mesos, Kubernetes, Chromium'dan gelenlerle konuştum ve hepsi de bir geliştirici olmanın en zor kısımlarından birinin yaptığı istemediğiniz yamalar için "Hayır" demek olduğu konusunda hemfikirler. + +Birinin katkısını kabul etmek istemediğiniz için suçluluk hissetmeyin. @Shykes'e [göre](https://twitter.com/solomonstre/status/715277134978113536) ilk açık kaynak kuralı: _"Hayır geçici, evet kalıcıdır."_ Başka birinin coşkusunu empati etmek iyi bir şey olsa da, bir katkıyı reddetmek, arkasındaki kişiyi reddetmekle aynı değildir. + +Sonuçta, eğer bir katkı yeterince iyi değilse, kabul etme yükümlülüğünüz yoktur. İnsanlar projenize katkıda bulunurken nazik ve duyarlı olun, ancak yalnızca projenizi daha iyi hale getireceğine gerçekten inandığınız değişiklikleri kabul edin. Ne kadar sık hayır demeyi pratik edersen, işin o kadar kolaylaşır. Kesinlikle. + +### Proaktif olun + +İstenmeyen katkıların hacmini ilk etapta azaltmak için, projenizin katkıda bulunma rehberinde katkı gönderme ve kabul etme sürecini açıklayın. + +Çok fazla düşük kaliteli katkı alıyorsanız, katkıda bulunanların önceden biraz çalışma yapmasını isteyin, örneğin: + +* Bir sorun veya PR şablonunu veya kontrol listesi doldurma +* PR göndermeden önce bir sorun açma + +Kurallarınıza uymuyorlarsa, belgelerinizi referans göstererek sorunu hemen kapatın. + +Bu yaklaşım ilk başta kaba görünebilir olsa da proaktif olmak her iki taraf için de iyidir. Birisinin kabul etmeyeceğiniz bir talep boşa saatlerce çalışma yapma riskini azaltır. Ve sizin de iş yükünüzü yönetmeyi kolaylaştırır. + + + +Bazen, hayır dediğinizde, katkıda bulunan kişi kararınızdan dolayı kırılabilir veya sizi eleştirebilir. Davranışları düşmanca olursa, yapıcı bir şekilde işbirliği yapmaya istekli olmazlarsa [durumu etkisiz hale getirmek için adımlar atın](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) ve hatta onları topluluğunuzdan çıkarın. + +### Mentorluğu benimseyin + +Belki de topluluğunuzdaki birileri düzenli olarak projenizin standartlarını karşılamayan katkılar sunar. Her iki tarafın da bu reddedilme süreçlerinden defalarca geçmesi sinir bozucu olabilir. + +Birinin projeniz için hevesli olduğunu ancak biraz el vermek gerektirdiğini görürseniz, sabırlı olun. Her durumda katkılarının neden projenin beklentilerini karşılamadığını açık bir şekilde açıklayın. Onları ellerini kirletmek için _"ilk iş için uygun"_ olarak işaretlenmiş bir konu gibi daha kolay veya daha az belirsiz bir işe yönlendirmeyi deneyin. Vaktiniz varsa, ilk katkılarınla onlara mentor olmayı düşünün veya topluluğunuzda mentor olmaya istekli olabilecek başka birini bulun. + +## Topluluğunuzdan yararlanma + +Her şeyi kendiniz yapmak zorunda değilsiniz. Projenizin topluluğunun olmasının bir nedeni var! Henüz aktif bir katkıda bulunan topluluğunuz olmasa bile, çok fazla kullanıcınız varsa, onları işe dahil edin. + +### İş yükünü paylaşın + +Başkalarının işe girişmesini istiyorsanız, bu dile getirerek başlayın. + +Yeni katılımcılar kazanmanın bir yolu da [yeni katılanlar için kolay çözülebilecek sorunları belirmektir](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub bu sorunları platform üzerindeki farklı sayfalarda göstererek farkedilebilir olmalarını sağlayacaktır. + +Katkıda bulunan arasında yeni olanları gördüğünüzde, çalışmalarını daha fazla sorumluluk sunarak tanıyın. İsterlerse kendilerinin de yöneticilik rolüne nasıl dönüşebileceğini belgeleyin. + +Başkalarını yüreklendirmek ve [projenin sahipliğini paylaşmak](../building-community/#projenizi-paylaşın) kendi iş yükünüzü azaltır. @lmccart kendi projesinde bunu nasıl yaptığını aşağıdaki gibi anlatıyor, [p5.js](https://github.com/processing/p5.js). + + + +Projenizden, ara sıra veya kalıcı olarak çıkmanız gerekirse, bir başkasının sizin için üstlenmesini istemek utanılacak bir şey değildir. + +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://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. + +### Başkalarının ihtiyaç duydukları çözümleri inşa etmelerine izin verin + +Potansiyel bir katılımcının projenizin ne yapması gerektiği konusunda farklı bir görüşü varsa, onları kendi çatalı üzerinde çalışmaya kibarca teşvik etmek isteyebilirsiniz. + +Bir projeyi terk etmek kötü bir şey olmak zorunda değildir. Projeleri kopyalayıp değiştirebilmek, açık kaynak kodlu hakkında en iyi şeylerden biridir. Topluluk üyelerinizi kendi çatalı üzerinde çalışmaya teşvik etmek, projenizin vizyonuyla çelişmeden ihtiyaç duydukları yaratıcı çıkışı sağlayabilir. + + + +Aynı şey, inşa edecek bant genişliğine sahip olmadığınız bir çözümü gerçekten isteyen bir kullanıcı için de geçerlidir. API'ler ve kişiselleştirme kancaları sunmak, kaynağını doğrudan değiştirmek zorunda kalmadan, başkalarının kendi ihtiyaçlarını karşılamasına yardımcı olabilir. @orta, CocoaPod'lar için teşvik edici eklentilerin "en ilginç fikirlerin bazılarına" yol açtığını [gördü](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) : + +> Bir proje büyükleştiğinde, bakımcılar yeni kodu nasıl girdikleri konusunda daha muhafazakar hale gelmek neredeyse kaçınılmazdır. Hayır demekte iyisin, ama birçok insanın meşru ihtiyaçları var. Bunun yerine aracınızı bir platforma dönüştürürsünüz. + +## Robotları kullanın + +Tıpkı diğer insanların size yardımcı olabileceği görevler olduğu gibi, hiçbir insanın yapmaması gereken görevler de vardır. Robotlar senin arkadaşın. Hayatınızı kolaylaştırmak için bunları kullanın. + +### Kodunuzun kalitesini yükseltmek için testler ve diğer kontrolleri zorunlu kılın + +Projenizi otomatikleştirmenin en önemli yollarından biri de testler eklemektir. + +Testler, katkıda bulunanların hiçbir şeyi kırmayacaklarından emin olmalarına yardımcı olur. Ayrıca katkıları hızla incelemenizi ve kabul etmenizi kolaylaştırır. Ne kadar duyarlı olursanız, toplumunuz o kadar adanmış olabilir. + +Tüm gelen katkılarda çalışacak otomatik testler ayarlayın ve testlerinizin katılımcılar tarafından kolayca yerel olarak çalıştırılabildiğinden emin olun. Tüm kod katkılarının gönderilmeden önce testlerinizi geçmesini şart koşun. Tüm gönderiler için minimum kalite standardı belirlenmesine yardımcı olmuş olacaksınız. GitHub'daki [zorunlu durum kontrolleri](https://help.github.com/articles/about-required-status-checks/) , testleriniz geçmeden değişiklik yapılmadan birleştirilmemesini sağlayabilir. + +Testler eklerseniz, CONTRIBUTING dosyanızda nasıl çalıştıklarını açıkladığınızdan emin olun. + + + +### Temel bakım görevlerini otomatikleştirmek için araçlar kullanın + +Popüler bir projeyi sürdürmenin iyi haberi, diğer geliştiricilerin de benzer sorunlarla karşı karşıya kalmaları ve bunun için bir çözüm üretmeleridir. + +Bakım çalışmalarının bazı yönlerini otomatikleştirmeye yardımcı olacak [çeşitli araçlar vardır](https://github.com/showcases/tools-for-open-source). Birkaç örnek: + +* [semantic-release](https://github.com/semantic-release/semantic-release) sürümlerinizi otomatikleştirir +* [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](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. + +E-posta bildirimlerinizi yönetmek için, önceliğe göre düzenlemek için [e-posta filtreleri](https://github.com/blog/2203-email-updates-about-your-own-activity) ayarlayabilirsiniz. + +Biraz daha gelişmiş olmak istiyorsanız, stil rehberleri ve taslaklar proje katkılarını standartlaştırabilir ve inceleme ve kabul etmeyi kolaylaştırabilir. + +Bununla birlikte, standartlarınız çok karmaşıksa, katılımların önüne engel olabilirler. Herkesin hayatını kolaylaştırmak için sadece yeterince kural eklediğinizden emin olun. + +Hangi araçları kullanacağınızdan emin değilseniz, özellikle ekosisteminizdeki diğer popüler projelerin neler yaptığına bakın. Örneğin, katılım süreci diğer Node modülleri için nasıl yapılmış? Benzer araçlar ve yaklaşımlar kullanmak, sürecinizi katkıda bulunması olası insanlar için daha tanıdık yapacaktır. + +## Duraklatmak sorun değildir + +Açık kaynak çalışması bir zamanlar size heyecan ve mutluluk getirmiştir. Ama şimdi size yük veya sorumluluk hissettirmeye başlamış olabilir. + +Belki de projelerinizi düşünürken bunalmış veya artan bir korku hissi duyuyorsunuz. Bu arada, sorunlar ve PR talepleri de yığılıyor. + +Tükenmişlik, özellikle geliştiriciler arasında açık kaynaklı çalışmalarda gerçek ve yaygın bir konudur. Bir geliştirici olarak mutluluğunuz, açık kaynaklı herhangi bir projenin hayatta kalması için tartışılmaz bir gerekliliktir. + +Söylemeye gerek yok ama, ara verin! Tatil yapmak için yanmış hissedene kadar beklemeniz gerekmez. Bir Python çekirdek geliştiricisi olan @brettcannon, 14 yıllık gönüllü OSS çalışmasının ardından [bir ay boyunca tatil](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) yapmaya karar verdi. + +Tıpkı diğer tüm işlerde olduğu gibi, düzenli molalar vermek de işinizi yenileyecek, mutlu ve heyecanlı tutacaktır. + + + +Bazen, herkesin size ihtiyacı olduğunu düşündüğünüz zamanlarda, bir açık kaynak projesine mola vermek zor olabilir. İnsanlar uzaklaştığınız için sizi suçlu hissettirmeye çalışabilir. + +Bir projeden uzaktayken kullanıcılarınız ve topluluğunuz için destek bulmak için elinizden geleni yapın. İhtiyacınız olan desteği bulamazsanız, yine de bir ara verin. Uygun olmadığınız zamanı duyurduğunuzdan emin olun, böylece insanlar yanıt verme konusundaki eksikliğinizden dolayı şaşkınlığa uğramazlar. + +Ara vermek, tatillerden daha fazlası için de geçerlidir. Hafta sonları veya mesai saatleri arasında açık kaynak kodlu bir iş yapmak istemiyorsanız, bu beklentinizi başkalarına iletin; böylece sizi rahatsız etmemeleri gerektiğini bilirler. + +## İlk önce kendinize iyi bakın! + +Popüler bir projeyi sürdürmek, büyümenin önceki aşamalarından farklı beceriler gerektirir, ancak daha az ödüllendirici değildir. Bir geliştirici olarak, birkaç kişinin deneyimleyebileceği bir seviyede liderlik ve kişisel beceriler geliştireceksiniz. Yönetimi her zaman kolay olmamakla birlikte, net sınırlar koymak ve yalnızca neleri yapacağınızı belirlemek sizin mutlu, yenilenmiş ve üretken kalmanıza yardımcı olacaktır. diff --git a/_articles/tr/building-community.md b/_articles/tr/building-community.md new file mode 100644 index 00000000000..db9461e5b0e --- /dev/null +++ b/_articles/tr/building-community.md @@ -0,0 +1,276 @@ +--- +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 +order: 4 +image: /assets/images/cards/building.png +related: +- best-practices +- coc +--- + +## Projenizi başarı için hazırlamak + +Projenizi başlattınız, mesajınızı yayıyorsunuz ve insanlar bunu farkediyor. Mükemmel! Şimdi, size katılmalarını nasıl sağlarsınız? + +Misafirperver bir topluluk, projenizin geleceğine ve itibarına yapılan bir yatırımdır. Projeniz ilk katkıları görmeye yeni başlıyorsa, erken katkıda bulunanlara olumlu bir deneyim vererek başlayın ve geri gelmelerini kolaylaştırın. + +### İnsanlara hoş geldiklerini hissettirmek + +Projenizin topluluğunu tanımlandırmanın bir yolu da @MikeMcQuaid'in dediği gibi onu [katılımcı hunisi olarak](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) düşünmektir: + +![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +Topluluğunuzu oluştururken huninin tepesindeki birinin (potansiyel bir kullanıcı) teorik olarak en alt seviyeye nasıl ulaşabileceğini (etkin bir geliştirici) düşünün. Amacınız, katılımcı deneyiminin her aşamasında engelleri azaltmaktır. İnsanlar kolay dahil olduklarında daha fazlasını yapmaya teşvik olurlar. + +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%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%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. + + + +Açık kaynak katkıda bulunanların çoğunluğu "geçici katkı yapanlardır": yani bir projeye yalnızca ara sıra katkıda bulunan insanlar. Sıradan bir katılımcının projenizi hızlandırmak için tam zamanı olmayacağı için işiniz onların katkıda bulunmalarını kolaylaştırmaktır. + +Diğer katılımcıları teşvik etmek kendinize yapılan bir yatırımdır. En büyük hayranlarınızı, heyecanlandıkları işle çalışmaya ikna ettiğinizde, her şeyi kendiniz yapmanız için daha az baskı olacaktır. + +### Her şeyi belgeleyin + + + +Yeni bir projeye başladığınızda, çalışmanızı özel tutmak doğal olabilir. Ancak, açık kaynaklı projeler, sürecinizi halka açık olarak belgelemeniz durumunda gelişir. + +Bir şeyleri yazdığınızda, her adımda daha fazla kişi katılabilir. İhtiyacın olduğunu bile bilmediğin bir konuda yardım alabilirsin. + +Bir şeyleri yazmak teknik dokümantasyondan daha fazlası demektir. Bir şeyi bir yere yazma istediğinizi veya projenizi özel olarak tartışmak istediğinizi her ne zaman hissederseniz, kendinize halka açılıp açılamayacağınızı sorun. + +Projenizin yol haritası, aradığınız katkı türleri, katkıların nasıl değerlendirildiği veya neden belirli kararlar aldığınız konusunda şeffaf olun. + +Aynı problemle karşılaşan birden fazla kullanıcı fark ederseniz, cevapları README'de belgeleyin. + +Toplantı notlarını ve sonuçlarını ilgili bir sorun açarak yayınlamayı düşünün. Bu şeffaflık seviyesinden alacağınız geri bildirimler sizi şaşırtabilir. + +Her şeyin belgelenmesi, yaptığınız iş için de geçerlidir. Projenize yönelik önemli bir güncelleme üzerinde çalışıyorsanız, bunun için bir PR açın ve devam etmekte olan bir çalışma (WIP) olarak işaretleyin. Bu şekilde, diğer insanlar bu sürece erkenden dahil olduklarını hissedebilirler. + +### Hızlı cevap verin + +[Projenizi duyurduğunuzda](../finding-users), insanların sizin için geri bildirimleri olacaktır. İşlerin nasıl yürüdüğü hakkında soruları olabilir veya başlamak için yardıma ihtiyaçları olabilir. + +Birisi bir sorun bildirirken, bir PR gönderdiğinde veya projeniz hakkında bir soru sorduğunda hızlıca cevap vermeye çalışın. Hızlı cevap verdiğinizde, insanlar bir diyaloğun parçası olduklarını hissedecekler ve katılım konusunda daha istekli olacaklar. + +İsteği hemen detaylı inceleyemezseniz bile, erkenden geri dönüş yapmak, katılımın artmasına yardımcı olur. İşte @dreyno'nun [Middleman'daki](https://github.com/middleman/middleman/pull/1466) PR için verdiği cevap: + +![Middleman pull request](/assets/images/building-community/middleman_pr.png) + +[Bir Mozilla çalışması](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177), 48 saat içinde kod incelemeleri alan katılımcıların çok daha yüksek bir getiri oranına ve katkı tekrarına sahip olduğunu gösterdi. + +Projenize ilişkin konuşmalar, İnternet üzerindeki Stack Overflow, Twitter veya Reddit gibi başka platformlarda da olabilir. Bu yerlerden bazılarında bildirimler ayarlayabilir, böylece birileri projenizden bahsettiğinde haberdar olursunuz. + +### Topluluğunuza toplanacak bir yer verin + +Topluluğuna toplanacak bir yer vermenin iki nedeni var. + +İlk sebep onlar için. İnsanların birbirlerini tanımalarına yardımcı olun. Ortak çıkarları olan insanlar kaçınılmaz olarak bunun hakkında konuşacakları bir yer isteyeceklerdir. İletişim kamuya açık ve erişilebilir olduğunda, herkes hızlanmak ve katılmak için geçmiş arşivleri okuyabilir. + +İkinci sebep sizin için. İnsanlara projeniz hakkında konuşacakları halka açık bir yer vermezseniz, muhtemelen sizinle doğrudan temasa geçerler. Başlangıçta, özel mesajlara "sadece bu seferlik" cevap verecek kadar kolay görünebilir. Ancak zamanla, özellikle de projeniz popüler hale gelirse, kendinizi yorgun hissedeceksiniz. Özel olarak projenizle ilgili insanlarla iletişim kurmaya özen gösterin. Bunun yerine, onları belirlenmiş bir genel kanala yönlendirin. + +Halkla iletişim, insanları doğrudan size e-posta göndermek veya blogunuza yorum yapmak yerine bir sorun açmaya yönlendirmek kadar basit olabilir. İnsanların projeniz hakkında konuşması için bir posta listesi oluşturabilir veya bir Twitter hesabı, Slack veya IRC kanalı oluşturabilirsiniz. Veya yukarıdakilerin hepsini deneyin! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved), topluluk üyelerine yardımcı olmak için her hafta bir miktar çalışma saatini ayırıyor: + +> Kops ayrıca topluluğa yardım ve rehberlik sunmak için her hafta biraz zaman ayırıyor. Kops şirket olarak çalışanlarının, yeni gelenlerle çalışmaya, PR'lara yardım etmeye ve yeni özellikleri tartışmaya özel olarak ayrılan zamanı kullanmasını kabul etti. + +Kamu iletişiminde dikkate değer istisnalar şunlardır: 1) güvenlik sorunları ve 2) hassas davranış kuralları ihlalleri. İnsanların bu sorunları özel olarak bildirmeleri için her zaman bir yolunuz olmalıdır. Kişisel e-postanızı kullanmak istemiyorsanız, özel bir e-posta adresi ayarlayın. + +## Topluluğunuzu büyütmek + +Topluluklar son derece güçlü yapılardır. Bu güç, onu nasıl kullandığınıza bağlı olarak bir lütuf veya bir lanet olabilir. Projenizin topluluğu büyüdükçe, yıkıcı değil, yapıcı bir güç haline gelmesine yardım etmenin yolları var. + +### Kötü karakterlere müsamaha göstermeyin + +Herhangi bir popüler proje kaçınılmaz olarak topluluğunuza yardım etmek yerine, zarar verebilecek insanları de çekecektir. Gereksiz tartışmalara başlatabilir, önemsiz özelliklere dikkat çekebilir veya başkalarını zorbalık edebilirler. + +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%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 + +İyi belgeler sadece topluluğunuz büyüdükçe daha önemli hale gelir. Projenize başka şekilde aşina olamayacak geçici katılımcılar, ihtiyaç duydukları bağlamı hızlı bir şekilde almak için belgelerinizi okuyabilirler. + +CONTRIBUTING dosyanızda, yeni katılımcılara nasıl başlayacaklarını açıkça söyleyin. Bu amaç için özel bir bölüm oluşturmak bile isteyebilirsiniz. Örneğin [Django](https://github.com/django/django), yeni katılımcıları karşılamak için özel bir açılış sayfasına sahiptir. + +![Django new contributors page](/assets/images/building-community/django_new_contributors.png) + +Sorun listenizde, katkıda bulunanlar için farklı türlerlerde etiket kullanmak uygundur: örneğin, [_"ilk gelenler için"_](https://kentcdodds.com/blog/first-timers-only) , _"başlamak için"_ veya _"belge"._ [Bu etiketler](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14), projenizde yeni birisinin sorunlarınızı hızla taramasını ve başlamasını kolaylaştırır. + +Son olarak, insanların yolun her aşamasında kendilerini rahat hissetmelerini sağlamak için belgelerinizi kullanın. + +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/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 + + + +İnsanlar sahiplik hissi duyduklarında projelere katkıda bulunmaktan heyecan duyarlar. Bu, projenizin vizyonunu devretmeniz veya istemediğiniz katkıları kabul etmeniz gerektiği anlamına gelmez. Ancak başkalarına ne kadar çok kredi verirseniz, o kadar çok sadık kalırlar. + +Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bulabilecek misiniz bir bakın. İşte bazı fikirler: + +* **Kolay (kritik olmayan) hataları kendiniz düzeltmeye karşı direnç gösterin.** Bunun yerine, bunları yeni katkıda bulunanlar bulmak için fırsatlar olarak kullanın veya katkıda bulunmak isteyen birini akıl hocası olarak kullanın. İlk başta doğal görünmeyebilir, ancak yatırımınız zamanla karşılığını verir. Örneğin, @michaeljoseph, bir katılımcıdan, sorunu kendisini düzeltmek yerine, [Cookiecutter](https://github.com/audreyr/cookiecutter) konusuna ilişkin bir PR isteği göndermesini istedi. + +![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/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. + +* **Her katkıda bulunana commit izni verin.** @felixge, bunun insanları [yamalarını geliştirme konusunda daha heyecanlı](https://felixge.de/2013/03/11/the-pull-request-hack.html) hale getirdiğini buldu ve bir süredir üzerinde çalışamadığı projeler için yeni geliştiriciler buldu. + +* 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/) 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. + + + +## Çatışmaları çözme + +Projenizin ilk aşamalarında, büyük kararlar vermek kolaydır. Bir şey yapmak istediğinizde, sadece yaparsınız. + +Projeniz popülerleştikçe, aldığınız kararlara daha fazla insan ilgi gösterecek. Katkıda bulunanların çok olduğu bir topluluğunuz olmasa bile, projenizde çok fazla kullanıcı varsa, kararlarınızı tartan ya da kendi sorunlarını dile getiren kişileri bulacaksınız. + +Çoğunlukla, arkadaş canlısı, saygılı bir topluluk oluşturduysanız ve süreçlerinizi açıkça belgelemişseniz, topluluğunuzun sorunlara çözüm bulabilmesi gerekir. Ancak bazen ele alınması biraz zor olan bir sorunla karşılaşırsınız. + +### Nezaket seviyesini ayarlayın + +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%C3%B6t%C3%BC-karakterlere-m%C3%BCsamaha-g%C3%B6stermeyin) geçin. + + + +Diğer insanlar rehberlik için size bakar. İyi bir örnek olun. Gerektiğinde hayal kırıklığını, mutsuzluğu veya endişeyi ifade edebilirsiniz, ancak bunu sakince yapın. + +Sakinleşmek kolay değildir, ancak liderlik göstermek topluluğunuzun sağlığını iyileştirir. İnternet size bu konuda minnettar olur. + +### README'nizi anayasa olarak kabul edin + +README'niz [bir talimat dizisinden daha fazlasıdır](../starting-a-project/#readme-yazma). Aynı zamanda amaçlarınız, ürün vizyonunuz ve yol haritanız hakkında konuşabileceğiniz bir yerdir. İnsanlar, belirli bir özelliğin haklarını tartışmaya aşırı odaklanıyorsa, README'nizi tekrar ziyaret etmek ve projenizin vizyonundan bahsetmek yardımcı olabilir. README'nize odaklanmak da konuşmayı kişiselleştirmekten uzaklaştırır, böylece yapıcı bir tartışma yapabilirsiniz. + +### Hedefe değil, yolculuğa odaklanın + +Bazı projeler büyük kararlar almak için bir oylama süreci kullanır. İlk bakışta mantıklı olsa da, oylama, birbirlerinin kaygılarını dinlemek ve ele almaktan ziyade, bir "cevaba" ulaşmayı vurgular. + +Oylama, topluluk üyelerinin birbirlerine iyilik yapmak veya belirli bir şekilde oy kullanmak için baskı yaptığını hissettiklerinde politik hale gelebilir. Toplumunuzdaki [sessiz çoğunluk](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users), ya da oylamadan haberdar olmayan mevcut kullanıcılar oy kullanmayabilir. + +Bazen oy vermek gerekli bir sonlandırıcıdır. Ancak, mümkün olduğu kadar, fikir birliği yerine ["uzlaşma arayışı"nı](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) vurgulayın. + +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. + + + +Aslında bir uzlaşma arama sürecini benimsemeseniz bile, bir proje sorumlusu olarak, insanların dinlediğinizi bilmesi önemlidir. Diğer insanların duyulduklarını hissetmeleri ve endişelerini çözmeyi denediğinizi görmeleri, hassas durumları dağıtmak için size bir yol verir. Ardından, kelimelerinizi eylemlerle devam ettirin. + +Karar almak için bir karara varmayın. Herkesin duyulduğunu hissettiğinden ve bir çözüme gitmeden önce tüm bilgilerin kamuya açıldığından emin olun. + +### Sohbeti eylem odaklı tutun + +Tartışma önemlidir, ancak üretken ve üretken olmayan konuşmalar arasında büyük bir fark vardır. + +Aktif olarak çözüme doğru hareket ettiği sürece tartışmayı teşvik edin. Konuşmanın durgunlaştığı veya konu dışı olduğu, atışmaların kişisel olduğu veya insanların küçük ayrıntılara takıldığı açıksa, bunu kapatma zamanı gelmiş demektir. + +Bu konuşmaların devam etmesine izin vermek yalnızca eldeki sorun için değil, topluluğunuzun sağlığı için de kötüdür. Bu tür konuşmalara izin verildiğini veya hatta teşvik edildiğini gösteren bir mesaj verir ve insanların gelecekteki sorunları dile getirmeleri veya çözmeleri konusunda cesaretlerini kırar. + +Siz veya başkaları tarafından yapılan her noktada kendinize, _"Bu bizi çözüme nasıl daha fazla yaklaştırır?" Diye sorun._ + +Konuşma çözülmeye ulaştıysa, sohbeti yeniden odaklamak için gruba _"Bundan sonra hangi adımları atmalıyız?"_ diye sorun. + +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. + + + +### Savaşlarınızı akıllıca seçin + +Bağlam önemlidir. Tartışmaya kimlerin dahil olduğunu ve toplumun geri kalanını nasıl temsil ettiğini düşünün. + +Topluluktaki herkes bu sorunla ilgili mi, hatta uğraştı mı? Yoksa yalnız bir baş belası mı? Yalnızca aktif sesleri değil, sessiz topluluk üyelerini de göz önünde bulundurmayı unutma. + +Sorun, topluluğunuzun daha geniş ihtiyaçlarını karşılamıyorsa, birkaç kişinin endişelerini onaylamanız gerekebilir. Bu, net bir çözüm olmadan tekrar eden bir sorunsa, konuyla ilgili önceki tartışmalara yönlendirin ve konuyu kapatın. + +### Topluluk için eşitlik bozucu tanımlayın + +İyi bir tutum ve net iletişim ile çoğu zor durum çözülebilir. Bununla birlikte, üretken bir konuşmada bile, nasıl devam edileceğine dair bir fikir ayrılığı olabilir. Bu gibi durumlarda, eşitlik bozucu olarak görev yapabilecek bir kişi veya grubu tanımlayın. + +Projenin ana sorumlusu bir eşitlik bozucu olabilir veya oylamaya dayalı bir karar veren küçük bir grup insan olabilir. İdeal olarak, kullanmak zorunda kalmadan önce bir GOVERNANCE dosyasında bir eşitlik bozucu ve ilişkili işlemi tanımlayın. + +Eşitlik bozucu son bir çare olmalı. Bölücü konular topluluğunuzun büyümesi ve öğrenmesi için bir fırsattır. Bu fırsatları benimseyin ve mümkün olan her yerde bir çözüme geçmek için ortak bir süreç kullanın. + +## Topluluk açık kaynağın ❤️ + +Sağlıklı, gelişen topluluklar her hafta açık kaynağa dökülen binlerce saati besliyor. Katkıda bulunan birçok kişi, diğer insanlara açık kaynak üzerinde çalışmanın veya çalışmamanın nedeni olarak ilham veriyor. Bu güce yapıcı olarak nasıl dokunulacağını öğrenerek, dışarıdaki birisinin unutulmaz bir açık kaynak deneyimine sahip olmasına yardımcı olacaksınız. diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md new file mode 100644 index 00000000000..a543e8a20a9 --- /dev/null +++ b/_articles/tr/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: tr +title: Davranış Kurallarınız +description: Bir davranış kuralını benimseyerek ve uygulayarak sağlıklı ve yapıcı topluluk davranışını kolaylaştırın. +class: coc +order: 8 +image: "/assets/images/cards/coc.png" +related: + - building + - leadership +--- + +## Neden bir davranış kural listesine ihtiyacım var? + +Davranış kural listesi, projenizin katılımcıları için davranış beklentilerini belirleyen bir belgedir. Bir davranış kuralını kabul etmek ve uygulamak, topluluğunuz için olumlu bir sosyal atmosfer yaratmanıza yardımcı olabilir. + +Davranış kuralları sadece katılımcılarınızı değil kendinizi de korumanıza yardımcı olur. Bir projeyi sürdürürken, diğer katılımcıların verimsiz tutumlarından dolayı zaman içinde çalışmalarınızda kendinizi yorgun veya mutsuz hissedebilirsiniz. + +Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını oluşturmanıza yardımcı olur. Proaktif olmak, sizin veya başkalarının projenizde yorulma olasılığını azaltır ve bir kişi aynı fikirde olmadığınız bir şey yaptığında harekete geçmenize yardımcı olur. + +## Davranış kural listesini oluşturmak + +Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya çalışın: İdeal olanı, projenizi ilk oluşturduğunuzda bunu yapmanızdır. + +Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar: + +* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_? +* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_? +* Birisi davranış kurallarını ihlal ederse ne olur? +* İhlaller nasıl rapor edilebilir? + +Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir. + +[Django Davranış Kuralları](https://www.djangoproject.com/conduct/) ve [Vatandaş Davranış Kuralları](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) da aynı zamanda iki iyi davranış kural listesi örneğidir. + +CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTING veya README dosyanızdan bağlantılayarak topluluğunuz tarafından görülebilir hale getirin. + +## Davranış kurallarınızı nasıl uygulayacağınıza karar verme + + + +Bir ihlal meydana _gelmeden önce_ davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var: + +* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. + +* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. + +* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. + +İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir. + +Birisinin, bu raporları alan bir kişi hakkındaki ihlali bildirmek isteyebileceğini de unutmayın. Bu durumda, ihlalleri bir başkasına bildirme seçeneği de verin. Örneğin, @ctb ve @mr-c"nin [projeleri üzerinde açıkladıkları gibi](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst) , [khmer](https://github.com/dib-lab/khmer) : + +> Kötü niyetli, taciz edici veya kabul edilemez davranışların **örnekleri** , yalnızca C. Titus Brown ve Michael R. Crusoe'ye gönderilen **khmer-project@idyll.org adresine** e-posta {strong2}gönderilerek{/strong2} bildirilebilir. İkisini de içeren bir sorunu bildirmek için lütfen {strong3}Judi Brown Clarke, Ph.D.{/strong3} NSAC Bilim ve Teknoloji Merkezi olan, Eylemdeki Evrim Çalışması Merkezi'ndeki BEACON Çeşitlilik Direktörü. * + +İlham almak için Django'nun [uygulama kılavuzunu inceleyin](https://www.djangoproject.com/conduct/enforcement-manual/) (ancak projenizin büyüklüğüne bağlı olarak bu kadar kapsamlı bir şeye ihtiyacınız olmayabilir). + +## Davranış kurallarınızı güçlendirmek + +Bazen, en iyi çabalarınıza rağmen, birileri bu kodu ihlal eden bir şey yapabilir. Olay ortaya çıktığında olumsuz ya da zararlı davranışları ele almanın birkaç yolu vardır. + +### Durum hakkında bilgi toplayın + +Her topluluğun üyesinin sesine, sizinki kadar önemli verin. Birinin davranış kurallarını ihlal ettiğini bildiren bir rapor alırsanız, ciddiye alın ve bu kişi olan kendi deneyiminize uymasa bile konuyu araştırın. Bunu yapmak, topluluğunuza kendi perspektifine değer verdiğinizi ve kararlarına güvendiğinizi gösterir. + +Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesine neden olan, ya da bir kez bir şey söyleyen veya yapan bir suçlu olabilir. Her ikisi de bağlama bağlı olarak eyleme geçmenin gerekçesi olabilir. + +Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın. + + + +### Uygun işlemi yapın + +Yeterli bilgiyi topladıktan ve işledikten sonra ne yapacağınıza karar vermeniz gerekir. Sonraki adımlarınızı düşündüğünüz gibi, moderatör olarak hedefinizin güvenli, saygılı ve işbirliğine dayalı bir ortam oluşturmak olduğunu unutmayın. Yalnızca söz konusu durumla nasıl başa çıkacağınızı değil, yanıtınızın topluluğunuzun davranışlarını ve ilerleyişindeki beklentilerini nasıl etkileyeceğini de düşünün. + +Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi gereken sizsiniz, bildiren kişi değil. Bazen, ihbar eden kişi kariyer, itibar veya fiziksel güvenlik açısından büyük risk altındaki bilgileri ifşa ediyordur. Onları tacizcileriyle yüzleşmeye zorlamak, ihbar eden kişiyi uzlaşma konumuna getirebilir. İhbar eden açıkça aksini talep etmediği sürece, söz konusu kişiyle doğrudan iletişime geçmelisiniz. + +Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır: + +* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. + +* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. + +Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin: + +* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** + +* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** + +Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız. + +## Proje sahibi olarak sorumluluklarınız + +Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kurallarının uygulayıcısı sizsiniz ve davranış kurallarının belirlediği kuralları takip etmek de sizin sorumluluğunuzda. + +Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler. + +_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. + +Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler. + +## Dünyada görmek istediğiniz davranışı teşvik edin 🌎 + +Bir proje düşmanca veya isteksiz göründüğü zaman, davranışları başkaları tarafından hoş görülebilecek tek bir kişi olsa bile, bazılarıyla hiç karşılaşmadığınız birçok katılımcıyı kaybetme riskiyle karşı karşıya kalırsınız. Bir davranış kural listesini kabul etmek veya uygulamak her zaman kolay değildir, ancak sıcak bir ortamı teşvik etmek topluluğunuzun büyümesine yardımcı olacaktır. diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md new file mode 100644 index 00000000000..e57ec3d59ce --- /dev/null +++ b/_articles/tr/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: tr +title: Projeniz için Kullanıcı Bulma +description: Açık kaynaklı projenizin, mutlu kullanıcıların eline geçerek büyümesini sağlayın. +class: finding +order: 3 +image: "/assets/images/cards/finding.png" +related: + - beginners + - building +--- + +## Duyurmak + +Başlar başlamaz açık kaynak projenizi tanıtmanız gerektiğini söyleyen bir kural yok. Açık kaynak kodlu çalışmanın popülerlikle ilgisi olmayan birçok yönü vardır. Başkalarının açık kaynak projenizi bulup kullanmasını ümit etmek yerine, yaptığınız sıkı çalışmayı duyurmanız gerekir! + +## Mesajını ilet + +Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığını ve neden önemli olduğunu açıklayabilmelisiniz. + +Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır. + +İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. + +Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) egzersizini kullanıcı kimliği geliştirmek için kontrol edin. + +## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun + + + +İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun. + +**Çalışmanızı tanıtma işini açık bir şekilde ele alın.** Bir Twitter hesabı, GitHub URL'si veya IRC kanalı, insanları projenize yönlendirmenin kolay bir yoludur. Bu iletişim noktaları aynı zamanda projenizin büyüyen topluluğuna toplanacak bir yer sağlar. + +Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun. + + + +**Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin. + +Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_. + +Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) . + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için kolay bir yolu olsun, haydi çıkıp izleyicilerinizle konuşun! + +## Projenizin hedef kitlesinin olduğu yere gidin (çevrimiçi olarak) + +Çevrimiçi sosyal yardım, mesajınızı hızla paylaşmanın ve yaymanın harika bir yoludur. Çevrimiçi kanalları kullanarak, çok geniş bir kitleye ulaşma potansiyeline sahip olursunuz. + +Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun. + + + +Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın: + +* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. +* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. +* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: _"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum_ ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. + +Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın. + +İlk duyurularınız hiç kimsesin dikkatini çekmiyorsa veya kimse cevap vermiyorsa, cesaretini kırmayın! Çoğu proje lansmanı aylar veya yıllar alabilen yinelemeli bir süreçtir. İlk kez bir yanıt alamazsanız, farklı bir taktik deneyin veya başkalarının çalışmalarına ilk olarak değer katmanın yollarını arayın. Projenizi tanıtmak ve başlatmak zaman ve özveri gerektirir. + +## Projenizin hedef kitlesinin olduğu yere gidin (çevrimdışı) + +![Public speaking](/assets/images/finding-users/public_speaking.jpg) + +Çevrimdışı etkinlikler, izleyicilere yeni projeler tanıtmanın popüler bir yoludur. Odaklı bir kitleye ulaşmak ve daha derin insan bağlantıları kurmak için, özellikle geliştiricilere ulaşmakla ilgileniyorsanız, harika bir yoldur. + +[Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın. + + + +Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar. + +Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin. + + + +Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir. + +Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz. + + + +## Bir itibar oluşturun + +Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve katkıda bulunmaya davet etmenin en iyi yolu, onların projelerini paylaşma ve katkıda bulunmakdır. + +Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir. + + + +İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin. + +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 new file mode 100644 index 00000000000..7bad96fde81 --- /dev/null +++ b/_articles/tr/getting-paid.md @@ -0,0 +1,176 @@ +--- +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 +order: 7 +image: /assets/images/cards/getting-paid.png +related: +- best-practices +- leadership +--- + +## Neden bazı insanlar finansal destek ister? + +Açık kaynaklı çalışmaların çoğu gönüllüdür. Örneğin, birileri kullandıkları bir projede bir hatayla karşılaşabilir hızlı bir düzeltme yapabilirler veya boş zamanlarında açık kaynak kodlu bir proje ile uğraşmanın tadını çıkarabilirler. + + + +Bir kişinin açık kaynak çalışmaları için ödeme almak istememesinin birçok nedeni vardır. + +* Boş zamanlarında açık kaynağa katkıda bulunmalarını sağlayan, **sevdikleri bir tam zamanlı işleri olabilir**. +* **Açık kaynaklı projeyi bir hobi olarak düşünmekten hoşlanıyor olabilirler**, işlerinde gösteremedikleri yaratıcılığı gösterebildikleri bir alan olarak da değerlendirebilir ve projeleri üzerinde çalışmak için mali olarak zorunluluk hissetmek istemeyebilirler. +* İtibar veya portföylerini oluşturmak, yeni bir beceri öğrenmek veya bir topluluğa daha yakın hissetmek gibi **açık kaynağa katkıda bulunarak başka faydalar elde** etmek istiyor olabilirler. + + + +Bazıları içinse, özellikle katkıların devamlı olduğu veya önemli bir zaman gerektirdiğinde, açık kaynağa katkıda bulunmak için ödeme almak, projenin gerektirdiği veya kişisel nedenlerden dolayı kabul edebilecekleri tek yoldur. + +Popüler projeleri sürdürmek, ayda birkaç saat yerine haftada 10 veya 20 saat süren önemli bir sorumluluk gerektirebilir. + + + +Ücretli işler aynı zamanda farklı yaşam alanlarından insanların anlamlı katkılar yapmalarını sağlar. Bazı insanlar şu anki mali durumları, borçları veya aileleri veya diğer sorumluluklarından açık kaynaklı projeler için ücretsiz zaman harcayamazlar. Bu, zamanını gönüllü olarak kullanamayan yetenekli insanların katkılarını asla dünyanın ile paylaşamamaları anlamına gelir. Bu, @ashedryden'in [açıkladığı](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) gibi etik tartışmalara yola açar, çünkü yapılan çalışmalar, yaşamda zaten avantajları olanlara, gönüllü katkılarına dayanarak ek avantajlar sağlarken, gönüllü olarak katkısı olamayanlar için dezavantajlar oluşturur. Bu açık kaynak toplumdaki mevcut çeşitlilik eksikliğini pekiştiren bir durumdur. + + + +Finansal destek arıyorsanız, dikkate alınması gereken iki yol vardır. Kendi zamanınızı katkıda bulunan kişi olarak fonlayabilir veya proje için organizasyonel fon bulabilirsiniz. + +## Kendi zamanınızı fonlamak + +Bugün, birçok insana yarı zamanlı veya tam zamanlı olarak açık kaynak üzerinde çalışmak için ödeme yapılır. Vaktiniz için ödeme almanın en yaygın yolu işvereninizle konuşmaktır. + +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. + +Örneğin @hueniverse, [Walmart'ın açık kaynak yatırımını](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html) haklılaştırmak için finansal sebeplerin olduğunu belirtti. Ve @jamesgpearce, Facebook'un açık kaynak programının işe alımda [bir fark](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) yarattığını keşfetti: + +> Programlama kültürümüz ve kuruluşumuzun nasıl algılandığı ile yakından ilişkilidir. Çalışanlarımıza “Facebook'taki açık kaynaklı yazılım programının farkında mıydınız?” diye sorduk. Üçte ikisi "Evet" dedi. Yarısı, programın bizim için çalışma kararlarına olumlu katkıda bulunduğunu söyledi. Bunlar marjinal sayılar değildir ve umarım devam eden bir eğilimdir. + +Şirketiniz bu rotadan geçerse, topluluk ve kurumsal faaliyet arasındaki sınırları net tutmak önemlidir. Sonuçta, açık kaynak, tüm dünyadaki insanlardan sağlanan katkılarla kendisini sürdürüyor ve bu, herhangi bir şirket veya konumdan daha büyüktür. + + + +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/) 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/) +* @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 + +Bireysel katılımcılar için yapılan düzenlemelerin ötesinde, bazen projeler devam eden çalışmaları finanse etmek için şirketler, bireyler veya başkalarından para toplarlar. + +Örgütsel finansman, projenin yürütülmesi (barındırma ücreti gibi) maliyetlerini kapsayan veya yeni özelliklere veya fikirlere yatırım yapma gibi mevcut katkı paylarını ödemeye yönelebilir. + +Açık kaynağın popülaritesi arttıkça, projelere fon bulmak için hala deneysel olmakla birlikte, birkaç seçenek vardır. + +### 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: + +* **[webpack](https://github.com/webpack)** [OpenCollective](https://opencollective.com/webpack) üzerinden şirketler ve bireylerden para topladı +* **[Ruby Together](https://rubytogether.org/) ,** [paketleyici](https://github.com/bundler/bundler) , [RubyGems](https://github.com/rubygems/rubygems) ve diğer Ruby altyapı projelerinde işe yarayan kar amacı gütmeyen bir organizasyon + +### Bir gelir akışı oluşturun + +Projenize bağlı olarak, ticari destek, barındırılan seçenekler veya ek özellikler için ücret alabilirsiniz. Birkaç örnek şunları içerir: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** , ek destek için ücretli sürümler sunar +* **[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/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 + +Bazı yazılım kurumları ve şirketleri açık kaynak kodlu çalışmalar için hibe sunar. Bazen, hibeler proje için tüzel kişilik oluşturmadan bireylere ödenebilir. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** projesi [Mozilla Açık Kaynak Desteği'nden](https://www.mozilla.org/en-US/grants/) hibe aldı +* **[OpenMRS](https://github.com/openmrs)** çalışması [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) ile finanse edildi +* **[Libraries.io](https://github.com/librariesio)** projesi [Sloan Vakfı'ndan](https://sloan.org/programs/digital-technology) burs aldı. +* **[Python Yazılım Vakfı](https://www.python.org/psf/grants/)** Python ile ilgili işler için bağışlar sunuyor + +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 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. + +Kendi zamanınız için ödeme almak veya bir projeye fon sağlamak için aşağıdaki soruları cevaplayabilmeniz gerekir. + +### Etki + +Bu proje neden faydalıdır? Kullanıcılarınız veya potansiyel kullanıcılar neden bu kadar hoşlanıyor? Beş yıl sonra nerede olacak? + +### Çekiş + +Projenizin metrikleri, tecrübeleri veya referansları olsun ve önemli olduğuna dair kanıt toplamaya çalışın. Şu anda projenizi kullanan şirketler veya kayda değer insanlar var mı? Olmazsa, tanınmış bir kişi bunu onayladı mı? + +### Fon verene katkı + +İşvereninize veya bir hibe veren vakıf olup olmadığına bakılmaksızın fon sağlayıcılara sıklıkla fırsatlar ile yaklaşılmalıdır. Projenizi neden başka bir fırsat üzerinde desteklemeliler? Kişisel olarak nasıl yararlanabilirler? + +### Fon kullanımı + +Önerilen fonla tam olarak ne yapacaksınız? Maaş ödemek yerine proje kilometre taşlarına veya sonuçlarına odaklanın. + +### Fonları nasıl alacaksınız? + +Fon verenin ödeme çevresinde herhangi bir şartı var mı? Örneğin, kar amacı gütmeyen veya kar amacı gütmeyen bir mali sponsora sahip olmanız gerekebilir. Veya belki de fonlar bir organizasyon yerine bireysel bir yükleniciye verilmelidir. Bu gereklilikler fon sağlayıcılar arasında farklılık gösterir, bu yüzden araştırmanızı önceden yaptığınızdan emin olun. + + + +## 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 new file mode 100644 index 00000000000..f7f8f258c3b --- /dev/null +++ b/_articles/tr/how-to-contribute.md @@ -0,0 +1,520 @@ +--- +lang: tr +title: Açık Kaynağa Nasıl Katkıda Bulunulur +description: Açık kaynağa katkıda bulunmak ister misiniz? İlk defa yapacaklar ve tecrübeliler için katkı yapma rehberi. +class: contribute +order: 1 +image: "/assets/images/cards/contribute.png" +related: + - beginners + - building +--- + +## 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 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 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 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 + +Sıcak, misafirperver topluluklarla açık kaynak projeler insanları yıllarca müdavimleri yaparlar. Pek çok insan, konferanslarda ya da açık kaynak projelerine katılarak, farklı konularla ilgili çevrimiçi gece sohbetlerine gireyecekleri ömür boyu sürecek arkadaşlıklar kurarlar. + +### Mentor bulma ve başkalarına öğretme + +Paylaşımlı bir projede başkalarıyla çalışmak demek, işlerinizi nasıl yaptığınızı açıklamanın yanı sıra diğer insanlardan yardım istemek demektir. Öğrenme ve öğretme eylemleri, katılan herkes için tatmin edici bir aktivite olabilir. + +### İtibarınızı (ve kariyerinizi) geliştirmenize yardımcı olacak eserler oluşturma + +Tanım olarak, açık kaynak kodlu çalışmaların tamamı kamuya açıktır; yapabileceklerinizin bir göstergesi olarak herhangi bir yerde göstermek için ücretsiz örneklere sahip olursunuz. + +### İnsani beceriler kazanma + +Açık kaynak, çatışmaları çözmek, ekipleri organize etmek ve işlerin önceliklerini yönetmek gibi liderlik ve yönetim becerilerini uygulama fırsatları sunar. + +### Küçük bile olsa değişiklik yapabilme gücü verir + +Açık kaynak geliştirmekten zevk alabilmek için ömür boyu katkıda bulunmanız gerekmez. Hiç bir web sitesinde bir yazım hatası gördünüz ve birisinin düzeltmesini dilediniz mi? Açık kaynak bir projede, bunu siz yapabilirsiniz. Açık kaynak, insanların yaşamları ve dünyayı nasıl tecrübe ettikleri konusunda kendilerini etkin hissetmelerine yardımcı olur ve bu kendi içinde memnuniyet vericidir. + +## Katkıda bulunmak ne demektir? + +Açık kaynaklı bir projeye ilk defa katkıda bulunuyorsanız, bu süreç korkutucu olabilir. Doğru proje nasıl bulunur? Ya nasıl kodlanacağını bilmiyorsan? Ya bir şeyler ters giderse? + +Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yolları vardır ve birkaç ipucu deneyiminizden en iyi şekilde yararlanmanıza yardımcı olacaktır. + +### Kod yazarak katkıda bulunmak zorunda değilsin + +Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye _büyük bir_ iyilik yapacaksınız! + + + +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 +* Projenin konferansını düzenleyin (eğer varsa) +* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun + +### Tasarlamayı sever misiniz? + +* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın +* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın +* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın +* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın + +### Yazmayı sever misin? + +* Proje dokümantasyonunu yazın ve geliştirin +* Projenin nasıl kullanıldığını gösteren örnekler oluşturun +* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın +* [PyPA'nın katılımcılarının yaptığı gibi](https://packaging.python.org/) proje için dersler yazın +* Projenin dokümantasyonu için çeviri yapın + + + +### Organize etmeyi sever misiniz? + +* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin +* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) +* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. + +### Kod yazmayı sever misiniz? + +* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun +* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun +* Proje kurulumunu otomatikleştirin +* Araçları ve testleri geliştirin + +### İnsanlara yardım etmeyi sever misiniz? + +* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te +* İnsanlar için açık konulardaki soruları cevaplayın +* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun + +### Başkalarına kod yazarken yardım etmeyi sever misiniz? + +* Diğer kişilerin gönderimlerindeki kodu inceleyin +* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın +* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz! + +"Açık kaynak" genellikle yazılımla ilişkilendirilse de, her şey için işbirliği yapabilirsiniz. Açık kaynak projeleri olarak geliştirilen kitaplar, tarifler, listeler ve sınıflar var. + +Örneğin: + +* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) +* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor +* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) + +Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır. + +## Kendinizi yeni bir projeye yönlendirmek + + + +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 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 + +Her açık kaynak topluluğu kendine özgüdür. + +Bir açık kaynak projeye yıllarınızı harcamak, projeyi tanıdığınız anlamına gelir. Farklı bir projeye geçin; kelime, norm ve iletişim biçimlerinin tamamen farklı olduğunu göreceksiniz. + +Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapılarını takip ettiği söylenebilir. Farklı topluluk rollerini ve genel süreci anlamak, yeni projeye hızlı bir şekilde odaklanmanıza yardımcı olacaktır. + +Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir: + +* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) +* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) +* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) +* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes +* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. + +Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın. + +Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir. + +* **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, 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 (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. + +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. + +Bunun yerine, zaten kullandığınız veya kullanmak istediğiniz projeleri düşünerek başlayın. Aktif olarak katkıda bulunacağınız projeler, kendinizi devamlı kullanırken bulduğunuz projelerdir. + +Bu projeler içinde, bir şeyin daha iyi veya farklı olabileceğini düşündüğünüzü farkettiğinizde, içgüdülerinize göre hareket edin. + +Açık kaynak bir seçilmişler kulübü değildir; tıpkı senin gibi insanlar tarafından yapılmıştır. "Açık kaynak", dünyadaki sorunların çözülebilir olarak algılanması için sadece süslü bir terimdir. + +Bir README tarayabilir ve bozuk bir link ya da yazım hatası bulabilirsiniz. Ya da yeni bir kullanıcısınız ve bir şeylerin bozuk olduğunu ya da belgelerde gerçekten olması gerektiğini düşündüğünüz bir eksikliğin olduğunu fark ettiniz. Bunu görmezden gelip devam etmek ya da başka birinden düzeltmesini istemek yerine, araya girip düzeltebileceğinizi görün. Bakın açık kaynak budur! + +> [Gündelik katkıların %28'i](https://www.igor.pro.br/publica/papers/saner2016.pdf) açık kaynağa yeniden biçimlendirme veya bir çeviri yazarken böyle bir yazım hatası düzeltme gibi belgelerdir. + +Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin başlayabileceğiniz acemi dostu sorunları vurgulayan bir `/contribute` sayfası vardır. GitHub'taki deponun ana sayfasına gidin ve URL'nin sonuna `/contrib` ekleyin (Örneğin [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz: + +* [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/) + +### 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. + +İşte bir projenin yeni katılımcılar için iyi olup olmadığını değerlendirmek için kullanışlı bir kontrol listesi. + +**Açık kaynak tanımını karşılar** + +
+ + +
+ +**Proje aktif olarak katkı kabul ediyor** + +Ana daldaki geliştirici faaliyetine bakın. GitHub'da, bu bilgiyi bir kütüphanenin ana sayfasında görebilirsiniz. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Ardından, projenin sorun listesine bakın. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Şimdi aynısını projenin PR listesi için yapın. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Proje katkı bekliyor mu?** + +Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olacağını belirtir. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## 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. + +### Etkili iletişim kurmak + +İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir. + + + +Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun. + +**Bağlam ver.** Başkalarının sizi anlamada hızlanmalarına yardımcı olun. Bir hatayla karşılaşıyorsanız, ne yapmaya çalıştığınızı ve nasıl tekrarlanabileceğini açıklayın. Yeni bir fikir önerecekseniz, neden projeye faydalı olacağını düşündüğünüzü açıklayın (sadece sizin için değil!). + +> 😇 _"Y yaptığımda X olmuyor"_ +> +> 😢 _"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'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?" + +**İ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. + +> 😇 _"Bir API öğretici belgesi yazmak istiyorum."_ +> +> 😢 _"Geçen gün otoyoldan aşağı iniyordum ve benzin için durdum ve sonra aklıma yapmamız gereken bir şey için inanılmaz bir fikir geldi, ama bunu açıklamadan önce sana göstereyim ..."_ + +**Tüm iletişimi herkese açık tutun.** Her ne kadar cazip olsa da, hassas bilgileri (güvenlik sorunu veya ciddi davranış ihlali gibi) paylaşmanız gerekmedikçe, geliştiricilere özel olarak ulaşmayın. Sohbeti herkese açık tuttuğunuzda, daha fazla kişi alış verişinizden öğrenebilir ve bundan faydalanabilir. Tartışmalar da kendi başlarına katkı sayılabilir. + +> 😇 _(yorum olarak) "@-maintainer Merhabalar! Bu PR'a nasıl devam edelim?"_ +> +> 😢 _(bir e-posta olarak) "Hey, e-posta yüzünden sizi rahatsız ettiğim için özür dilerim, ancak PR'mi gözden geçirme şansınız olup olmadığını merak ediyordum"_ + +**Soru sormak sorun değil (ama sabırlı olun!).** Herkes bir zamanlar projede yeniydi ve deneyimli katılımcıların bile yeni bir projeye bakarken hız kazanmaları gerekiyor. Aynı şekilde, uzun süredir devam edenler bile, projenin her bölümüne aşina değildir. Onlara size göstermelerini istediğiniz sabrı gösterin. + +> 😇 _"Bu hatayı incelediğiniz için teşekkür ederiz. Önerilerinizi takip ettim. İşte sonuç."_ +> +> 😢 _"Neden sorunumu çözemiyorsun? Bu senin projen değil mi?"_ + +**Topluluk kararlarına saygı gösterin.** Fikirleriniz, toplumun öncelikleri veya vizyonundan farklı olabilir. Geri bildirim sunabilir veya fikrinizi sürdürmemeye karar verebilirler. Tartışmanız ve uzlaşı aramanız gerekirken, geliştiriciler kararınızla sizden daha uzun yaşamak zorundadır. Düşüncelerine katılmıyorsanız, her zaman kendi çatalınızla çalışabilir veya kendi projenizi başlatabilirsiniz. + +> 😇 _"Fikrimi destekleyemediğiniz için hayal kırıklığına uğradım, ancak bunun sadece kullanıcıların küçük bir bölümünü etkilediğini açıkladığınızdan, nedenini anlıyorum. Dinlediğiniz için teşekkürler."_ +> +> 😢 _"Neden fikrimi desteklemiyorsun? Bu kabul edilemez!"_ + +**Her şeyden önce, zarif olun.** Açık kaynak dünyanın her yerinden ortak çalışanlardan oluşur. Bağlam diller, kültürler, coğrafyalar ve zaman dilimleri arasında kaybolur. Ek olarak, yazılı iletişim bir ton veya ruh halini iletmeyi zorlaştırır. Bu konuşmaların niyetlerinin iyi olduğunu düşünün. Bir fikre kibarca geri dönmek, daha fazla içerik istemek veya konumunuzu daha da netleştirmek iyi bir şey. İnterneti bulduğunuzdan daha iyi bir yer bırakmaya çalışın. + +### Bağlamı toparlama + +Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığından emin olmak için hızlıca kontrol edin. Projenin README"sini, sorun (açık ve kapalı) listesini, e-posta listesini ve StackOverflow"u gözden geçirin. Her şeyi yapmak için zaman harcamak zorunda değilsiniz, ancak birkaç anahtar terim için hızlı arama yapmak çok fayda sağlar. + +Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız: + +* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir +* **PR** bir çözüm üzerinde çalışmaya başlamak içindir +* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. + +Bir sorun açmadan veya talepte bulunmadan önce, belirli bir şey eklemeniz gerekip gerekmediğini görmek için projenin katkıda bulunma belgelerini (genellikle CONTRIBUTING veya README dosyaları) kontrol edin. Örneğin, bir şablon izlemenizi istenebilir veya test ortamı kullanmanız gerekebilir. + +Önemli bir katkı yapmak istiyorsanız, üzerinde çalışmadan önce sormanız gereken bir sorun açın. Projeyi bir süre izlemeniz yararlı olacaktır (GitHub'da, tüm konuşmalar size bildirilmek için ["İzle"yi tıklayabilirsiniz](https://help.github.com/articles/watching-repositories/)) ve kabul edilmeyebilecek bir işe başlamadan önce topluluk üyelerini tanıyın. + + + +### Bir istek/sorun açmak + +Genellikle aşağıdaki durumlarda bir sorun açmalısınız: + +* Çözemediğiniz bir hatayı bildirmek için +* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) +* Yeni bir özellik veya başka bir proje fikri önermek için + +Sorunlar üzerinde iletişim kurmak için ipuçları: + +* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. +* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. +* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. + +### PR açma + +Genellikle aşağıdaki durumlarda bir PR açmalısınız: + +* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) +* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda + +Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz. + +Proje GitHub'taysa, PR nasıl gönderilir: + +* **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) +* Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . +* **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") +* Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. +* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. +* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. + +Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz. + +## Yaptığınız katkıyı gönderdikten sonra ne olur? + +Başardınız! Açık kaynak dünyasına katkıda bulunduğunuz için tebrikler. Umarız yapacağınız katkıların ilkidir. + +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%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 (@). + +Özel olarak o kişiye ulaşmaya **çalışmayın;** Açık iletişiminin açık kaynaklı projeler için hayati önem taşıdığını unutmayın. + +Kibar hatırlatmanıza rağmen hala kimse cevap vermiyorsa, hiç kimsenin cevap vermemesi mümkündür. Harika bir duygu değil, ama bunun sizin cesaretinizi kırmasına izin vermeyin. Herkesin başına gelmiştir! Kontrolünüz dışında olabilecek kişisel durumlar da dahil olmak üzere, yanıt alamamanızın birçok olası nedeni olabilir. Başka bir proje ya da katkıda bulunmanın başka bir yolunu bulmaya çalışın. Eğer bir şey bulamıyorsanız, bu topluluk üyeleri size dönmeden ve cevap vermeden önce katkı yapmak için çok fazla zaman harcamamak için iyi bir nedendir. + +### 🚧 Biri katkınızda değişiklik talep eder. + +Katkınızda değişiklik yapmanızın istenmesi, fikrinizin kapsamı hakkında geribildirimde bulunulması veya kodunuzda değişiklik yapmanız istenmesi yaygındır. + +Birisi değişiklik istediğinde, duyarlı olun. Katkınızı gözden geçirmek için zaman harcadılar. Bir PR açmak ve uzaklaşmak kötü bir durumdur. Nasıl değişiklik yapılacağını bilmiyorsanız, sorunu araştırın, daha sonra ihtiyacınız olursa yardım isteyin. + +Artık sorun üzerinde çalışmak için zamanınız yoksa (örneğin, tartışma aylardır devam ediyorsa ve koşullarınız değiştiyse), ilgili kişilere yanıt beklememelerini bildirin. Başkası devralmaktan mutlu olabilir. + +### 👎 Katkınız kabul edilmez. + +Katkınız sonunda kabul edilebilir veya kabul edilmeyebilir. Umarım zaten çok fazla iş yapmamışsındır. Neden kabul edilmediğinden emin değilseniz, bakıcıdan geri bildirim ve açıklama istemek tamamen mantıklıdır. Ancak, sonuçta, bunun kendi kararları olduğundan saygı duymanız gerekir. Tartışma içine girmeyin ya da düşmanca davranmayın. Anlaşmazsanız her zaman kendi versiyonunuzla çalışmaya hazırsınız! + +### 🎉 Katkınız kabul edilir. + +Yaşasın! Açık kaynak dünyasına bir katkı yaptınız! + +## Başardınız! + +İster açık kaynak dünyasına ilk katkıyı yapmış, ister katkıda bulunmak için yeni yollar arıyor olun, harekete geçmek için ilham aldığınızı umarız. Katkınız kabul edilmese bile, bir geliştirici size yardım etmek için çaba gösterdiğinde teşekkür etmeyi unutmayın. Açık kaynak, sizin gibi insanlar tarafından üretilir: bir sorun, bir PR, yorum ya da beşlik. diff --git a/_articles/tr/index.html b/_articles/tr/index.html new file mode 100644 index 00000000000..12cf403b695 --- /dev/null +++ b/_articles/tr/index.html @@ -0,0 +1,6 @@ +--- +layout: index +lang: tr +title: Açık Kaynak Rehberleri +permalink: /tr/ +--- diff --git a/_articles/tr/leadership-and-governance.md b/_articles/tr/leadership-and-governance.md new file mode 100644 index 00000000000..c7ff8e2ee48 --- /dev/null +++ b/_articles/tr/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: tr +title: Liderlik ve Yönetim +description: Büyüyen açık kaynak projeleri, karar almak için resmi kurallardan yararlanabilir. +class: leadership +order: 6 +image: "/assets/images/cards/leadership.png" +related: + - best-practices + - metrics +--- + +## Büyüyen projeniz için yönetimi anlama + +Projeniz büyüyor, insanlar dahil olmaya başladı ve siz bu şeyi sürdürmeye kararlısınız. Bu aşamada, düzenli proje katılımcılarını iş akışınıza nasıl dahil edeceğinizi, örneğin birine giriş izni verilmesini veya topluluk tartışmalarını nasıl çözüleceğini merak ediyor olabilirsiniz. Sorularınız varsa, cevaplarımız da var. + +## Açık kaynak projelerde kullanılan resmi rol türleri nelerdir? + +Birçok proje katılımcı rolleri ve tanınması için ortak benzer bir yapı izler. + +Bu rollerin aslında ne anlama geldiği tamamen size kalmış bir şey. İşte size de tanıdık gelebilecek rollerin birkaçı: + +* **Sorumlu (maintainer)** +* **Katkıda bulunan (contributor)** +* **Ekip üyesi** + +**Bazı projeler için, "sorumlular"** projeye giriş hakkı olan projedeki tek kişilerdir. Diğer projelerde, onlar sadece README'de listelenen insanlardır. + +Bir sorumlunun projeniz için kod yazan biri olması gerekmez. Projenizi değiştirmek için çok fazla iş yapan veya projeyi başkalarına daha erişilebilir kılan yazılı belgeler olabilir. Günlük olarak ne yaptıklarından bağımsız olarak, bir sorumlu muhtemelen proje yönünden sorumluluk duyan ve geliştirmeye kendini adamış bir kişidir. + +**"Katkıda bulunan"**, bir sorun veya PR hakkında yorum yapan, projeye değer katan insanlar (sorunları birleştiren, kod yazan veya etkinlik düzenleyen) veya birleştirilmiş PR'si olan herkes (belki de en dar tanımı katkıda bulunan) olabilir. + + + +**"committer" terimi** , belirli bir sorumluluk türü olan commit erişimini diğer katkı şekillerinden ayırmak için kullanılabilir. + +Proje rollerinizi dilediğiniz şekilde tanımlayabilmenize rağmen, daha fazla katkı biçimi geliştirmek için [daha geniş tanımları kullanmayı düşünün](../how-to-contribute/#katkıda-bulunmak-ne-demektir). Teknik becerilerinden bağımsız olarak, projenize olağanüstü katkı sağlayan kişileri resmen tanımak için liderlik rollerini kullanabilirsiniz. + + + +## Bu liderlik rollerini nasıl resmileştiririm? + +Liderlik rollerini resmileştirmek, insanların sahipliğini hissetmesine yardımcı olur ve diğer topluluk üyelerine kimden yardım isteyenleri söyler. + +Daha küçük bir proje için, lider seçmek isimlerini README veya bir CONTRIBUTORS metin dosyasına eklemek kadar basit olabilir. + +Daha büyük bir proje için, bir web siteniz varsa, bir ekip sayfası oluşturun veya proje liderlerinizi burada listeleyin. Örneğin, [Postgres](https://github.com/postgres/postgres/) , her katılımcı için kısa profillerden oluşan [kapsamlı bir ekip sayfasına](https://www.postgresql.org/community/contributors/) sahiptir. + +Projeniz çok aktif bir katılımcı topluluğa sahipse, farklı konu alanlarına (örneğin, güvenlik, sorun izleme veya topluluk davranışı) sahip olan kişilerden oluşan bir "çekirdek ekip" veya hatta alt grup komiteleri oluşturabilirsiniz. Rolleri sizin atamanız yerine, insanların en çok heyecanlandıkları roller için kendi kendilerini organize ve gönüllü olmalarına fırsat verin. + + + +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. + +[Vossibility](https://github.com/icecrime/vossibility-stack) gibi araçlar, projeye kimin katkı sağladığını (ya da yapmadığını) izlemenize yardımcı olabilir. Bu bilginin belgelenmesi, topluluk sahiplerinin, kararlarını özel olarak veren bir klik olduğuna inanmalarını engeller. + +Son olarak, projeniz GitHub'daysa, projenizi kişisel hesabınızdan bir organizasyon hesabına taşımayı ve en az bir yedek yönetici eklemeyi düşünün. [GitHub Organizasyonları](https://help.github.com/articles/creating-a-new-organization-account/) izinleri ve çoklu depoları yönetmeyi kolaylaştırır ve projenizin mirasını [ortak mülkiyet](../building-community/#projenizi-paylaşın) yoluyla korur. + +## Ne zaman birine commit izni vermeliyim? + +Bazı insanlar katkıda bulunan herkese commit yetkisi vermeniz gerektiğini düşünür. Bunu yapmak, daha fazla kişiyi projenizin sahipliğini hissetmeye teşvik edebilir. + +Öte yandan, özellikle daha büyük, daha karmaşık projeler için, yalnızca kendilerini kanıtlayan kişilere commit hakkı vermek isteyebilirsiniz. Bunu yapmanın doğru bir yolu yok - sizi en rahat ettiren şeyi yapın! + +Projeniz GitHub'daysa, belirli bir dala kimin ve hangi şartlar altında kod gönderebileceğini yönetmek için [korumalı dalları](https://help.github.com/articles/about-protected-branches/) kullanabilirsiniz. + + + +## Açık kaynaklı projeler için ortak yönetim yapılarının bazıları nelerdir? + +Açık kaynak projeleriyle ilgili üç ortak yönetim yapısı vardır. + +* **BDFL:** BDFL (Benevolent Dictator for Life) "Yaşam için Yardımcı Diktatör" anlamına gelir. Bu yapı altında, bir kişinin (genellikle projenin ilk yazarı) tüm büyük proje kararları hakkında kesin sözleri vardır. [Python](https://github.com/python) klasik bir örnektir. Daha küçük projeler muhtemelen varsayılan olarak BDFL'dir, çünkü yalnızca bir veya iki koruyucu vardır. Bir şirketten kaynaklanan bir proje de BDFL kategorisine girebilir. + +* **Meritokrasi:** **(Not: "meritokrasi" terimi, bazı topluluklar için olumsuz çağrışımlar taşır ve özellikle [karmaşık bir sosyal ve politik tarihe sahip](http://geekfeminism.wikia.com/wiki/Meritocracy) ülkelerde.)** Bir meritokrasi kapsamında, aktif proje katılımcılarına ("sahiplik" gösterenler) resmi bir karar verme rolü verilir. Kararlar genellikle saf oy birliği ile yapılır. Meritokrasi kavramı [Apache Vakfı](https://www.apache.org/) tarafından öncülük edildi; [tüm Apache projeleri](https://www.apache.org/index.html#projects-list) meritokrasilerdir. Katkılar, bir şirketi değil, yalnızca kendilerini temsil eden kişiler tarafından yapılabilir. + +* **Liberal katkı:** Liberal katkı modelinde, en çok işi yapan insanlar en etkili olarak kabul edilir, ancak bu mevcut çalışmalara dayanmaktadır ve tarihi katkılara dayanmamaktadır. Büyük proje kararları, saf oylama yerine oybirliği arayışı sürecine (büyük şikayetleri tartışmak) temel almakta ve mümkün olduğunca çok toplum perspektifini dahil etmeye çalışmaktadır. Liberal bir katkı modeli kullanan popüler proje örnekleri arasında [Node.js](https://foundation.nodejs.org/) ve [Rust](https://www.rust-lang.org/) bulunur. + +Hangisini kullanmalısın? Sana kalmış! Her modelin avantajları ve dezavantajları vardır. İlk başta oldukça farklı görünseler de, üç modelin de göründüğünden daha çok ortak noktaları vardır. Bu modellerden birini benimsemekle ilgileniyorsanız, şu şablonları inceleyin: + +* [BDFL model şablonu](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritokrasi modeli şablonu](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js'in liberal katkı politikası](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## Projemi başlattığımda yönetim belgelerine ihtiyacım var mı? + +Projenizin yönetimini şekillendirmek için doğru zaman yok, ancak topluluk dinamiklerini belirlendikten sonra tanımlamak çok daha kolay. Açık kaynak yönetimi ile ilgili en iyi (ve en zor) kısım, toplum tarafından şekillendirilmesidir! + +Bununla birlikte, bazı erken hazırlanmış belgeler kaçınılmaz olarak projenizin yönetimine katkıda bulunacaktır, bu yüzden ne yapabileceğinizi yazmaya başlayın. Örneğin, projenizin başlangıcında bile davranışa ilişkin net beklentileri veya katkıda bulunan sürecin nasıl çalıştığını tanımlayabilirsiniz. + +Açık kaynak kodlu bir projeyi başlatmakta olan bir şirketin bir parçasıysanız, şirketinizin projeyi sürdürmek ve ilerletmek için nasıl bir karar vereceğini önceden içerde tartışmaya açmaya değer. Ayrıca, şirketinizin projeye nasıl dahil olacağına (veya olmayacağına) açık bir şekilde açıklamak isteyebilirsiniz. + + + +## Şirket çalışanları katkı göndermeye başlarsa ne olur? + +Başarılı açık kaynak projeler birçok kişi ve şirket tarafından kullanılmakta ve bazı şirketler nihayetinde projeye bağlı olarak gelir akışlarına neden olabilmektedir. Örneğin, bir şirket, bir ticari hizmet teklifinde projenin kodunu bir bileşen olarak kullanabilir. + +Proje yaygınlaştıkça, konusunda uzmanlığı olan kişilerden daha fazla rağbet görür - onlardan biri siz de olabilirsiniz! - ve bazen projede yaptıkları iş için para da alıyor olabilirler. + +Ticari faaliyeti normal kabul edip ve başka bir gelişim enerjisi kaynağı olarak ele almak önemlidir. Ücretli geliştiriciler elbette ücretsiz olanlardan farklı muamele görmemelidir. Her katkı, teknik esasına göre değerlendirilmelidir. Bununla birlikte, insanlar ticari faaliyetlerde bulunmak için kendilerini rahat hissetmeli ve belirli bir geliştirme veya özellik lehine tartışırken kullanım durumlarını belirtmekte kendilerini rahat hissetmelidirler. + +"Ticari", "açık kaynak" ile tamamen uyumludur. "Ticari" sadece bir yerde para olduğu anlamına gelir - yazılımın bir projenin benimsenmesi arttıkça artan bir şekilde ticarette kullanıldığı anlamına gelir. (Açık kaynak yazılım, açık kaynak olmayan bir ürünün parçası olarak kullanıldığında, genel ürün hala "tescilli" bir yazılımdır, ancak açık kaynak gibi ticari veya ticari olmayan amaçlar için de kullanılabilir.) + +Diğer herkes gibi, ticari olarak motive edilmiş geliştiriciler, katkılarının niteliği ve niceliği ile projede etki kazanabilirler. Açıkçası, zamanı için ödeme yapan bir geliştirici, ödeme almayan birinden daha fazlasını yapabilir, ancak sorun değil: ödeme, birisinin yapabileceklerini etkileyebilecek olası birçok faktörden yalnızca biridir. Proje tartışmalarınızda, insanların bu katkıları yapmalarını sağlayan dış etkenlere değil, katkılara odaklanmaya devam edin. + +## Projemi desteklemek için tüzel kişiliğe ihtiyacım var mı? + +Parayla çalışmadığınız sürece açık kaynak projenizi desteklemek için tüzel kişiliğe ihtiyacınız yoktur. + +Örneğin, ticari bir işletme oluşturmak istiyorsanız, bir C Corp veya LLC kurmak istersiniz (ABD merkezli iseniz). Açık kaynak projenizle ilgili sadece sözleşmeli iş yapıyorsanız, parayı tek mal sahibi olarak kabul edebilir veya bir LLC (ABD merkezli iseniz) kurabilirsiniz. + +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/), [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. + + + +Projeniz belirli bir dil veya ekosistem ile yakından ilişkiliyse, birlikte çalışabileceğiniz ilgili bir yazılım kuruluşu da olabilir. Örneğin, [Python Software Foundation](https://www.python.org/psf/) [PyPI](https://pypi.org/) Python paket yöneticisini desteği ve [node.js Vakfı](https://foundation.nodejs.org/)'nın [Express.js](https://expressjs.com/) Node tabanlı bir çerçeveye desteği gibi. diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md new file mode 100644 index 00000000000..84244d43e88 --- /dev/null +++ b/_articles/tr/legal.md @@ -0,0 +1,158 @@ +--- +lang: tr +title: Açık Kaynağın Hukuki Tarafı +description: Açık kaynağın yasal yönü hakkında merak ettiğiniz her şey ve merak etmediğiniz birkaç şey. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: +- contribute +- leadership +--- + +## Açık kaynağın yasal etkilerini anlama + +Yaratıcı çalışmalarınızı dünyayla paylaşmak heyecan verici ve faydalı bir deneyim olabilir. Ayrıca endişelenmeniz gereken bilmediğiniz bir sürü yasal şey anlamına da gelebilir. Neyse ki, sıfırdan başlamak zorunda değilsiniz. Yasal ihtiyaçlarınızı karşıladık. (Kazma vurmadan önce, [yasal uyarılarımızı](/notices/) okuduğunuzdan emin olun.) + +## İnsanlar neden açık kaynağın yasal tarafını bu kadar önemsiyorlar? + +Sormanıza sevindim! Yaratıcı bir çalışma yaptığınızda (yazı, grafik veya kod gibi), bu varsayılan olarak özel telif hakkı altındadır. Diğer bir deyişle, yasa çalışmanızın yazarı olarak başkalarının onunla neler yapabileceği konusunda bir sözünüz olduğunu varsayar. + +Genel olarak, bu çalışmalarınızı dava riski altında olmadan hiç kimsenin kullanamayacağı, kopyalayamayacağı, dağıtamayacağı veya değiştiremeyeceği anlamına gelir. + +Açık kaynak sıradışı bir durumdur, çünkü yazar diğerlerinin çalışmayı kullanmasını, değiştirmesini ve paylaşmasını bekler. Ancak yasal varsayılan hala özel bir telif hakkı olduğundan, bu izinleri açıkça belirten bir lisansa ihtiyacınız vardır. + +Açık kaynak lisansı uygulamazsanız, projenize katkıda bulunan herkes, çalışmalarının münhasır bir telif hakkı sahibi olur. Bu, hiç kimsenin katkılarını kullanamayacağı, kopyalayamayacağı, dağıtamayacağı veya değiştiremeyeceği anlamına gelir - ve bu "hiç kimse" sizi de içerir. + +Son olarak, projeniz sizin bilmediğiniz lisans gereksinimlerine bağlı olabilir. Projenizin topluluğu veya işvereninizin politikaları, projenizin özel açık kaynak lisansları kullanmasını da gerektirebilir. Aşağıda bu durumları ele alacağız. + +## Açık GitHub projeleri açık kaynak mı? + +GitHub'da [yeni bir proje oluşturduğunuzda](https://help.github.com/articles/creating-a-new-repository/), proje kütüphanesini **gizli** veya **açık** hale getirme seçeneğiniz vardır. + +![Create repository](/assets/images/legal/repo-create-name.png) + +**GitHub projenizi herkese açık hale getirmek, projenizi lisanslamakla aynı değildir.** Genel projeler, başkalarının projenizi görüntülemesine ve düzenlemesine izin veren [GitHub'ın Hizmet Koşulları](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) kapsamındadır, gizli yaparsanız işiniz başkalarına izinsizdir. + +Başkalarının projenizi kullanmasını, dağıtmasını, değiştirmesini veya katkıda bulunmasını istiyorsanız, açık kaynaklı bir lisans eklemeniz gerekir. Örneğin, birileri, açıkça yapma hakkını vermediğiniz sürece, kamuya açık olsa bile, GitHub projenizin herhangi bir bölümünü yasalarında kullanamaz. + +## Sadece bana projemi korumak için ihtiyacım olan karışık metni verin. + +Şanslısınız, çünkü bugün açık kaynaklı lisanslar standartlaştırılmış ve kullanımı kolaydır. Mevcut bir lisansı doğrudan projenize kopyalayıp yapıştırabilirsiniz. + +[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 de vardır. [Choosealicense.com](https://choosealicense.com/)'da bu lisansların tam metnini ve nasıl kullanılacağına ilişkin talimatları bulabilirsiniz. + +GitHub'da yeni bir proje oluşturduğunuzda sizden [bir lisans eklemeniz istenir](https://help.github.com/articles/open-source-licensing/). + + + +## Projem için hangi açık kaynak lisansı uygundur? + +Boş bir sayfadan başlıyorsanız, [MIT Lisansı](https://choosealicense.com/licenses/mit/) ile yanlış yapmak zordur. Kısa, anlaşılması çok kolaydır ve telif hakkı uyarınız da dahil olmak üzere herhangi bir lisansın bir kopyasını sakladığı sürece herhangi bir şey yapmasına izin verir. Gerekirse, projeyi farklı bir lisans altında yayınlayabilirsiniz. + +Aksi takdirde, projeniz için doğru açık kaynak lisansını seçmek hedeflerinize bağlıdır. + +Projenizin büyük olasılıkla (veya olacak) **bağımlılıkları var**. Örneğin, bir Node.js projesi yapıyorsanız, muhtemelen Node Paket Yöneticisi'nden (npm) kitaplıkları kullanırsınız. Bağlandığınız bu kütüphanelerin her birinin kendi açık kaynaklı lisansı olacaktır. Lisanslarının her biri "izin verilebilir" ise (kamuya, alt lisans lisansı için herhangi bir şart olmaksızın, kullanma, değiştirme ve paylaşma izni verir), istediğiniz herhangi bir lisansı kullanabilirsiniz. Yaygın izin verilen lisanslar MIT, Apache 2.0, ISC ve BSD'dir. + +Öte yandan, bağımlılıklarınızın herhangi birindeki lisansları "güçlü copyleft" ise (aynı lisansı aynı lisansı kullanma şartı ile halka açık kullanıma aynı izinler verir), projeniz aynı lisansı kullanmak zorunda kalacaktır. Ortak güçlü copyleft lisanslarına GPLv2, GPLv3 ve AGPLv3 dahildir. + +Ayrıca, projenizi kullanacağını ve projenize katkıda bulunacağını umduğunuz **toplulukları** göz önünde bulundurmak isteyebilirsiniz: + +* **Projenizin diğer projeler tarafından bir bağımlılık olarak kullanılmasını istiyor musunuz?** İlgili topluluktaki en popüler lisansı kullanmak için muhtemelen en iyisi. Örneğin, [MIT](https://choosealicense.com/licenses/mit/), [npm kütüphaneleri](https://libraries.io/search?platforms=NPM) için en popüler lisanstır. +* **Projenizin büyük işletmelere hitap etmesini ister misiniz?** Büyük bir işletme muhtemelen tüm katılımcılardan açık bir patent lisansı isteyecektir. Bu durumda, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) size (ve onlara) uygundur. +* **Projenizin, yaptıkları katkıların kapalı kaynak kodlu yazılımlarda kullanılmasını istemeyenlere hitap etmesini ister misiniz?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) veya (kapalı kaynak hizmetlerine katkıda bulunmak istemiyorlarsa) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) sizin için iyidir. + +**Şirketinizin** açık kaynaklı projeleri için özel lisanslama gereksinimleri olabilir. Örneğin, izin verilen bir lisans gerektirebilir, böylece şirket projenizi şirketin kapalı kaynaklı ürününde kullanabilir. Veya şirketiniz güçlü bir copyleft lisansı ve ek bir katkı sözleşmesi (aşağıya bakınız) isteyebilir, böylece yalnızca şirketiniz ve başka hiç kimse projenizi kapalı kaynaklı yazılımında kullanamaz. Yada şirketiniz, herhangi biri belirli bir lisanslama stratejisi gerektirebilecek standartlar, sosyal sorumluluk veya şeffaflıkla ilgili belirli ihtiyaçlara sahip olabilir. [Şirketinizin hukuk departmanıyla](#şirketimin-hukuk-ekibinin-neleri-bilmesi-gerekiyor) konuşun. + +GitHub'da yeni bir proje oluşturduğunuzda, size bir lisans seçme seçeneği sunulur. Yukarıda belirtilen lisanslardan birinin dahil edilmesi GitHub projenizi açık kaynak yapacaktır. Başka seçenekler görmek isterseniz, projeniz için doğru lisansı bulmak için [choosealicense.com](https://choosealicense.com) adresini ziyaret edin, proje [yazılım](https://choosealicense.com/non-software/) projesi olmasa bile. + +## Projemin lisansını değiştirmek istersem ne olur? + +Çoğu projenin lisanslarını değiştirmesi gerekmez. Ancak bazen koşullar değişebilir. + +Örneğin, projeniz büyüdükçe bağımlılık veya kullanıcı sayısı artar veya şirketiniz, herhangi biri farklı bir lisans gerektirebilecek veya isteyebilecek strateji değişikliğine gidebilir. Ayrıca, projenizi baştan itibaren lisanslamayı ihmal ettiyseniz, bir lisans eklemek etkili bir şekilde lisans değiştirmekle aynıdır. Projenizin lisansını eklerken veya değiştirirken göz önünde bulundurmanız gereken üç temel husus vardır: + +**Bu iş karmaşıktır.** Lisans uygunluğunu ve uyumluluğunu belirlemek ve telif hakkını elinde tutan kişiler çok hızlı bir şekilde karmaşık ve kafaları karışık olabilir. Yeni sürümler ve katkılar için yeni ama uyumlu bir lisansa geçmek, tüm mevcut katkılardan vazgeçmekten farklıdır. Lisans değiştirme isteğinin ilk aşamalarına hukuk ekibinizi dahil edin. Bir lisans değişikliği için projenizin telif hakkı sahiplerinden izin almış olsanız veya izin alsanız bile, değişikliğin projenizin diğer kullanıcıları ve katkıda bulunanları üzerindeki etkisini göz önünde bulundurun. Projeniz için, paydaşlarınızla net iletişim ve istişarelerde daha sorunsuz bir şekilde ilerleyebilecek olan bir lisans değişikliğini projeniz için bir "yönetişim etkinliği" olarak düşünün. Bunların hepsi projeniz için başlangıçtan itibaren uygun bir lisans seçmek ve kullanmak için yeterince sebeplerdir! + +**Projenizin mevcut lisansı.** Projenizin mevcut lisansı, değiştirmek istediğiniz lisansla uyumluysa, yeni lisansı kullanmaya başlayabilirsiniz. Bunun nedeni, eğer A lisansı B lisansı ile uyumluysa, B şartlarına uyurken A şartlarına uymanız gerekir (ancak bunun tersi geçerli değildir). Dolayısıyla, şu anda izin verilen bir lisans kullanıyorsanız (örneğin, MIT), MIT lisansının bir kopyasını ve ilgili tüm telif hakkı bildirimlerini sakladığınız sürece, daha fazla koşullu bir lisansa geçebilirsiniz (örneğin, MIT lisansının asgari koşulları). Ancak mevcut lisansınıza izin verilmezse (örneğin, copyleft veya lisansınız yoksa) ve tek telif hakkı sahibi değilseniz, projenizin lisansını MIT olarak değiştiremezsiniz. Esasen, izin verilen bir lisans ile projenin telif hakkı sahiplerinin lisanslarını değiştirmek için önceden izin vermişlerdir. + +**Projenizin mevcut telif hakkı sahipleri.** Projenize katkıda bulunan tek kişi iseniz, o zaman siz veya şirketiniz projenin tek telif hakkı sahibisiniz. Sizin veya şirketinizin istediği lisansı ekleyebilir veya değiştirebilirsiniz. Aksi takdirde, lisansları değiştirmek için anlaşma yapmanız gereken başka telif hakkı sahipleri olabilir. Onlar kim? Projenizde katkısı olan kişiler başlamak için iyi bir yerdir. Ancak bazı durumlarda telif hakkı bu kişilerin işverenleri tarafından verilecektir. Bazı durumlarda insanlar sadece asgari katkı sağlayacaklardır, ancak bazı kod satırları altındaki katkıların telif haklarına tabi olmadığına dair kesin ve hızlı bir kural yoktur. Ne yapalım? Duruma göre değişir. Göreceli olarak küçük ve yeni bir proje için, mevcut tüm katılımcılardan bir sorun ya da çekme talebinde lisans değişikliğini kabul etmelerini sağlamak mümkün olabilir. Büyük ve uzun ömürlü projeler için birçok katılımcı ve hatta mirasçıları aramanız gerekebilir. Mozilla'nın Firefox, Thunderbird ve ilgili yazılımları yeniden lisanması yıllarını (2001-2006) aldı. + +Alternatif olarak, katkıda bulunanlara, mevcut açık kaynak lisansınız tarafından izin verilenlerin ötesinde, belirli koşullar altında belirli lisans değişikliklerinde önceden (ek bir anlaşma yaparak - aşağıya bakınız) karar vermiş olabilirsiniz. Bu, değişen lisansların karmaşıklığını biraz değiştirir. Önceden avukatlarınızdan daha fazla yardıma ihtiyacınız olacak ve bir lisans değişikliği yaparken projenizin paydaşlarıyla açıkça iletişim kurmak isteyeceksiniz. + +## 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/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. + +Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız olduğuna inandığı "evraklar" ekleyerek (sözleşme alıcısı katkıda bulunanlardan veya halkın projenin açık kaynak lisansı aracılığıyla yaptığı haklardan daha fazla hak kazandığında), ek bir katılımcı anlaşması projenin topluluğuna dostça görülmeyebilir. + + + +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://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. + +## Şirketimin hukuk ekibinin neleri bilmesi gerekiyor? + +Açık kaynaklı bir projeyi bir şirket çalışanı olarak yayınlıyorsanız, önce hukuk ekibiniz bir proje tedarik ettiğinizi bilmelidir. + +Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi düşünün. Büyük olasılıkla, şirketinizle kendilerine projelerinizi kontrol etmelerini sağlayan bir "çalışan IP sözleşmesi" uygulamanız vardır, özellikle de şirketin işi ile ilgili ise veya projeyi geliştirmek için herhangi bir şirket kaynağını kullanıyorsanız. Şirketiniz size kolayca izin _vermeli_ ve belki de zaten çalışan dostu bir IP sözleşmesi veya şirket politikası ile sahip olabilir. Aksi takdirde pazarlık yapabilirsiniz (örneğin, projenizin şirketin sizin için mesleki öğrenme ve gelişim hedeflerine hizmet ettiğini açıklayın) veya daha iyi bir şirket bulana kadar projeniz üzerinde çalışmaktan kaçının. + +**Şirketiniz için bir proje açmaya açıksanız**, kesinlikle onları bilgilendirin. Yasal ekibinizde muhtemelen, şirketin iş gereksinimlerine ve projenizin bağımlılıklarının lisanslarına uymasını sağlama konusundaki uzmanlığına dayalı olarak kullanılacak açık kaynaklı lisans (ve belki de ek katkı sözleşmesi) için politikalar zaten vardır. Olmazsa, sen ve onlar şanslısınız demektir! Hukuk ekibiniz bu olayları çözmek için sizinle birlikte çalışmaya istekli olmalıdır. Göz önünde bulundurulması gereken bazı şeyler: + +* **Üçüncü taraf materyali:** Projeniz başkaları tarafından yaratılan bağımlılıklara sahip mi, yoksa başkalarının kodunu içeriyor veya kullanıyor mu? Bunlar açık kaynak ise, malzemelerin açık kaynak lisanslarına uymanız gerekir. Bu, üçüncü taraf açık kaynaklı lisanslarla çalışan bir lisans seçmekle başlar (yukarıya bakın). Projeniz üçüncü taraf açık kaynak materyalini değiştirir veya dağıtırsa, yasal ekibiniz ayrıca üçüncü taraf açık kaynak lisanslarının diğer koşullarını yerine getirdiğinizi bilmek isteyecektir. Projeniz açık kaynak lisansı olmayan başkalarının kodunu kullanıyorsa, büyük olasılıkla üçüncü taraf bakımcılardan [açık kaynak lisansı eklemelerini](https://choosealicense.com/no-license/#for-users) istemeniz ve bunlardan birini alamamanız durumunda, kodlarını kullanmaktan vazgeçmeniz gerekir. + +* **Ticari sırlar:** Projede, şirketin genel kullanıma açık olmasını istemediği bir şey olup olmadığını dikkate alın. Öyleyse, gizli tutmak istediğiniz malzemeyi çıkardıktan sonra projenizin geri kalan kısmını kaynak olarak açabilirsiniz. + +* **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/#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. + +Şirketinizin ilk açık kaynaklı projesini yayınlıyorsanız, yukarıdakiler üstesinden gelmek için fazlasıyla yeterlidir (ancak endişelenmeyin, çoğu proje endişelendirecek bir durum oluşturmayacaktır). + +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://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/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%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 new file mode 100644 index 00000000000..753ff7060fd --- /dev/null +++ b/_articles/tr/metrics.md @@ -0,0 +1,126 @@ +--- +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 +order: 9 +image: "/assets/images/cards/metrics.png" +related: + - finding + - best-practices +--- + +## Neden her şeyi ölçmeli? + +Veriler akıllıca kullanıldığında, açık kaynaklı bir geliştirici olarak daha iyi kararlar almanıza yardımcı olabilir. + +Daha fazla bilgi ile şunları yapabilirsiniz: + +* Kullanıcıların yeni bir özelliğe verdiği tepkiyi anlama +* Yeni kullanıcıların nereden geldiğini bulma +* Bir aykırı kullanım senaryosunu veya işlevselliğini belirleme ve destekleyip desteklememeye karar verme +* Projenizin popülaritesini ölçme +* Projenizin nasıl kullanıldığını anlama +* Sponsorluklar ve bağışlar yoluyla para toplama + +Örneğin, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) ekibi Google Analytics"in çalışmalarına öncelik vermelerine yardımcı olduğunu keşfediyor: + +> Homebrew ücretsiz olarak verilmektedir ve tamamen boş zamanlarında gönüllüler tarafından geliştirilmektedir. Sonuç olarak, gelecekteki özellikleri en iyi nasıl tasarlayacağınıza ve mevcut çalışmaya öncelik vereceğimize karar vermek için Homebrew kullanıcılarının detaylı kullanıcı çalışmalarını yapacak kaynaklara sahip değiliz. Anonim toplam kullanıcı analitiği, insanların Homebrew'i nasıl, nerede ve ne zaman kullandıklarına dayanarak düzeltmeleri ve özellikleri öncelik sırasına koymamızı sağlar. + +Popülerlik her şey değildir. Herkes farklı nedenlerden dolayı açık kaynağa dahil oluyor. Açık kaynak kod geliştiricisi olarak hedefiniz çalışmanızı göstermekse, kodunuz konusunda şeffaf olmaksa veya sadece eğlenmek ise, metrikler sizin için önemli olmayabilir. + +Eğer daha derin bir seviyede projenizi anlamak isteğiniz _varsa_, projenizin etkinliğini analiz etmek için yolunu bulmak için okumaya devam edin. + +## Keşif + +Herhangi biriniz projenizi kullanmadan veya katkıda bulunmadan önce, onun var olduğunu bilmeleri gerekir. Kendinize sorun: _insanlar bu projeden haberdarlar mı?_ + +![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +Projeniz GitHub'da barındırıyorsanız, projenizi kaç kişinin gördüğünü ve nereden geldikleri [görüntüleyebilirsiniz](https://help.github.com/articles/about-repository-graphs/#traffic). Projenizin sayfasından "Insights" menüsünü, ardından "Traffic" alt menüsünü tıklayın. Bu sayfada şunları görebilirsiniz: + +* **Toplam sayfa görüntüleme:** Projenizin kaç kez görüntülendiğini gösterir + +* **Toplam tekil ziyaretçi:** Projenizi kaç kişinin görüntülediğini gösterir + +* **Yönlendiren siteler:** Ziyaretçilerin nereden geldiğini gösterir. Bu ölçüm, hedef kitlenize nerede ulaşacağınızı ve tanıtım çalışmalarınızın işe yarayıp yaramadığını çözmenize yardımcı olabilir. + +* **Popüler içerik:** Ziyaretçilerin projenizde nereye gittiğini, sayfa görünümlerine ve benzersiz ziyaretçilere göre ayrıldığını gösterir. + +[GitHub yıldızları](https://help.github.com/articles/about-stars/) ayrıca temel bir popülarite ölçüsü sağlamaya yardımcı olabilir. GitHub yıldızları, indirmeler ve kullanımla mutlaka ilişkilendirilmezken, size kaç kişinin çalışmanızdan haberdar olduğunu söyleyebilirler. + +[Belirli yerlerdeki keşfedilebilirliği izlemek](https://opensource.com/business/16/6/pirate-metrics) isteyebilirsiniz: örneğin, Google PageRank, projenizin web sitesinden yönlendirilen trafik veya diğer açık kaynaklı projelerden veya web sitelerinden gelen yönlendirmeler. + +## Kullanım + +İnsanlar projenizi internet dediğimiz bu vahşi ve çılgın şey üzerinde buluyorlar. İdeal olarak, projenizi gördüklerinde, bir şeyler yapmaya zorlanırlar. Sormak isteyeceğiniz ikinci soru şudur: _insanlar bu projeyi kullanıyorlar mı?_ + +Projenizi dağıtmak için npm veya RubyGems.org gibi bir paket yöneticisi kullanıyorsanız, projenizin indirmelerini takip edebilirsiniz. + +Her paket yöneticisi "indirme" nin biraz farklı bir tanımını olabilir ve indirme işlemleri kurulum veya kullanım ile mutlaka ilişkili değildir, ancak karşılaştırma için bazı temel bilgiler sağlar. Birçok popüler paket yöneticisinde kullanım istatistiklerini izlemek için [Libraries.io](https://libraries.io/) servisini kullanmayı deneyin. + +Projeniz GitHub'daysa, tekrar "Trafik" sayfasına gidin. [Klon grafiğini](https://github.com/blog/1873-clone-graphs), projenizin belirli bir günde kaç kez klonlandığını, toplam klonların ve benzersiz klonların karşılaştırmlı hallerini görmek için kullanabilirsiniz. + +![Clone graph](/assets/images/metrics/clone_graph.png) + +Kullanım, projenizi keşfeden kişi sayısına kıyasla düşükse, göz önünde bulundurulması gereken iki husus vardır. Ya: + +* Projeniz kitlenizi başarıyla dönüştüremiyor ya +* Yanlış kitleyi çekiyorsun + +Örneğin, projeniz Hacker News'in ön sayfasına girerse, muhtemelen keşifte (trafik) bir artış göreceksiniz, ancak Hacker News'deki herkese ulaştığınız için daha düşük bir dönüşüm oranı göreceksiniz. Ancak, Ruby projeniz bir Ruby konferansında tanıtılıyorsa, hedef kitleden yüksek bir dönüşüm oranı görmeniz daha olasıdır. + +Kitlenizin nereden geldiğini anlamaya çalışın ve bu iki sorunun hangisiyle karşılaştığınızı anlamak için proje sayfanızdan geri bildirim isteyin. + +İnsanların projenizi kullandığını öğrendikten sonra, onunla ne yaptığını anlamaya çalışmak isteyebilirsiniz. Kodunuzu yazıp özellikleri ekleyerek üzerine mi inşa ediyorlar? Akademik çalışma ya da iş için mi kullanıyorlar? + +## Akılda Tutma + +İnsanlar projenizi buluyor ve kullanıyorlar. Kendinize sormak isteyeceğiniz bir sonraki soru şudur: _insanlar bu projeye geri dönüş ve katkıda bulunuyor mu?_ + +Katkıda bulunanlar hakkında düşünmeye başlamak için asla erken değildir. Diğer insanlar girmeden, kendinizi projenizin _popüler olduğu_ (birçok kişi kullanır) ancak _desteklenmez_ sağlıksız bir duruma sokma riskini alırsınız (talebi karşılamak için yeterli zaman bekletici değil). + +Akılda tutulma, daha önce aktif olan katılımcılar eninde sonunda başka şeylere geçeceğinden, [yeni katılımcıların girişini](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) gerektirir. + +Düzenli olarak izlemek isteyebileceğiniz topluluk ölçümleri örnekleri şunlardır: + +* **Katkıda bulunan toplam katılımcı sayısı ve komisyon sayısı:** Ne kadar katılımcının bulunduğunu ve kimin ya da daha az aktif olduğunu gösterir. GitHub'da bunu "Insights" -> "Katkıda Bulunanlar" altında görebilirsiniz. Şu anda, bu grafik yalnızca deponun varsayılan koluna bağlı olan katılımcıları sayar. + +![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **İlk kez, geçici ve tekrar eden katılımcılar:** Yeni katılımcılar alıp almadığınızı ve geri gelip gelmeyeceklerini izlemenize yardımcı olur. (Sıradan katkıda bulunanlar, az sayıda katkı veren katılımcılardır. Bu, bir katkı, beş katkıdan az veya size kalmış başka bir sayı.) Yeni katılımcılar olmadan, projenizin topluluğu durgun hale gelebilir. + +* **Açık işlerin ve PR'lerin sayısı:** Bu sayılar çok yükselirse, sorun giderme ve kod incelemeleri konusunda yardıma ihtiyacınız olabilir. + +* **Açılan işlerin ve açılan PR'lerin sayısı:** Açılan sorunlar, birinin projenizi açması için yeterince önemsediği anlamına gelir. Bu sayı zaman içinde artarsa, insanların projenize ilgi duyduğunu gösterir. + +* **Katkı türleri:** Örneğin, yazım hatalarını veya hataları düzeltme veya bir konuda yorum yapma. + + + +## Geliştirici etkinliği + +Son olarak, projenizin sahiplerinin alınan katkıların hacmini karşılayabildiğinden emin olarak döngüyü kapatmak isteyeceksiniz. Kendinize sormak isteyeceğiniz son soru şudur: _Topluluğumuza cevap veriyor muyum (muyuz)?_ + +Tepki vermeyen geliştiriciler açık kaynaklı projeler için bir el freni haline gelir. Birisi bir katkı gönderirse, ancak bir geliştiriciden bir geri bildirim gelmezse, cesareti kırılır ve projeden ayrılabilir. + +[Mozilla'da yapılan bir araştırma](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177), geliştiricilerin sürdürülebilirlik konusundaki duyarlılığının, tekrar eden katkıları teşvik etmede kritik bir faktör olduğunu öne sürüyor. + +Bir sorunun ya da PR talebinin katkısına yanıt vermenizin (veya başka bir geliştiricinin) ne kadar sürdüğünü takip edin. Yanıt vermek, harekete geçmek gerektirmez. Şunu söylemek kadar basit olabilir: _"Gönderiminiz için teşekkürler! Bunu önümüzdeki hafta içinde gözden geçireceğim."_ + +Ayrıca, katkı sürecindeki aşamalar arasında geçiş için geçen süreyi ölçebilirsiniz, örneğin: + +* Bir sorunun açık kaldığı ortalama süre +* Sorunların PR'ler ile kapatılıp kapatılmadığı +* Eski sorunların kapatılıp kapatılmadığı +* Bir PR isteğini birleştirmek için ortalama süre + +## İnsanlar hakkında bilgi edinmek için 📊 kullanın. + +Ölçümleri anlamak, aktif ve büyüyen bir açık kaynak proje oluşturmanıza yardımcı olacaktır. Bir gösterge panosundaki her bir ölçümü izlemeseniz bile, dikkatinizi projenizin gelişmesine yardımcı olacak davranış türüne odaklamak için yukarıdaki çerçeveyi kullanın. 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 new file mode 100644 index 00000000000..46d0b75a3c8 --- /dev/null +++ b/_articles/tr/starting-a-project.md @@ -0,0 +1,356 @@ +--- +lang: tr +title: Açık Kaynaklı bir Projeye Başlamak +description: Açık kaynak dünyası hakkında daha fazla bilgi edinin ve kendinizi proje başlatmaya hazırlayın. +class: beginners +order: 2 +image: "/assets/images/cards/beginner.png" +related: + - finding + - building +--- + +## Açık kaynağın "nedir"i ve "neden"i + +Yani açık kaynak kodlu bir projeye başlamayı mı düşünüyorsun? Tebrikler! Dünya katkınızı takdir ediyor. Açık kaynağın ne olduğu ve insanların neden yaptıkları hakkında konuşalım. + +### "Açık kaynak" ne demek? + +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. 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. + +_Ö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? + + + +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 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/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://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir. + +Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın. + +### 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ı ücretli olursa, herkes yasal olarak bir kopya çıkarabilir ve bunun yerine ücretsiz sürümü kullanabilir. + +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 kaynakların nasıl çalıştığını öğrenmek için harika bir yoldur. + +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 ç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 bir dakikanızı ayırın. + +### Hedeflerinizi belirlemek + +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 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 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 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 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 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. + +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. + + + +### Diğer projelere katkıda bulunmak + +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 Kaynaklara Nasıl Katkıda Bulunur](../how-to-contribute/) kılavuzumuza göz atın + +## Kendi açık kaynak projenizi başlatmak + +İş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 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 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) +* [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Davranış kuralları](../code-of-conduct/) + +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'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.** + +[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. + +![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) + +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 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'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 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 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. + +### Katkıda bulunma rehberinizi yazmak + +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 +* Proje ortamı nasıl kurulur ve testler nasıl yapılır + +Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: + +* Aradığınız katkı türleri +* Proje için yol haritanız veya vizyonunuz +* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) + +Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: + +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/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. + +### Davranış kural listesi oluşturmak + + + +Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. + +Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın. + +Katılımcıların _nasıl_ davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir. + +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. + +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 + +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 + +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). + +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). + +### 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. + +Bir web sitesi, Twitter hesabı veya projenizi temsil eden diğer özellikleri istiyorsanız, istediğiniz adları aldığınızdan emin olun. İdeal olarak, [bu isimleri](https://instantdomainsearch.com/) henüz kullanmak istemediğiniz zamanlarda bile, rahat etmek için şimdiden alın. + +Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez. + +[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. + +### 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. + +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. + +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. 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** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Kod** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**İnsanlar** + +Bireyseniz: + +
+ + +
+ +Bir şirket veya kuruluşsanız: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## 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 15acb852678..00000000000 --- a/_articles/zh-cn/finding-users.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -lang: zh-cn -title: 为项目寻找适合的用户 -description: 通过找到诚心如意的用户，帮助开源项目成长。 -class: finding -toc: - spreading-the-word: "四处传播" - figure-out-your-message: "发出自己的声音" - help-people-find-and-follow-your-project: "帮助人们找到并关注你的项目" - go-where-your-projects-audience-is-online: "到项目成员线上经常去的地方" - go-where-your-projects-audience-is-offline: "到项目成员线下经常去的地方" - build-a-reputation: "赢得口碑" -order: 3 -image: /assets/images/cards/finding.png -related: - - beginners - - building ---- - -## Spreading the word - -还没有规定说应该怎么去倡导刚创建的开源项目。但没有任何理由说必须默默无闻的在开源项目上工作。相反，如果你向有更多的人发现和使用你的开源项目，你就应该让所有人知道你所努力的成果！ - -## Figure out your message - -在你开始推广你的项目之前，你应该能够解释你的项目是做什么的，为什么大家需要他? - -是什么让你的项目变得不同或者有趣，在自己心中问这些问题会让你更容易说服别人。 - -牢记一件事情，别人之所以使用你的项目，甚至是为你的项目做贡献，是因为你的项目解决了他们的问题。所以你要找出他们需要什么，然后把他当成你项目的卖点或者说价值所在。 - -举个例子，[@robb](https://github.com/robb)用代码实例来清晰的阐述为什么他的项目[Cartography](https://github.com/robb/Cartography)是有用的。 - -![cartography readme](/assets/images/finding-users/cartography.jpg) - -如果你想深入了解如何挖掘项目的"卖点"，看一下Mozilla的["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/)，练习如何建立用户的形象。 - -## Help people find and follow your project - - - -通过引导他们到一个唯一的地址来帮助人们发现和记住你的项目。 - -**要有一个推广的主阵地。**一个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) - -现在你的项目有了"卖点"，和让人们很容易发现你项目的渠道，接下来我们谈谈如何和你的用户交流吧！ - -## Go where your project's audience is (online) - -网上拓展是分享和快速宣传项目的一个好方法。借助一些网上的渠道，你有可能找到一大批受众。 - -利用好已有的线上社区和平台去找你的受众。如果你的开源项目是一个软件项目，你可能会在[Stack Overflow](http://stackoverflow.com/), [reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), 或者[Quora](https://www.quora.com/)。找到你觉得人们会最有可能从你的项目中受益或者对你项目感兴趣的渠道。 - - - -来看看下面的一些方法吧，也许推广你的项目的时候用得着。 - -* **快找找有没有相关的开源项目和社区。**有时候，你不需要直接的推广你的项目。如果你的项目对使用Python的数据科学家来说是无可挑剔的，那么就去找Python数据科学的社区。等他们知道你的项目之后，很自然的就会谈论然后分享你的工作成果。 -* **如果你项目尝试解决某些问题，那么找到会遇到这些问题的人。**想象你的项目受众会在哪些论坛，然后搜索这些论坛，回答他们的问题，然后找一个合适的实际，向他们建议使用你的项目来作为一种解决方案。 -* **寻求反馈。**给一个可能会用到你项目的人介绍你自己和你做的工作。对哪些人会从你的项目受益要很明确。尝试完善一下下面这句话："我觉得我的项目能够帮助A，那些尝试做B的人"。听取和回复别人的反馈，而不是简单的推广。 - -一般来说，在你索取什么回报之前先把精力放在帮助别人上。因为在网上推广一个项目对任何人都是一个不难的事情，所以有很多人和坐着一样的事。告诉人们你是谁，而不是你想要什么，这样才能从众多推广者中脱颖而出。 - -如果没有人对你的推广感兴趣，不要灰心！大部分的项目的开展都是一个要花费数月和数年的反复过程。如果你第一次没收到反应，尝试换一种策略，或者找办法给别人的项目做做贡献。这都是些需要时间和奉献精神的事情。 - -## Go where your project's audience is (offline) - -![public speaking](/assets/images/finding-users/public_speaking.jpg) - -线下活动是一个推广项目流行的方式。这是一个接触某个忠实听众和建立深层次的联系的好方式，特别是如果你对到场的开发者感兴趣的话。 - -如果你还是个[公中演讲的新手](http://speaking.io/)，从寻找一个和你项目使用的语言或者生态系统相关的当地的聚会开始吧。 - - - -如果你从来没在公共场合讲过话，感觉紧张那就太正常啦！记住你的听众就在哪儿，因为他们都是真正的想听你介绍你的项目。 - -当你在写你的演讲稿的时候，把重点放在你的听众会感兴趣而且能获取价值的事情上。保证你的语言要友好和和蔼可亲。笑一笑，深呼吸，幽默一点儿。 - - - -等你准备好了，考虑一下在某个会议上发言的时候推广你的项目研讨会可以帮助你接触更多人，有时候是来自全世界各地的人。 - - - -## Build a reputation - -除了上面提到的策略之外，邀请人们分享和支持你的项目的最好办法就是分享和支持他们的项目。 - -帮助新手，分享资源，给别人的项目认真的做贡献会帮助你建立起良好的声誉。然后他们就很有可能知道你的项目而且更有可能关注和分享你在做的事情。 - -有时候，这些关系还会进一步发展成更广阔的生态系统中的官方合作伙伴（意思即使你有可能成为那些有名社区的成员） - - - -种一棵树最好的时候是十年前，其次是现在。所以啥时候开始建立你的声望都不晚。即使是你早就已经建立了自己的项目，还是要继续找办法帮助别人。 - -建立用户群没有一蹴而就的方法。获取别人的新人和尊重需要时间，同样，建立声望的过程也永远不会停止。 - - - -## Keep at it! - -有时候，让人么注意你的开源项目会话费很多事件。但是关系！现在很多流行的项目都是花了很多年才有今天的活跃度。把重点放在建立声望上而不是企图一夜成名。耐心一点，一如既往的和那些可能会从中受益的人们分享你的项目。 diff --git a/_articles/zh-cn/best-practices.md b/_articles/zh-hans/best-practices.md similarity index 69% rename from _articles/zh-cn/best-practices.md rename to _articles/zh-hans/best-practices.md index d5df3835147..edc4b09aa07 100644 --- a/_articles/zh-cn/best-practices.md +++ b/_articles/zh-hans/best-practices.md @@ -1,31 +1,25 @@ --- -lang: zh-cn +lang: zh-hans title: 维护者最佳实践 description: 身为开源的维护者，如何轻松驾驭项目？本指南从文档流程到有效利用社区来展开。 class: best-practices -toc: - what-does-it-mean-to-be-a-maintainer: "身为一名维护者意味着什么？" - documenting-your-processes: "将流程撰文档化" - learning-to-say-no: "学会拒绝他人" - leverage-your-community: "有效利用社区" - bring-in-the-robots: "使用机器人" - its-okay-to-hit-pause: "首先照顾好自己" order: 5 image: /assets/images/cards/best-practices.png related: - metrics - leadership +redirect_from: /zh-cn/best-practices/ --- -## What does it mean to be a maintainer? +## 身为维护者意味这什么？ -如果你维护着一个非常流行的项目，你可能就会意识到自己写代码的时间变少，而花费在回答issue的时间越来越多。 +如果你维护着一个非常流行的项目，你可能就会意识到自己写代码的时间变少，而花费在回答 issue 的时间越来越多。 在项目的起步阶段，你会不断尝试着实现自己的新想法，也能够基于自己想要的作出决定。随着项目逐渐的开始流行，就会发现你的大部分时间都花在了与用户、贡献者打交道上。 -维护一个项目需要的不仅仅是写代码的能力。有些时候会有一个你意想不到的的事情要应付，但是这对一个项目的成长也很重要（相对于代码来说），我们收集了一些小技巧来让你的维护工作变得稍轻松些，这些技巧，涉及范围颇广，从写文档到管理社区都有所涉猎。 +维护项目需要的不仅仅是编码。有些意料之外的任务，对于项目的持续发展同样重要。我们收集了几种方法让你的维护工作变得稍轻松些，这些技巧，涉及范围颇广，从编写文档到管理社区都有所涉及。 -## Documenting your processes +## 流程文档化 对于一个项目的维护者来说写文档是最重要的事情之一。 @@ -41,11 +35,11 @@ related: 有一个明确的，用文档表达清晰的愿景，能保证项目的走向不会跑偏，同时也能保障因为其他的贡献者增加的奇怪的需求而使项目变质。 -比如，@lord 发现项目有一个明确的愿景能够帮助他决定哪个 PR 值得花时间。作为一个维护者的新手，他甚至还后悔当他接到第一个关于[slate](https://github.com/lord/slate))PR的时候没有坚持项目本身的原则。 +比如，@lord 发现项目有一个明确的愿景能够帮助他决定哪个 PR 值得花时间。作为一个维护者的新手，他甚至还后悔当他接到第一个关于 [slate](https://github.com/lord/slate) PR 的时候没有坚持项目本身的原则。 @@ -237,31 +231,31 @@ fork一个项目不什么坏事情。能复制并且修改别人的代码是开 * [mention-bot](https://github.com/facebook/mention-bot) 可能的贡献者来帮你复查代码 * [Danger](https://github.com/danger/danger) 帮你自动复查代码 -对于bug报告和其他常见形式的贡献，Github有[Issue 模版和 Pull Request 模版](https://github.com/blog/2111-issue-and-pull-request-templates), 你可以用来降低沟通成本。你也可以设置[邮件过滤](https://github.com/blog/2203-email-updates-about-your-own-activity)来管理你的邮件提醒。 +对于 bug 报告和其他常见形式的贡献，GitHub 有[Issue 模版和 Pull Request 模版](https://github.com/blog/2111-issue-and-pull-request-templates), 你可以用来降低沟通成本。你也可以设置[邮件过滤](https://github.com/blog/2203-email-updates-about-your-own-activity)来管理你的邮件提醒。 -如果你想更加的先进和高效，代码风格指南和linter能让你项目收到的贡献更加规范，而且更容易复查和被接受。 +如果你想更加的先进和高效，代码风格指南和 linter 能让你项目收到的贡献更加规范，而且更容易复查和被接受。 当然啦，如果你的标准太复杂了，反倒会增加了贡献的难度。所以保证你只添加那些让每个人工作起来更容易的规则。 -如果你不确定用什么工具，看一看别的流行项目是怎么做的，特别是和你在一个生态系统的。比如，其他的Node模块的贡献流程是怎么样的？用相似的工具和方法，能够让你项目的贡献流程对于开发者来说是很熟悉的。 +如果你不确定用什么工具，看一看别的流行项目是怎么做的，特别是和你在一个生态系统的。比如，其他的 Node 模块的贡献流程是怎么样的？用相似的工具和方法，能够让你项目的贡献流程对于开发者来说是很熟悉的。 ## 不干了也没关系 开源项目曾经让你开心，但可能现在开始让你不开心了。 -可能当你想到你的项目的时候感觉到"亚历山大"。而同时，issue和PR又纷至沓来。 +可能当你想到你的项目的时候感觉到"亚历山大"。而同时，issue 和 PR 又纷至沓来。 疲倦在开源工作工作中是一个常见的问题，特别是在维护者中间。作为一个维护者，你做的开心对项目的生存来说是一个没有商量余地的条件。 -虽然你不需要跟谁请假，但是也不要拖到自己疲倦不堪的时候才去度假。[@brettcannon](https://github.com/brettcannon)，一个python的核心开发者，决定在14年的义务劳动之后[休一个月的假](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) +虽然你不需要跟谁请假，但是也不要拖到自己疲倦不堪的时候才去度假。[@brettcannon](https://github.com/brettcannon)，一个 Python 的核心开发者，决定在 14 年的义务劳动之后[休一个月的假](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering)。 就像其他工作一样，有规律的休息会让你对工作保持舒适愉快的心情。 @@ -271,6 +265,6 @@ fork一个项目不什么坏事情。能复制并且修改别人的代码是开 休假不仅适用于度假。如果你周末不想做开源项目的工作了，或者在本该工作的时候不想干活了，和别人说，这样他们知道什么时候不该打扰你。 -## It's okay to hit pause +## 不必事必躬亲 -维护一个大型项目时，相比早期的增长阶段，是需要更多的不一样的技能，作为一个维护者，你会将自己的领导力和个人能力提高一个层次，而这是很少人能体会的到的。但是与此同时，要挑战管理项目，以及设定清晰的界限。只做你感到舒服的事情，能够让你保持开心，活力，高产的状态。 +维护一个大型项目时，相比早期的增长阶段，是需要更多的不一样的技能，作为一个维护者，你会将自己的领导力和个人能力提高一个层次，而这是很少人能体会的到的。但是与此同时，要挑战管理项目，以及设定清晰的界限。只做你感到舒服的事情，能够让你保持开心、活力和高产的状态。 diff --git a/_articles/zh-cn/building-community.md b/_articles/zh-hans/building-community.md similarity index 79% rename from _articles/zh-cn/building-community.md rename to _articles/zh-hans/building-community.md index 8b360c697d5..67504dafbb1 100644 --- a/_articles/zh-cn/building-community.md +++ b/_articles/zh-hans/building-community.md @@ -1,20 +1,17 @@ --- -lang: zh-cn +lang: zh-hans title: 打造受欢迎的社区 description: 打造人们愿意使用、贡献、并主动宣传的人气社区。 class: building -toc: - setting-your-project-up-for-success: "建立成功的项目" - growing-your-community: "社区生长" - resolving-conflicts: "解决冲突" order: 4 image: /assets/images/cards/building.png related: - best-practices - coc +redirect_from: /zh-cn/building-community/ --- -## Setting your project up for success +## 让项目向成功方向迈进 现在的你，已经启动了属于自己的项目，而且正在传播它，更重要的是现在已经有人将之下载到本地进行观摩。这真是令人振奋！那么你现在要做的就是，怎么能够让这些有兴趣的人们坚持下去，持续跟进项目。 @@ -22,7 +19,7 @@ related: ### 让大家感到受欢迎 -可以通过被@MikeMcQuaid称之为[贡献者漏斗](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)的方法思考项目的社区。 +可以通过被@MikeMcQuaid称之为[贡献者漏斗](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/)的方法思考项目的社区。 ![contributor funnel](https://opensource.guide/assets/images/building-community/contributor_funnel_mikemcquaid.png) @@ -30,19 +27,19 @@ related: 从你的文档开始： -* **让大家很容易上手。** [一份友好的 README](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#编写readme)以及清晰的代码示例将让大家很容易的上手。 -* **清楚的解释如何做贡献**，使用[你的CONTRIBUTING file](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md#编写你的贡献指南)以及持续更新issues。 +* **让大家很容易上手。** [一份友好的 README](../starting-a-project/#撰写自述文件)以及清晰的代码示例将让大家很容易的上手。 +* **清楚的解释如何做贡献**，使用[你的CONTRIBUTING file](../starting-a-project/#编写你的贡献指南)以及持续更新issues。 好的文档能够邀请他人参与你们项目的互动。最终，一些人会开一个issue或者pull request。将这些互动视为机会，将他们转移到漏斗的下方。 -* **当一些人选择了你们的项目，请对他们表示感谢！** 仅仅只是一次消极的经历就足以让一些人再也不想回来。 +* **当一些人选择了你们的项目，请对他们表示感谢！** 一次糟糕的体验就可能失去一个用户。 * **及时回应。** 如果你们一个月都没有回答他们的问题，他们可能早已忘记了你们的项目。 -* **对你以后接受的所有贡献者持开放态度。** 很多贡献者是从一份bug报告或者小的修复开始的。这里有[很多为项目做贡献的方式](../how-to-contribute/#what-it-means-to-contribute)。让大家选择他们喜欢的方式。 -* **如果你不赞成一个贡献，** 首先你需要对他们的想法表示感谢，同时 [解释为什么](../best-practices/#learning-to-say-no)它不适合项目，如果有必要的话你可以给出相关的文档链接。 +* **对你以后接受的所有贡献者持开放态度。** 很多贡献者是从一份bug报告或者小的修复开始的。这里有[很多为项目做贡献的方式](../how-to-contribute/#贡献意味着什么)。让大家选择他们喜欢的方式。 +* **如果你不赞成一个贡献，** 首先你需要对他们的想法表示感谢，同时 [解释为什么](../best-practices/#学会说不)它不适合项目，如果有必要的话你可以给出相关的文档链接。 @@ -79,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，或者询问项目的有关问题时，你们应该尽量回答他们。当你们快速地做出回应时，人们将感觉到他们参与了对话，以及他们将会更热情地参与。 @@ -87,7 +84,7 @@ related: ![middleman pull request](/assets/images/building-community/middleman_pr.png) -[一份Mozilla研究发现](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) 如果贡献者在48小时内收到代码审查，他们会有很大的回头率，且极有可能会再次贡献。 +[Mozilla的一份研究发现](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) 如果贡献者在48小时内收到代码审查，他们会有很大的回头率，且极有可能会再次贡献。 与项目有关的话题也可能发生在互联网的其它地方，例如Stack Overflow，Twitter，或者Reddit。你可以在像这样的一些网站设置通知，这样当有人提及项目时，可以即时的收到提醒。 @@ -107,55 +104,55 @@ related: 公开交流需要特别注意的事项：1）有关安全方面的issues 2）敏感的行为准则。应该为大家提供一个私下报告这些issue的方式。若不想使用自己的个人邮箱，那么就创建一个公用的邮箱。 -## Growing your community +## 发展你们的社区 社区拥有强大的能量。这种能量可能是正面的也可能是负面的，这一切都取决于你如何驾驭它。随着项目社区的成长，要想办法让之成为建设性的力量，而不是具有破坏性的。 -### Don't tolerate bad actors +### 不纵容坏人 一些流行的项目将不可避免地会吸引到一些破坏它们的人。这些人可能会从一些没必要的争论开始，对一些细枝末节进行纠缠不清，甚或用语言伤及他人。 对于这类人，必须采取零容忍的政策。一旦犹豫不决，那么这些消极的人会给社区的其他人带来不愉快的感觉。那时就会出现劣币驱逐良币的现象。 -对项目的微不足道的问题进行定期辩论会分散别人的注意力，包括你自己，要将精力几种在重要的任务上，新人如果看见这样的情景，他们可能不会加入到项目中来。 +关于项目琐碎方面的定期辩论会分散其他人（包括您）的注意力，使他们无法专注于重要任务。新人可能会看到这些对话而不想参加。 -当发现社区中有消极的行为时，要即时、公然的指出来。特别说明的是，要用坚定的语气解释他们的行为为什么是不可接受的。如果这种问题继续发生，你有必要[要求他们离开](../code-of-conduct/#enforcing-your-code-of-conduct)。你的[行为准则](../code-of-conduct/)是为这些情景准备的建设性指南。 +当发现社区中有消极的行为时，要即时、公然的指出来。特别说明的是，要用坚定的语气解释他们的行为为什么是不可接受的。如果这种问题继续发生，你有必要[要求他们离开](../code-of-conduct/#执行你们的行为守则)。你的[行为准则](../code-of-conduct/)是为这些情景准备的建设性指南。 ### 知道贡献者在哪里 随着项目的成长，好的文档会变得愈加重要。临时贡献者或路人是不可能一下子就对项目非常熟悉，一份好的文档，能够很快找到他们需要的。 -在 CONTRIBUTING 文件里，需要明确告诉新来的贡献者该如何开始。而且若是可能为了想要达到这个目的，还需要准备一个专门的部分。 +在 CONTRIBUTING 文件里，需要明确告诉新来的贡献者该如何开始。你甚至可能为此专门准备一个独立的部分：例如 [Django](https://github.com/django/django), 就提供一个专门的首页面来欢迎和指导新晋贡献者。 ![django new contributors page](/assets/images/building-community/django_new_contributors.png) -在issue列表中，缺陷的标签需要做到适合不同类型的贡献者：例如，[_"仅供入门者"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), _"优质Bug首秀"_, 或者 _"文档"_. [这些标签](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14)能够帮助新人快速浏览issues以及开始。 +在issue列表中，缺陷的标签需要做到适合不同类型的贡献者：例如，[_"仅供入门者"_](https://kentcdodds.com/blog/first-timers-only), _"优质Bug首秀"_, 或者 _"文档"_. [这些标签](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/master/.github/contributing.md)： +例如，这里是[Rubinius](https://github.com/rubinius/rubinius/)如何开始[它的贡献指南](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md)： -> 我们想感谢你们使用Rubinius。这个项目是一个充满爱的工作，我们希望所有用户查找bugs，取得性能上的提升，以及帮助完善文档。每一个贡献都是有意义的，所以感谢你们的参与。话虽如此，但我们还是要求你们遵守一些指南，这样我们就能够找到你们的issue。 +> 我们想感谢你们使用Rubinius。这个项目是一个充满爱的工作，我们希望所有用户查找bugs，取得性能上的提升，以及帮助完善文档。每一个贡献都是有意义的，所以感谢你们的参与。话虽如此，但我们还是要求你们遵守一些指南，这样我们就能够解决你们的issue。 -### Share ownership of your project +### 共享项目所有权 @@ -167,17 +164,17 @@ related: ![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) -* **在项目中添加一个贡献者或者作者文件** 用于记录每一个参与贡献的人。 +* **在项目中添加一个贡献者文件(CONTRIBUTORS) 或者作者文件(AUTHORS)** 用于记录每一个参与贡献的人。 * 如果社区有了一定的规模，那么 **发送一封信或者发表一篇博客** 感谢贡献者们。Rust的[Rust周报](https://this-week-in-rust.org/)和Hoodie的[Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)就是两个非常好的范例。 -* **给每个贡献者提交的通道。**@felixge发现这样会使大家[越发乐意斟酌他们的补丁](http://felixge.de/2013/03/11/the-pull-request-hack.html)，以及他甚至发现，在他没有工作的一段时间，项目依然有新的维护者进来。 +* **给每个贡献者提交的通道。**@felixge发现这样会使大家[越发乐意斟酌他们的补丁](https://felixge.de/2013/03/11/the-pull-request-hack.html)，以及他甚至发现，在他没有工作的一段时间，项目依然有新的维护者进来。 * 如果项目是托管在GitHub上，那么 **将项目从你们的个人账号转移到一个组织**，以及添加至少一个备份管理员。组织能让与其他人一起工作在同一个项目在变得更加容易。 事实上很多项目只有一个或者两个做大量工作的维护者。随着项目以及社区越来越大，就会有更多的人参与进来。 -虽然并不是一直都有人在回答问题，但是你可以去增加一些信号，以让他人有能够接触的机会，越是尽早开始，越是能够获得帮助。 +虽然并不是一直都有人在回答问题，但是你可以去增加一些信号，以让他人有能够加入的机会，越是尽早开始，越是能够获得帮助。 -## Resolving conflicts +## 解决冲突 在项目的早期，做决定是件蛮容易的事。几乎是想做什么就可以做什么。 @@ -206,7 +203,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)

@@ -216,14 +213,14 @@ related: ### 将你们的README视为最高法则 -README [不仅仅是一组指令](../starting-a-project/#writing-a-readme)。它也是一个谈论目标、产品愿景和路线的地方。 -如果人们过分专注于讨论特定功能的优点，它可能有助于重新审视您的README，并谈论项目的更高的愿景。关注README也会使对话变得个人化，所以可以进行建设性的讨论。 +README [不仅仅是一个简单的说明](../starting-a-project/#撰写自述文件)。它也是一个谈论目标、产品愿景和路线的地方。 +如果人们过分专注于讨论特定功能的优点，那么你可能需要重新审视您的README，并谈论项目的更高的愿景。关注README也会使对话变得个人化，所以可以进行建设性的讨论。 ### 专注过程，而不是结果 一些项目用投票的方式做重要决定。虽然看上去是明智的，投票强调的是得到一个"答案"，而不是倾听以及解决每个人的顾虑。 -投票会变成政治，社区成员在做感兴趣的事或者表决一个明确的方法时会感到压力。不是每个人都参与了投票，可能在你们的社区中[保持沉默的人占了多数](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users)，或者用户不知道投票这件事正在发生。 +投票会变成政治，社区成员在做感兴趣的事或者表决一个明确的方法时会感到压力。不是每个人都参与了投票，可能在你们的社区中[保持沉默的人占了多数](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)而不是共识本身。 @@ -234,7 +231,7 @@ README [不仅仅是一组指令](../starting-a-project/#writing-a-readme)。它 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 决策流程

@@ -261,7 +258,7 @@ Atom Issues不存在投票系统的部分原因是因为Atom团队在所有情 指导一件事朝着正确的方向发展是一门艺术。它对阻止人们浪费时间或者要求他们发表有建设性的看法没有作用。（。。。）反而，你们必须为接下来的进展给出条件：给大家一个路线，跟随一个可以得到你们想要的结果的途径，这样就不像是些无用的口头行为。

-— @kfogel, [_打造开源软件_](http://producingoss.com/en/producingoss.html#common-pitfalls) +— @kfogel, [_打造开源软件_](https://producingoss.com/en/producingoss.html#common-pitfalls)

@@ -281,6 +278,6 @@ Atom Issues不存在投票系统的部分原因是因为Atom团队在所有情 使用决策者应该是你们最后才能采取的手段。分离issues是一个你们社区成长和学习的机会。利用这些机会并精诚合作，尽量找出问题的解决方案。 -## Community is the ❤️ of open source +## 社区是开源的❤️ 健康，蓬勃的社区每周都会为开源付出大量辛勤的劳动。许多贡献者指出其他人在开源工作或不在开源工作的原因。通过学习如何建设性地利用这股力量，你们会帮助他人有一个难忘的开源体验。 diff --git a/_articles/zh-cn/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md similarity index 76% rename from _articles/zh-cn/code-of-conduct.md rename to _articles/zh-hans/code-of-conduct.md index dc76262339c..4d0478080cb 100644 --- a/_articles/zh-cn/code-of-conduct.md +++ b/_articles/zh-hans/code-of-conduct.md @@ -1,21 +1,17 @@ --- -lang: zh-cn +lang: zh-hans title: 行为准则 description: 社区的长远发展和健康成长，离不开一些行为准则，需要遵守并执行。 class: coc -toc: - why-do-i-need-a-code-of-conduct: "我为什么需要行为守则?" - establishing-a-code-of-conduct: "建立行为守则" - deciding-how-youll-enforce-your-code-of-conduct: "决定你们如何执行行为守则" - enforcing-your-code-of-conduct: "执行你们的行为守则" order: 8 image: /assets/images/cards/coc.png related: - building - leadership +redirect_from: /zh-cn/code-of-conduct/ --- -## Why do I need a code of conduct? +## 为什么我们需要行为守则？ 行为守则是一份确立项目参与者行为规范的文件。采用和执行行为守则可以帮助你们的社区营造积极的氛围。 @@ -23,9 +19,9 @@ related: 一份行为守则可以帮助你们促进健康，有建设性的社区行为。积极主动减少你们或其他人在你们的项目中变得疲劳的可能性，并帮助你们在有人做出你们不同意的事情时采取行动。 -## Establishing a code of conduct +## 建立一个行为守则 -尽可能早地建立行为守则，当你们第一次创建项目的时候。 +当你们第一次创建项目的时候，尽可能早的建立行为守则。 此外，说出你们的要求。行为守则的描述遵循如下几点： @@ -34,22 +30,22 @@ related: * 如果有人违反了行为守则会怎样？ * 大家如何举报违规 -无论你们在哪里，请使用已有的行为守则。[贡献者盟约](http://contributor-covenant.org/)是一个被超过40，000个开源项目（包括Kubernetes, Rails和Swift）所使用的行为守则。 +无论你们在哪里，请使用已有的行为守则。[贡献者盟约](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中附上其链接，这样对你们的社区是可见的。 -## Deciding how you'll enforce your code of conduct +## 决定你们如何执行行为守则 -你们应该解释如何执行行为守则在违规发生**之前**。有几点理由说明为什么这么做： +你们应该在违规发生**之前**解释如何执行行为守则。有几点理由说明为什么这么做： * 必要的时候，它表示你们处事认真谨慎。 @@ -59,21 +55,21 @@ 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/)（你们是否需要如此详细的手册，这取决于你们的项目）。 -## Enforcing your code of conduct +## 执行你们的行为守则 有时，尽管你们尽了最大的努力，仍然会有人违反守则。当这样的情况发生时，有几种方法来解决消极或有害的行为。 ### 搜集有关违规的信息 -认真对待社区中每个成员的想法。如果你们收到有人违规的报告，请认真对待并调查此事，即使它不符合你们自己的经验。这样做可以向你们的社区表面，你们珍视他们的观点和信任他们的判断。 +认真对待社区中每个成员的想法。如果你们收到有人违规的报告，请认真对待并调查此事，即使它不符合你们自己的经验。这样做可以向你们的社区表明，你们珍视他们的观点和信任他们的判断。 -有的社区成员可能是让大家一直不舒服的惯犯，或者他们只是说了或做了一次。这都需要依据实际情况进行处理。 +有的社区成员可能是让大家一直不舒服的惯犯，或者他们只是初犯。这都需要依据实际情况进行处理。 在你们做出回应之前，请认真思考发生了什么事。通过阅读他们过去的评论和对话可以更好地理解他们为什么要那样做。尽量收集其他人对他们行为的看法。 @@ -86,9 +82,9 @@ related: ### 采取适当的行动 -当搜集和处理足够的信息后，你们需要决定做什么。当你们在考虑下一步的时候，请牢记你们的目的是营造一个安全，尊重和协作的社区氛围。不仅要考虑如何处理有问题的情况，还要考虑们的反应将如何影响你们社区的其他行为和期望。 +当搜集和处理足够的信息后，你们需要决定做什么。当你们在考虑下一步的时候，请牢记你们的目的是营造一个安全，尊重和协作的社区氛围。不仅要考虑如何处理有问题的情况，还要考虑你们的反应将如何影响你们社区的其他行为和期望。 -当有人报告违规时，处理它是你们的工作，而不是他们的。有时，报告者透露他们的信息会给他们的职业生涯，声誉和人生安全带来很大的风险。迫使报告者面对骚扰者会将他们置于妥协的位置。除非报告者有特别的要求，你们应该直接和有问题的人沟通。 +当有人报告违规时，处理它是你们的工作，而不是他们的。有时，透露报告者本人的信息会给他们的职业生涯，声誉和人生安全带来很大的风险。迫使报告者面对骚扰者会将他们置于妥协的位置。除非报告者有特别的要求，你们应该直接和有问题的人沟通。 这里有些方法帮助你们回应违规行为： @@ -110,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 64% rename from _articles/zh-cn/getting-paid.md rename to _articles/zh-hans/getting-paid.md index a8f3f438f7e..81803ba7cb9 100644 --- a/_articles/zh-cn/getting-paid.md +++ b/_articles/zh-hans/getting-paid.md @@ -1,27 +1,23 @@ --- -lang: zh-cn +lang: zh-hans title: 通过为开源工作获得报酬 -description: 为了让你能够持续的为开源项目，理应得到相应的经济上的报酬。 +description: 为了让你能够以开源方式维持工作，理应得到相应的经济上的报酬。 class: getting-paid -toc: - why-some-people-seek-financial-support: "为何会有人寻求经济上的支持" - funding-your-own-time: "你的时间是最宝贵的，理应得到资助" - finding-funding-for-your-project: "为你的项目寻找资助" - building-a-case-for-financial-support: "建立经济上的支持" order: 7 image: /assets/images/cards/getting-paid.png related: - best-practices - leadership +redirect_from: /zh-cn/getting-paid/ --- -## Why some people seek financial support +## 为何有人需要寻找经济上支持 很多开源的工作都是来自志愿者的辛勤付出。例如，有些人在使用项目的过程中遇到了问题，然后快速的修复了；也有些人是利用他们的业余时间在开源项目中需求挑战。 -如果你实在无法在当前的雇主下开展相关开源的工作，那么是该考虑换老板的时候，应到找个支持想开源作贡献的老板！寻找那些致力于开源工作的公司。比如： +如果你实在无法在当前的雇主下开展相关开源的工作，那么是到了该考虑换老板的时候，应到找个支持想为开源作贡献的老板！寻找那些致力于开源工作的公司。比如： * [Ghost](https://ghost.org/) 就是一家围绕很多[开源项目](https://github.com/tryghost/ghost)的好公司 -* [Rackspace](https://www.rackspace.com/en-us) 甚至为其员工提供了[贡献开源守则](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/) 那些大公司发起的项目，如 [Go](https://github.com/golang) 或 [React](https://github.com/facebook/react)，均希望雇佣到优秀的工程师来为他们工作。 当然最终还是要看你自身的条件而定，你甚至可以利用你的开源项目来独立的进行融资。这边就有几个案例： -* @gaearon 通过 [Patreon crowdfunding campaign](http://redux.js.org/)为他的项目 [Redux](https://github.com/reactjs/redux)成功的融到了资金。 -* @andrewgodwin [通过 Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 为Django schema 迁移拿到了资金 +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) +* @gaearon 通过 [Patreon crowdfunding campaign](https://redux.js.org/) 为他的项目 [Redux](https://github.com/reactjs/redux) 成功的融到了资金。 +* @andrewgodwin [通过 Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 为 Django schema 迁移拿到了资金 -## Finding funding for your project +## 为你的项目募资 除了针对个人贡献者的建议之外，还有一些项目可以从公司、独立投资方、以及其它的资金处来获得进一步的工作。 @@ -118,18 +106,17 @@ related: 一些获得组织资助的项目案例： * **[webpack](https://github.com/webpack),** [通过 OpenCollective](https://opencollective.com/webpack) 从公司和个人来筹集资金 -* **[Vue](https://github.com/vuejs/vue),** 由 @yyx990803 创建，[通过 Patreon](https://github.com/open-source/stories/yyx990803)获得资助 * **[Ruby Together](https://rubytogether.org/),** 由 @indirect 创建的非盈利组织 ，为诸如 [bundler](https://github.com/bundler/bundler)、[RubyGems](https://github.com/rubygems/rubygems)、以及其它的一些 Ruby 的基础设施项目提供资金支持 -尽管开源日渐的流行，但是为项目寻找资金仍然是处于试验中。目前所收集到的包括： +尽管开源日渐的流行，但是为项目寻找资金仍处于试验阶段。目前所收集到的包括： * **通过大力宣传活动或募捐，为您的工作筹集资金** 这策略在你拥有足够的粉丝，或者是已经社区声誉良好的情况下，又或者是项目非常的受欢迎，等情况下有效。 -* **接受基金巨头的资助** 一些软件基金会和公司为开源的相关工作提供很好的机会，如[Python 软件基金会](https://www.python.org/psf/grants/), [Mozilla 基金会](https://www.mozilla.org/en-US/grants/)、以及[Stripe](https://stripe.com/blog/open-source-retreat-2016). +* **接受基金巨头的资助** 一些软件基金会和公司为开源的相关工作提供很好的机会，如 [Python 软件基金会](https://www.python.org/psf/grants/), [Mozilla 基金会](https://www.mozilla.org/en-US/grants/)、以及 [Stripe](https://stripe.com/blog/open-source-retreat-2016)。 * **获得公司或独立投资商的赞助** 通过软件基金会，或者是干脆 **创业** 来支撑项目。 更多的案例和细节， @nayafia [专门写过一个指南](https://github.com/nayafia/lemonade-stand) ，专门针对的就是如何为开源工作获得报酬。不同类型的资助需要不同的技能，所以仔细的掂量下资格，然后找个最适合自己的方式。 -## Building a case for financial support +## 获取商业支持 无论你的项目是新的创意，还是已经运行多年，你都需要为你的资助者满意，并提出有效而合理的案例。 @@ -145,24 +132,24 @@ related: ### 充分利用资助者的价值 -资助者，无论他是雇佣你的老板，还是一家获得授权的基金会，你都有机会和他们频繁的进行接触。 他们为什么会放弃其它机会而去支持你的项目？他们个人有何好处？ +资助者，无论他是雇佣你的老板，还是一家获得授权的基金会，你都有机会和他们频繁的进行接触。 他们为什么会放弃其它机会而去支持你的项目？对他们个人有何好处？ ### 利用风投 -您将如何用拟议的资金完成什么？专注于项目里程碑或成果，而不是支付工资。 +您将如何分配拟议的资金？专注于项目里程碑或成果，而不是支付工资。 ### 你将以何种方式接受资助 -资助者是否有关于宣传的额外需求？例如，你可能需要您可能需要成为非盈利组织或拥有非营利性财政赞助商。又或者是资助者必须给到个人而不是一个组织。这些不同的需求会因为不同的资助者而异，所以请事先做好准备。 +资助者是否有关于宣传的额外需求？例如，你可能需要成为非盈利组织或拥有非营利性财政赞助商，又或者是资助者必须给到个人而不是一个组织。这些不同的需求会因为不同的资助者而异，所以请事先做好准备。 -## Experiment and don't give up +## 持续尝试不言放弃 -赚更多的钱不是件容易的事情，无论你是在开源项目，亦或是在非盈利组织，又或者是软件的创业公司，但是无论在哪里，挣更多钱的秘密就是更多的创造力。当确定了你想如何获得报酬的时候，请继续你的研究，将自己放在投资人的角度来看问题，可以帮助你更好的构建一个更加令人信服的赚钱之道。 +赚更多的钱不是件容易的事情，无论你是在开源项目，亦或是在非盈利组织，又或者是软件创业公司，但是无论在哪里，挣更多钱的秘密就是更多的创造力。当确定了你想如何获得报酬的时候，请继续你的研究，将自己放在投资人的角度来看问题，可以帮助你更好的构建一个更加令人信服的赚钱之道。 diff --git a/_articles/zh-cn/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md similarity index 57% rename from _articles/zh-cn/how-to-contribute.md rename to _articles/zh-hans/how-to-contribute.md index 643c74aa7aa..471aa8210e1 100644 --- a/_articles/zh-cn/how-to-contribute.md +++ b/_articles/zh-hans/how-to-contribute.md @@ -1,27 +1,21 @@ --- -lang: zh-cn +lang: zh-hans title: 如何为开源做贡献 -description: 想为开源贡献力量？本指南针为"菜鸟"和初学者而准备！ +description: 想为开源贡献力量？本指南为"菜鸟"和初学者而准备！ class: contribute -toc: - why-contribute-to-open-source: "为何要为开源贡献力量？" - what-it-means-to-contribute: "贡献的具体含义是什么" - orienting-yourself-to-a-new-project: "根据项目定位自我" - finding-a-project-to-contribute-to: "寻找打算做贡献的项目" - how-to-submit-a-contribution: "如何提交成果" - what-happens-after-you-submit-a-contribution: "在提交完之后需要善后事宜" order: 1 image: /assets/images/cards/contribute.png related: - beginners - building +redirect_from: /zh-cn/how-to-contribute/ --- -## Why contribute to open source? +## 为什么要为开源做贡献? -## Which open source license is appropriate for my project? +## 我的项目适合什么样的开源许可？ -如果你们是小白，那么使用[MIT License](https://choosealicense.com/licenses/mit/)，不容易出错。它很短，很容易理解，并允许任何人做任何事情，只要他们保留许可证的副本，包括你们的版权声明。如果你们需要，您们能够根据不同的许可协议发布项目。 +如果你们是从头开始的，那么使用[MIT License](https://choosealicense.com/licenses/mit/)，不容易出错。它很短，很容易理解，并允许任何人做任何事情，只要他们保留许可证的副本，包括你们的版权声明。如果你们需要，您们能够根据不同的许可协议发布项目。 -然而，为项目选择合适的开源许可协议这取决于你们。 +否则，为项目选择合适的开源许可协议，取决于你们的目标。 你们的项目非常可能有（或将有）**依赖**。例如，如果你们开源了一个Node.js的项目，你们将可能使用来自npm（Node Package Manager）的库。你们依赖的这些库都有它们自己的开源许可协议。如果他们的许可协议"允许"（对使用，修改和分享给予公共权限，而对有关项目的许可协议没有要求），这样你们就可以使用任何你们想要的许可协议。共同允许许可协议包括MIT，Apache 2.0，ISC和BSD。 -另一方面，如果你们的依赖中有一个的许可协议是"强硬的copyleft"（他们也给同样的允许，但条件是有关项目得使用同样的许可协议），那么你们的项目将使用与之相同的许可协议。copyleft许可协议包括GPLv2，GPLv3和AGPLv3。 +另一方面，如果你们的依赖中有一个的许可协议是"强硬的copyleft"（也给予公众相同的权限，但条件是有关项目得使用同样的许可协议），那么你们的项目将必须使用与之相同的许可协议。copyleft许可协议包括GPLv2，GPLv3和AGPLv3。 -你们也会想到考虑希望你们的社区使用以及贡献你们的项目： +你们也会想要考虑你们希望的社区使用以及为你们的项目做贡献： -* **你们是否想让你们的项目成为其它项目的依赖？**在你们的相关社区最好尽可能使用最流行的许可协议。例如，[MIT](https://choosealicense.com/licenses/mit/)是[npm libraries](https://libraries.io/npm)使用的最流行的许可协议。 +* **你们是否想让你们的项目成为其它项目的依赖？**在你们的相关社区最好尽可能使用最流行的许可协议。例如，[MIT](https://choosealicense.com/licenses/mit/)是[npm libraries](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/)适合你们。 -你们的公司可能为自己的项目准备了特定的许可协议。例如，它可能需要许可许可证，以便公司可以在公司的闭源产品中使用你们的项目。或者你们的公司要求强大的copyleft许可协议同时要求贡献者赞成，这样项目只属于你们公司，没有人能在有关的软件中使用你们的项目。或者你们的公司可能有与标准，社会责任或透明度相关的某些需求，其中任何一个都可能需要特定的许可策略。与你们[公司的法律部门](#what-does-my-companys-legal-team-need-to-know)谈谈。 +你们的公司可能为自己的项目准备了特定的许可协议。例如，它可能需要宽松的许可证，以便公司可以在公司的闭源产品中使用你们的项目。或者你们的公司要求严格的copyleft许可协议和一份附加的贡献者协议，以便除了你们公司以外，没有人能在封闭源代码的软件中使用你们的项目。或者你们的公司可能有与标准，社会责任或透明度相关的某些需求，其中任何一个都可能需要特定的许可策略。与你们[公司的法律部门](#公司的法律团队需要知道什么)谈谈。 -当你们在GitHub上创建了一个新项目，它给你们提供了选择许可协议的机会。包括上面提到的可以使你们的GitHub项目开源的许可协议。如果你们想要了解其他选择，可以通过查阅[choosealicense.com](https://choosealicense.com)找到适合你们项目（即使它[不是软件](https://choosealicense.com/non-software/)）的许可协议。 +当你们在GitHub上创建了一个新项目，它给你们提供了选择许可协议的选项。包括上面提到的可以使你们的GitHub项目开源的许可协议。如果你们想要了解其他选择，可以通过查阅[choosealicense.com](https://choosealicense.com)找到适合你们项目（即使它[不是软件](https://choosealicense.com/non-software/)）的许可协议。 -## What if I want to change the license of my project? +## 如果我想修改开源许可该怎么办？ 大多数项目绝不需要更换许可协议。但是情况偶尔有变。 例如，随着你们项目的壮大，它添加了新的依赖或用户，或者你们的公司改变了策略，或者其他的要求要更换不同的许可协议。如果你们在开始项目的时候没有添加许可协议，那么再添加一个许可协议和更换许可协议是一样的效果。当你们要添加或者更换项目的许可协议时，需要考虑以下三件事： -**这件事很复杂。**确定许可协议的兼容性和合规行，以及谁拥有版权，这会非常快速地变得复杂和混乱。为新的发布和贡献选择一个新的且合适的许可协议与重新许可已存在的贡献是不同的。一旦你们有任何想改变许可协议的想法，请首先让法律团队知道。即使你们已经或者能获得可以更换许可协议的权限，请考虑者会给项目的其他用户和贡献者带来怎样的影响。将更换许可协议视为"管理事件"，只有通过与项目的利益相关者进行明确的沟通和咨询，才更有可能顺利进行。请谨记，从一开始就为你们的选择和使用合适的许可协议。 +**这件事很复杂。**确定许可协议的兼容性和合规性，以及谁拥有版权，这会非常快速地变得复杂和混乱。为新的发布和贡献选择一个新的且合适的许可协议与重新许可已存在的贡献是不同的。一旦你们有任何想改变许可协议的想法，请首先让法律团队知道。即使你已经或可以获得项目版权所有者的许可证更改许可，请考虑更改对项目的其他用户和贡献者的影响。将更换许可协议视为"管理事件"，只有通过与项目的利益相关者进行明确的沟通和咨询，才更有可能顺利进行。请谨记，从一开始就为你们的选择和使用合适的许可协议。 **你们的项目已经有了许可协议。**如果项目的现有许可证与您要更改的许可证兼容，则可以开始使用新许可证。这是因为如果A许可协议与B许可协议兼容，你们将遵守A的条款，同时遵守B的条款（但不一定反之亦然）。因此，如果你们目前正在使用许可型的许可协议（例如MIT），则可以更改为具有更多条件的许可协议，只要你们保留MIT许可协议的副本和任何相关的版权声明（即继续遵守MIT许可协议的最低条件）。如果你们现在的许可协议不是许可型的（例如，copyleft或者你们还没有许可协议）以及你们不是版权的唯一所有者，那么你们不能将许可协议改为MIT。基本上，只要是使用的许可型的许可协议，版权所有者能事先更换许可协议。 -**你们的项目已经有版权所有者。**如果你们是你们项目的唯一贡献者，然后你们或者你们的公司是项目版权的唯一所有者。你们可以添加或更换任何你们或者你们公司心仪的许可协议。不然你们需要取得其他版权所有者的同意。他们是谁？他们是已经参与你们项目提交的人。但有些情况是项目版权掌握在这些人的雇主手中。在某些情况下，人们只是做了_微小的_贡献，但没有硬性规定，在一些行代码下的贡献不受版权保护。对与这样的情况该怎么办？对于一个相对较小以及年轻的项目来说，取得所有贡献者对更换许可协议的同意是可行的。。但对于大项目和老项目来说，你们必须寻求很多贡献者以及他们继承者的共识。Mozilla花费了多年重新授权Firefox，Thunderbird和相关软件。 +**你们的项目已经有版权所有者。**如果你们是你们项目的唯一贡献者，然后你们或者你们的公司是项目版权的唯一所有者。你们可以添加或更换任何你们或者你们公司心仪的许可协议。不然你们需要取得其他版权所有者的同意。他们是谁？他们是已经参与你们项目提交的人。但有些情况是项目版权掌握在这些人的雇主手中。在某些情况下，人们只是做了_微小的_贡献，但没有硬性规定，在一些行代码下的贡献不受版权保护。对与这样的情况该怎么办？对于一个相对较小以及年轻的项目来说，取得所有贡献者对更换许可协议的同意是可行的。但对于大项目和老项目来说，你们必须寻求很多贡献者以及他们继承者的共识。Mozilla花费了多年(2001-2006)重新授权Firefox，Thunderbird和相关软件。 或者，你们可以让贡献者事先同意（通过额外的贡献者协议 - 见下文）在某些条件下更改某些许可协议，这些更改将超过现有的开源许可协议。这会改变许可协议改的复杂性。如果在执行许可协议更改时，你们仍然想要和项目利益相关者进行沟通，你们需要从你们律师那得到更多帮助。 -## Does my project need an additional contributor agreement? +## 我们的项目需要额外的贡献者协议吗？ -可能不要。对于大多数的开源项目，一个开源许可协议可作用与所有贡献者和用户。 +可能不要。对于大多数的开源项目，一个开源许可协议可作用于所有贡献者和用户。 贡献者协议会给维护者带来额外的管理工作。这些协议增加了多少工作得取决去项目和实施。简单的协议可能要求贡献者确认和点击，在项目的开源许可协议下他们有权利贡献。更复杂的协议可能需要法律的审查和贡献者的雇主的签字。 @@ -107,52 +99,52 @@ related: avatar 我们已经删除了Node.js的CLA。这样做降低了Node.js贡献者的参与门槛，从而吸引更多的贡献者。

-— @bcantrill, ["Broadening Node.js Contributions"](https://www.joyent.com/blog/broadening-node-js-contributions) +— @bcantrill, ["Broadening Node.js Contributions"](https://www.tritondatacenter.com/blog/broadening-node-js-contributions)

一些情况下你们可能想要为你们的项目考虑一个额外的贡献协议： -* 你们的律师想要所有的贡献者明确接受贡献者条款，或者因为他们觉得只有开源许可协议还远远不够。如果这是唯一的问题，那么有肯定项目开源许可协议的贡献者协议就足够了。[jQuery个人贡献者许可协议](https://contribute.jquery.org/CLA/)就是一个很好的轻量级的个人贡献者协议。对于一些项目来说，[Developer Certificate of Origin](https://github.com/probot/dco)是一个很好的先择。 +* 你们的律师想要所有的贡献者明确接受贡献者条款，或者因为他们觉得只有开源许可协议还远远不够。如果这是唯一的问题，那么有肯定项目开源许可协议的贡献者协议就足够了。[jQuery个人贡献者许可协议](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/)就是一个很好的轻量级的个人贡献者协议。对于一些项目来说，[Developer Certificate of Origin](https://github.com/probot/dco)是一个很好的先择。 * 你们的项目使用的开放源许可协议不包括明确的专利授权（如MIT），你们需要所有贡献者的专利授权，这些可能适合用于你们公司的专利组合或者项目的其他贡献者和用户。[Apache 个人贡献者许可协议](https://www.apache.org/licenses/icla.txt)是一种常用的附加贡献者协议，其具有与Apache许可2.0中的专利许可相同的专利许可。 * 如果你们的项目使用的是copyleft许可协议，但你们也需要分发项目的专有版本。那你们需要每个贡献者分配版权给你们或者授予你们许可权。[MongoDB贡献者协议](https://www.mongodb.com/legal/contributor-agreement)就是这中类型的。 * 你们认为你们的项目在其有效期内需要更换许可协议，以及事先得到贡献者的同意。 -如果您们实需要在您的项目中使用额外的贡献者协议，请考虑使用诸如CLA助手之类的集成，以最大限度地减少贡献者的分心。 +如果你的项目确实需要使用额外的贡献者协议，请考虑使用[CLA助手](https://github.com/cla-assistant/cla-assistant)等集成来最大限度地减少贡献者分心。 -## What does my company's legal team need to know? +## 公司的法律团队需要知道什么？ 作为一名公司的雇员，如果你们在发布一个开源项目，你们首先需要让法律团队知道。 -即使只是一个个人项目，请考虑让他们知道。你们可能和公司有一个"员工知识产权协议"，这给了公司一些对你们项目的控制权，特别是当项目和公司的业务有着很多的联系或者你们使用公司的资源发展项目。你们的公司_应该_很容易给们许可，也许已经通过一个员工友好的知识产权协议或公司政策。如果不是这样，你么可以谈判（例如，解释你们的项目为公司的专业学习和发展目标服务），或者你们在找到一个更好的公司前停止你们项目的工作。 -**如果你们的开源项目是为了你们的公司，**者绝对需要让他们知道。根据公司的业务需求和专业知识，你们的法律团队可能已经制定了有关开放源代码许可协议（以及可能还有其他贡献者协议）的政策，以确保您的项目符合其依赖关系的许可协议。如果不是这样，你们和他们很幸运！你们的法律团队应该渴望与你们合作，把这个东西搞清楚。你们需要思考这些事： +即使是个人项目，请考虑让他们知道。你们可能和公司有一个"员工知识产权协议"，这给了公司一些对你们项目的控制权，特别是当项目和公司的业务有着很多的联系或者你们使用公司的资源发展项目。你的公司 _应该_ 很容易地给你许可，也许已经通过一个员工友好的知识产权协议或公司政策。如果不是这样，你们可以谈判（例如，解释你们的项目为公司的专业学习和发展目标服务），或者在你们找到一个更好的公司前停止该项目的工作。 -* **第三方资源：**你们的项目有其他人创建的依赖或者使用他人的代码？如果这些事开源项目，你们需要遵守第三方资源的开源许可协议。首先，选择与第三方资源的开放源许可协议一起使用的许可协议（见上文）。如果你们的项目修改或者发布第三方开源资源，那么你们法律团队还想知道你们符合第三方开源许可协议的其他条件，例如保留版权声明。如果你们使用了其他没有开源许可协议的代码，那么你们可能会要求第三方资源的维护者[添加一个开源许可协议](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.linux.com/blog/why-companies-use-open-source-need-compliance-program)可以避免麻烦，产品延迟发布和诉讼。 +* **合规性：**即使你们公司没有发布任何开源项目，他们也会使用别人的开源软件。[意识和过程](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻烦，产品延迟发布和诉讼。 -## Maintainer activity +## 维护者活动情况 最后，你还需要确定一件事，那就是维护者有足够的能力和时间处理社区的贡献。最后一个问题你要问自己的是：_我是不是对社区有足够的时间和精力来响应？_ @@ -124,9 +119,9 @@ related: * 一个issue保持打开状态的时间（也就代表一个问题保持没有被解决状态的时间）。 * 一个issue是否因为一个PR得到了解决。 -* 陈旧的iuuse是否被关闭了（被解决的问题应该关闭）。 +* 陈旧的issue是否被关闭了（被解决的问题应该关闭）。 * 合并一个PR的时间。 -## Use 📊 to learn about people +## 通过统计 📊 来了解人们的习惯 理解一些细节能够帮助你建设活跃的、成长的开源项目。哪怕是你无法追踪每一个细节，通过使用上述的框架，将能够让你集中精力到该用力的地方，进而助项目成功！ diff --git a/_articles/zh-hans/security-best-practices-for-your-project.md b/_articles/zh-hans/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..7d9e67c4843 --- /dev/null +++ b/_articles/zh-hans/security-best-practices-for-your-project.md @@ -0,0 +1,83 @@ +--- +lang: zh-hans +title: 项目安全最佳实践 +description: 从多因素认证和代码扫描，到安全的依赖管理和私人漏洞报告，通过这些必要安全实践建立信任，为项目长远发展保驾护航。 +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +抛开缺陷（bug）和新特性不谈，一个项目能否长久发展，不仅取决于其实用性，更在于它能否赢得用户的信任。而强有力的安全措施，正是维系这份信任的关键。以下是一些可以显著提高项目安全性的重要举措。 + +## 确保所有特权贡献者都启用了多因素认证 + +### 一旦恶意攻击者成功冒充特权贡献者，后果将不堪设想。 + +获得特殊访问权限后，攻击者便可以篡改代码使其执行恶意操作（例如挖掘加密货币），或向项目用户的基础设施分发恶意软件，抑或访问私有代码仓库（repository）以窃取知识产权及敏感数据（包括其他服务的凭证）。 + +多因素认证（Multi-Factor Authentication）为账户安全增加了一道防线。一经启用，除了用户名和口令（password），您还需要额外提供一种您独有的身份认证信息，才能完成登录。 + +## 将代码安全纳入开发流程 + +### 比起投入生产环境后才发现代码中的安全漏洞，在流程早期就检测到的话，修复成本要低得多。 + +使用静态应用安全测试（Static Application Security Testing）工具来检测您代码中的安全漏洞。这类工具在代码层面运行，无需执行环境，因此可以在开发初期就使用，也可以在构建阶段或代码审查阶段无缝集成到您平时的开发流程中。 + +这就像有位安全专家在您编写代码时检查您的代码仓库，帮您发现那些看似平常、实则暗藏风险的常见安全漏洞。 + +如何选择适合您的静态应用安全测试工具？ + +* 查看许可证：有些工具对开源项目免费，例如 GitHub CodeQL 或 SemGrep。 +* 检查是否支持您使用的所有语言。 +* 优先选择能轻松与您使用的其他工具和现有流程集成的工具。例如，将警报信息直接显示在现有代码审查流程或工具中，就比切换到另一个工具来查看要好。 +* 注意误报率！您一定不希望被无缘无故地拖慢进度！ +* 关注不同工具的特殊功能：有些工具非常强大，支持污点追踪（如 GitHub CodeQL），有些则可以提供 AI 生成的修复建议，还有些能让您更轻松地编写自定义规则。 + +## 莫将秘密公之于众 + +### API 密钥、令牌、口令等敏感信息有时会被不小心提交到仓库中。 + +想象这样一个场景：您维护着一个由全球开发者贡献的热门开源项目。有一天，一位贡献者无意中将某第三方服务的 API 密钥提交到了仓库。几天后，有人发现了这些密钥，并通过它们非法访问了该服务。服务被攻陷，用户遭遇业务中断，项目名誉受损。作为维护者，您面临艰巨的任务：撤销泄露的密钥，调研攻击者还可能利用这些密钥作出哪些恶意行为，通知受影响的用户并修复问题。 + +正是为了避免这样的事故，才有了机密扫描方案，帮您检测代码中的敏感信息。像 GitHub Secret Scanning 和 Truffle Security 的 Trufflehog 这样的工具可以避免您将敏感信息推送到远程分支，防患于未然，还有一些工具则可以自动撤销已泄露的信息。 + +## 检查和更新依赖项 + +### 项目中的依赖项可能存在漏洞，从而危及整个项目的安全，而手动更新耗时费力。 + +想象一下，一个项目建立于某个基础坚实且被广泛使用的库上，该库后来发现了一个重大安全问题，但项目开发者对此却毫不知情。攻击者利用了这一点，潜入并窃取了项目用户们暴露无遗的敏感数据。这并非危言耸听，这正是 2017 年臭名昭著的 Equifax 数据泄露事件的情况：他们在收到 Apache Struts 存在高危漏洞的通知后未能及时更新依赖项，最终导致 1.44 亿用户数据被攻击者盗走。 + +想要避免类似悲剧，可以使用软件成分分析工具（Software Composition Analysis）工具，如 Dependabot 和 Renovate，它们会自动检查项目依赖项中是否有已经发布在公开数据库（如 NVD 或 GitHub Advisory Database）上的已知漏洞，并自动创建拉取请求来将其更新到安全版本。保持依赖项在最新安全版本，可以保护项目免受潜在风险的威胁。 + +## 通过保护分支避免不必要的更改 + +### 不限制对主分支的访问权限，可能导致意外或恶意的改动，从而引入漏洞或破坏项目稳定性。 + +一位初来乍到的贡献者获得了主分支的写入权限，结果不小心推送了未经测试的更改，一个严重的安全漏洞随之暴露。为防止此类问题，分支保护规则会确保未经审查或未通过指定状态检查的改动不会被合并到重要的分支上。有了这道额外安全保障，您的项目将会更加安全可靠，永远保持最高质量。 + +## 建立漏洞报告接收机制 + +### 方便用户报告缺陷固然是好事，但关键问题在于：如果该缺陷涉及安全问题，如何让用户安全地报告，而不使项目招致攻击？ + +想象一下，一位安全研究员发现了您项目中的漏洞，但由于找不到一个明确或安全的方法来报告，无奈之下，他可能就会创建一个公开的议题（issue）或在社交媒体上公开讨论该漏洞。即便他们是出于好意并提供了修复方案，但只要他们是通过公开的拉取请求来修复，其他人就会在更改合并之前看到它。这会导致在您还没来得及修复该漏洞时，就将其暴露给恶意攻击者，从而可能招致零日攻击，危及项目和用户。 + +### 安全策略 + +为避免这种情况，请发布安全策略（security policy）。安全策略一般定义在 `SECURITY.md` 文件中，用于详细说明报告安全问题的步骤，创建透明的协调披露流程，并明确项目团队处理所报告的问题之责任。安全策略可以简单到这样一句话："请不要在公开议题或拉取请求中公布漏洞细节，请发送私密邮件到 security@example.com"，当然也可以包含更多细节，比如用户何时能收到回复。任何有助于提高披露流程有效性和效率的内容都可以纳入其中。 + +### 私人漏洞报告 + +在一些平台上，您可以通过私密议题来进一步简化并强化漏洞管理流程，从接收到发布。在 GitLab 上，这可以通过保密议题（confidential issue）来实现。而在 GitHub 上，这称为私人漏洞报告（Private Vulnerability Reporting）。私人漏洞报告让维护者能够在 GitHub 平台内完成接收和处理漏洞报告的整个过程。GitHub 会自动创建私有复刻（fork）用于修复漏洞，并起草安全公告。所有这些都将保密，直到您决定披露问题并发布修复。随后，安全公告将会发布，通知所有用户，并通过他们的软件成分分析工具保护他们。 + +## 结论：您的几小步，用户安全的一大步 + +这些步骤对您来说可能很简单或很基础，却能在很大程度上提高项目的安全性，为用户筑起一道抵御最常见的威胁的坚实防线。 + +## 贡献者 + +### 非常感谢所有为本文分享经验和建议的维护者！ + +本文由 [@nanzggits](https://github.com/nanzggits) 和 [@xcorail](https://github.com/xcorail) 撰写，并得到以下贡献者的支持： + +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) 等众多同仁！ diff --git a/_articles/zh-cn/starting-a-project.md b/_articles/zh-hans/starting-a-project.md similarity index 80% rename from _articles/zh-cn/starting-a-project.md rename to _articles/zh-hans/starting-a-project.md index 3d9ce5fde76..20fff338b81 100644 --- a/_articles/zh-cn/starting-a-project.md +++ b/_articles/zh-hans/starting-a-project.md @@ -1,34 +1,29 @@ --- -lang: zh-cn -title: 开启一个开源项目 +lang: zh-hans +title: 开始一个开源项目 description: 从开源的世界汲取智慧，然后开始准备着手发起开源项目。 class: beginners -toc: - the-what-and-why-of-open-source: "什么是开源，为什么要开源" - should-i-launch-my-own-open-source-project: "我有必要去发起开源项目?" - launching-your-own-open-source-project: "发起自己的开源项目" - naming-and-branding-your-project: "为项目命名及设立品牌" - your-pre-launch-checklist: "发起项目之前的检查项" order: 2 image: /assets/images/cards/beginner.png related: - finding - building +redirect_from: /zh-cn/starting-a-project/ --- -## The "what" and "why" of open source +## 什么是开源，为什么要开源 -所以你在考虑开始参与开源？恭喜！世界赞赏你的贡献。让我们来谈谈开源是什么，以及人们这样做。 +如果你正在考虑开始参与开源，那么恭喜你！世界会感激你的贡献。首先我们来谈谈什么是开源以及为什么我们要开源。 ### "开源"是什么意思？ 当一个项目被开源，这意味着**任何人都可以出于任何目的查看，使用，修改和分发你的项目**。 这些权限通过[开源许可](https://opensource.org/licenses)强制实施。 -开源是强大的，因为它降低了事物被采纳的障碍，允许想法迅速传播。 +开源是强大的，因为它降低了事物被采纳的障碍，使得我们的想法可以被迅速传播。 -要了解它的工作原理，想象你的朋友组织了一场聚餐，而你带去了一个樱桃派。 +接下来我们通过一个例子了解它的工作原理。想象你的朋友组织了一场聚餐，而你带去了一个樱桃派。 -* 每个人都尝了那个派（_使用_) +* 每个人都尝了那个派（_使用_） * 派的味道棒极了！大家请你分享它的配方（_view_） * 一个叫 Alex 的朋友是个糕点师，他建议少放点糖（_modify_） * 一个叫 Lisa 的朋友想要用它作为下周的晚餐（_distribute_） @@ -41,31 +36,31 @@ related: avatar 我从开源使用和协作中获得的最有价值的经验之一，就是在我面临许多与其他开发人员相同问题的过程中所建立的联系。

- — @kentcdodds, ["参与开源对我来说太棒了"](https://medium.com/@kentcdodds/how-getting-into-open-source-has-been-awesome-for-me-8480cd756a80#.pjt9oqp4w) + — @kentcdodds, ["参与开源对我来说太棒了"](https://kentcdodds.com/blog/how-getting-into-open-source-has-been-awesome-for-me)

-个人或组织为何想要开源一个项目，[有各种各样的的原因](http://ben.balter.com/2015/11/23/why-open-source/)，例如： +个人或组织为何想要开源一个项目，[有各种各样的的原因](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) 的现有项目。 +* **采用和重组：** 任何人几乎可以出于任何目的使用开源项目。人们甚至可以使用它来构建其他东西。例如，[WordPress](https://github.com/WordPress) 就是派生自一个名为 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) 的现有项目。 -* **透明度：** 任何人都可以检查开源项目是否有错误或不一致。 透明度对[保加利亚](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美国](https://sourcecode.cio.gov/)等政府，银行或医疗保健等受监管行业以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全软件都很重要。 +* **透明度：** 任何人都可以检查开源项目是否有错误或不一致。 透明度对[保加利亚](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美国](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/)等政府，银行或医疗保健等受监管行业以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全软件都很重要。 -开源并不仅仅限于软件。您可以开源任何事物，从数据集到书本。查看 [GitHub Explore](https://github.com/explore) 开找找有什么是你可以开源的。 +开源并不仅仅限于软件。您可以开源任何事物，从数据集到书本。查看 [GitHub Explore](https://github.com/explore) 来找找有什么是你可以开源的。 ### 开源是指"免费"吗？ -开源最大的吸引之一是它不花钱。 但是，"免费"只是开源的总体价值的一个副产品。 +开源最大的吸引之一是它不花钱。 但是，"免费"只是开源的总体价值的一小部分。 -因为[开源许可证要求](https://opensource.org/osd-annotated)任何人可以几乎出于任何目使用，修改和共享您的项目，项目本身往往是免费的。 如果该项目花钱使用，任何人也都可以合法地复制和使用免费版本。 +因为[开源许可证要求](https://opensource.org/osd-annotated)任何人可以几乎出于任何目的使用，修改和共享您的项目，项目本身往往是免费的。 如果该项目花钱使用，任何人也都可以合法地复制和使用免费版本。 因此，大多数开源项目是免费的，但"免费"不是开源定义的一部分。 有些方法可以通过双重许可或有限功能间接地为开源项目收费，同时仍然遵守开源的官方定义。 -## Should I launch my own open source project? +## 我应该开始自己的开源项目吗？ -简单来说，答案是肯定的，因为无论结果如何，启动您自己的项目来了解开源的工作原理是一个好方法。 +简单来说，答案是肯定的，因为无论结果如何，开始一个您自己的开源项目来了解开源的工作原理是一个好方法。 如果你从来没有创建过一个项目，你可能会担心人们会说什么，或者是否有人会注意到。 如果这听起来像你现在的状态，别担心，你并不孤独！ @@ -75,7 +70,7 @@ related: ### 设置你的目标 -目标可以帮助你弄清该做什么，不应该说什么，以及你在哪方面需要其他人的帮助。 首先问自己，_我是为什么开源这个项目？_ +目标可以帮助你弄清该做什么，不应该说什么，以及你在哪方面需要其他人的帮助。 首先问自己，_我为什么要开源这个项目？_ 这个问题没有标准答案。 对于一个项目你可以有多个目标，或者具有不同目标的不同项目。 @@ -85,7 +80,7 @@ related: avatar 在某些时候，我创建了一个自己正在使用的自定义 UIAlertView，我决定将它开源。所以我修改它使其更有活力，并把它上传到了 GitHub。我还写了我的第一个文档，解释给其他开发人员如何在他们的项目中使用它。很可能没有人会去使用它，因为它是一个简单的项目，但我的贡献让我感觉很好。

-— @mavris, ["自学的软件开发者：为什么开源对我们那么重要"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576#.zhwo5krlq) +— @mavris, ["自学的软件开发者：为什么开源对我们那么重要"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)

@@ -101,7 +96,7 @@ related: avatar 当你开始开源一个项目时，确保您的管理流程考虑到您项目周围社区的贡献和能力很重要。不要害怕让那些没有在你的企业中受雇的贡献者参与项目的关键部分 - 尤其如果他们是频繁的贡献者的话。

-— @captainsafia, ["所以你想开源一个项目，是吗？"](https://writing.safia.rocks/2016/12/06/so-you-wanna-open-source-a-project-eh/) +— @captainsafia, ["所以你想开源一个项目，是吗？"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)

@@ -109,9 +104,9 @@ related: 如果你的目标是学习如何与他人合作或了解开源的工作方式，请考虑为现有项目做出贡献。从你已经使用并喜欢的项目开始。像修复拼写错误或更新文档简单的事也能为项目做出贡献。 -如果你不知道如何开始作为贡献者，请查看我们的[如何贡献开源指南](../how-to-contribute/)。 +如果你不知道如何开始成为贡献者，请查看我们的[如何贡献开源指南](../how-to-contribute/)。 -## Launching your own open source project +## 发起你自己的开源项目 即使你没有很好的时间来开源你的工作。你也可以开源一个想法，正在进行中的工作，或是关闭了多年的源码。 @@ -136,13 +131,13 @@ related: [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项目成为开源。 +当你在GitHub上创建新项目时，你可以选择许可证。包括开源许可证将使你的GitHub项目成为开源项目。 ![挑选一个许可证](/assets/images/starting-a-project/repository-license-picker.png) 如果您在管理开放源码项目的法律方面有其他问题或疑虑，我们已经[在这里](../legal/)介绍了。 -### Writing a README +### 撰写自述文件 自述文件不仅仅是用于说明如何使用你的项目。他们还可以解释你的项目为什么重要，以及它可以为你的用户做什么。 @@ -153,13 +148,13 @@ related: * 如何开始？ * 如果需要，我可以在哪里获得更多的帮助？ -您可以使用自己的README回答其他问题，例如处理贡献，项目的目标以及许可证和归属信息。 如果您不想接受他人的贡献，或者您的项目尚未准备好作为产品提供使用，请将这些信息写下来。 +您可以使用自己的 README 回答其他问题，例如处理贡献，项目的目标以及许可证和归属信息。 如果您不想接受他人的贡献，或者您的项目尚未准备好作为产品提供使用，请将这些信息写下来。 @@ -169,9 +164,9 @@ related: 当你在根目录中包含一个 README 文件时，GitHub 会自动将其显示在存储库的主页上。 -### Writing your contributing guidelines +### 编写你的贡献指南 -贡献文件 (CONTRIBUTING file) 告诉你的受众如何参与你的项目. 例如，你可以包括一下信息: +贡献文件 (CONTRIBUTING 文件) 告诉你的受众如何参与你的项目. 例如，你可以包括以下信息: * 如何提交错误报告（尝试使用[issue 和 pull request 模板](https://github.com/blog/2111-issue-and-pull-request-templates)） * 如何建议一个新功能 @@ -183,19 +178,19 @@ related: * 你项目的路线图或者版本 * 贡献者应该（或者不应该）如何与你取得联系 -温柔友好的逾期和向贡献者们提供具体的建议（例如写文档或者搭建一个网页）能够有效地使新人感到受欢迎并乐于参与其中。 +使用热情友好的语气并提供具体的贡献建议（例如编写文档或者搭建网站）可以大大提高新人的参与度。 -例如，[Active Admin](https://github.com/activeadmin/activeadmin/) 以这样的方式开始[它的贡献指南](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md)： +例如，[Active Admin](https://github.com/activeadmin/activeadmin/) 以这样的方式开始[它的贡献指南](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)： -> 首先， 非常感谢你考虑为 Active Admin 贡献帮助。正式你这样的人们使得 Active Admin 成为了如此优秀的工具。 +> 首先， 非常感谢你考虑为 Active Admin 贡献帮助。正是你这样的人使 Active Admin 成为一个很棒的工具。 在你项目开始的初期，你的贡献文件可以很简单。你应该经常解释如何提交错误和文件问题，以及关于如何作出贡献的技术问题（例如测试）。 -随着时间的推移，你硬弓增加其他常见问题到你的贡献文件中去。写下这些信息意味着问你相同问题的人会越来越少。 +随着时间的推移，你可以将其他常见问题添加到贡献文件中去。写下这些信息意味着问你相同问题的人会越来越少。 -想要获得更多有关编写贡献文件的方式，请查阅 @nayafia 的 [贡献指南模板](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) 或者 @mozilla 的 ["如何构建 CONTRIBUTION.md"](http://mozillascience.github.io/working-open-workshop/contributing/)。 +想要获得更多有关编写贡献文件的方式，请查阅 @nayafia 的 [贡献指南模板](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) 或者 @mozilla 的 ["如何构建 CONTRIBUTION.md"](https://mozillascience.github.io/working-open-workshop/contributing/)。 -来你的 README 中链接你的 CONTRIBUTING，这样更多人就能看到他。如果你[在你的项目中放入了 CONTRIBUTING 文件](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)，当一个贡献者创建 issue 或者开启一个 pull request 时，GitHub 会自动链接你的文件。 +在你的 README 中链接你的 CONTRIBUTING，这样更多人就能看到他。如果你[在你的项目中放入了 CONTRIBUTING 文件](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)，当一个贡献者创建 issue 或者开启一个 pull request 时，GitHub 会自动链接你的文件。 ![贡献指南](/assets/images/starting-a-project/Contributing-guidelines.jpg) @@ -205,21 +200,21 @@ related: avatar 我们都有过这样的关于重复劳动的经验，无论是维护者试着解释为什么某些事物必须通过某种明确的方式执行，或者是用户...提出一个简单的问题。行为规范成为一个便利的参考和可链接的文档标明你的团队会认真对待具有建设性的讨论。

-— @mlynch, ["让开源成为一个有趣的地方"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f#.v4qhl7t7v) +— @mlynch, ["让开源成为一个有趣的地方"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)

-最后，行为规范有助于为你项目的参与者车里行为规则。这在你为社区或者项目推出一个开源项目的时候尤为有价值。一份行为帮助你促进健康，有建设性的社区行为，这也会减轻你作为维护者的压力。 +最后，行为准则有助于为项目参与者的行为设定基本规则。这在你为社区或者项目推出一个开源项目的时候尤为有价值。一份行为帮助你促进健康，有建设性的社区行为，这也会减轻你作为维护者的压力。 更多信息，请参见 [行为规范指导](../code-of-conduct/)。 除了传达你期待参与者**如何**行动，行为规范也倾向于描述这些期待针对谁，适用于何时，以及对于违规行为的处理方法。 -就像开源许可证一样，有现成的行为规范，所以你不必自己编写。[贡献者公约](http://contributor-covenant.org/)是一个行之有效的行为规范，已经被用在[超过4000个开源项目](http://contributor-covenant.org/adopters/)，包括 Kubernetes，Rails，以及 Swift。无论你使用哪一种，你都应该准备好在必要时执行行为规范。 +就像开源许可证一样，有现成的行为规范，所以你不必自己编写。[贡献者公约](https://www.contributor-covenant.org/)是一个行之有效的行为规范，已经被用在[超过4000个开源项目](https://www.contributor-covenant.org/adopters)，包括 Kubernetes，Rails，以及 Swift。无论你使用哪一种，你都应该准备好在必要时执行行为规范。 将文本直接粘贴到项目存储库中的 CODE_OF_CONDUCT 文件中。将文件保存在项目的根目录中，以便轻松找到，并从 README 中链接到它。 -## Naming and branding your project +## 项目命名以及品牌建设 品牌不仅是一个华丽的logo或者易记的项目名。它还关于你如何谈论你的项目，以及你想把信息传递给谁。 @@ -234,7 +229,7 @@ related: 考虑阐明所有。押韵虽然有趣，但是记住玩笑不可能转变成其它的文化，或者他人与你有不同的经历。你的一些潜在用户可能是公司员工，你不能让他们在工作中很难解释你的项目！ -### Avoiding name conflicts +### 避免命名冲突 [查看是否有同名的开源项目](http://ivantomic.com/projects/ospnc/)，尤其是你分享的是同样的语言或者生态系统。如果你的名字与一个已存在的知名的项目有冲突，你会让你的粉丝感到困惑。 @@ -244,11 +239,11 @@ related: 你可以查阅[WIPO全球品牌数据库](http://www.wipo.int/branddb/en/)避免商标冲突。如果你是在公司工作，[法律团队会帮你做这件事](../legal/)。 -最后，去谷歌搜索你的项目名。大家会很容易地找到你的项目吗？在搜索结果礼是否有你不想让大家看到的东西？ +最后，去谷歌搜索你的项目名。大家会很容易地找到你的项目吗？在搜索结果里是否有你不想让大家看到的东西？ ### 你的写作（和代码）如何影响你的品牌 -在项目的整个生命周期中，你需要做很多文字工作：READMEs，教程，社区文档，回复issues，甚至肯能要处理很多来信和邮件。 +在项目的整个生命周期中，你需要做很多文字工作：READMEs，教程，社区文档，回复issues，甚至可能要处理很多来信和邮件。 是否是官方文档或者一封普通的邮件，你的书写风格都是你项目品牌的一部分。考虑你可能会拥有粉丝，以及这是你想传达的声音。 @@ -256,17 +251,17 @@ related: avatar 我尝试处理每一个细节，包括：处理邮件，展示示例，友好待人，认真处理大家的issues以及试图帮助到大家。经过一段时间后，大家可能不再是只问问题，还会帮助我解决其他人的疑问以及给我喜悦，他们模仿我的风格。

-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](http://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)

使用热情，通俗易懂的语言（如"他们"，即使是指一个人）能够让新来的贡献者感觉项目非常欢迎他们。使用简单的语言，因为你的读者可能英语不是很好。 -除了书写风格外，你的编码风格也是你项目品牌的一部分。 [Angular](https://github.com/johnpapa/angular-styleguide) 和 [jQuery](http://contribute.jquery.org/style-guide/js/)是两个项目代码风格严谨的示例和指南。 +除了书写风格外，你的编码风格也是你项目品牌的一部分。 [Angular](https://github.com/johnpapa/angular-styleguide) 和 [jQuery](https://contribute.jquery.org/style-guide/js/)是两个项目代码风格严谨的示例和指南。 当你的项目才开始时，没有必要为项目编写一份风格指南。你可能会发现你喜欢将不同的编码风格融入到项目。但是你应该想到你的书写和编码风格会吸引或者拒绝不同类型的人。项目的早期是你建立你希望看见的先例的机会。 -## Your pre-launch checklist +## 发布项目之前的检查项 准备好开源你的项目了吗？有一份帮助检查清单。检查所有内容？你准备开始吧！ [点击 "publish"](https://help.github.com/articles/making-a-private-repository-public/) 以及拍下自己的后背。 @@ -296,7 +291,7 @@ related:
@@ -305,7 +300,7 @@ related:
@@ -364,6 +359,6 @@ related: -## You did it! +## 你做到了！ -恭喜你开源了你的首个项目。不论结果如何，对开源社区都是一份礼物。随着每次commit,comment和pull request，你正在为自己或者他人创造学习和成长的机会。 +恭喜你开源了你的首个项目。不论结果如何，对开源社区都是一份礼物。随着每次commit，comment和pull request，你正在为自己或者他人创造学习和成长的机会。 diff --git a/_articles/zh-hant/README.md b/_articles/zh-hant/README.md new file mode 100644 index 00000000000..7d1ec86dd6a --- /dev/null +++ b/_articles/zh-hant/README.md @@ -0,0 +1,16 @@ +# 開源軟體指南 繁體中文 + +[開源軟體指南](https://opensource.guide/) 是一份給個人、開源社群或是公司希望學習如何運行和貢獻開源項目的資源指南。 + +## 貢獻 + +網站是由[Jekyll](https://jekyllrb.com/) 套件建立而成。請先閱讀 [貢獻指引](https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING.md) 來了解如何回饋以及貢獻。 + +## 授權 + +內容以 [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/) 的方式釋出。請參閱 [notices](https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING.md) 文件以了解歸音指南、貢獻條款、軟體以及第三方授權權限。 + +## 人員致謝 + +1. [opencc](https://github.com/BYVoid/OpenCC): 協助繁簡體字轉換簡化翻譯效率。 +2. [tmonk](https://github.com/felixshai): 致力彙整維護翻譯。 diff --git a/_articles/zh-hant/best-practices.md b/_articles/zh-hant/best-practices.md new file mode 100644 index 00000000000..91d348b7545 --- /dev/null +++ b/_articles/zh-hant/best-practices.md @@ -0,0 +1,270 @@ +--- +lang: zh-hant +title: 維護者最佳實踐 +description: 身為開源的維護者，如何輕鬆駕馭專案？本指南從文件流程到有效利用社群來展開。 +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +redirect_from: /zh-tw/best-practices/ +--- + +## 身爲一名維護者意味著什麼? + +如果你維護著一個非常流行的專案，你可能就會意識到自己寫程式的時間變少，而花費在回答issue的時間越來越多。 + +在專案的起步階段，你會不斷嘗試著實現自己的新想法，也能夠基於自己想要的作出決定。隨著專案越來越受歡迎，就會發現你大部分的時間都花在了與用戶、貢獻者打交道上。 + +維護一個專案需要的不僅僅是寫程式的能力。有些時候會有一個你意想不到的的事情要應付，但是這對一個專案的成長也很重要(相對於寫程式來說)，我們收集了一些小技巧來讓你的維護工作變得稍輕鬆些，這些技巧，涉及範圍頗廣，從寫文件到管理社群都有所涉獵。 + +## 將流程文件化 + +對於一個專案的維護者來說寫文件是最重要的事情之一。 + +文件不僅說清楚了你的想法是什麼，還能幫助別人在問問題之前理解你需要什麼和接下在希望做什麼。 + +將一些東西寫下來，當遇到不符合專案預期的內容時，可以輕鬆的拒絕。同時，它對於人們的參與和提供幫助提供了指導。最有意思的是，撰寫文件的人可能永遠也不知道是誰讀了他寫的文件，或者使用專案。 + +即使你不想長篇大論，對要點略說一二也比啥都不寫要好。 + +### 寫下你的專案的發展方向 + +請在專案啓動時就寫下專案目標，並將之加到 README 文件中，或者創建一個單獨的 **VISION** 文件，其它還能幫助人們瞭解這方面的訊息如專案管理路線圖，最好是也把他們公開。 + +有一個明確的，用文件表達清晰的願景，能保證專案的走向不會跑偏，同時也能保障不會因爲其他的貢獻者增加的奇怪的需求而使專案變質。 + +比如，@lord 發現專案有一個明確的願景能夠幫助他決定哪個 PR 值得花時間。作爲一個維護者的新手，他甚至還後悔當他接到第一個關於[slate](https://github.com/lord/slate)PR的時候沒有堅持專案本身的原則。 + + + +### 和大家交流你自己對專案的期望 + +制定規則是很傷腦筋的。有時候你可能覺得你像是在限制別人的行爲或者說把好玩的東西都搞沒了。 + +制定了規則，然後嚴格執行，當然啦，好的規則會讓維護者更輕鬆。他們會把你從做自己不願意做的事情中解脫出來。 + +大多數知道你專案的人對你或者你的處境都是一無所知。他們可能會覺得你做這個專案是有錢拿的，特別是你的專案是他們經常用的而且某種程度上有點依賴的時候。其實你只是在有時候會在專案上花很多時間，但是現在你在忙著安置新工作或者照顧剛出生的兒子。 + +這些都是再正常不過的事情！所以確保讓別人也知道這些。 + +如果你維護某個專案是利用空閒時間或者完全自願的，能花多少時間就花多少時間。而不是你覺得專案需要你花多少時間或者別人想讓你花多少時間。 + +這裡是一些值得你寫進專案裡的東西： + +* 怎樣的貢獻會被複查和接受(_需要測試嗎？提Issue有模板嗎？_) +* 你本人會接受什麼類型的貢獻？（_你是不是只希望在某些部分的程式上需要別人的幫助？_） +* 在合適的時候跟進專案（比如說 _如果你在七天之內沒有收到maintainer的回覆，而且依舊沒有其它任何人的回應，那麼就直接找他/她。_） +* 你會在這個專案上話多少時間（比如說 "_我們每星期只會在這個專案上花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) 均是爲維護者和貢獻者提供了很好的基本規則的專案，乃業內典範。 + +### 保證交流是公開進行的 + +不管是什麼時候，保證你的交流是在公共的場所（就是大家都能看到的地方）。如果有人嘗試和你私聊，哪怕是討論一個新的需求或者功能，請禮貌的引導他/她到公共的交流場所，比如郵件列表或者issue tracker。 + +如果你和別的維護者面談了，或者在私下做了一個很重要的決定，把這些訊息告訴大家，即使只是把你的筆記發上去。 + +這樣的話，每個人新加入到你們社群的人和已經待了多年的人能夠瞭解到的訊息是一樣的。 + +## 學會拒絕他人 + +把所有的事情都寫下來，當然，對你執行你制定的規則的時候客觀分析實際情況也有幫助。 + +拒絕別人確實不是很好玩，但是也要表現出專業程度，比如使用"你的貢獻不符合這個專案的標準"而不是"我不喜歡你的貢獻"這樣顯得粗魯的語句。 + +作爲一個維護者，在很多情況下，你都要拒絕別人：不符合專案規則的PR, 某個人脫離了討論的重點，給別人做無關緊要的工作等等。 + +### 保持友好溝通 + +你要學會拒絕的最重要的地方就是Issue和PR請求。作爲一個專案的維護者, 你會不可避免的收到你不想接受的建議。 + +可能某個貢獻並不在專案的範圍或者和你的期望不合。又或者是可能想法很好，但是實現的卻很爛。 + +不管是什麼原因，在處理這些不符合專案標準的貢獻的時候都要婉轉。 + +如果你收到了你不想接受的貢獻，你的第一反應可能是忽略或者假裝沒看到。但是這麼做會嚴重傷害到別人而且可能會讓你社群裡的其他貢獻者失去動力。 + + + +別因爲自己感到內疚或者想做一個好人就把你不想接受的貢獻繼續保留。隨著時間的流逝，這些你沒有回答的issue和PR會讓你覺得很不爽。 + +更好的方式是馬上關掉你不想接受的貢獻。如果你的專案已經飽受積壓的issue的折磨，@steveklabnik 可以給你點建議，[如何高效率的解決issue](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)。 + +第二點，忽略別人的貢獻等於是在社群傳遞了一個負面的信號。讓人感覺提交一個貢獻是蠻恐懼的事情，尤其是對於剛加入的新手來說。即使你不接受他們的貢獻，告訴他們爲什麼然後致謝。這會讓人覺得更舒服。 + +如果你不想接受某個貢獻： + +* **感謝他們** 的貢獻 +* **解釋爲什麼他們的貢獻不符合** 專案的需求範圍，然後提供清楚的建議以供改善，如果你可以的話。和藹一點，但同時也要講原則。 +* **引用相關的文件，** 如果你有的話。如果你發現你反覆收到你不想接受的貢獻，把他們加到文件以免你重複敘述。 + +你不需要用超過1-2兩句話來回覆。比如，當一個[celery](https://github.com/celery/celery/)的用戶報告了一個window相關的錯誤，@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://github.com/shykes)[所說](https://twitter.com/solomonstre/status/715277134978113536)開源的第一原則就是 _"拒絕是暫時的，接受是永遠的。"_ 當然啦，認同別人的熱情還是一件好事，拒絕他的貢獻和拒絕他這個人是兩碼事。（要做到對事不對人。） + +最後，如果一個貢獻不是夠好，你沒任何義務接受它。對那些想對你的專案做貢獻的人保持和藹和積極的態度，但是只能接受那些你確定會讓你的專案變得更好的提交。你說拒絕的次數越多，對你來說拒絕別人就越容易。謹記！ + +### 保持主動 + +要想減少你不想接受的貢獻的數量，首先，在你專案的貢獻指南中解釋如何提交貢獻以及怎樣的貢獻會被接受。 + +如果你收到太多低質量的貢獻，讓那個貢獻者先多做做功課，比如： + +* 填寫一個 issue 或者 PR 的模板/清單 +* 在提交PR之前先開一個 issue + +如果他們不遵從你的規則，馬上關掉 issue 並引用你的文件。 + +當然啦，這麼搞一開始是不太舒服，但是你主動一點確實對雙方都好。它減少了某個人花了太多時間到一個你不想要的 PR 上的可能性。而且讓你管理起來更輕鬆。 + + + +有時候，當你說不的時候，你潛在的貢獻者會感到對你的沮喪或者不爽。如果他們開始找你撕逼了，[採取必要的措施以應對局勢](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items)或者乾脆把他們從你的社群開除，如果他們不打算和你保持建設性的合作關係的話。 + +### 成爲導師 + +可能在你的社群裡有人不斷提交一些不符合專案需求的貢獻。對你們雙方來說，不停的拒絕他的提交，會令雙方都很尷尬。 + +如果你發現有人對你的專案很上心，但是就是需要調教，那就耐心一點。給他解釋明白每次它的提交爲什麼不符合專案需求。嘗試著讓他先做一些簡單一點的事，比如那些標有 _"good first issue"_ 標籤的issue，以此讓他慢慢習慣。如果你有時間的話，考慮教他怎麼完成第一次的貢獻，或者在社區找一個人來負責。 + +## 有效利用社群 + +你不需要凡事親力親爲。這就是社群存在的原因！即使你沒有一個活躍的貢獻者社群，但是如果你有很多用戶的話，拉他們來幹活兒。 + +### 分擔工作量 + +如果你正在尋找其他人來參與，從身邊的人開始。 + +當你看到新的貢獻者不停的提交貢獻，通過分配給他們更多任務來表示認可。如果別人願意的話，記錄下別人是怎麼成長爲領導者的過程。 + +鼓勵別人來[一起管理專案](../building-community/#分享專案的所有權)能很大程度上減輕你的工作量，就像 [@lmccart](https://github.com/lmccart) 在他的專案上做的那樣，[p5.js](https://github.com/processing/p5.js) + + + +如果你需要暫時或者永久的離開的專案，請找人來代替你，這並沒有什麼不好意思。 + +如果別人認同專案的發展方向，給他們提交的權限或者正式把專案所有權轉移給他。如果有人fork了你的專案而且在保持活躍的維護中，考慮在你的原始的倉庫放上這個fork版本的鏈接。如果大家都希望你的專案繼續的話這不失爲一種好辦法 + +[@progruim](https://github.com/progrium) [發現](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) 由於它給他的專案[Dokku](https://github.com/dokku/dokku)寫一個關於專案發展方向的文件，即使在它離開這個專案後他的那些目標仍然會被實現。 + +> 我寫了一個wiki來描述我想要啥和爲什麼。不知道爲啥，專案的維護者就開始推動專案朝這個方向發展，這對我來說還是有點驚訝的。他們會絲毫不差的按照我的意願去做這個專案嗎？不總是這樣，但是總是會把專案推動到離我的理想狀態更近的位置。 + +### 讓別人嘗試他們自己想要的解決方案 + +如果有貢獻者關於專案有不同的意見，你可以禮貌的鼓勵它在他自己fork版本上繼續工作。 + +fork一個專案不什麼壞事情。能複製並且修改別人的程式是開源專案最大的好處之一。鼓勵你的社群成員在他自己fork的倉庫上繼續工作，這是在不和你的專案衝突的基礎上，給實現他們的想法最好的出口。 + + + +這對於那些強烈的需要某個你沒時間實現的解決方案的用戶來說也是一樣的。提供API或者自定義的鉤子幫助他們更好的實現自己的需求而不需要改動源碼。[@orta](https://github.com/orta)[發現](https://artsy.github.io/blog/2016/07/03/handling-big-projects/)鼓勵在CocoaPods上使用插件導致了很多有趣的想法的誕生。 + +> 一旦一個專案變大之後，維護者對怎麼增加新程式變得保守是不可避免的事情。你可能很會拒絕別人的需求，但是很多人提的都是合法的需求。所以，你不得不把你的一個工具變成平臺。 + +## 使用機器人 + +就像很多工作別人可以幫你做一樣，也有很多工作不需要人來做。因爲有機器可以替代人工，尤其是那些重複、無聊的工作，用好它們能夠讓你的維護生活變得更容易。 + +### 引進測試和別的檢查來改善你的程式質量 + +讓你專案自動化的最重要的方法之一就是引進測試。 + +測試能夠幫助貢獻者自信他們沒有弄壞什麼。測試也讓你複查程式和接受別人的貢獻的過程更加容易。你反應的越多，社群參與的就越多。 + +設置自動化的測試讓所有新來的貢獻者都可用，而且保證你的測試可以很容易在貢獻者的本地運行。保證所有的程式貢獻者在提交之前都運行你的測試。你還得爲所有的提交設置一個基本的標準。 + +如果你添加了測試，確保在 CONTRIBUTING 文件裡面解釋他們是怎麼工作的。 + + + +### 用工具來自動化日常的維護工作 + +對於維護一個流行的專案來說，一個好消息是別的維護者也可能遇到過類似的問題而且已經找到一個解決方案。 + +這裡有[各種各樣的工具](https://github.com/integrations)幫你自動化一部分的維護工作。這裡僅列舉一些常見的例子： + +* [semantic-release](https://github.com/semantic-release/semantic-release) 自動化版本發佈 +* [mention-bot](https://github.com/facebook/mention-bot) 可能的貢獻者來幫你複查程式 +* [Danger](https://github.com/danger/danger) 幫你自動複查程式 + +對於bug報告和其他常見形式的貢獻，GitHub有[Issue 模版和 Pull Request 模版](https://github.com/blog/2111-issue-and-pull-request-templates), 你可以用來降低溝通成本。你也可以設置[郵件過濾](https://github.com/blog/2203-email-updates-about-your-own-activity)來管理你的郵件提醒。 + +如果你想更加的先進和高效，程式風格指南和linter能讓你專案收到的貢獻更加規範，而且更容易複查和被接受。 + +當然啦，如果你的標準太複雜了，反倒會增加了貢獻的難度。所以保證你只添加那些讓每個人工作起來更容易的規則。 + +如果你不確定用什麼工具，看一看別的流行專案是怎麼做的，特別是和你在一個生態系統的。比如，其他的Node模塊的貢獻流程是怎麼樣的？用相似的工具和方法，能夠讓你專案的貢獻流程對於開發者來說是很熟悉的。 + +## 不幹了也沒關係 + +開源專案曾經讓你開心，但可能現在開始讓你不開心了。 + +可能當你想到你的專案的時候感覺到"亞歷山大"。而同時，issue和PR又紛至沓來。 + +疲倦在開源工作工作中是一個常見的問題，特別是在維護者中間。作爲一個維護者，你做的開心對專案的生存來說是一個沒有商量餘地的條件。 + +雖然你不需要跟誰請假，但是也不要拖到自己疲倦不堪的時候纔去度假。[@brettcannon](https://github.com/brettcannon)，一個python的核心開發者，決定在14年的義務勞動之後[休一个月的假](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering)。 + +就像其他工作一樣，有規律的休息會讓你對工作保持舒適愉快的心情。 + + + +有時候，當你感覺大家都離不開你的時候，請假去休息是一件蠻困難的事情。甚至你自己會因爲離開而感到愧疚。 + +在你離開專案的時候儘可能的在用戶和社群中間尋求支持，如果你找到支持你的人，還是休息吧。在你不工作的時候還是要保持和別人交流，這樣人們不會因爲你的失聯而感到奇怪。 + +休假不僅適用於度假。如果你週末不想做開源專案的工作了，或者在本該工作的時候不想幹活了，和別人說，這樣他們知道什麼時候不該打擾你。 + +## 首先照顧好自己！ + +維護一個大型專案時，相比早期的增長階段，是需要更多的不一樣的技能，作爲一個維護者，你會將自己的領導力和個人能力提高一個層次，而這是很少人能體會的到的。但是與此同時，要挑戰管理專案，以及設定清晰的界限。只做你感到舒服的事情，能夠讓你保持開心，活力，高產的狀態。 diff --git a/_articles/zh-hant/building-community.md b/_articles/zh-hant/building-community.md new file mode 100644 index 00000000000..90c5937a31a --- /dev/null +++ b/_articles/zh-hant/building-community.md @@ -0,0 +1,281 @@ +--- +lang: zh-hant +title: 打造友善、溫暖的社群 +description: 打造個人們願意使用、貢獻並願意主動宣傳的人氣社群。 +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +redirect_from: /zh-tw/building-community/ +--- + +## 讓專案朝成功邁進 + +現在的你，你已經啓動屬於你自己的專案，正在向世界介紹它，有人對你的專案感到好奇。這真是令人振奮！接下來要考慮的是，如何讓有興趣的人持續地待在這個社群裡。 + +友善的社群對於專案的未來至關重要，如果你的專案開始有人願意貢獻，記得給這些先行者一個愉快的協作體驗，鼓勵他們持續參與。 + +### 讓大家感到受歡迎 + +@MikeMcQuaid 提供了一個思考專案社群的看法稱之為[貢獻者漏斗](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) + +![contributor funnel](https://opensource.guide/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +當你建立了自己的開源社群，想想這些處於漏斗上方的人（潛在用戶）是如何下潛到底部（活躍的維護者）。你的目標是減少貢獻者在每個階段所遇到的摩擦。當人們能從中輕易的獲得成就感時，就會樂意去做更多的事。 + +從你的說明文件開始著手： + +* **讓大家很容易上手。** [一份好閱讀的 README](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-02.md#編寫readme)以及清晰的程式碼範例，讓大家很容易的上手。 +* **清楚的說明該如何貢獻**，使用[你的CONTRIBUTING file](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-02.md#編寫你的貢獻指南)並持續更新issues。 + +在 [GitHub 2017 開源調查報告](http://opensourcesurvey.org/2017/)中指出，令人困惑或不完整的說明文件是開源使用者最大的困擾，好的說明文件會吸引人們與專案互動。總有一天，會有人開啟一個 issue 或 PR。盡量使用這些工具讓人們有機會朝漏斗的下方邁進。 + +* **當有人選擇了你們的專案，記得對他們表示謝意！** 因為可能只是一次不愉快的經歷，就足以讓一些人再也不想回來。 +* **及時回應。** 如果一個月都沒有回答他們的 issue，他們可能也早就忘記了你們的專案。 +* **以開放的態度接受各式各樣的貢獻。** 很多貢獻者是從提報一份 bug 或者修一些小東西開始的。這裡有[很多為專案做貢獻的方式](../how-to-contribute/#具體而言什麼是貢獻)。讓大家選擇他們喜歡的方式。 +* **如果你不贊成一個貢獻。** 首先你需要對他們的想法表示感謝，同時 [解釋為什麼](../best-practices/#學會拒絕他人)這點子不適合專案，如果有必要的話你可以給出相關文件的連結。 + + + +多數開源貢獻者是「不固定的貢獻者」，因為他們只是偶爾參與專案。一位不固定的貢獻者可能沒有充裕的時間全程參與你的專案，所以你的工作是能讓他們很輕鬆地參與貢獻。 + +鼓勵其他的貢獻者也是對專案的一種投資。當你們授權大量的粉絲做他們感興趣的工作時，壓力就會少很多。 + +### 記錄一切 + + + +當你開始一個新專案，會覺得就私下默默地工作是很正常的。但開源專案真正開始茁壯的時候，是當你開始公開的把你的進度歷程紀錄下來的時候。 + +把事情記錄下來，會更多的人參與，參與的人也方便能從歷程的每個階段著手。你甚至可能會得到意想不到的幫助。 + +技術文件只是文件紀錄的一種。任何時刻，你覺得有必要寫下來的事情，或是私下針對專案的討論內容，你都可以想想是不是能將內容公開。 + +試著盡量讓你的專案規劃保持透明公開：你們期待什麼類型的貢獻者，如何審查貢獻，或者你們做某些決定時的理由。 + +如果你注意到有很多使用者遇過同樣的問題，那麼你應該將回覆記錄在 README 中。 + +如果是會議的內容，試著將你的筆記或重點摘要附在相關的 issue 裡頭，這樣的公開方式有時會給你意想不到的回饋。 + +記錄一切也適用於你的工作。如果你正在進行重要的更新工作，請將它放入 pull request 並標記為正在進行中（WIP）。讓其他人了解，能夠在該工作的初期有參與感。 + +### 積極迴應 + +一旦你[推廣專案](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/HEAD/github-open-source-guide-03.md)，人們將會給你們回饋。他們可能會問專案是如何工作的，或者希望有人教他怎麼使用。 + +當有人提出一條 issue ，提交一個 pull request ，或詢問專案有關的問題時，你們應該盡快回覆他們。當你們快速地做出反應時，大家會覺得有參與到對話，會有熱情去參與專案。 + +如果你無法做到及時，至少試著去及早確認，如此一來有助於提高大眾的參與度。以下是@tdreyno在[Middleman](https://github.com/middleman/middleman/pull/1466)回覆的一個pull request： + +![middleman pull request](/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 。你可以在這些網站設定通知，當有人提到你的專案時，可即時的收到提醒。 + +### 為你們社群提供一個聚會的場所 + +有兩個理由可以解釋為什麼要給社群提供聚會的場所。 + +第一個理由是為了貢獻者。讓社群的人相互認識。因為有共同興趣的人一定會想要一個可以聊天的地方。當資訊是公開的而且容易接觸時候，任何人可以透過過去的資料，快速的跟上大家的話題。 + +第二個理由是為了你自己。如果沒有提供公共場所來談論專案，大家可能會直接與你聯繫。剛開始可能覺得回覆私訊很輕鬆。但是一段時間後，尤其是如果專案變的熱門時，就會感到疲於應付。不要私下和人們討論你們的專案，直接請他們去指定的公共渠道。 + +公共交流和指引人開一條 issue 一樣簡單，而不是直接發電子郵件或者在你的部落格上留言。為了方便人們談論專案，你可以設置一個郵件列表、創一個 Twitter 賬號， Slack ， IRC 頻道。或者嘗試以上所有的方式。 + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) 每隔一週抽出辦公時間來協助社群成員： + +> Kops 每隔一週都會提供晤談時間，為社群提供幫助和指導。 Kops 維護者約定好留出一些時間專門與新手一起工作，處理 PR，以及討論新的功能。 + +此外請謹記，有一些事情反而是不適合公開討論的：1）有關資安方面的 issues 2）嚴重違規準則的行為。你應該為大家提供一個私下討論這些 issue 的方式。若不想用自己的個人信箱，那麼就設一個專用的郵箱 + +## 讓社群成長茁壯 + +社群擁有強大的能量。這種能量可能是正面的也可能是負面的，一切都取決於你如何駕馭它。隨著社群的成長，要想辦法讓之成為建設性的力量，而非具有破壞性的。 + +### 不要容忍來者不善的人 + +熱門的專案都不可避免地會吸引到想破壞社群的人。他們可能會從一些不必要的爭論開始，對一些細枝末節糾纏不清，或用語言傷害他人。 + +對於這些人，必須採取零容忍的政策。一旦猶豫不決，那麼這些負面的人會給社群的其他人帶來不愉快的感覺。甚至出現劣幣驅逐良幣的現象。 + + + +對專案的顯而易見的問題進行定期辯論，會分散別人的注意力，包括你自己，新人如果看見這樣的情景，他們可能不會加入到專案中來。記得要將精力放在重要的任務上。 + +當發現社群中有負面的行為時，要即時、公開的指出來。要用堅定的語氣解釋他們的行為為什麼是不可接受的。如果問題持續發生，你有必要 [請他們離開](../code-of-conduct/#蒐集有關違規的資訊) 。你的 [行為準則](../code-of-conduct/) 是為這些情境準備的建設性指南。 + +### 知道貢獻者在哪裡 + +隨著專案的成長，好的說明文件會變得愈加重要。不固定的貢獻者或路人不可能一下子就對專案非常熟悉，一份好的文件，能讓他們很快地找到他們需要的資訊。 + +在 CONTRIBUTING 文件裡，需要明確告訴新來的貢獻者該如何使用。為了想要達到這個目的，你也許會想要設立一個專區說明。 + +![django new contributors page](/assets/images/building-community/django_new_contributors.png) + +試著對每個 issue 標上標籤，為不同類型的貢獻者做指引：例如，[_"僅供入門者"_](https://kentcdodds.com/blog/first-timers-only), _"適合新手的Bug"_, 或者 _"說明文件"_. [這些標籤](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 。這專案是個充滿愛的工作，我們感激所有參與的人，不論是為我們抓 bug 、提升性能或完善說明文件。每一個貢獻都是有意義的，感謝你們的參與。話雖如此，我們還是要求參與者遵守一些指南，如此一來我們也才能夠回覆你們的 issue 。 + +### 分享專案的所有權 + + + +當大家覺得自己也是專案的主人之一時，就會非常樂意為專案付出。這並不代表就要去調整專案的願景，又或者代表要接受你不要的貢獻。但是社群越信任他們，他們就會越樂意待在這。 + +試著找一些方法向社群分享你的所有權，這裡有一些經驗和大家分享： + +* **不要親自去修簡單（不嚴重）的錯誤。** 相反，將這些錯誤作為招募新貢獻者的工具，或指導有意貢獻付出的人。剛開始可能會覺得過程很不自然，但一段時間你會得到想要的結果。例如，在[Cookiecutter](https://github.com/audreyr/cookiecutter) 的一則 issue 下面， @michaeljoseph 要求貢獻者提交一個 pull request ，而不是親自處理它。 + +![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **在專案中添加一個貢獻者列表或者作者列表** 記錄每一個參與貢獻的人。 + +* 如果社群有了一定的規模，就 **發送一封信或者發表一篇文章** 感謝貢獻者們。[Rust 週報](https://this-week-in-rust.org/)和 Hoodie 的[Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)就是兩個非常好的範例。 + +* **給每個貢獻者提交的權限。**@發現這樣會使大家[越來越樂意發表他們的補丁](https://felixge.de/2013/03/11/the-pull-request-hack.html)，甚至找到人手來協助維護他已很久沒處理的專案。 + +* 如果專案是放在 GitHub 上，那麼 **將專案從你們的個人賬號轉移到一個[組織](https://help.github.com/articles/collaborating-with-groups-in-organizations/)**，加入至少一個備份管理員。組織能讓社群與來自外界的貢獻，彼此協作的工作變得更加容易。 + +事實上很多專案[只有一個或者兩個維護者](https://peerj.com/preprints/1233/)去做大部分的工作。隨著社群變得越來越大，就會有更多的人參與進來。 + +雖然並不是一直都有人在回答問題，但是你可以去試著增加一些機會，讓他人有能夠參與的機會，越是儘早開始，越是能夠獲得幫助。 + + + +## 化解衝突 + +在專案的一開始，做決定是蠻容易的事。想做什麼就放手去做吧。 + +隨著專案變得熱門，會有更多人對社群的決策感興趣。如果專案有很多使用者，你會發現大家都很關心決策，或者踴躍的提交他們的 issue ，即使社群沒有很多貢獻者。 + +大多數情況下，如果你們經營了一個友善、受尊重的社群並紀錄社群歷程公開給大家知道，社群應該能自己找到解決方案。但有時也會遇到難以處理的麻煩。 + +### 建立友好的氛圍 + +當社群正熱烈討論一個困難的 issue 時，火氣可能會不小。人們可能會為此憤怒或者沮喪，甚至會做出直接的人身攻擊。 + +身為一名維護者的工作就是別讓這種情況惡化。即使你對該話題有自己強烈的看法，也要盡量擔任一個仲裁者或推動者的角色，而非跳下去參與爭論以及推動自己的觀點。如果有人態度不好或者嘗試壟斷話題，那麼請[立即採取行動](https://ocselected.github.io/open-source-guide/building-community/)，讓討論保持它應有的禮節，讓討論是有意義的。 + + + +一些人希望得到指導。試著當一個好典範。當然你仍然可以表達失望、不高興或者憂慮，但得心平氣和。 + +保持不慍不火並不容易，但是展現領導力能促進社群健康的發展。網路世界感謝你們的付出。 + +### 視 README 為最高原則 + +README [不僅僅是指導手冊](../starting-a-project/#編寫自述文件)。它也是一個談論目標、願景和路線的地方。 +如果人們放太多精力在討論特定功能的優點，這時重新審視 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)而不是要獲得共識本身。 + +尋求共識的過程中，社群成員討論關心在乎的事，直到他們覺得意見已經獲得充分的表達。當僅剩下一些次要的議題時，社群就往前邁進。「尋求共識」不能確保社群能得到一個完美的解答。而是側重聆聽和討論。 + + + +即使不全然採用尋求共識的方式，身為一名維護者，讓人們知道你願意傾聽意見是一件很重要的事。讓其他人知道意見有被聽見，並且承諾解決他們的問題，這很大程度上減少了棘手情況的發生。接著言出必行的去採取行動。 + +不要為了得到解決方案而急於做出決定。在有所行動前請確保每個人已經知情，保持所有的資訊公開。 + +### 將對話重點聚焦於行動 + +討論很重要，但是有成效和沒有效果的對話是有很大區別的。 + +鼓勵討論，只要它正積極地朝著解決問題的方向前進。如果你很清楚地發現對話已經漸漸停滯下來、偏離主題、溝通開始對人對不對事或在小細節上鑽牛角尖，那就是時候該結束對話了。 + +允許上述的這些對話進行下去，不僅無法解決問題，還不利於社群的健康發展。這樣讓大家認為這類的對話是被允許甚至是被鼓勵的，它可能阻礙了人們往後提問的意願或者在解決之後的問題上產生困擾。 + +當你或其他人每次提出想法時，問問自己：「這發言如何使我們更接近一個解決辦法？」 + +如果對話開始有發散的徵兆，問問團隊：「我們下一步該做什麼？」才能重新聚焦討論。 + +如果一個對話沒有清楚的方向，也會沒有明確的辦法可以執行，又或者合適的解決辦法已經被採納，那麼就結束 issue 並解釋為什麼結束它。 + + + +### 謹言慎行 + +了解來龍去脈很重要。想想誰正在參與討論，以及這些人如何代表社群的其他人。 + +社群的每個人都是否參與討論？大家是否對這個議題感到困擾？還是有人在搗亂？記得不僅要關心有發言的人，也要記得為社群中保持沉默的人考量。 + +如果這個議題不代表社群普遍的需求，你們可能要理解這只是少數人的疑慮。如果這是一個反覆出現的 issue ，而且直到現在還是沒有一個明確的解決辦法，那麼指引他們去看看以前討論的內容，並結束這個討論串。 + +### 找出社群中的決策者 + +保持態度良善，維持目標清晰的對話，很多困難都可以被解決。但即便在富有建設性的對話中，還是可能會對該如何執行有不同的意見。在這樣的情況下，你要找找看是否有一個人或一組人，可以擔任決策者。 + +負責做出決策的人可能是專案的主要維護者，或者是大家投票選出的一個團體。理想情況下，事前要先確定決策者是誰和與之相關的事宜，寫在 GOVERNANCE 文件以便不時之需。 + +使用決策者應該是你們最後的手段。區分這些 issues 是一個社群成長和學習的機會。利用這些機會協作，儘量找出問題的解決辦法。 + +## 社群是開源的❤️ + +健康，蓬勃的社群每週都會為開源注入大量的動力。許多貢獻者指出，開源專案的其他成員是促成他們參與（或導致不參與）的主要因素。通過學習如何建設性地利用這股力量，你會在協助的過程中讓他人有個難忘的開源體驗。 diff --git a/_articles/zh-hant/code-of-conduct.md b/_articles/zh-hant/code-of-conduct.md new file mode 100644 index 00000000000..d92260bbebf --- /dev/null +++ b/_articles/zh-hant/code-of-conduct.md @@ -0,0 +1,115 @@ +--- +lang: zh-hant +title: 建立一套行為準則 +description: 為了促進社羣朝健康且有建設性的方向發展，必須設立一個共同遵守的行為守則。 +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +redirect_from: /zh-tw/code-of-conduct/ +--- + +## 我爲什麼需要行爲守則 + +行爲守則是一份確立專案參與者行爲規範的文件。採用和執行行爲守則可以幫助你們的社群營造積極的氛圍。 + +行爲守則不僅幫助保護你們的參與者，同時還有你們自己。如果你們維護一個專案，隨着時間的推移，可能會發現其他參與者懶散的態度會讓你們疲憊或對工作不滿意。 + +一份行爲守則可以幫助你們促進健康，有建設性的社群行爲。積極主動減少你們或其他人在你們的專案中變得疲勞的可能性，並幫助你們在有人做出你們不同意的事情時採取行動。 + +## 建立行爲守則 + +儘可能早地建立行爲守則，當你們第一次創建專案的時候。 + +此外，說出你們的要求。行爲守則的描述遵循如下幾點： + +* 行爲守則在哪裏有效 _(只在issues以及pull requests，或者社群活動？)_ +* 行爲守則適用於誰 _(社群成員以及維護者，那贊助商呢？)_ +* 如果有人違反了行爲守則會怎樣？ +* 大家如何舉報違規 + +無論你們在哪裏，請使用已有的行爲守則。[貢獻者盟約](http://contributor-covenant.org/)是一個被超過40，000個開源專案（包括Kubernetes, Rails和Swift）所使用的行爲守則。 + +[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)都是非常好的行爲守則。 + +請將CODE_OF_CONDUCT文件放在你們專案的根目錄，並在README中附上其鏈接，這樣對你們的社群是可見的。 + +## 決定你們如何執行行爲守則 + + + +你們應該解釋如何執行行爲守則在違規發生**之前**。有幾點理由說明爲什麼這麼做： + +* 必要的時候，它表示你們處事認真謹慎。 + +* 你們的社群會因爲投訴確實可以得到回覆而更加放心。 + +* 如果他們發現自己因爲違規而被調查時，你們能確保社群的審查流程是公平透明的。 + +你們可以給大家一個私有的渠道（如email地址）以便大家報告違規行爲以及解釋誰收到了這一的報告。它可以是維護者，一組維護者或行爲守則工作組。 + +請不要忘記了有人可能想要報告某些人違規接受了這些報告。在這樣的情況下，也給他們舉報那些人的機會。例如，@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來說是個好主意，因爲他們知道你們採取了行動。在徵求他們的意見之前，請向報告人徵求同意。 + +有時，一個解決方案不能達到目的。有關的人可能在面對或者不改變他們的行爲時變得氣勢洶洶或敵對。在這種情況下，你會想到考慮採用強制措施。例如： + +* **暫停有關人員**在專案中的工作，通過暫時禁止參與專案的任何方面執行 + +* **永久禁止**有關人員加入專案 + +對于禁止成員的做法，你們應該非常謹慎，只有在沒有其他解決方案的情況下才能使用。 + +## 維護者的責任和義務 + +行爲守則不是可以任意執行的法律。你們是行爲守則的執行者，同時你們的責任是遵守行爲守則確立的規矩。 + +作爲維護者，你們可以爲社群指定準則，同時你們可以根據行爲守則執行這些準則。這意味着你們需要認真處理違規行爲。報告者對他們的投訴進行了徹底和認真地審查。如果你們確定他們報告的行爲沒有違規，你們需要他們進行溝通並解釋你們爲什麼不進行處理。他們會怎樣做，取決於他們：容忍他們認爲有問題的行爲，或者停止參與社群。 + +如果報告的行爲沒有_技術上_的違規，這可能表面你們的社群依然存在問題，同時你們應該調查潛在的問題以及採取相應的行動。這可能包括修改你們的行爲守則，以澄清可接受的行爲和/或與行爲被舉報的人交談，並告訴他們，雖然他們沒有違反行爲守則，但是他們在期望和確定的邊緣另其他參與者感到不舒服。 + +最後，作爲維護者，你們給可接受的行爲建立和執行標準。你們有能力塑造專案社群的價值觀，以及參與者希望你們能 公平公正地執行這些價值觀。 + +## 鼓勵你們希望看見的行爲 🌎 + +當你們的社群變得似乎敵對或者不受歡迎時，即使是一個大家能容忍的個人行爲，也會讓你們失去很多貢獻者，你們可能再也遇不到其中的一些人。雖然執行或者採用行爲守則很難，但是營造一個受歡迎的環境將幫助你們社群成長。 diff --git a/_articles/zh-hant/finding-users.md b/_articles/zh-hant/finding-users.md new file mode 100644 index 00000000000..9627eb3cf42 --- /dev/null +++ b/_articles/zh-hant/finding-users.md @@ -0,0 +1,149 @@ +--- +lang: zh-hant +title: 找尋專案的使用者 +description: 透過使用者的心得來幫助你的開源專案成長。 +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +redirect_from: /zh-tw/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"](http://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](http://stackoverflow.com/), [reddit](http://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) + +線下活動是一個推廣專案流行的方式。這是一個接觸某個忠實聽眾和建立深層次的聯繫的好方式，特別是如果你對到場的開發者感興趣的話。 + +如果你還是個[公中演講的新手](http://speaking.io/)，從尋找一個和你專案使用的語言或者生態系統相關的當地的聚會開始吧。 + + + +如果你從來沒在公共場合講過話，感覺緊張那就太正常啦！記住你的聽眾就在哪兒，因爲他們都是真正的想聽你介紹你的專案。 + +當你在寫你的演講稿的時候，把重點放在你的聽眾會感興趣而且能獲取價值的事情上。保證你的語言要友好和和藹可親。笑一笑，深呼吸，幽默一點兒。 + + + +等你準備好了，考慮一下在某個會議上發言的時候推廣你的專案研討會可以幫助你接觸更多人，有時候是來自全世界各地的人。 + + + +## 贏得口碑 + +除了上面提到的策略之外，邀請人們分享和支持你的專案的最好辦法就是分享和支持他們的專案。 + +幫助新手，分享資源，給別人的專案認真的做貢獻會幫助你建立起良好的聲譽。然後他們就很有可能知道你的專案而且更有可能關注和分享你在做的事情。 + +有時候，這些關係還會進一步發展成更廣闊的生態系統中的官方合作伙伴（意思即使你有可能成爲那些有名社群的成員） + + + +種一棵樹最好的時候是十年前，其次是現在。所以何時開始建立你的聲望都不晚。即使是你早就已經建立了自己的專案，還是要繼續找辦法幫助別人。 + +建立用戶群沒有一蹴而就的方法。獲取別人的新人和尊重需要時間，同樣，建立聲望的過程也永遠不會停止。 + +## 保持精進 + +有時候，讓人麼注意你的開源專案會花費很多時間。但是沒關係！現在很多流行的專案也都是花了很多年才有今天的活躍度。把重點放在建立聲望上而不是企圖一夜成名。耐心一點，一如既往的和那些可能會從中受益的人們分享你的專案。 diff --git a/_articles/zh-hant/getting-paid.md b/_articles/zh-hant/getting-paid.md new file mode 100644 index 00000000000..b1d961d4213 --- /dev/null +++ b/_articles/zh-hant/getting-paid.md @@ -0,0 +1,155 @@ +--- +lang: zh-hant +title: 透過為開源專案工作而獲得報酬 +description: 透過經濟上的補助，支持你在開源專案裡的工作。 +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +redirect_from: /zh-tw/getting-paid/ +--- + +## **為何有人尋求經濟上的支持** + +很多開源工作都來自志願者的辛勤付出。例如，有人在使用的過程中遇到了臭蟲，就自己著手修正；也有些人單純利用自己的閒暇時間享受維護開源專案所帶來的樂趣。 + + + +有些人為開源貢獻，卻不求報酬，可能的原因有： + +* **他們本來就有一份自己熱愛的全職工作**，這可以讓他們在沒有後顧之憂的情況下利用業餘空閒時間來爲開源做貢獻。 +* **他們熱衷於沉浸在開源的思考中**，或是純粹享受創作的過程，不想因為有收錢而有要負責的壓力。 +* **他們能夠從開源的貢獻中獲得其它好處**，比如獲得名聲、當作自己的作品集或是藉此學習新的技能，又或者是能跟社群互動。 + + + +但是對其他人來說，尤其是正在進行的或者是需要花費大量時間的付出時，能夠取得報酬是人們積極參與開源的唯一理由，無論是專案的需要還是個人原因。 + +維護熱門的專案是一項很重要的責任，每週需要花上 10～20 小時，而不是每個月花上幾個小時就能搞定。 + + + +有償工作也能使各行各業的人創造有意義的貢獻。有些人需要贊助才願意參與開源專案，可能是因為他當前的財務收入不足、身上有債務、或者需要照顧家庭、撫養他人。有能力但在經濟上沒辦法無償貢獻自己時間的人，依然能當個貢獻者。這涉及道德倫理，正如 @ashedryden 在 [無償勞動的倫理和開源軟體社群](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) 一文中所描述的，人們經常誤以為，專案成果都是由那些在事業上已經有成就的人們完成的，這些人得以透過無償貢獻獲得更多的成果，而其他無法負擔無償貢獻的人就會錯失了這樣的機會，不斷負向循環下去，會使得開源社群越來越缺乏多樣性。 + + + +如果正在尋找經濟上的支持，有兩個方法可以參考。透過群眾募資，或是找一能夠爲專案提供資金的組織。 + +## **為你的貢獻募資** + +在今日，無論是兼職或全職，很多人透過開源獲得了報酬。最爲常見的做法就是去找願意爲你付出的時間和工作成果掏腰包的雇主談談。 + +如果你的老闆使用了該開源專案，贊助的事情自然就比較好談，盡量發揮創意地去向雇主提案。也可能雇主沒有使用到開源專案，但他們有使用 Python ，用來經營一個熱門的專案，吸引有興趣的 Python 開發者，又或者都不是，那老闆也至少營造了一個對開發者友善的環境。 + +如果你現在還沒有爲開源專案做工作，但是你希望你現在所做得成績開源出來，那麼你可以和你的老闆講，奉勸他將內部的軟體開源。 + +很多公司都在開發開源專案，從而能夠打造自己的品牌，以及希望僱傭到高質量的人才。 + +@hueniverse ，舉例來說，有充足的證據證明 [沃爾瑪對開源的投資](https://hueniverse.com/2014/08/15/open-source-aint-charity/)是合理的。 @jamesgpearce 同樣，Facebook的開源專案讓它的招聘顯得[與衆不同](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) : + +> 開源能夠與我們Hacker文化密切配合，也能夠和我們的組織融洽。我們詢問員工："在Facebook真的那麼的在意開源軟體？" 超過2/3的人的回答是"yes"。一半的人表示，該計劃對他們爲我們工作的決定作出了積極的貢獻。這可不是一個戲謔的數字，我們希望繼續保持這樣。 + +如果你所在的公司不贊同這麼做，沒關係，重要的是保持社群和企業活動之間的界限清晰。你要告訴老闆，開源的維持是由全球各地的人所貢獻，要比任何一個公司或某一地域都大的多。老闆會自己作出權衡的。 + + + +如果你實在無法在當前的僱主下開展相關開源的工作，那麼是該考慮換老闆的時候，應到找個支持想開源作貢獻的老闆！尋找那些致力於開源工作的公司。比如： + +* [Ghost](https://ghost.org/) 就是一家圍繞很多[開源專案](https://github.com/tryghost/ghost)的好公司 + +那些大公司發起的專案，如 [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 通過 [Patreon crowdfunding campaign](http://redux.js.org/)爲他的專案 [Redux](https://github.com/reactjs/redux)成功的融到了資金。 +* @andrewgodwin [通過 Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 爲Django schema 遷移拿到了資金 + +## 為你的專案尋找資助 + +除了針對個人貢獻者的建議之外，還有一些專案可以從公司、獨立投資方、以及其它的資金處來獲得進一步的工作。 + +機構資金可能用於支付當前的貢獻者，涵蓋運行專案的成本（如託管費用）或投資於新功能或想法。 + +一些獲得組織資助的專案案例： + +* **[webpack](https://github.com/webpack),** [通過 OpenCollective](https://opencollective.com/webpack) 從公司和個人來籌集資金 +* **[Ruby Together](https://rubytogether.org/),** 由 @indirect 創建的非盈利組織 ，爲諸如 [bundler](https://github.com/bundler/bundler)、[RubyGems](https://github.com/rubygems/rubygems)、以及其它的一些 Ruby 的基礎設施專案提供資金支持 + +儘管開源日漸的流行，但是爲專案尋找資金仍然是處於試驗中。目前所收集到的包括： + +* **通過大力宣傳活動或募捐，爲您的工作籌集資金** 這策略在你擁有足夠的粉絲，或者是已經社群聲譽良好的情況下，又或者是專案非常的受歡迎，等情況下有效。 +* **接受基金巨頭的資助** 一些軟體基金會和公司爲開源的相關工作提供很好的機會，如[Python 軟體基金會](https://www.python.org/psf/grants/), [Mozilla 基金會](https://www.mozilla.org/en-US/grants/)、以及[Stripe](https://stripe.com/blog/open-source-retreat-2016). +* **獲得公司或獨立投資商的贊助** 通過軟體基金會，或者是乾脆 **創業** 來支撐專案。 + +更多的案例和細節， @nayafia [專門寫過一個指南](https://github.com/nayafia/lemonade-stand) ，專門針對的就是如何爲開源工作獲得報酬。不同類型的資助需要不同的技能，所以仔細的掂量下資格，然後找個最適合自己的方式。 + +## 建立經濟上的支持 + +無論你的專案是新的創意，還是已經運行多年，你都需要爲你的資助者滿意，並提出有效而合理的案例。 + +不管是你自己尋找相應的工作，還是爲專案融資，你都應該嘗試回答下面的問題。 + +### 影響 + +爲什麼說這個專案有實際用處？你的用戶或潛在的用戶會喜歡它？5年之後它會是什麼樣子？ + +### 牽引 + +嘗試着去收集一些和你專案休慼相關的證據，比如指標、有趣的事情、還是其他人的推薦。是否有其它公司或者是業內意見領袖正在使用你的專案？如果沒有的話，是不是應該去找相應的人去推薦下？ + +### 充分利用資助者的價值 + +資助者，無論他是僱傭你的老闆，還是一家獲得授權的基金會，你都有機會和他們頻繁的進行接觸。 他們爲什麼會放棄其它機會而去支持你的專案？他們個人有何好處？ + +### 利用風險投資 + +您將如何用擬議的資金完成什麼？專注於專案里程碑或成果，而不是支付工資。 + +### 你將以何種方式接受資助 + +資助者是否有關於宣傳的額外需求？例如，你可能需要您可能需要成爲非盈利組織或擁有非營利性財政贊助商。又或者是資助者必須給到個人而不是一個組織。這些不同的需求會因爲不同的資助者而異，所以請事先做好準備。 + + + +## 嘗試，不要放棄 + +賺更多的錢不是件容易的事情，無論你是在開源專案，亦或是在非盈利組織，又或者是軟體的創業公司，但是無論在哪裏，掙得更多錢的祕密就是更多的創造力。當確定了你想如何獲得報酬的時候，請繼續你的研究，將自己放在投資人的角度來看問題，可以幫助你更好的構建一個更加令人信服的賺錢之道。 diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md new file mode 100644 index 00000000000..ce1ff212d83 --- /dev/null +++ b/_articles/zh-hant/how-to-contribute.md @@ -0,0 +1,515 @@ +--- +lang: zh-hant +title: 如何為開源做貢獻？ +description: 想為開源貢獻心力？一個菜鳥老手都值得一看的指南。 +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +redirect_from: /zh-tw/how-to-contribute/ +--- + +## **為何要為開源貢獻心力？** + + + +透過為開源貢獻力量，能從中學習、幫助他人並且從中累積相關技能的經驗 - 任何你能想像得到的技能。 + +為什麼會有人為開源做出貢獻？有數不清的原因！ + +### **鞏固現有技能** + +無論是撰寫程式碼、設計使用者介面、平面設計，撰寫文章或是組織活動，只要你有意願實踐，你總能在開源專案中找到自己的位置。 + +### **認識那些與你有相似興趣的人** + +一個友善、溫暖的開源社群會讓人們持續的參與。許多人透過參與開源建立了深厚的友誼，可能是在一次的技術研討中，也可能是在線上聊天室的閒聊中發生。 + +### **尋找導師，並且嘗試幫助他人** + +與他人在共享的專案中工作，你會需要向他人解釋自己是如何做的，同時也需要向他人求助。每個參與開源的人都教學相長。 + +### **在公眾建立你的名聲（以及職業名聲）** + +根據開源的定義，你在開源裡的所有工作都是公開的，這也意味開源專案是一個能好好展現你實力的地方。 + +### **學習人際交往的能力** + +開源為練習領導及管理的能力提供了很好的機會。例如如何解決衝突、組織團隊以及如何為工作的優先順序排列。 + +### **鼓勵作出改變，哪怕只是很微小的改變** + +你不一定要持續不斷的貢獻開源才能享受參與的樂趣。你是否曾在某個網站上發現拼寫錯誤，並希望有人能夠修改它？在開源專案中你可以親自修正這樣的錯誤即可。開源讓人們自在的做事，而這正是這個世界應有的體驗。 + +## 具體而言什麼是貢獻 + +如果你是一名開源世界的新手，可能會對貢獻的流程心生畏懼。如何找到適合彼此的專案？不會寫程式又想參與怎麼辦？萬一中間出了差錯怎麼辦？ + +不用擔心！條條大路通羅馬，有很多能參與開源專案的方式。以下是一些實用的技巧，幫你快速的獲得經驗。 + +### **你不一定要會寫程式才能貢獻** + +對開源做出貢獻常見的誤解之一就是：要寫程式才算貢獻。其實專案裡不需編碼的工作也是[經常被忽視](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) +* 整理一個風格指南，以幫助專案有一致的視覺設計方針。 +* 透過藝術創作設計T恤或畫一個新標誌，就像 [hapi.js 的貢獻者所做的](https://github.com/hapijs/contrib/issues/68) + +### **你是否熱愛寫作？** + +* 撰寫和改善專案的說明文件 +* 策劃一個資料夾來蒐集專案的實際應用案例 +* 辦一個專案的電子報，或者蒐整郵件列表的摘要 +* 寫一個專案教學，就像 [PyPA 的貢獻者做的](https://packaging.python.org/) +* 翻譯專案的說明文件 + + + +### **你喜歡組織活動嗎？** + +* 指認出過去討論過或重複的議題、推薦一個新的議題類別，讓事物井井有序 +* 瀏覽在開放狀態（open）的議題，並建議將已經處於開放狀態很久的議題設為已結束（closed）[就像 @nzakas 在專案 eslint 做的](https://github.com/eslint/eslint/issues/6765) +* 鼓勵最近才剛提問的人將疑問闡釋清楚，加速討論的進展 + +### **你喜歡寫程式？** + +* 嘗試解決一個開放狀態（open）的議題（issue） [就像 @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-to-ge) )或者 reddit 上 +* 回答處於開放狀態的議題 +* 鼓勵、協助創造友善的討論區禮儀 + +### **你喜歡協助他人改善它的程式嗎？** + +* 為他人貢獻的程式碼做程式碼審查 +* 寫一個教學向大家介紹如何使用該專案 +* 當其他貢獻者的導師， [像在 Rust 專案中 @ereichert 為 @bronzdoc 做的](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### **其實不一定要是開源軟體的專案！** + +雖然很多人提到「開源」兩字是指「開源軟體」，其實不盡是如此，許多事物你都可以開源協作，你可以開源一本書、開源食譜、開源一張你整理的清單，都可以像開源軟體一樣發展你想製作的東西。 + +舉例來說： + +* @sindresorhus 蒐集了 [「驚奇」（awesome） 列表](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 幫助人認識與使用專案，「貢獻」這個文件則是針對想對專案貢獻的人寫的指南。它會說明目前專案需要怎樣類型的貢獻者，並介紹貢獻時的流程是如何進行。並非所有的專案都會有這個文件，但如果有的話某種程度上也是向有意貢獻的人表達友善的意思。 +* **行爲準則（CODE_OF_CONDUCT）:** 這份文件裡頭設立了基本規範來約束參與者的行為以及提醒應有的禮儀，並非所有的專案都會有這個文件，但如果有的話某種程度上也是向有意貢獻的人表達友善的意思。 +* **其它文件:** 有些專案也許還有其它文件，例如教學、專案導覽，或者是管理政策，這在大型專案中常見。 + +此外，開源專案還會利用如下列的一些工具來進行組織討論，閱讀這些檔案對於理解社群的想法、是如何工作的有非常大的作用。 + +* **問題追蹤（Issue tracker）:** 這裡是人們討論專案相關問題的地方。 +* **請求提取（Pull requests）:** 這裡給人們檢查程式碼、以及相關問題的討論。 +* **論壇或郵件列表:** 一些專案會利用對話式的方式討論主題（例如 _"How do I..."_ 或 _"What do you think about..."_ 來替代回報 Bug 或特別的請求）。然而有一些專案討論過程都全程使用問題追蹤。 +* **即時在線聊天:** 有一些專案會使用聊天頻道（諸如 Slack 或 IRC），能夠隨意的談話、協作和快速的交換意見。 + +## **找尋專案開始貢獻** + +讀到這裏，已經對開源專案如何運作有了進一步的了解，是該找一個合適的專案做貢獻的時候了！ + +如果你從來都沒有爲開源做過貢獻的話，那麼請謹記來自美國總統約翰 F.肯尼迪的這段話：「**不問國家能爲你做什麼，要問你能爲國家做什麼。**」 + +開源專案的每個面向與跨專案間都需要貢獻者，先不用太鑽牛角尖的去想你一定要先在那做貢獻，或是做得好不好。 + +不如從你使用過的或將來會使用到的專案開始貢獻，你特別關注的專案才會是你會自願積極參與的專案。 + +參與的過程中，如果有任何點子，覺得可以讓專案更好或更不一樣的，就依你的直覺行事。 + +開源並不是會員專屬的俱樂部；它就是由你這樣的人所打造。「開源」只是針對這個世界的需要修復的問題的一個夢幻術語罷了。 + +你或許在查看 README 的時候，發現了失效的超連結、或發現了錯字。又或者你在使用的過程中發現了問題、某件你真的覺得該寫進說明文件的議題，與其視而不見或請別人處理，試著自己投入看看是否有你能幫上忙的地方，這就是開源的精神！ + +> 平均一個專案有[28% 的貢獻是隨意且偶然的](http://www.igor.pro.br/publica/papers/saner2016.pdf) ，像是寫說明文件、修正錯字、調整格式或翻譯。 + +你也可以利用如下列的資源來找到合適的新專案： + +* [GitHub 探索](https://github.com/explore/) +* [First Timers Only](http://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](http://up-for-grabs.net/) +* [貢獻忍者](https://contributor.ninja) +* [最初的贡献](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### **提交貢獻前應做的檢查清單** + +當你找到了你打算貢獻的專案時，在有任何行動之前，先整體做個瀏覽，確保專案是願意接受貢獻的。否則，你辛勤的工作可能沒有任何的回報。 + +以下是一個簡易的檢查表，用來評估一個專案是否適合新的貢獻者。 + +**符合開源的定義** + +
+ + +
+ +**專案是否積極地接受各方的貢獻** + +在 main branch 上看看提交的活躍度。在 GitHub 上託管的開源專案，你可以在專案主頁上看到這些訊息。 + +
+ + +
+ +
+ + +
+ +
+ + +
+ +接下來，就是看專案 issue 的數量。 + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +同樣再來看看 PR 的情形。 + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**專案是友善的** + +一個專案的友好程度意味着更能接納新的貢獻者。 + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## **如何提交成果** + +你已經找到了你喜愛的專案，也已準備好貢獻了，接下來就剩思考如何以一個適當的方式去貢獻。 + +### **有效溝通** + +無論你只是一次性的貢獻，或是決定長期參與社群，在開源的世界裡，學會如何與他人共事是很重要的技能之一。 + + + +在你提出一個 issue 或 PR 之前，或者是在聊天室提問之前，請謹記下面所列出的幾點建議，會讓你的工作更有效率。 + +**交代來龍去脈。** 以便於讓其他人能夠快速的理解。比方說執行程式時遇到一個錯誤，你要解釋你當時是想做甚麼，並描述如何做才能重現錯誤。又比方說你是提交一個新的想法，你要解釋爲什麼這麼想，為什麼你認為這點子對專案會有幫助（而不是只對你有幫助！） + +> 😇 _"當我做 Y 的時候 X 功能沒有正常運作"_ +> +> 😢 _"X 出問題! 請修好它。"_ + +**在進一步行動前，做好準備工作。** 不知道沒關係，但至少你要先嘗試過、努力過。在尋求幫助之前，請確認閱讀了專案的 README、文件、issue（open 的和 closed 的）、郵件列表，並在網絡上查查看。當你表現出很強烈的求知慾時，人們會很樂意的幫助你的。 + +> 😇 _"我不確定 X 是如何做到的，我查閱了說明文件，但沒有找到相關的介紹。"_ +> +> 😢 _"我該怎麼做 X 這件事?"_ + +**溝通時力求精簡明瞭。** 就像發送一份郵件、每一次的貢獻，無論是多麼的簡單，都是需要他人去檢閱的。很多專案都是請求的人多，提供幫助的人少。保持簡潔，能讓你得到他人幫助的機會大大增加。 + +> 😇 _"我很樂意寫 API 的教學。"_ +> +> 😢 _" 有一天開車在高速公路上，停在某個加油站加油的時候，我突發奇想，覺得我們應該這麼做，在進一步解釋之前，我先和大家展示一下… "_ + +**盡量讓溝通都是在公開場合下進行。** 盡量不要發私訊給維護者，雖然很多人會想這樣做，除非是你要分享一些機敏資訊（諸如安全問題或有人嚴重的違反行為準則）。你若能夠保持談話是公開的，很多人可以從彼此交換的意見中學習和受益。 + +> 😇 _（評論） "@維護者 你好！我們該如何處理這個 PR ？"_ +> +> 😢 _（郵件） "你好，非常抱歉發信給你，但是我實在很希望你能看一下我提交的 PR 。"_ + +**大膽的提問（但是要有耐心！）。** 每個人參與社群，開始的時候都是新手，哪怕是經驗老到的貢獻者也一樣，在剛進入一個新專案的時候，也是新手。出於同樣的原因，長期維護的人也並不一定都熟悉專案的每一個部分。協作時表現出你的耐心，你也會得到同樣的回報。 + +> 😇 _"感謝你檢查了這個錯誤，我按照您的建議做了，這是輸出結果。"_ +> +> 😢 _"你爲什麼不處理我的問題？這不是你的專案嗎？"_ + +**尊重社群的決定。** 你的想法可能會和社群的優先順序、願景有所差異，他們可能回覆了你的想法或最後決定不採納你的建言，這時你應該去積極討論並尋求折衷的辦法，維護者必須慎重的考慮你的想法。但是如果你實在是不能同意社群的做法，你還是可以堅持己見將專案分支（fork）出去另起爐灶。 + +> 😇 _"雖然我很遺憾你不能支援我的需求，但是你解釋這只是對一小部分使用者起作用，我理解你的理由。感謝你的耐心傾聽。"_ +> +> 😢 _"你爲什麼不支援我的需求？這真是難以接受！"_ + +**以上幾點，要銘記在心。** 開源是由來自世界各地的人們共同協作實現的。需要面對跨語言、跨文化、不同的地理位置、不同的時區的問題，另外，單純文字上的溝通無法傳達語氣和情緒。就先假設這些對話都充滿善意吧。不用害怕拒絕人家，詢問事情的狀況，進一步澄清你的立場。試著讓網路世界成為一個更好的地方。 + +### **多了解來龍去脈** + +在正式開始之前，做一些快速檢查，也許有人已經討論過你的疑惑了。瀏覽專案的 README、issue（ open 和 closed 都算）、郵件列表、Stack Overflow。毋需去花好幾個小時去全部折騰一遍，但是用幾個關鍵字搜尋一下是必要的。 + +如果你沒有找到和你想法一樣的內容，你就可以開工了。如果專案是在 GitHub 上的話，你可以開啓一個 issue 或 PR： + +* **Issues** 開啓一次對話或討論 +* **Pull requests** 請求接受自己的解決方法 +* **簡單的溝通** ，例如澄清或 how-to 的問題，嘗試到 Stack Overflow 、IRC、Slack 或其它聊天頻道問問看。 + +在你創建 issue 和 PR 之前，請檢查專案的貢獻者文件（文件名通常叫做 CONTRIBUTING，或者就直接寫在 README 中），找到你需要、較具體的東西，例如他們會要求你遵循某個樣板，或者是要求你使用某個測試。 + +如果你想做一個重大的貢獻，在正式開始之前先創建一個 issue。監控專案是很有幫助的（在GitHub，[點擊 "Watch"](https://help.github.com/articles/watching-repositories/) ，所有當中的對話都會通知你），通知社群的成員們，讓大家知道你要做的工作，免得你做了之後，他們事後才知道。 + + + +### 提出問題 + +你應該在遇到下列情況時，去創建一個 issue： + +* 報告一個你自己無法解決的錯誤 +* 討論一個重要的主題或想法（例如：社群、遠景、政策等） +* 提議做一個新的功能，或者其它專案的想法 + +在 issue 的溝通中幾點實用的技巧： + +* **假如你看到一個 open 的 issue，也是你打算解決的**，寫下留言，告訴其他人你要開工了。這樣的話，可以避免與其他人做了重複的事情。 +* **假如某個 issue 已經處於 open 的狀態很久了**，可能是有人正在處理中，又或者是已經解決了，也請你留言確認一下事情的狀態再決定下一步。 +* **假如你創建了 issue ，但是沒多久自己解決了**，也要留言，讓其他人知道，然後結束該 issue 。記錄本身就是爲社群的貢獻。 + +### **創建 pull request** + +在下面的情形時，請你務必使用 PR： + +* 提交簡易的補丁 (例如拼寫錯誤、失效的超連結、或者是其它較明顯的錯誤) +* 開始一項別人請求的任務，或者是過去在 issue 中早就討論過的事情 + +一個 PR 並不代表工作已經完成了。它通常是儘早開啓一個 PR ，這樣其他人可以了解或者給你一些回饋。只需要標記爲 "WIP"（Working in Progress）。你可以隨時添加任何留言。 + +如果說專案是託管在 GitHub 上，以下是我們對於提交 PR 的建議： + +* **[Fork 程式碼](https://guides.github.com/activities/forking/)** 並下載到自己的電腦，在本地端設定「上游」爲遠端倉庫。這樣你可以在提交你的 PR 時保持和「上游」同步，合併時會減少解決衝突的時間。（更多關於同步的說明，請參考[這裡](https://help.github.com/articles/syncing-a-fork/)。） +* **[創建一個分支](https://guides.github.com/introduction/flow/)** 方便自己編輯。 +* **參考任何相關的 issue**或在你的 PR 中註記相關的文件（例如："Closes #37."） +* **留下更動前後的螢幕截圖**，如果你修改了 HTML/CSS。在你的 PR 中放上截圖。 +* **測試你的工作！**用原本寫好的測試來跑你寫好的新功能，若沒有的話，則需要寫一個測試。無論是否有測試，一定要確保你的改動不會弄壞現有的專案的功能。 +* **和專案現有的風格保持一致**，盡你最大的努力，在使用縮排、分號或註釋很可能和你自己的風格大相徑庭，但這是為了節省維護者的精力，為了以後要了解、維護時的方便。 + +如果這是你第一次提交 PR。可以瀏覽[提交 PR](http://makeapullrequest.com/)的文件，這是 @kentcdodds 專門爲初次創建 PR 的人寫的手把手教學。 + +## **提交後需要善後的事宜** + +你做到了！恭賀你成爲貢獻開源的一員。希望這是一個好的開始。 + +在你提交了貢獻之後，下面幾種情形中的某種是可能發生的： + +### 😭 **沒有人理你。** + +希望你在工作開始之前[檢查過了專案的活躍度](./#提出問題)，不過有時即使檢查過了，在一個活躍的專案中沒有人理會你的貢獻也是很正常的。 + +如果過了一週，依舊沒有人回應，請心平氣和的在同個條目下留言，請人幫你審核。如果你知道可以找誰審核，你可以使用 @名字，提醒他一下。 + +**千萬不要**私下去聯絡他人；要記住開源專案裡，所有的溝通都應該是公開的。 + +如果還是沒有人回覆，那就是真的沒有人對你的貢獻做出回應。這可能感覺很差，但千萬不要灰心。每個人都會遇到這樣的情況。有很多原因會導致沒人回應你，這些原因通常也不是你能控制的。再接再厲，換一種方法去提交，或者換一個專案。這也是一個好時機讓你決定不要投資太多時間在成員活動不活躍的專案。 + +### 🚧 **有人希望你修改你的貢獻。** + +被人要求修改你的貢獻是很常見的事情，可能是改變你的提議，或是修改程式碼。 + +當有人提出變更時，請及時回覆。畢竟他們花時間看了你的工作。開了一則 PR ，然後一走了之是一個壞習慣。如果你不知道如何改，花點時間研究，如果還是沒有想到好辦法，那麼是該向他人求助的時候了。 + +如果你沒時間處裡一則 issue （舉例來說，如果對話已經持續了一個月了，而你還有其他的事情要處裡），那麼請通知維護的人，你無法及時的回覆了，肯定有人非常樂意接替你的工作的。 + +### 👎 **你的貢獻沒有被採納。** + +你的工作最後可能沒有被接受。希望你沒有為此花太多力氣。如果你不確定爲什麼沒有被接收，這正是一個很好的機會，去詢問維護者的看法、給他們一個澄清的機會。無論如何，你都要對他們的決定表示尊重。別花時間在爭論或樹立敵人上。如果你堅持自己，你還是可以隨意 fork 專案，按照自己的思路發展出分支來。 + +### 🎉 **你的貢獻被接受。** + +太棒了！你完成了一次開源貢獻！ + +## 你辦到了! + +不論你是第一次貢獻，還是正在嘗試其他的貢獻方式， 希望本文有提供你一些靈感去實踐。即便你的貢獻沒有被採納，別忘了對幫助過你的維護者表示感謝。開源就是由你這樣的人所打造：一則 issue、一則 PR或透過留言討論。 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-hant/leadership-and-governance.md b/_articles/zh-hant/leadership-and-governance.md new file mode 100644 index 00000000000..6ba380ebe46 --- /dev/null +++ b/_articles/zh-hant/leadership-and-governance.md @@ -0,0 +1,159 @@ +--- +lang: zh-hant +title: 領導與治理 +description: 有了正式規則的決策，可讓開源專案順利的成長。 +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +redirect_from: /zh-tw/leadership-and-governance/ +--- + +## 針對增長的專案來理解治理 + +當專案開始有條不紊的進行，人員也開始穩定，那麼你就應該開始社群的治理了。對於社群的治理，你或許有一些疑問，諸如如何將常規專案的貢獻者納入你的工作流？如何才能判斷應該賦予誰提交的權限？又或者是如何解決社群的債務？如果你對這些有疑問的話，我們這裏會盡力幫你解決。 + +## 開源專案中通常都有那些角色 + +很多專案針對貢獻者角色和身份均遵循相似的結構。 + +這些角色實際上意味着什麼完全取決於你。我們這裏所列舉的，相信你是非常熟悉的了： + +* **維護者** +* **貢獻者** +* **修訂者** + +**對於某些專案來說， "維護者"** 就是唯一擁有提交權限的人。然而在其它的一些專案中，維護者會列在README上 + +作爲一名維護者，不一定非得一定要爲專案撰寫程式。有可能是專案的佈道師，爲專案的宣傳做了很多的工作，又或者是撰寫文件讓更多的人參與進來。不管他們每天做什麼，維護者就是那些對專案方向負責的人，並致力於專案的改進。 + +**作爲 "貢獻者" 可以是任何人** ，只要提出issue或PR 就叫做貢獻者，那些爲專案作出有價值的都算（無論是分類問題，編寫程式還是組織會議），又或者是將他們的PR合並進主乾的（或許這個定義是最接近所謂的貢獻者的）。 + + + +**術語 "修訂者"** 可能用於區分其他形式的貢獻的提交訪問，這是一種特定類型的責任。 + +其實你可以根據自己喜歡的方式來定義專案的角色，[考慮使用更廣泛的定義](../how-to-contribute/#具體而言什麼是貢獻) 來鼓勵更多的形式的貢獻。無論技術技能如何，您都可以使用領導角色來正式識別爲您的專案做出突出貢獻的人員。 + + + +## 該如何將這些領導力角色正規化 + +將領導力角色正規化，可以幫助人們找到歸屬感，且可以讓其它社群成員明白應該找誰能夠獲得幫助。 + +對於一個較小的專案來講，指定領導者，只需要在 README 或 CONTRIBUTORS 文本文件中寫上他們的名字即可。 + +對於稍大型點的專案，如果你已經擁有了網頁的話，那麼請創建一個團隊的頁面，或者創建一個團隊領導的頁面。舉例來說， [PostgreSQL](https://github.com/postgres/postgres/) 就擁有一個[很全面地團隊頁面](https://www.postgresql.org/community/contributors/) ，而且每位貢獻者都擁有簡短的介紹。 + +如果你的專案擁有非常活躍的貢獻者社群，你或許會專門建立一個維護者的"核心團隊"，甚至是根據不同的話題所有者成立子的委員會（例如，安全，問題篩選，或者是社群準則）。讓人們自行組織、且能夠讓志願者自行找到自己喜歡的角色，而不是去分配他們。 + + + +領導者團隊或許要創建一個指定的頻道（如IRC），又或者是參與專案的日常討論（如Gitter或Google Hangout）。你需要將這些會議可以公開訪問，以便讓人們方便傾聽。舉例來說， + [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)就會[每週開一次會議，每次持續幾小時](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +一旦你建立了領導力角色，一定不要忘記撰寫文件，告訴人們如何成爲領導者！要爲如何成爲一名維護者或加入到專案的子委員會創建一個清晰的流程，並將之寫入 GOVERNANCE.md 文件。 + +諸如[Vossibility](https://github.com/icecrime/vossibility-stack) 這樣的工具，可以幫助你追蹤誰是（或不是）專案的貢獻者。爲這些資訊作說明，以避免社群出現維護者作出私自的決定。 + +另外，如果你的專案在託管在GitHub上，考慮將你的專案從個人賬戶遷移到某個組織，而且要爲組織增加額外的一個備份的管理員。 +[GitHub 上的組織](https://help.github.com/articles/creating-a-new-organization-account/) 能夠讓權限管理和多倉庫管理更加的輕鬆，而且可通過 [共享所有權](../building-community/#分享專案的所有權)來保護你的專案。 + +## 何時該賦予提交者權限 + +有的人認爲專案應該對所有人都開放提交訪問，從而讓任何人都可以做出貢獻。理由是這樣做的話，會讓人們感到擁有這個專案，進而達到鼓勵的目的。 + +換句話說，尤其是針對那些大型的、更加複雜的專案，你或許只是會給那些證明自己有能力提交程式碼的人賦予權限。這個沒有一個確切的衡量標準，做你認爲正確的就好了，或者是最讓專案成員感到舒服的方式。 + +假如專案是託管在GitHub上，可以使用[受保護的分支](https://help.github.com/articles/about-protected-branches/)來管理那些可以提交特定的分支情況。 + + + +## 對於開源專案來說有那些常見的治理結構 + +關於開源專案有三類通用的相關治理結構。 + +* **BDFL:** BDFL 是 "仁慈的獨裁者生活" 的縮寫. 在此結構下，有一個人（通常是專案的最初的作者）擁有專案中所有的最後決定權。[Python](https://github.com/python) 就是一個非常經典的例子。較小的專案可能默認就是 BDFL 結構，因爲他一般就是一到兩位維護者。若是公司組織的專案也極有可能會採用BDFL結構。 + +* **精英制:** **(注: 術語 "精英制" 對於一些社群可能具有消極的含義，其擁有較[複雜的社會和政治的歷史](http://geekfeminism.wikia.com/wiki/Meritocracy).)** 在精英制下，活躍的專案貢獻者（他們用行動證明自己是"精英"）給一個正式的決策作用，決定通常會基於純粹的投票一致性。精英制的概念首次由[Apache Foundation](http://www.apache.org/)提出；[所有的Apache 專案](http://www.apache.org/index.html#projects-list) 都是基於精英制的。貢獻者只能代表自己是獨立的個體，不可以是公司。 + +* **自由貢獻:** 在自由貢獻的模式下，做最多工作的人通常被認爲是最具影響力的，但是是基於當前的工作，而不是歷史的共享。專案的重大決策是基於尋求共識的過程（對不同的聲音要討論）而不是純粹的投票，儘可能的努力的去囊括多的社群觀點。較流行的使用自由貢獻模式的專案有[Node.js](https://nodejs.org/en/foundation/) 和 [Rust](https://rust-lang.org/)。 + +應該選擇哪一種模式了呢？由你自己來做決定！每個模式都有優點，也有缺點。雖然上面的描述乍一看，這三種模式有着很大的不同，其實不然，它們還是有着共同點的。如果你對上述三種模式有興趣，可以採用下面的模版： + +* [BDFL 模式模版](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [精英模式模版](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js 的自由貢獻規則](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79) + +## 當我創建開源專案時，需要專門撰寫一份治理文件嗎 + +其實沒有什麼合適的時間來撰寫專案的治理，但是可以根據社群的動態來進行恰當的定義。開源治理最好的也是最難的部分是有社群本身來塑造！ + +在專案的治理中，一些早期的文件將會不可避免的，然而也不必太強求，寫下你所能夠想到的。舉例來說，你可以將某些預期的行爲定義清楚，貢獻的流程是如何的，或者專案是如何啓動的，等等。 + +如果你自己是公司所啓動開源的一部分，在啓動之前，應該做一些討論，如公司將會如何維護專案，隨着專案的發展，決策該如何定奪。你可以會公開的解釋一下，貴公司將如何參與（或不參與）該專案。 + + + +## 公司員工該如何開啓提交貢獻之旅？ + +成功的開源專案，會有很多的用戶和公司使用，而且有一些公司的主要收入和專案是綁在一起的。舉例來說，某公司在其商業產品或服務中使用了開源專案的程式碼作爲其一個組件。 + +一個專案越是被廣泛的使用，有相關背景的專業人士的需求就會上升，**你或許就是其中之一**，那麼就順勢成爲繼續爲開源專案做事，還有一定的報酬。 + +將商業的活動視爲正常不過的事情很重要，它也只是程式碼的開發方法之一。爲開發者付費不應該被特殊的對待，好像程式碼必須是無償開發的才行；每個貢獻都必須有技術的衡量標準來進行評估。人們應該在這些商業的活動中感到非常的自在，而且針對特定的增強或功能項討論時也應是坦蕩的、自然的。 + +"商業" 是完全和"開源"相容的。"商業"僅僅是意味着某些地方有錢的參與 —— 就是說軟體被用於了商業行爲，也就是說專案被採用獲得了認可。（當開源軟體被用於非開源產品的一個部分時，這個整體的產品仍然是"專有的"軟體，因爲開源，它可以用於商業或非商業的目的。） + +和這個世界上很多的其它商業產品一樣，商業能夠激勵開發者去積極的貢獻於專案，通過他們靠譜的提交貢獻。顯而易見的是，一位因花了自己的時間和精力的開發者獲得報酬，理應比沒有獲得報酬的更具持久性，當然，這對於某些聖徒是不成立的，或者這麼說吧，報酬是能體現一個貢獻度的衆多衡量因素的其中之一。所以將你的專案討論聚焦於貢獻上，不要讓人們分散精力去思考或做其它的事情。 + +## 我是否需要一個法律實體來支持我的專案 + +除非你特別的有錢，其實你根本沒有必要爲開源專案而專門搞一個法律實體來支持。 + +舉例來說，假如你打算創辦自己的商業公司，（假如是在美國的話）你需要成立一家集團公司或有限責任公司。如果你只是爲你的開源專案做一些合約的工作，你可以以投資人的身份接受錢財，或者成立一家有限責任公司（如果是在美國的話）。 + +如果你打算讓自己的開源專案接受捐贈的話，你可以創建一個捐贈按鈕（使用PayPal或Stripe，舉例來說），但是你要知道，這些錢並非是免稅的，除非你是認證過的非盈利性組織（在美國的話，諸如501c3）。 + +很多專案都不願意成立非盈利組織那麼麻煩，所以他們會以贊助商的身份尋找一個非營利性組織。財政資助代表你接受捐款,通常以換取一定比例的捐贈。針對開源專案接受財政資助的非營利性組織有很多，如[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) 等等。 + + + +如果你的專案是和某特定的語言或生態系統緊密相連的，那麼你可以直接在相關的軟體基金會下工作。例如，[Python 軟體基金會](https://www.python.org/psf/) 就幫襯著專案 [PyPI](https://pypi.python.org/pypi)，這是一塊優秀的Python包管理器，又比如[Node.js 基金會](https://nodejs.org/en/foundation/) 支撐着 [Express.js](http://expressjs.com/)，一款基於Node的框架。 diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md new file mode 100644 index 00000000000..7da68d25d2a --- /dev/null +++ b/_articles/zh-hant/legal.md @@ -0,0 +1,157 @@ +--- +lang: zh-hant +title: 開源的法律保障 +description: 對於開源你應該瞭解的法律知識。 +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +redirect_from: /zh-tw/legal/ +--- + +## 瞭解開源的法律含義 + +向世界分享你們具有創造性的工作，這是一個多麼令人激動和有價值的經歷。這也意味著你們必須擔心一堆你們不清楚的法律問題。幸運的是，你們不必從頭開始。我們已經涵蓋了你們的法律需求。（在你們行動前，請確定閱讀了我們的[免責聲明](https://github.com/cnbo/open-source-guide/blob/gh-pages/notices.md)。） + +## 爲什麼大家非常擔心有關開源的法律問題 + +很高興你們提問！當你們行創造性工作（例如寫作，圖形或程式碼）時，默認情況下該作品屬於專有版權（copyright）。也就是說，法律承認你們是你們作品的作者，他人在沒有經得你們同意的情況下不能使用你們的工作。 + +一般來說，這意味著沒有人可以在沒有你們授權的情況下使用，複製，分發或者修改你們的工作。 + +然而，開源有著不一樣的情況。因爲作者希望他人使用，修改以及分享他們的工作。但因爲法律默認依然是專有版權（copyright），所以你們需要一個明確說明這些權限的協議。 + +如果你們不應用開源許可協議，那麼對你們專案做出貢獻的人也都將成爲其工作的專屬版權（copyright）所有者。這意味著沒有人（也包括你們）可以使用，複製，分發後者修改他們的貢獻， + +最後，你們的專案可能具有你們不知道的許可證要求的依賴關係。你們的專案社群，或者你們的僱主政策也可能要求你們使用特定的開源許可協議。 + +## 公開的GitHub專案是開源的嗎 + +當你們在GitHub上[創建一個新專案](https://help.github.com/articles/creating-a-new-repository/) 時，你們可以選擇將倉庫設置成**private**或者**public**。 + +![Create repository](/assets/images/legal/repo-create-name.png) + +**讓你們的GitHub專案公開與許可你們的專案是不同的。**公開專案是由[GitHub的服務條款](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)保護，它允許他人瀏覽以及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 License](https://choosealicense.com/licenses/mit/)，不容易出錯。它很短，很容易理解，並允許任何人做任何事情，只要他們保留許可證的副本，包括你們的版權聲明。如果你們需要，您們能夠根據不同的許可協議發佈專案。 + +然而，爲專案選擇合適的開源許可協議這取決於你們。 + +你們的專案非常可能有（或將有）**依賴**。例如，如果你們開源了一個Node.js的專案，你們將可能使用來自npm（Node Package Manager）的庫。你們依賴的這些庫都有它們自己的開源許可協議。如果他們的許可協議"允許"（對使用，修改和分享給予公共權限，而對有關專案的許可協議沒有要求），這樣你們就可以使用任何你們想要的許可協議。共同允許許可協議包括MIT，Apache 2.0，ISC和BSD。 + +另一方面，如果你們的依賴中有一個的許可協議是"強硬的copyleft"（他們也給同樣的允許，但條件是有關專案得使用同樣的許可協議），那麼你們的專案將使用與之相同的許可協議。copyleft許可協議包括GPLv2，GPLv3和AGPLv3。 + +你們也會想到考慮希望你們的社群使用以及貢獻你們的專案： + +* **你們是否想讓你們的專案成爲其它專案的依賴？**在你們的相關社群最好儘可能使用最流行的許可協議。例如，[MIT](https://choosealicense.com/licenses/mit/)是[npm libraries](https://libraries.io/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/)適合你們。 + +你們的公司可能爲自己的專案準備了特定的許可協議。例如，它可能需要許可許可證，以便公司可以在公司的閉源產品中使用你們的專案。或者你們的公司要求強大的copyleft許可協議同時要求貢獻者贊成，這樣專案只屬於你們公司，沒有人能在有關的軟件中使用你們的專案。或者你們的公司可能有與標準，社會責任或透明度相關的某些需求，其中任何一個都可能需要特定的許可策略。與你們[公司的法律部門](#公司的法律團隊需要知道什麼)談談。 + +當你們在GitHub上創建了一個新專案，它給你們提供了選擇許可協議的機會。包括上面提到的可以使你們的GitHub專案開源的許可協議。如果你們想要瞭解其他選擇，可以通過查閱[choosealicense.com](https://choosealicense.com)找到適合你們專案（即使它[不是軟體](https://choosealicense.com/non-software/)）的許可協議。 + +## 如果我想更換專案的許可協議，該怎麼辦 + +大多數專案絕不需要更換許可協議。但是情況偶爾有變。 + +例如，隨著你們專案的壯大，它添加了新的依賴或用戶，或者你們的公司改變了策略，或者其他的要求要更換不同的許可協議。如果你們在開始專案的時候沒有添加許可協議，那麼再添加一個許可協議和更換許可協議是一樣的效果。當你們要添加或者更換專案的許可協議時，需要考慮以下三件事： + +**這件事很複雜。**確定許可協議的兼容性和合規行，以及誰擁有版權，這會非常快速地變得複雜和混亂。爲新的發佈和貢獻選擇一個新的且合適的許可協議與重新許可已存在的貢獻是不同的。一旦你們有任何想改變許可協議的想法，請首先讓法律團隊知道。即使你們已經或者能獲得可以更換許可協議的權限，請考慮者會給專案的其他用戶和貢獻者帶來怎樣的影響。將更換許可協議視爲"管理事件"，只有通過與專案的利益相關者進行明確的溝通和諮詢，才更有可能順利進行。請謹記，從一開始就爲你們的選擇和使用合適的許可協議。 + +**你們的專案已經有了許可協議。**如果專案的現有許可證與您要更改的許可證兼容，則可以開始使用新許可證。這是因爲如果A許可協議與B許可協議兼容，你們將遵守A的條款，同時遵守B的條款（但不一定反之亦然）。因此，如果你們目前正在使用許可型的許可協議（例如MIT），則可以更改爲具有更多條件的許可協議，只要你們保留MIT許可協議的副本和任何相關的版權聲明（即繼續遵守MIT許可協議的最低條件）。如果你們現在的許可協議不是許可型的（例如，copyleft或者你們還沒有許可協議）以及你們不是版權的唯一所有者，那麼你們不能將許可協議改爲MIT。基本上，只要是使用的許可型的許可協議，版權所有者能事先更換許可協議。 + +**你們的專案已經有版權所有者。**如果你們是你們專案的唯一貢獻者，然後你們或者你們的公司是專案版權的唯一所有者。你們可以添加或更換任何你們或者你們公司心儀的許可協議。不然你們需要取得其他版權所有者的同意。他們是誰？他們是已經參與你們專案提交的人。但有些情況是專案版權掌握在這些人的僱主手中。在某些情況下，人們只是做了_微小的_貢獻，但沒有硬性規定，在一些行程式碼下的貢獻不受版權保護。對與這樣的情況該怎麼辦？對於一個相對較小以及年輕的專案來說，取得所有貢獻者對更換許可協議的同意是可行的。。但對於大專案和老專案來說，你們必須尋求很多貢獻者以及他們繼承者的共識。Mozilla花費了多年重新授權Firefox，Thunderbird和相關軟件。 + +或者，你們可以讓貢獻者事先同意（通過額外的貢獻者協議 - 見下文）在某些條件下更改某些許可協議，這些更改將超過現有的開源許可協議。這會改變許可協議改的複雜性。如果在執行許可協議更改時，你們仍然想要和專案利益相關者進行溝通，你們需要從你們律師那得到更多幫助。 + +## 我的專案需要額外的貢獻者協議嗎 + +可能不要。對於大多數的開源專案，一個開源許可協議可作用與所有貢獻者和用戶。 + +貢獻者協議會給維護者帶來額外的管理工作。這些協議增加了多少工作得取決去專案和實施。簡單的協議可能要求貢獻者確認和點擊，在專案的開源許可協議下他們有權利貢獻。更複雜的協議可能需要法律的審查和貢獻者的僱主的簽字。 + +此外，貢獻者協議有時被認爲對專案社群不友好。他們也增加了人們參與社群的障礙。 + + + +一些情況下你們可能想要爲你們的專案考慮一個額外的貢獻協議： + +* 你們的律師想要所有的貢獻者明確接受貢獻者條款，或者因爲他們覺得只有開源許可協議還遠遠不夠。如果這是唯一的問題，那麼有肯定專案開源許可協議的貢獻者協議就足夠了。[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)就是這中類型的。 +* 你們認爲你們的專案在其有效期內需要更換許可協議，以及事先得到貢獻者的同意。 + +如果您們實需要在您的專案中使用額外的貢獻者協議，請考慮使用諸如CLA助手之類的集成，以最大限度地減少貢獻者的分心。 + +## 公司的法律團隊需要知道什麼 + +作爲一名公司的僱員，如果你們在發佈一個開源專案，你們首先需要讓法律團隊知道。 +即使只是一個個人專案，請考慮讓他們知道。你們可能和公司有一個"員工知識產權協議"，這給了公司一些對你們專案的控制權，特別是當專案和公司的業務有著很多的聯繫或者你們使用公司的資源發展專案。你們的公司_應該_很容易給們許可，也許已經通過一個員工友好的知識產權協議或公司政策。如果不是這樣，你麼可以談判（例如，解釋你們的專案爲公司的專業學習和發展目標服務），或者你們在找到一個更好的公司前停止你們專案的工作。 + +**如果你們的開源專案是爲了你們的公司，**絕對需要讓他們知道。根據公司的業務需求和專業知識，你們的法律團隊可能已經制定了有關開放源程式碼許可協議（以及可能還有其他貢獻者協議）的政策，以確保您的專案符合其依賴關係的許可協議。如果不是這樣，你們和他們很幸運！你們的法律團隊應該渴望與你們合作，把這個東西搞清楚。你們需要思考這些事： + +* **第三方資源：**你們的專案有其他人創建的依賴或者使用他人的程式碼？如果這些是開源專案，你們需要遵守第三方資源的開源許可協議。首先，選擇與第三方資源的開放源許可協議一起使用的許可協議（見上文）。如果你們的專案修改或者發佈第三方開源資源，那麼你們法律團隊還想知道你們符合第三方開源許可協議的其他條件，例如保留版權聲明。如果你們使用了其他沒有開源許可協議的程式碼，那麼你們可能會要求第三方資源的維護者[添加一個開源許可協議](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/HEAD/github-open-source-guide-02.md#避免命名衝突)。如果你們將自己公司的商標用於專案，請檢查它有沒有造成衝突。[FOSSmarks](http://fossmarks.org/)是在自由和開源專案的背景下理解商標的實用指南。 + +* **隱私：**你們的專案是否收集了用戶數據並存儲到公司的服務器？你們的法律團隊可以幫助你們遵守公司政策和外部法規。 + +如果你們發佈了公司的第一開源專案，爲了能通過，以上這些綽綽有餘（不要擔心，大多數專案不會引起重大關注）。 +長期來說，們的法律團隊可以做更多的事情，以幫助公司從開源中獲得更多，並保持安全： + +* **員工貢獻策略：**考慮制定一個公司策略，指明你們的員工如何爲開源專案貢獻。明確的政策將減少你們員工的迷惑，並幫助他們爲公司的最佳利益向開源專案做貢獻，無論是作爲他們工作的一部分還是在自由時間。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/blog/why-companies-that-use-open-source-need-a-compliance-program/)可以避免麻煩，產品延遲發佈和訴訟。 + + + +* **專利：**你們的公司可能希望加入[開放發明網絡](http://www.openinventionnetwork.com/)，一個共享的專利防禦池，以保護成員使用主要開源專案，或探索其他替代專利許可。 + +* **管理：**特別是當如果將專案轉移到公司以外的法律實體是有意義的。 diff --git a/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..e09d43caa41 --- /dev/null +++ b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,218 @@ +--- +lang: zh-hant +untranslated: false +title: 保持平衡——開源專案維護者的指南 +description: 作為一名維護者，照顧自己並避免疲憊的小建議。 +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +隨著一個開源專案的受歡迎程度不斷增長，設定清晰的界限變得至關重要，以幫助您保持平衡，確保長期保持清新和高效。 + +為了深入了解維護者的經驗以及他們尋找平衡的策略，我們與Maintainer Community的40名成員一起進行了一個工作坊，讓我們能夠從他們在開源領域遭受疲憊的第一手經驗中學習，以及幫助他們在工作中保持平衡的實踐。這就是個人生態學的概念派上用場的地方。 + +那麼，什麼是個人生態學？正如Rockwood Leadership Institute所描述的，它涉及"保持平衡、節奏和效率，以維持我們在長期活動中的能量。" 這個概念幫助維護者認識到他們的行為和貢獻是一個隨時間演變的更大生態系統的一部分。在維護者中，經常出現由於長期的工作壓力而導致的疲憊，這通常會導致動機的喪失，無法集中注意力，以及對您一起工作的貢獻者和社區缺乏同理心。根據世界衛生組織的定義，疲憊是一種由於長期的工作場所壓力而引起的綜合症狀，這種情況在維護者中並不少見。 + + + +透過擁抱個人生態學的概念，維護者可以主動避免疲憊，優先考慮自我照顧，並保持平衡感，以便做出最佳的工作表現。 + +## 作為維護者的自我照顧和避免疲憊的建議： + +### 辨識您參與開源工作的動機 + +花些時間反思開源維護中哪些部分能夠為您注入活力。了解您的動機可以幫助您以一種讓自己保持參與和迎接新挑戰的方式來優先考慮工作。無論是來自使用者的積極反饋、與社區合作和社交的樂趣，還是深入研究程式碼所帶來的滿足感，認識自己的動機可以幫助引導您的關注點。 + +### 反思是什麼使您失去平衡並感到壓力重重 + +了解導致我們感到疲憊的原因至關重要。以下是一些我們在開源維護者中常見的主題： + +* **缺乏積極的回饋：** 使用者更有可能在他們有投訴時聯絡您。如果一切都運作良好，他們通常會保持沉默。看到問題清單不斷增長，卻沒有積極的回饋顯示您的貢獻正在產生影響，可能會讓人感到沮喪。 + + + +* **不說"不"：** 在開源專案中，很容易承擔比您應該負責的更多責任。無論是來自使用者、貢獻者還是其他維護者，我們不能總是滿足他們的期望。 + + + +* **單獨工作：** 做一名維護者可能會讓人感到極度孤獨。即使您與一組維護者一起工作，過去幾年來，因分散的團隊難以親自聚會而變得困難。 + + + +* **時間和資源不足：** 對於那些必須犧牲自己的空閒時間來參與項目的志願維護者來說，這一點尤其真實。 + + + +* **需求衝突：** 開源充滿了擁有不同動機的群體，這可能很難應對。如果您受薪工作於開源項目，您的雇主的利益有時可能與社區的利益相衝突。 + + + +### 注意疲憊的跡象 + +您能夠保持這種節奏達10週嗎？10個月？10年？ + +有一些工具，例如來自 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 可以幫助您反思您目前的節奏，並查看是否有任何調整的空間。一些維護者還使用可穿戴技術來追蹤睡眠質量和心率變異性等指標（這些都與壓力有關）。 + + + +### 您需要什麼來持續支持自己和您的社群？ + +對每位維護者來說，這可能因年齡階段和其他外部因素而有所不同。但以下是一些我們聽到的主題： + +* **依賴社群：** 委託和找到貢獻者可以減輕工作負荷。項目有多個聯絡點可以幫助您在休息時不必擔心。與其他維護者和更廣泛的社群建立聯繫，例如 [Maintainer Community](http://maintainers.github.com/)。這可以是同儕支持和學習的重要資源。 + +您還可以尋找與使用者社群互動的方式，以便定期聽取反饋並了解您的開源工作的影響。 + +* **探索資金支持：** 無論您是尋找一些額外的財政支持，還是嘗試全職投入開源，都有許多資源可以幫助您！作為第一步，考慮啟用 [GitHub Sponsors](https://github.com/sponsors)，以允許其他人贊助您的開源工作。如果您考慮轉向全職，請申請下一輪的 [GitHub Accelerator](http://accelerator.github.com/)。 + + + +* **使用工具：** 探索工具，如 [GitHub Copilot](https://github.com/features/copilot/) 和 [GitHub Actions](https://github.com/features/actions)，以自動化乏味的任務，釋放更多時間進行有意義的貢獻。 + + + +* **休息和恢復：** 為自己的興趣和愛好留出時間，遠離開源項目的工作。週末休息一下，放鬆身心，並設定您的 [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) 以反映您的可用性！一晚好的睡眠對於您長期維護努力的能力可能會產生重大影響。 + +如果您發現項目的某些方面特別令人愉快，請嘗試結構化您的工作，以便您可以在一天中體驗到這些樂趣。 + + + +* **設定界限：** 您無法對每個請求都答應。這可以是簡單地說，"我現在無法處理這個，並且將來也沒有計劃"，或在 README 中列出您有興趣和不願意做的事情。例如，您可以說："我只會合併明確列出為什麼要這樣做的 PR"，或者，"我只會在每兩週的週四晚上 6 點到 7 點之間審查問題。" 這會讓其他人對您的期望有所了解，並且在其他時候有助於緩解貢獻者或使用者對您的時間的需求。 + + +學會堅定地制止有毒行為和負面互動。不對您不關心的事情付出精力是可以接受的。 + + + + + +請記住，個人生態學是一個不斷演變的實踐，隨著您在開源之旅中的進展而變化。通過優先考慮自我照顧和保持平衡感，您可以有效且持久地貢獻於開源社群，確保自己的幸福以及項目的長期成功。 + +## 額外資源 + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid +* [Governing Open](https://governingopen.com/) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series + +## 貢獻者 + +非常感謝所有與我們分享他們經驗和建議的維護者！ + +本指南由[@abbycabs](https://github.com/abbycabs)撰寫，[@jianan1104](https://github.com/jianan1104)翻譯，並得到以下貢獻者的貢獻： + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + 很多人! diff --git a/_articles/zh-hant/metrics.md b/_articles/zh-hant/metrics.md new file mode 100644 index 00000000000..9fffa326ec7 --- /dev/null +++ b/_articles/zh-hant/metrics.md @@ -0,0 +1,127 @@ +--- +lang: zh-hant +title: 開源衡量準則 +description: 透過持續的追蹤專案，幫助你做出最佳決策，讓開源專案更成功。 +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +redirect_from: /zh-tw/metrics/ +--- + +## 爲何要度量所有 + +數據，只有在充滿智慧的運用它，才能發揮出其應有的功效。作爲一名開源專案的維護者，可以利用數據來助自己一臂之力。 + +當獲取到很多的資訊之後，就可以做很多事，比如： + +* 理解用戶對一個新功能是怎麼反應的 +* 搞清楚新用戶是從哪裏來的 +* 鑑別，並且決定是否支持一個跑偏的使用場景或者功能 +* 量化你專案的流行程度 +* 知道你的專案是怎樣被別人使用的 +* 通過贊助商或者讚賞掙點小錢 + +舉個例子，[Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) 就利用Google數據分析，來幫助他們對工作進行了優先級的區分： + +> Homebrew 是免費的，完全由志願者在業餘時間維護。所以，我們沒有資源去做詳細的Hemobrew用戶調查從而決定如何更好的設計未來的新功能以及對當前的工作分出優先級。匿名的聚合用戶數據分析讓我們基於用戶如何，何地，何時使用Homebrew來優先考慮某些補丁和功能。 + +流行程度並不能代表一切。每個人都是因爲不同的原因參與到開源專案中來，如果你做專案維護者的原因是展示你的工作成果，公開你的代碼，或者只是爲了好玩，那麼度量標準可能對你來說就不是那麼的重要。 + +如果你想對自己的專案有一個深層次的瞭解，那麼請繼續閱讀下文介紹的分析專案活躍度的方法。 + +## 發現專案 + +在有人能夠使用或者回饋你的專案之前，他們得知道是否有這樣的專案存在，問問你自己：_人們都在尋找這樣專案嗎？_ + +![traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +如果你的專案是託管在GitHub, 你可以[訪問](https://help.github.com/articles/about-repository-graphs/#traffic) 獲取諸如多少人訪問過你的專案，他們從哪裏得知的之類的資訊。在你的專案主頁，點擊"Graphs", 然後"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)看看你的專案在一個給定的日期被克隆了多少次，按照獨立克隆者的總克隆數排序。 + +![clone graph](/assets/images/metrics/clone_graph.png) + +如果使用專案的數量低於發現專案的數量的話，那麼就有兩個問題值得考慮。他們是： + +* 你的專案沒有成功的轉化你的受衆，或者 +* 你吸引了錯誤的受衆 + +舉個例子，如果你的專案佔據了Hacker News的頭版頭條，你可能會看到一個流量的高峰，但是與此同時，轉化率會比較低，因爲Hacker News上所有人都看見了你的專案。如果你的Ruby專案是在Ruby研討會上宣傳的，那麼，更有可能從目標受衆羣體中獲得較高的轉化率。 + +努力找出你的受衆是從哪裏來的，然後在你的專案主頁尋求他們的反饋，看看是上述兩種情況的哪一種。 + +一旦知道了都是有那些人在使用你的專案的話，接下來就是看看他們會做些什麼，他們是否基於源程式碼開始構建？爲專案增加新的特性？他們將專案用於科研？還是業務？ + +## 留下來 + +人們找到了你的專案，而且已經在使用了。那麼接下來你要問自己的問題就是：_人們有對這個專案做貢獻嗎?_ + +不管什麼時候考慮貢獻者這個問題都不能算早。沒有大眾的參與，你就可能會把自己置於一個尷尬的境地，那就是你的專案雖然很 _流行_（很多人用）但是並不被 _支持_（維護者沒有足夠的時間來滿足用戶的需求）。 + +保持專案的進展需要[貢獻者的流動](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2)（意思是有進有出）因爲之前很活躍的貢獻者也可能會去幹別的事情。 + +可能會經常用的衡量社群的指標包括： + +* **貢獻者的總數和每個貢獻者的提交次數：** 有多少貢獻者，哪些是活躍的，哪些是不活躍。github上，你可以在"Graphs" -> "Contributors"面板查看這些資訊。目前，這個圖標只計算了那些往倉庫默認分支推送的貢獻者。 + +![contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **第一次，偶爾爲之的，和持續的貢獻者：** 幫助檢測是否有新的貢獻者，以及他們是不是會再來。（偶爾的貢獻者是那些提交的次數很少的人，當然啦，這個數目是多少取決於你，比如說五次。）如果沒有新的貢獻者，你的專案就會停滯不前。 + +* **打開的issue的數目和PR的數目：** 如果這些數目太高，就意味着你可能需要有人幫你給issue分類以及做代碼審查。 + +* **所有的打開過的issue和PR：** 一個issue被人提出說明你的專案對他來說比較重要。如果這個數目隨着時間在增長，這就意味着人們對你的專案感興趣。 + +* **不同種類的貢獻者：** 比如說，提交代碼，修復筆誤或者bug，或者在issue下面評論。 + + + +## 維護者活躍度 + +最後，你還需要確定一件事，那就是維護者有足夠的能力和時間處理社群的貢獻。最後一個問題你要問自己的是：_我是不是有足夠的時間和精力來回應社群？_ + +沒有責任心的維護者絕對是開源專案的災難。想象一下就知道，假如一位貢獻者提交了代碼或其他貢獻，但從來沒有得到過維護者的回覆，他 100% 會感到灰心，並最終選擇離開。 + +[來自Mozilla的研究](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) 說： **維護者的回應是鼓勵更多貢獻者中非常重要的一環**。 + +考慮記錄一下你或者其他的專案維護者對一次貢獻（issue或者PR）回應的時間，回應並不需要花多少精力。哪怕只是說一句："謝謝你的貢獻，我下週會查看的。" + +你也可以測量一在一個貢獻被處理的過程中狀態變化的時間。比如： + +* 一個issue保持打開狀態的時間（也就代表一個問題保持沒有被解決狀態的時間）。 +* 一個issue是否因爲一個PR得到解決。 +* 陳舊的iuuse是否被關閉了（被解決的問題應該關閉）。 +* 合併一個PR的時間。 + +## 使用 📊 學習關於人本身 + +理解一些細節能夠幫助你建設活躍的、成長的開源專案。哪怕是你無法追蹤每一個細節，通過使用上述的框架，將能夠讓你集中精力到該用力的地方，進而助專案成功！ diff --git a/_articles/zh-hant/security-best-practices-for-your-project.md b/_articles/zh-hant/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..f7a81a4fea6 --- /dev/null +++ b/_articles/zh-hant/security-best-practices-for-your-project.md @@ -0,0 +1,158 @@ +--- +lang: zh-hant +untranslated: true +title: Security Best Practices for your Project +description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security. + +## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA) + +### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages. + +Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services. + +MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to. + +## Secure your code as part of your development workflow + +### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production. + +Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases. + +It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code. + +How to choose your SAST tool? +Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep. +Check the coverage for your language(s) + +* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them. +* Beware of False Positives! You don't want the tool to slow you down for no reason! +* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep). + +## Don't share your secrets + +### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository. + +Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes. + +To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you. + +## Check and update your dependencies + +### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task. + +Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data. + +To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. + +## Understand and manage open source license risks + +### Open source licenses come with terms and ignoring them can lead to legal and reputational risks. + +Using open source dependencies can speed up development, but each package includes a license that defines how it can be used, modified, or distributed. [Some licenses are permissive](https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project), while others (like AGPL or SSPL) impose restrictions that may not be compatible with your project's goals or your users' needs. + +Imagine this: You add a powerful library to your project, unaware that it uses a restrictive license. Later, a company wants to adopt your project but raises concerns about license compliance. The result? You lose adoption, need to refactor code, and your project's reputation takes a hit. + +To avoid these pitfalls, consider including automated license checks as part of your development workflow. These checks can help identify incompatible licenses early in the process, preventing problematic dependencies from being introduced into your project. + +Another powerful approach is generating a Software Bill of Materials (SBOM). An SBOM lists all components and their metadata (including licenses) in a standardized format. It offers clear visibility into your software supply chain and helps surface licensing risks proactively. + +Just like security vulnerabilities, license issues are easier to fix when discovered early. Automating this process keeps your project healthy and safe. + +## Avoid unwanted changes with protected branches + +### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project. + +A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time. + +## Make it easy (and safe) to report security issues + +### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers? + +Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users. + +### Security Policy + +To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process. + +### Private Vulnerability Reporting + +On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool. + +### Define your threat model to help users and researchers understand scope + +Before security researchers can report issues effectively, they need to understand what risks are in scope. A lightweight threat model can help define your project's boundaries, expected behavior, and assumptions. + +A threat model doesn't need to be complex. Even a simple document outlining what your project does, what it trusts, and how it could be misused goes a long way. It also helps you, as a maintainer, think through potential pitfalls and inherited risks from upstream dependencies. + +A great example is the [Node.js threat model](https://github.com/nodejs/node/security/policy#the-nodejs-threat-model), which clearly defines what is and isn't considered a vulnerability in the project's context. + +If you're new to this, the [OWASP Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process) offers a helpful introduction to build your own. + +Publishing a basic threat model alongside your security policy improves clarity for everyone. + +## Prepare a lightweight incident response process + +### Having a basic incident response plan helps you stay calm and act efficiently, ensuring the safety of your users and consumers. + +Most vulnerabilities are discovered by researchers and reported privately. But sometimes, an issue is already being exploited in the wild before it reaches you. When this happens, your downstream consumers are the ones at risk, and having a lightweight, well-defined incident response plan can make a critical difference. + + + +Even when a vulnerability is reported privately, the next steps matter. Once you receive a vulnerability report or detect suspicious activity, what happens next? + +Having a basic incident response plan, even a simple checklist, helps you stay calm and act efficiently when time matters. It also shows users and researchers that you take incidents and reports seriously. + +Your process doesn't have to be complex. At minimum, define: + +* Who reviews and triages security reports or alerts +* How severity is evaluated and how mitigation decisions are made +* What steps you take to prepare a fix and coordinate disclosure +* How you notify affected users, contributors, or downstream consumers + +An active incident, if not well managed, can erode trust in your project from your users. Publishing this (or linking to it) in your `SECURITY.md` file can help set expectations and build trust. + +For inspiration, the [Express.js Security WG](https://github.com/expressjs/security-wg/blob/main/docs/incident_response_plan.md) provides a simple but effective example of an open source incident response plan. + +This plan can evolve as your project grows, but having a basic framework in place now can save time and reduce mistakes during a real incident. + +## Treat security as a team effort + +### Security isn't a solo responsibility. It works best when shared across your project's community. + +While tools and policies are essential, a strong security posture comes from how your team and contributors work together. Building a culture of shared responsibility helps your project identify, triage, and respond to vulnerabilities faster and more effectively. + +Here are a few ways to make security a team sport: + +* **Assign clear roles**: Know who handles vulnerability reports, who reviews dependency updates, and who approves security patches. +* **Limit access using the principle of least privilege**: Only give write or admin access to those who truly need it and review permissions regularly. +* **Invest in education**: Encourage contributors to learn about secure coding practices, common vulnerability types, and how to use your tools (like SAST or secret scanning). +* **Foster diversity and collaboration**: A heterogeneous team brings a wider set of experiences, threat awareness, and creative problem-solving skills. It also helps uncover risks others might overlook. +* **Engage upstream and downstream**: Your dependencies can affect your security and your project affects others. Participate in coordinated disclosure with upstream maintainers, and keep downstream users informed when vulnerabilities are fixed. + +Security is an ongoing process, not a one-time setup. By involving your community, encouraging secure practices, and supporting each other, you build a stronger, more resilient project and a safer ecosystem for everyone. + +## Conclusion: A few steps for you, a huge improvement for your users + +These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues. + +Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface. + +## Contributors + +### Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: + +[@JLLeitschuh](https://github.com/JLLeitschuh), [@intrigus-lgtm](https://github.com/intrigus-lgtm), [@UlisesGascon](https://github.com/ulisesgascon) + many others! diff --git a/_articles/zh-hant/starting-a-project.md b/_articles/zh-hant/starting-a-project.md new file mode 100644 index 00000000000..65a75b30853 --- /dev/null +++ b/_articles/zh-hant/starting-a-project.md @@ -0,0 +1,364 @@ +--- +lang: zh-hant +title: 發起一個開源專案 +description: 從開源的世界汲取智慧，著手發起開源專案。 +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +redirect_from: /zh-tw/starting-a-project/ +--- + +## 什麼是開源，爲什麼要開源 + +所以你在考慮開始參與開源？恭喜！世界讚賞你的貢獻。讓我們來談談開源是什麼，以及人們這樣做。 + +### "開源"是什麼意思 + +當一個專案被開源，這意味着**任何人都可以出於任何目的查看，使用，修改和分發你的專案**。 這些權限通過[開源許可](https://opensource.org/licenses)強制實施。 + +開源是強大的，因爲它降低了事物被採納的障礙，允許想法迅速傳播。 + +要瞭解它的工作原理，想象你的朋友組織了一場聚餐，而你帶去了一個櫻桃派。 + +* 每個人都嚐了那個派（_使用_) +* 派的味道棒極了！大家請你分享它的配方（_view_） +* 一個叫 Alex 的朋友是個糕點師，他建議少放點糖（_modify_） +* 一個叫 Lisa 的朋友想要用它作爲下週的晚餐（_distribute_） + +相比之下，一個閉源過程就像去一家餐廳訂購一個櫻桃派。你必須爲了吃餅支付費用，餐廳恐怕不會給你他們的食譜。如果你準確地複製了他們的餡餅，並以你自己的名義出售，餐廳可以對你採取措施。 + +### 人們爲什麼把他們的作品開源？ + + + +個人或組織爲何想要開源一個專案，[有各種各樣的的原因](http://ben.balter.com/2015/11/23/why-open-source/)，例如： + +* **協作：** 開源專案可以接受世界各地人們的修改。 例如 [Exercism](https://github.com/exercism/) 就是一個擁有350多個貢獻者的練習平臺。 + +* **採用和重組：** 任何人幾乎可以出於任何目的使用開源專案。人們甚至可以使用它來構建其他東西。例如，[WordPress](https://github.com/WordPress) 就是派生自一個名爲 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) 的現有專案。 + +* **透明度：** 任何人都可以檢查開源專案是否有錯誤或不一致。 透明度對[保加利亞](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 或[美國](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/)等政府，銀行或醫療保健等受監管行業以及 [Let's Encrypt](https://github.com/letsencrypt) 等安全軟件都很重要。 + +開源並不僅僅限於軟件。您可以開源任何事物，從數據集到書本。查看 [GitHub Explore](https://github.com/explore) 開找找有什麼是你可以開源的。 + +### 開源是指"免費"嗎 + +開源最大的吸引之一是它不花錢。 但是，"免費"只是開源的總體價值的一個副產品。 + +因爲[開源許可證要求](https://opensource.org/osd-annotated)任何人可以幾乎出於任何目使用，修改和共享您的專案，專案本身往往是免費的。 如果該專案花錢使用，任何人也都可以合法地複製和使用免費版本。 + +因此，大多數開源專案是免費的，但"免費"不是開源定義的一部分。 有些方法可以通過雙重許可或有限功能間接地爲開源專案收費，同時仍然遵守開源的官方定義。 + +## 我是否應該發起我自己的開源專案 + +簡單來說，答案是肯定的，因爲無論結果如何，啓動您自己的專案來瞭解開源的工作原理是一個好方法。 + +如果你從來沒有創建過一個專案，你可能會擔心人們會說什麼，或者是否有人會注意到。 如果這聽起來像你現在的狀態，別擔心，你並不孤獨！ + +開源工作就像任何其他充滿創意的活動，無論是寫作還是繪畫。 向世界分享你的作品會讓你提心吊膽，但唯有練習能夠讓你的感覺變好的方法 - 即使你沒有觀衆。 + +如果你還不確信，請花一點時間思考你的目標可能是什麼。 + +### 設置你的目標 + +目標可以幫助你弄清該做什麼，不應該說什麼，以及你在哪方面需要其他人的幫助。 首先問自己，_我是爲什麼開源這個專案？_ + +這個問題沒有標準答案。 對於一個專案你可以有多個目標，或者具有不同目標的不同專案。 + +如果你唯一的目標是炫耀你的工作，你甚至可能不需要他人的貢獻，甚至在你的 README 中說明這點。但另一方面，如果你需要貢獻者，你會投入時間來使文檔清晰，好讓新的參與者感到歡迎。 + + + +隨着你的專案增長，你的社群可能不僅需要你的代碼。迴應問題，審查代碼和傳播你的專案都會成爲開源專案中的重要任務。 + +而你在非編碼的任務上花費的時間將取決於專案的大小和範圍，你應該準備好作爲維護者來自己解決或找人幫助你。 + +**如果你是公司開源專案的一部分，** 確保你的專案有它需要茁壯成長的內部資源。 你需要確定誰在啓動後負責維護專案，以及如何與你的社群共享這些任務。 + +如果你需要專門的預算或人員來促進，操作和維護專案，請儘早提出。 + + + +### 加入其他專案 + +如果你的目標是學習如何與他人合作或瞭解開源的工作方式，請考慮爲現有專案做出貢獻。從你已經使用並喜歡的專案開始。像修復拼寫錯誤或更新文檔簡單的事也能爲專案做出貢獻。 + +如果你不知道如何開始作爲貢獻者，請查看我們的[如何貢獻開源指南](../how-to-contribute/)。 + +## 發起自己的開源專案 + +即使你沒有很好的時間來開源你的工作。你也可以開源一個想法，正在進行中的工作，或是關閉了多年的源碼。 + +一般來說，如果你樂意於他人對你工作的查看和反饋，你就應該開源你的專案。 + +無論您決定開展專案的哪個階段，每個專案都應包括以下文檔： + +* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Code of conduct](../code-of-conduct/) + +作爲維護者，這些組件將幫助你交流你的期望，管理貢獻並保護每個人的合法權益（也包括您自己的）。他們能夠大大增加你積極體驗的機會。 + +如果您的專案在 GitHub 上，則將這些文件放在您的根目錄中，並使用推薦的文件名將有助於 GitHub 識別並自動將其顯示給讀者。 + +### 選擇一個許可證 (license) + +開源許可證保證其他人可以使用，複製，修改和貢獻給您的專案，而不會產生不良後果。 它也可以保護您免受繁瑣的法律影響。**啓動開源專案時，請務必包含許可證。** + +法律工作是非常無趣的。但好消息是，您可以將現有許可證複製並粘貼到存儲庫中。只需要花這麼一點時間，就能保護你的辛苦工作。 + +[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 的很好的理由。 + +想要獲得更多靈感，請嘗試使用 @18F 的 ["讓 README 可讀"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) 或者 @PurpleBooth 的 [README 模板](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) 來撰寫一個完整的 README。 + +當你在根目錄中包含一個 README 文件時，GitHub 會自動將其顯示在存儲庫的主頁上。 + +### 編寫你的貢獻指南 + +貢獻文件 (CONTRIBUTING file) 告訴你的受衆如何參與你的專案. 例如，你可以包括一下資訊: + +* 如何提交錯誤報告（嘗試使用[issue 和 pull request 模板](https://github.com/blog/2111-issue-and-pull-request-templates)） +* 如何建議一個新功能 +* 如何配置你的環境和運行測試 + +除了技術細節， 貢獻文件也是一個供你傳達對貢獻期待的機會， 例如： + +* 你在尋求的貢獻類型 +* 你專案的路線圖或者版本 +* 貢獻者應該（或者不應該）如何與你取得聯繫 + +溫柔友好的逾期和向貢獻者們提供具體的建議（例如寫文檔或者搭建一個網頁）能夠有效地使新人感到受歡迎並樂於參與其中。 + +例如，[Active Admin](https://github.com/activeadmin/activeadmin/) 以這樣的方式開始[它的貢獻指南](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)： + +> 首先， 非常感謝你考慮爲 Active Admin 貢獻幫助。正式你這樣的人們使得 Active Admin 成爲瞭如此優秀的工具。 + +在你專案開始的初期，你的貢獻文件可以很簡單。你應該經常解釋如何提交錯誤和文件問題，以及關於如何作出貢獻的技術問題（例如測試）。 + +隨着時間的推移，你硬弓增加其他常見問題到你的貢獻文件中去。寫下這些資訊意味着問你相同問題的人會越來越少。 + +想要獲得更多有關編寫貢獻文件的方式，請查閱 @nayafia 的 [貢獻指南模板](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) 或者 @mozilla 的 ["如何構建 CONTRIBUTION.md"](http://mozillascience.github.io/working-open-workshop/contributing/)。 + +來你的 README 中鏈接你的 CONTRIBUTING，這樣更多人就能看到他。如果你[在你的專案中放入了 CONTRIBUTING 文件](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)，當一個貢獻者創建 issue 或者開啓一個 pull request 時，GitHub 會自動鏈接你的文件。 + +![貢獻指南](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### 建立行爲規範 + + + +最後，行爲規範有助於爲你專案的參與者車裏行爲規則。這在你爲社群或者專案推出一個開源專案的時候尤爲有價值。一份行爲幫助你促進健康，有建設性的社群行爲，這也會減輕你作爲維護者的壓力。 + +更多資訊，請參見 [行爲規範指導](../code-of-conduct/)。 + +除了傳達你期待參與者**如何**行動，行爲規範也傾向於描述這些期待針對誰，適用於何時，以及對於違規行爲的處理方法。 + +就像開源許可證一樣，有現成的行爲規範，所以你不必自己編寫。[貢獻者公約](http://contributor-covenant.org/)是一個行之有效的行爲規範，已經被用在[超過4000個開源專案](http://contributor-covenant.org/adopters/)，包括 Kubernetes，Rails，以及 Swift。無論你使用哪一種，你都應該準備好在必要時執行行爲規範。 + +將文本直接粘貼到專案存儲庫中的 CODE_OF_CONDUCT 文件中。將文件保存在專案的根目錄中，以便輕鬆找到，並從 README 中鏈接到它。 + +## 爲專案命名及設立品牌 + +品牌不僅是一個華麗的logo或者易記的專案名。它還關於你如何談論你的專案，以及你想把資訊傳遞給誰。 + +### 選擇正確的名字 + +選擇一個容易記住，有創意，能表達專案用意的名字。例如： + +* [Sentry](https://github.com/getsentry/sentry) 監控應用程序的崩潰報告 +* [Thin](https://github.com/macournoyer/thin) 是一個簡單快速的Ruby web服務器。 + +如果你的專案是基於一個已存在的專案創建，那麼使用他們的名字作爲你專案名的前綴會幫助你闡述你專案的用途。 (例如 [node-fetch](https://github.com/bitinn/node-fetch)將`window.fetch` 添加到了 Node.js)。 + +考慮闡明所有。押韻雖然有趣，但是記住玩笑不可能轉變成其它的文化，或者他人與你有不同的經歷。你的一些潛在用戶可能是公司員工，你不能讓他們在工作中很難解釋你的專案！ + +### 避免命名衝突 + +[查看是否有同名的開源專案](http://ivantomic.com/projects/ospnc/)，尤其是你分享的是同樣的語言或者生態系統。如果你的名字與一個已存在的知名的專案有衝突，你會讓你的粉絲感到困惑。 + +如果你想要一個網站，Twitter賬號或者其他特性來展示你的專案，先確保你能得到你想要的名字。理想情況下，爲了美好的未來[現在保留這些名字](https://instantdomainsearch.com/)，即使你現在不想用他們。 + +確保你的專案名沒有侵權。如果有侵權，可能會有公司要求你的專案下架，或者對你採取法律措施。這樣得不償失。 + + 你可以查閱[WIPO全球品牌數據庫](http://www.wipo.int/branddb/en/)避免商標衝突。如果你是在公司工作，[法律團隊會幫你做這件事](../legal/)。 + +最後，去谷歌搜索你的專案名。大家會很容易地找到你的專案嗎？在搜索結果禮是否有你不想讓大家看到的東西？ + +### 你的寫作（和代碼）如何影響你的品牌 + +在專案的整個生命週期中，你需要做很多文字工作：READMEs，教程，社群文檔，回覆issues，甚至可能要處理很多來信和郵件。 + +是否是官方文檔或者一封普通的郵件，你的書寫風格都是你專案品牌的一部分。考慮你可能會擁有粉絲，以及這是你想傳達的聲音。 + + + +使用熱情，通俗易懂的語言（如"他們"，即使是指一個人）能夠讓新來的貢獻者感覺專案非常歡迎他們。使用簡單的語言，因爲你的讀者可能英語不是很好。 + +除了書寫風格外，你的編碼風格也是你專案品牌的一部分。 [Angular](https://github.com/johnpapa/angular-styleguide) 和 [jQuery](http://contribute.jquery.org/style-guide/js/)是兩個專案代碼風格嚴謹的示例和指南。 + +當你的專案纔開始時，沒有必要爲專案編寫一份風格指南。你可能會發現你喜歡將不同的編碼風格融入到專案。但是你應該想到你的書寫和編碼風格會吸引或者拒絕不同類型的人。專案的早期是你建立你希望看見的先例的機會。 + +## 發起專案之前的檢查項 + +準備好開源你的專案了嗎？有一份幫助檢查清單。檢查所有內容？你準備開始吧！ [點擊 "publish"](https://help.github.com/articles/making-a-private-repository-public/) 以及拍下自己的後背。 + +**文檔** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**代碼** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**人** + +如果你是代表個人： + +
+ + +
+ +如果你有一家公司或者組織： + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## 你做到了 + +恭喜你開源了你的首個專案。不論結果如何，對開源社群都是一份禮物。隨着每次commit,comment和pull request，你正在爲自己或者他人創造學習和成長的機會。 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 new file mode 100644 index 00000000000..0997210c73a --- /dev/null +++ b/_data/locales/de.yml @@ -0,0 +1,31 @@ +de: + locale_name: Deutsch + nav: + about: Über + 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 + article: + table_of_contents: Inhaltsverzeichnis + back_to_all_guides: Zurück zur Übersicht + related_guides: Verwandte Anleitungen + footer: + contribute: + heading: Mitmachen + description: Möchten Sie etwas vorschlagen? Unsere Anleitungen sind quelloffen. Helfen Sie uns, sie zu verbessern. + button: Mitmachen + subscribe: + heading: Bleiben Sie in Kontakt + description: Erfahren Sie als Erste*r von GitHubs neuesten Open-Source-Tipps und -Ressourcen. + label: E-Mail-Adresse + button: Abonnieren + byline: + # [code], [love], und [github] werden mit Octicons ersetzt. + format: "[code] mit [love] von [github] und [friends]" + # Label für das Code-Octicon + code_label: code + # Label für das Herz-Octicon + love_label: love + # Label für das Octicon der Mitwirkenden + 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 72926681599..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: Be the first to hear about GitHub's latest open source tips and resources. - label: Dirección de correo + description: Sea el primero en enterarse de los últimos consejos y recursos de código abierto. + 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 new file mode 100644 index 00000000000..76cf2976556 --- /dev/null +++ b/_data/locales/fr.yml @@ -0,0 +1,31 @@ +fr: + locale_name: Français + nav: + about: A propos + contribute: Contribuer + index: + 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 à tous les guides + related_guides: Guides liés + footer: + contribute: + heading: Contribuer + 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 + button: S'abonner + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] avec [love] par [github] et [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: amour + # Label for the contributors link + friends_label: amis 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/hu.yml b/_data/locales/hu.yml new file mode 100644 index 00000000000..d78dfc39cb8 --- /dev/null +++ b/_data/locales/hu.yml @@ -0,0 +1,31 @@ +hu: + locale_name: Magyar + nav: + about: Rólunk + contribute: Közreműködés + index: + lead: A nyílt forráskódú szoftvereket ugyanolyan emberek készítik mint te. Tanuld meg, hogy hogyan indíthatod el és hogyan növekedhet a projekted! + opensourcefriday: Péntek van! Szánj pár órát a kedvenc szoftveredre amit használsz! + article: + table_of_contents: Tartalomjegyzék + back_to_all_guides: Vissza az Útmutatókra + related_guides: Kapcsolódó Útmutató + footer: + contribute: + heading: Közreműködés + description: Van javaslatod? Ez a tartalom is nyílt forráskód, segíts benne! + button: Közreműködés + subscribe: + heading: Maradjunk kapcsolatban + description: Legyél Te az első, aki hall a GitHub's legfissebb nyílt forráskódú híreiről és anyagairól + label: Email cím + button: Feliratkozás + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] amely [love] készült a [github] és [friends] által" + # Label for code octicon + code_label: kód + # Label for love octicon + love_label: szeretettel + # Label for the contributors link + friends_label: barátai 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/pt.yml b/_data/locales/pt.yml new file mode 100644 index 00000000000..58533f9d454 --- /dev/null +++ b/_data/locales/pt.yml @@ -0,0 +1,31 @@ +pt: + locale_name: "Português" + nav: + about: Sobre + contribute: Contribua + index: + lead: "Software open source é feito por pessoas assim como você. Aprenda como iniciar e expandir o seu projeto." + opensourcefriday: "É Sexta-feira! Invista algumas horas contribuindo para o software que você usa e ama" + article: + table_of_contents: "Índice" + back_to_all_guides: Voltar para todos os guias + related_guides: Guias relacionados + footer: + contribute: + heading: Contribua + description: "Quer fazer um sugestão? Este conteúdo é open source. Ajude-nos a melhorá-lo." + button: Contribua + subscribe: + heading: Fique ligado(a) + description: "Seja o(a) primeiro(a) a saber as últimas dicas e recursos open source do GitHub." + label: Endereço de E-mail + button: Inscrever-se + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] com [love] pelo [github] e seus [friends]" + # Label for code octicon + code_label: codificado + # Label for love octicon + love_label: amor + # Label for the contributors link + friends_label: amigos diff --git a/_data/locales/ro.yml b/_data/locales/ro.yml new file mode 100644 index 00000000000..ede0c73d7ad --- /dev/null +++ b/_data/locales/ro.yml @@ -0,0 +1,31 @@ +ro: + locale_name: Romanian + nav: + about: Despre + contribute: Contribuie + index: + lead: Software-ul cu sursă deschisă este făcut de oameni exact ca tine. Învață cum să îți lansezi și să îți crești proiectul. + opensourcefriday: Este vineri! Investește câteva ore contribuind la software-ul pe care îl folosești și îl iubești + article: + table_of_contents: Cuprins + back_to_all_guides: Înapoi la toate ghidurile + related_guides: Ghiduri relevante + footer: + contribute: + heading: Contribuie + description: Dorești să sugerezi ceva? Acest conținut este cu sursă deschisă. Ajută-ne să-l îmbunătățim. + button: Contribuie + subscribe: + heading: Păstrează legătura + description: Fii primul care să audă despe ultimele sfaturi și resurse despre open source ale GitHub. + label: Adresă de email + button: Abonează-te + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] cu [love] de [github] și [friends]" + # Label for code octicon + code_label: cod + # Label for love octicon + love_label: iubire + # Label for the contributors link + friends_label: prieteni 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 new file mode 100644 index 00000000000..10ca80cce10 --- /dev/null +++ b/_data/locales/ta.yml @@ -0,0 +1,31 @@ +ta: + 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/tr.yml b/_data/locales/tr.yml new file mode 100644 index 00000000000..9851448afd5 --- /dev/null +++ b/_data/locales/tr.yml @@ -0,0 +1,31 @@ +tr: + locale_name: Türkçe + nav: + about: Hakkında + contribute: Katkıda Bulun + index: + 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 + back_to_all_guides: Anasayfaya Geri Dön + related_guides: İlgili Kılavuzlar + footer: + contribute: + heading: Katkıda Bulun + 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 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] tarafından [love] ile [code]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: gönüllüler diff --git a/_data/locales/zh-cn.yml b/_data/locales/zh-cn.yml deleted file mode 100644 index 89028188460..00000000000 --- a/_data/locales/zh-cn.yml +++ /dev/null @@ -1,31 +0,0 @@ -zh-cn: - locale_name: 简体中文 - nav: - about: 关于 - contribute: 贡献 - index: - lead: 开放源代码软件就是由你这样的人所打造，这里只是为了节省你的学习时间而设，从这里开启你的开源项目之旅吧！ - opensourcefriday: It's Friday! Invest a few hours contributing to the software you use and love - article: - table_of_contents: 目录 - back_to_all_guides: Back to all guides - related_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: 代码 - # Label for love octicon - love_label: 爱心 - # Label for the contributors link - friends_label: friends diff --git a/_data/locales/zh-hans.yml b/_data/locales/zh-hans.yml new file mode 100644 index 00000000000..3c1aaa9534d --- /dev/null +++ b/_data/locales/zh-hans.yml @@ -0,0 +1,31 @@ +zh-hans: + 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/zh-hant.yml b/_data/locales/zh-hant.yml new file mode 100644 index 00000000000..db6a6373738 --- /dev/null +++ b/_data/locales/zh-hant.yml @@ -0,0 +1,31 @@ +zh-hant: + 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]" + # Label for code octicon + code_label: 程式 + # Label for love octicon + love_label: 愛心 + # Label for the contributors link + friends_label: 協作朋友 diff --git a/_includes/footer.html b/_includes/footer.html index 7bed68534ac..6680765bf2e 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -1,15 +1,18 @@ {% assign t = site.data.locales[page.lang][page.lang] %} +