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..b65eb374905 --- /dev/null +++ b/.github/dependabot.yml @@ -0,0 +1,48 @@ +version: 2 +updates: + - package-ecosystem: npm + directory: "/" + schedule: + interval: daily + time: "10:00" + timezone: Europe/Vienna + pull-request-branch-name: + separator: "-" + open-pull-requests-limit: 99 + rebase-strategy: disabled + commit-message: + prefix: "chore(deps)" + groups: + dependencies: + applies-to: version-updates + update-types: + - "minor" + - "patch" + - package-ecosystem: "github-actions" + directory: "/" + schedule: + interval: daily + open-pull-requests-limit: 99 + rebase-strategy: disabled + commit-message: + prefix: "chore(deps)" + groups: + dependencies: + applies-to: version-updates + update-types: + - "minor" + - "patch" + - package-ecosystem: bundler + directory: "/" + schedule: + interval: daily + versioning-strategy: increase + open-pull-requests-limit: 99 + commit-message: + prefix: "chore(deps)" + groups: + dependencies: + applies-to: version-updates + update-types: + - "minor" + - "patch" diff --git a/.github/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..6900c3bc23f --- /dev/null +++ b/.github/workflows/jekyll-preview.yml @@ -0,0 +1,63 @@ +# 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: + # Limit permissions of the GITHUB_TOKEN for untrusted code + permissions: + contents: read + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4 + with: + # For PRs make sure to checkout the PR branch + ref: ${{ github.event.pull_request.head.ref }} + repository: ${{ github.event.pull_request.head.repo.full_name }} + - name: Setup Pages + uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5 + - name: Build with Jekyll + uses: actions/jekyll-build-pages@b178f9334b208360999a0a57b523613563698c66 # v1 + with: + source: ./ + destination: ./_site + - name: Upload artifact + # Automatically uploads an artifact from the './_site' directory by default + uses: actions/upload-pages-artifact@56afc609e74202658d3ffba0e8f6dda462b719fa # v3 + # 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@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4 + with: + preview: 'true' diff --git a/.github/workflows/jekyll.yml b/.github/workflows/jekyll.yml new file mode 100644 index 00000000000..662d70b0d57 --- /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@692973e3d937129bcbf40652eb9f2f61becf3332 # v4 + - name: Setup Pages + uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5 + - name: Build with Jekyll + uses: actions/jekyll-build-pages@b178f9334b208360999a0a57b523613563698c66 # v1 + with: + source: ./ + destination: ./_site + - name: Upload artifact + # Automatically uploads an artifact from the './_site' directory by default + uses: actions/upload-pages-artifact@56afc609e74202658d3ffba0e8f6dda462b719fa # v3 + # 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@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4 diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml new file mode 100644 index 00000000000..063c3c76c9f --- /dev/null +++ b/.github/workflows/stale.yml @@ -0,0 +1,20 @@ +name: Mark stale PRs +on: + workflow_dispatch: + schedule: + - cron: "0 12 * * *" +jobs: + stale: + runs-on: ubuntu-latest + steps: + - uses: actions/stale@28ca1036281a5e5922ead5184a1bbf96e5fc984e # v9 + with: + stale-pr-message: > + This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. + + stale-pr-label: "stale" + exempt-pr-labels: "pinned,security" + days-before-pr-stale: 30 + days-before-pr-close: 7 + ascending: true + operations-per-run: 100 diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 401cc70771b..ebf1ef1f8b6 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -3,28 +3,22 @@ on: push: branches: master pull_request: [] + merge_group: jobs: tests: runs-on: ubuntu-latest steps: - - name: Set up Git repository - uses: actions/checkout@v1 - - - name: Set up Ruby - uses: actions/setup-ruby@v1 - - - name: Set up Node - uses: actions/setup-node@v1 - - - name: Restore bundler cache - uses: actions/cache@v1 - with: - path: vendor/gems - key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }} - restore-keys: ${{ runner.os }}-gems- - - - name: Bootstrap - run: script/bootstrap - - - name: Tests - run: script/test + - name: Set up Git repository + uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4 + - name: Set up Ruby + uses: ruby/setup-ruby@97e35c5302afcf3f5ac1df3fca9343d32536b286 # v1 + with: + bundler-cache: true + - name: Set up Node + uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4 + - name: Bootstrap + run: script/bootstrap + env: + SKIP_BUNDLER: true + - name: Tests + run: script/test diff --git a/.gitignore b/.gitignore index 1e32f1a37a4..177fab1a1b5 100644 --- a/.gitignore +++ b/.gitignore @@ -10,3 +10,4 @@ bin css/main.scss test/node_modules test/package-lock.json +Gemfile.lock 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..a3ec5a4bd3d --- /dev/null +++ b/.ruby-version @@ -0,0 +1 @@ +3.2 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..5833ae49be5 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 @@ -47,7 +47,7 @@ threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of -representing a project or community include using an official project e-mail +representing a project or community includes using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d07f0c1a17c..f64492b3dc1 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -18,14 +18,13 @@ We've put together the following guidelines to help you figure out where you can 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 @@ -33,33 +32,43 @@ 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, 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. +If you don't see your idea listed, and you think it fits into the goals of this guide, open a pull request. ## 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 [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. 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.lock b/Gemfile.lock deleted file mode 100644 index 008598d6fa3..00000000000 --- a/Gemfile.lock +++ /dev/null @@ -1,264 +0,0 @@ -GEM - remote: https://rubygems.org/ - specs: - activesupport (6.0.2.1) - concurrent-ruby (~> 1.0, >= 1.0.2) - i18n (>= 0.7, < 2) - minitest (~> 5.1) - tzinfo (~> 1.1) - zeitwerk (~> 2.2) - addressable (2.7.0) - public_suffix (>= 2.0.2, < 5.0) - coffee-script (2.4.1) - coffee-script-source - execjs - coffee-script-source (1.11.1) - colorator (1.1.0) - commonmarker (0.17.13) - ruby-enum (~> 0.5) - concurrent-ruby (1.1.5) - dnsruby (1.61.3) - addressable (~> 2.5) - em-websocket (0.5.1) - eventmachine (>= 0.12.9) - http_parser.rb (~> 0.6.0) - ethon (0.12.0) - ffi (>= 1.3.0) - eventmachine (1.2.7) - execjs (2.7.0) - faraday (1.0.0) - multipart-post (>= 1.2, < 3) - ffi (1.12.1) - forwardable-extended (2.6.0) - gemoji (3.0.1) - github-pages (204) - github-pages-health-check (= 1.16.1) - jekyll (= 3.8.5) - jekyll-avatar (= 0.7.0) - jekyll-coffeescript (= 1.1.1) - jekyll-commonmark-ghpages (= 0.1.6) - jekyll-default-layout (= 0.1.4) - jekyll-feed (= 0.13.0) - jekyll-gist (= 1.5.0) - jekyll-github-metadata (= 2.13.0) - jekyll-mentions (= 1.5.1) - jekyll-optional-front-matter (= 0.3.2) - jekyll-paginate (= 1.1.0) - jekyll-readme-index (= 0.3.0) - jekyll-redirect-from (= 0.15.0) - jekyll-relative-links (= 0.6.1) - jekyll-remote-theme (= 0.4.1) - jekyll-sass-converter (= 1.5.2) - jekyll-seo-tag (= 2.6.1) - jekyll-sitemap (= 1.4.0) - jekyll-swiss (= 1.0.0) - jekyll-theme-architect (= 0.1.1) - jekyll-theme-cayman (= 0.1.1) - jekyll-theme-dinky (= 0.1.1) - jekyll-theme-hacker (= 0.1.1) - jekyll-theme-leap-day (= 0.1.1) - jekyll-theme-merlot (= 0.1.1) - jekyll-theme-midnight (= 0.1.1) - jekyll-theme-minimal (= 0.1.1) - jekyll-theme-modernist (= 0.1.1) - jekyll-theme-primer (= 0.5.4) - jekyll-theme-slate (= 0.1.1) - jekyll-theme-tactile (= 0.1.1) - jekyll-theme-time-machine (= 0.1.1) - jekyll-titles-from-headings (= 0.5.3) - jemoji (= 0.11.1) - kramdown (= 1.17.0) - liquid (= 4.0.3) - mercenary (~> 0.3) - minima (= 2.5.1) - nokogiri (>= 1.10.4, < 2.0) - rouge (= 3.13.0) - terminal-table (~> 1.4) - github-pages-health-check (1.16.1) - addressable (~> 2.3) - dnsruby (~> 1.60) - octokit (~> 4.0) - public_suffix (~> 3.0) - typhoeus (~> 1.3) - html-pipeline (2.12.3) - activesupport (>= 2) - nokogiri (>= 1.4) - html-proofer (3.15.1) - addressable (~> 2.3) - mercenary (~> 0.3) - nokogumbo (~> 2.0) - parallel (~> 1.3) - rainbow (~> 3.0) - typhoeus (~> 1.3) - yell (~> 2.0) - http_parser.rb (0.6.0) - i18n (0.9.5) - concurrent-ruby (~> 1.0) - jekyll (3.8.5) - addressable (~> 2.4) - colorator (~> 1.0) - em-websocket (~> 0.5) - i18n (~> 0.7) - jekyll-sass-converter (~> 1.0) - jekyll-watch (~> 2.0) - kramdown (~> 1.14) - liquid (~> 4.0) - mercenary (~> 0.3.3) - pathutil (~> 0.9) - rouge (>= 1.7, < 4) - safe_yaml (~> 1.0) - jekyll-avatar (0.7.0) - jekyll (>= 3.0, < 5.0) - jekyll-coffeescript (1.1.1) - coffee-script (~> 2.2) - coffee-script-source (~> 1.11.1) - jekyll-commonmark (1.3.1) - commonmarker (~> 0.14) - jekyll (>= 3.7, < 5.0) - jekyll-commonmark-ghpages (0.1.6) - commonmarker (~> 0.17.6) - jekyll-commonmark (~> 1.2) - rouge (>= 2.0, < 4.0) - jekyll-default-layout (0.1.4) - jekyll (~> 3.0) - jekyll-feed (0.13.0) - jekyll (>= 3.7, < 5.0) - jekyll-gist (1.5.0) - octokit (~> 4.2) - jekyll-github-metadata (2.13.0) - jekyll (>= 3.4, < 5.0) - octokit (~> 4.0, != 4.4.0) - jekyll-mentions (1.5.1) - html-pipeline (~> 2.3) - jekyll (>= 3.7, < 5.0) - jekyll-optional-front-matter (0.3.2) - jekyll (>= 3.0, < 5.0) - jekyll-paginate (1.1.0) - jekyll-readme-index (0.3.0) - jekyll (>= 3.0, < 5.0) - jekyll-redirect-from (0.15.0) - jekyll (>= 3.3, < 5.0) - jekyll-relative-links (0.6.1) - jekyll (>= 3.3, < 5.0) - jekyll-remote-theme (0.4.1) - addressable (~> 2.0) - jekyll (>= 3.5, < 5.0) - rubyzip (>= 1.3.0) - jekyll-sass-converter (1.5.2) - sass (~> 3.4) - jekyll-seo-tag (2.6.1) - jekyll (>= 3.3, < 5.0) - jekyll-sitemap (1.4.0) - jekyll (>= 3.7, < 5.0) - jekyll-swiss (1.0.0) - jekyll-theme-architect (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-cayman (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-dinky (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-hacker (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-leap-day (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-merlot (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-midnight (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-minimal (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-modernist (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-primer (0.5.4) - 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-seo-tag (~> 2.0) - jekyll-theme-tactile (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-theme-time-machine (0.1.1) - jekyll (~> 3.5) - jekyll-seo-tag (~> 2.0) - jekyll-titles-from-headings (0.5.3) - jekyll (>= 3.3, < 5.0) - jekyll-watch (2.2.1) - listen (~> 3.0) - jemoji (0.11.1) - gemoji (~> 3.0) - html-pipeline (~> 2.2) - jekyll (>= 3.0, < 5.0) - kramdown (1.17.0) - liquid (4.0.3) - listen (3.2.1) - rb-fsevent (~> 0.10, >= 0.10.3) - rb-inotify (~> 0.9, >= 0.9.10) - mercenary (0.3.6) - mini_portile2 (2.4.0) - minima (2.5.1) - jekyll (>= 3.5, < 5.0) - jekyll-feed (~> 0.9) - jekyll-seo-tag (~> 2.1) - minitest (5.14.0) - multipart-post (2.1.1) - nokogiri (1.10.8) - mini_portile2 (~> 2.4.0) - nokogumbo (2.0.2) - nokogiri (~> 1.8, >= 1.8.4) - octokit (4.15.0) - faraday (>= 0.9) - sawyer (~> 0.8.0, >= 0.5.3) - parallel (1.19.1) - pathutil (0.16.2) - forwardable-extended (~> 2.6) - public_suffix (3.1.1) - rainbow (3.0.0) - rake (13.0.1) - rb-fsevent (0.10.3) - rb-inotify (0.10.1) - ffi (~> 1.0) - rouge (3.13.0) - ruby-enum (0.7.2) - i18n - rubyzip (2.0.0) - safe_yaml (1.0.5) - sass (3.7.4) - sass-listen (~> 4.0.0) - sass-listen (4.0.0) - rb-fsevent (~> 0.9, >= 0.9.4) - rb-inotify (~> 0.9, >= 0.9.7) - sawyer (0.8.2) - addressable (>= 2.3.5) - faraday (> 0.8, < 2.0) - terminal-table (1.8.0) - unicode-display_width (~> 1.1, >= 1.1.1) - thread_safe (0.3.6) - typhoeus (1.3.1) - ethon (>= 0.9.0) - tzinfo (1.2.6) - thread_safe (~> 0.1) - unicode-display_width (1.6.1) - yell (2.2.1) - zeitwerk (2.2.2) - -PLATFORMS - ruby - -DEPENDENCIES - github-pages - html-proofer - rake - -BUNDLED WITH - 2.1.2 diff --git a/README.md b/README.md index cfcc09bcb5c..fa135ab3dbd 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,12 @@ # Open Source Guides - [![Build Status](https://github.com/github/opensource.guide/workflows/GitHub%20Actions%20CI/badge.svg)](https://github.com/github/opensource.guide/actions) -Open Source Guides (https://opensource.guide/) are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project. +Open Source Guides (https://opensource.guide/) are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open-source project. ## Background -Open Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is because we felt that there weren't enough resources for people creating open source projects. +Open Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is that we felt that there weren't enough resources for people creating open-source projects. -Our goal is to aggregate community best practices, *not* what GitHub (or any other individual or entity) thinks is best. Therefore, we try to use examples and quotations from others to illustrate our points. +Our goal was to aggregate community best practices, *not* what GitHub (or any other individual or entity) thinks is best. Therefore, we used examples and quotations from others to illustrate our points. ## Contributing @@ -19,9 +18,40 @@ Content is released under [CC-BY-4.0](https://creativecommons.org/licenses/by/4. ## Acknowledgments -The initial release of these guides were authored by **@nayafia, @bkeepers, @stephbwills,** and **@mlinksva**. +The initial release of these guides were 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], [@joshsimmons][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides. ## 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/joshsimmons +[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/best-practices.md b/_articles/best-practices.md index c125b826beb..e842f33af14 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 diff --git a/_articles/code-of-conduct.md b/_articles/code-of-conduct.md index a92e75e7811..3c3d187ae79 100644 --- a/_articles/code-of-conduct.md +++ b/_articles/code-of-conduct.md @@ -3,12 +3,6 @@ lang: en title: Your Code of Conduct description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. class: coc -toc: - why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?" - establishing-a-code-of-conduct: "Establishing a code of conduct" - deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct" - enforcing-your-code-of-conduct: "Enforcing your code of conduct" - your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer" order: 8 image: /assets/images/cards/coc.png related: @@ -37,7 +31,7 @@ In addition to communicating your expectations, a code of conduct describes the Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. -The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples. +The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples. Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file. @@ -46,7 +40,7 @@ Place a CODE_OF_CONDUCT file in your project's root directory, and make it visib @@ -60,7 +54,7 @@ You should explain how your code of conduct will be enforced **_before_** a viol You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group. -Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.* diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md index 10cc7bdd7fa..e4402da32af 100644 --- a/_articles/de/best-practices.md +++ b/_articles/de/best-practices.md @@ -265,7 +265,7 @@ Viele Maintainer\*innen populärer Projekte sind mit ähnlichen Problemen konfro * [mention-bot](https://github.com/facebook/mention-bot) erwähnt potentielle Reviewer für Pull Requests * [Danger](https://github.com/danger/danger) hilft bei der Automatisierung des Code Review * [no-response](https://github.com/probot/no-response) schließt Issues deren Autor\*in nicht auf Nachfragen antwortet -* [dependabot-preview](https://github.com/marketplace/dependabot-preview) prüft bekannte Abhängigkeitsdateien täglich und eröffnet Pull Requests, sobald Aktualisierungen verfügbar werden +* [dependabot](https://github.com/dependabot) prüft bekannte Abhängigkeitsdateien täglich und eröffnet Pull Requests, sobald Aktualisierungen verfügbar werden Für Fehlerberichte und andere allgemeine Beiträge hat GitHub [Issue- und Pull-Request-Templates](https://github.com/blog/2111-issue-and-pull-request-templates), die Sie erstellen können, um die Kommunikation zu optimieren. @TalAter hat einen [Choose Your Own Adventure Guide](https://www.talater.com/open-source-templates/#/) erstellt, der Ihnen beim Schreiben dieser Vorlagen hilft. @@ -297,7 +297,7 @@ Genau wie bei jeder anderen Art von Arbeit, werden Sie durch regelmäßige Pause _In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important._

-— @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/de/building-community.md b/_articles/de/building-community.md index ed8c7f0bebf..8415d5ff371 100644 --- a/_articles/de/building-community.md +++ b/_articles/de/building-community.md @@ -14,33 +14,33 @@ related: Ihr gerade gestartetes Projekt wird schon verbreitet und Leute schauen vorbei? Fantastisch! Wie überzeugen Sie sie, da zu bleiben? -Eine einladende, offenherzige Gemeinschaft ist eine Investition in die Zukunft und in den Ruf Ihres Projekts. Wenn Ihr Projekt gerade erst die initialen Kontributionen erfährt, fangen Sie damit an, den frühen Kontributor\*innen eine positive Erfahrung zu bereiten, und machen Sie es ihnen leicht, wiederzukommen. +Eine einladende, offenherzige Gemeinschaft ist eine Investition in die Zukunft und in den Ruf Ihres Projekts. Wenn Ihr Projekt gerade erst die initialen Beiträge erfährt, fangen Sie damit an, den frühen Mitwirkenden eine positive Erfahrung zu bereiten, und machen Sie es ihnen leicht, wiederzukommen. ### Geben Sie Leuten das Gefühl, willkommen zu sein -Die Community Ihres Projekts kann nach @MikeMcQuaid als "Kontributorentrichter" ([contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)) aufgefasst werden: +Die Community Ihres Projekts kann nach @MikeMcQuaid als "Mitwirkendenrichter" ([contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)) aufgefasst werden: ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) -Während Sie Ihre Community aufbauen, überlegen Sie sich, wie jemand am Eingang des Trichters (potenzielle\*r Benutzer\*in) theoretisch den Weg nach unten finden könnte (aktiver\* Mitstreiter\*in). Ihr Ziel ist es, jede Phase des Mithelfens möglichst reibungslos zu gestalten. Denn wenn die Leute "leichte Beute" machen können, ermutigt sie dies zu weiteren Beiträgen. +Während Sie Ihre Community aufbauen, überlegen Sie sich, wie jemand am Eingang des Trichters (potenzielle\*r Benutzer\*in) theoretisch den Weg nach unten finden könnte (aktive\*r Mitstreiter\*in). Ihr Ziel ist es, jede Phase des Mithelfens möglichst reibungslos zu gestalten. Denn wenn die Leute "leichte Beute" machen können, ermutigt sie dies zu weiteren Beiträgen. Beginnen Sie mit der Dokumentation: * **Helfen Sie beim Einstieg in ihr Projekt.** [Eine freundliche README](../starting-a-project/#eine-readme-schreiben) und anschauliche Codebeispiele erleichtern Allen, die auf Ihr Projekt stoßen, den Einstieg. * **Erklären Sie in klaren Worten, wie Leute beitragen sollen**, bspw. in [einer CONTRIBUTING-Datei](../starting-a-project/#ihre-beitragsrichtlinien-aufschreiben), und indem Sie die Issues stets aktuell halten. -* **Good first issues**: Um neuen Mitwirkenden den Einstieg zu erleichtern, sollten Sie [für Anfänger\*innen* geeignete Issues explizit kenntlich machen (Englisch)](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub weist auf solche Issues vermehrt hin, sodass beitragswillige Neulinge zu nützlicher Mitarbeit ermuntert werden, ohne sich erst durch vermutlich zu schwere Issues durchkämpfen zu müssen. +* **Good first issues**: Um neuen Mitwirkenden den Einstieg zu erleichtern, sollten Sie [für Anfänger\*innen geeignete Issues explizit kenntlich machen (Englisch)](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub weist auf solche Issues vermehrt hin, sodass beitragswillige Neulinge zu nützlicher Mitarbeit ermuntert werden, ohne sich erst durch vermutlich zu schwere Issues durchkämpfen zu müssen. -[GitHubs 2017er Open-Source-Umfrage](http://opensourcesurvey.org/2017/) zeigte, dass unvollständige oder verwirrende Dokumentation das größte Problem für Open-Source-Anwender\*innen ist. Eine gute Dokumentation lädt zur Interaktion mit Ihrem Projekt ein. Wenn jemand ein Issue oder Pull Request erstellt, bietet sich für Sie die Möglichkeit, diese Person durch den Trichter zu bugsieren. +[GitHubs Open-Source-Umfrage aus dem Jahr 2017](http://opensourcesurvey.org/2017/) zeigte, dass unvollständige oder verwirrende Dokumentation das größte Problem für Open-Source-Anwender\*innen ist. Eine gute Dokumentation lädt zur Interaktion mit Ihrem Projekt ein. Wenn jemand ein Issue oder Pull Request erstellt, bietet sich für Sie die Möglichkeit, diese Person durch den Trichter zu bugsieren. * **Wenn Leute neu zu Ihrem Projekt hinzustoßen, danken Sie ihnen für ihr Interesse!** Ansonsten braucht es nur eine negative Erfahrung, um jemanden nachhaltig abzuschrecken. * **Antworten Sie schnell.** Wenn Sie einen Monat lang nicht auf jemandes Issue reagieren, ist es wahrscheinlich, dass diese Person Ihr Projekt bereits vergessen hat. -* **Nehmen Sie verschiedener Beitragsarten an.** Viele Mitwirkende beginnen mit einem Fehlerbericht oder einer kleinen Korrektur: Es gibt [viele Möglichkeiten, einen Beitrag zu leisten](../how-to-contribute/#was-einen-beitrag-leisten-bedeutet) zu einem Projekt. Lassen Sie Leute so helfen, wie diese es möchten. +* **Nehmen Sie unterschiedliche Arten von Beiträgen an.** Viele Mitwirkende beginnen mit einem Fehlerbericht oder einer kleinen Korrektur: Es gibt [viele Möglichkeiten, einen Beitrag zu leisten](../how-to-contribute/#was-einen-beitrag-leisten-bedeutet) zu einem Projekt. Lassen Sie Leute so helfen, wie diese es möchten. * **Wenn es einen Beitrag gibt, mit dem Sie nicht einverstanden sind,** bedanken Sie sich trotzdem, aber [erklären warum](../best-practices/#lernen-nein-zu-sagen) die Idee nicht in den Projektrahmen passt. Verlinken Sie auf relevante Dokumentation, wenn vorhanden. @@ -73,7 +73,7 @@ Wenn Sie Dinge aufschreiben, können mehr Leute an jedem Schritt des Weges teiln Dinge aufzuschreiben, ist mehr als nur technische Dokumentation. Wenn Sie den Drang verspüren, etwas aufzuschreiben oder Ihr Projekt privat zu diskutieren, fragen Sie sich, ob Sie es nicht doch öffentlich machen können. -Seien Sie transparent was die Roadmap Ihres Projekts angeht, die Arten von Beiträgen, nach denen Sie suchen, wie Beiträge überprüft werden, oder warum Sie bisherige Entscheidungen so getroffen haben. +Seien Sie transparent, was die Roadmap Ihres Projekts angeht, die Arten von Beiträgen, nach denen Sie suchen, wie Beiträge überprüft werden, oder warum Sie bisherige Entscheidungen so getroffen haben. Wenn Sie feststellen, dass mehrere Benutzer\*innen auf das gleiche Problem stoßen, dokumentieren Sie die Antworten in der README. @@ -83,15 +83,15 @@ Alles zu dokumentieren, gilt auch für Ihre Arbeit. Wenn Sie an einem umfangreic ### Antworten Sie schnell -Wenn Sie [für Ihr Projekt werben](../finding-users), werden Leute Ihnen Rückmeldungen geben. Vielleicht in Form von Fragen, wie etwas in Ihrem Projekt funktioniert, oder sie brauchen Starthilfe bei der Benutzung. +Wenn Sie [für Ihr Projekt werben](../finding-users), werden Sie sicherlich Rückmeldungen geben - vielleicht in Form von Fragen, wie etwas in Ihrem Projekt funktioniert, oder wo sie Hilfe für die Benutzung finden können. -Versuchen Sie, schnell zu reagieren, wenn jemand ein Issue oder Pull Request einreicht, oder eine Frage zu Ihrem Projekt stellt. Eine schnell Antwort gibt den Leuten das Gefühl, an einem Dialog teilzunehmen, und das kann ermutigend wirken, weiter mitzuhelfen. +Versuchen Sie, schnell zu reagieren, wenn jemand ein Issue oder Pull Request einreicht, oder eine Frage zu Ihrem Projekt stellt. Eine schnelle Antwort gibt den Leuten das Gefühl, an einem Dialog teilzunehmen, und das kann ermutigend wirken, weiter mitzuhelfen. -Auch wenn Sie die Anfrage nicht sofort inhaltlich prüfen können, hilft die frühzeitige Bestätigung, das Engagement zu erhöhen. Ein Beispiel: @tdreyno reagiert auf einen Pull Request an [Middleman](https://github.com/middleman/middleman/pull/1466): +Auch wenn Sie die Anfrage nicht sofort inhaltlich prüfen können, hilft eine frühzeitige Bestätigung, das Engagement zu erhöhen. Ein Beispiel: @tdreyno reagiert auf einen Pull Request an [Middleman](https://github.com/middleman/middleman/pull/1466): ![Pull Request an Middleman](/assets/images/building-community/middleman_pr.png) -[Eine Mozilla-Studie fand heraus, dass](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) Kontributor\*innen, deren Codebeitrag innerhalb von 48 Stunden überprüft wurde, deutlich häufiger nochmal mithalfen. +[Eine Mozilla-Studie fand heraus, dass](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) Mitwirkende, deren Codebeitrag innerhalb von 48 Stunden überprüft wurde, deutlich häufiger nochmal mithalfen. Ihr Projekt kann an allen möglichen Stellen des Internets besprochen werden, wie z.B. auf Stack Overflow, Twitter oder Reddit. Dort können Sie Benachrichtigungen einrichten, um über Erwähnungen Ihres Projektes informiert zu werden. @@ -99,13 +99,13 @@ Ihr Projekt kann an allen möglichen Stellen des Internets besprochen werden, wi Es gibt zwei Gründe, Ihrer Gemeinschaft einen Ort der Begegnung zu geben. -Der erste Grund ist, Menschen mit gemeinsamen Interessen zu helfen, sich kennenzulernen. Menschen mit gemeinsamen Interessen wollen sich zwangsläufig treffen können, um über diese zu reden. Wenn die Kommunikation öffentlich und zugänglich ist, kann jede\*r die Archive lesen, um sich auf den neuesten Stand zu bringen und sich daran zu beteiligen. +Der erste Grund ist, Menschen mit gemeinsamen Interessen zu helfen, sich kennenzulernen. Menschen mit gemeinsamen Interessen wollen sich zwangsläufig treffen können, um über diese zu reden. Wenn die Kommunikation öffentlich und zugänglich ist, kann jeder die Archive lesen, um sich auf den neuesten Stand zu bringen und sich daran zu beteiligen. Der zweite Grund nützt Ihnen selbst: Wenn Sie den Leuten _keinen_ öffentlichen Ort geben, um über Ihr Projekt zu sprechen, werden sie wahrscheinlich direkt mit Ihnen in Verbindung treten. Am Anfang mag es einfach erscheinen, hin und wieder mal auf private Nachrichten zu antworten, aber mit der Zeit, besonders wenn Ihr Projekt populär wird, werden Sie sich erschöpft fühlen und der Versuchung widerstehen, mit Leuten über Ihr Projekt privat zu kommunizieren, anstatt sie an einen bestimmten öffentlichen Kanal zu verweisen. -Öffentliche Kommunikation kann ganz einfach sein: Bitten Sie Leute, ein Issue zu öffnen, anstatt Ihnen direkt eine E-Mail zu schreiben oder in Ihr Blog zu kommentieren. Sie können für Leute, die über Ihr Projekt sprechen möchten, auch eine Mailingliste einrichten oder einen Twitter-Account, einen Slack- oder IRC-Kanal. Oder all dies gleichzeitig ausprobieren! +Öffentliche Kommunikation kann ganz einfach sein: Bitten Sie Leute, ein Issue zu öffnen, anstatt Ihnen direkt eine E-Mail zu schreiben oder in Ihr Blog zu kommentieren. Sie können für Leute, die über Ihr Projekt sprechen möchten, auch eine Mailingliste einrichten oder einen Twitter-Account, einen Slack- oder IRC-Kanal. Oder gleich alles auf einmal! -[Kubernetes' Kops](https://github.com/kubernetes/kops#getting-involved) legt alle zwei Wochen Bürozeiten fest, um den Mitgliedern der Gemeinschaft zu helfen: +[Kubernetes' Kops](https://github.com/kubernetes/kops#getting-involved) legt alle zwei Wochen Bürozeiten fest, um den Mitglieder*innen der Gemeinschaft zu helfen: > Die Kops-Betreuer\*innen haben sich bereit erklärt, Zeit einzuplanen für die Arbeit mit Neuankömmlingen, die Unterstützung von Pull Requests, sowie für die Diskussion über neue Funktionen. > @@ -141,7 +141,7 @@ Wenn Sie ein destruktives Verhalten in Ihrem Projekt beobachten, sprechen Sie es ### Holen Sie Mitwirkende dort ab, wo sie sich stehen -Eine gute Dokumentation wird nur immer wichtiger, je mehr Ihre Community wächst. Gelegenheitskontributor\*innen, die mit Ihrem Projekt nicht vertraut sind, lesen Ihre Dokumentation, um schnell den nötigen Überblick zu bekommen. +Eine gute Dokumentation wird immer wichtiger, je mehr Ihre Community wächst. Mitwirkende, die nur gelegentlich Beiträge leisten und damit mit Ihrem Projekt nicht zwingend vertraut sind, lesen Ihre Dokumentation, um schnell den nötigen Überblick zu bekommen. Geben Sie in Ihrer CONTRIBUTING-Datei explizit an, wie sie anfangen sollen. Vielleicht möchten Sie sogar eine eigene Sektion für diesen Zweck einrichten: [Django](https://github.com/django/django) zum Beispiel, hat eine spezielle Startseite, die neue Mitwirkende willkommen heißt. @@ -151,9 +151,9 @@ Die Liste der Issues sollte durchsortiert sein, Bugs z.B. als solche markiert, s Nicht zuletzt sollten Sie die Dokumentation nutzen, um Leute mit offenen Armen zu empfangen und ihnen Schritt-für-Schritt zu helfen. -Sie werden mit den meisten Leuten, die auf Ihr Projekt stoßen nie interagieren. Ihnen könnten Beiträge entgehen, weil jemand sich eingeschüchtert fühlte, oder nicht herausfand, was es denn zu tun gab. Schon ein paar freundliche Worte können verhindern, dass jemand einfach weiter zieht. +Sie werden mit den meisten Leuten, die auf Ihr Projekt stoßen, nie interagieren. Ihnen könnten Beiträge entgehen, weil jemand sich eingeschüchtert fühlte, oder nicht herausfand, was es denn zu tun gab. Schon ein paar freundliche Worte können verhindern, dass jemand einfach weiter zieht. -Zum Beispiel: [Rubinius](https://github.com/rubinius/rubinius/) beginnt [den Kontributionsratgeber](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md) mit: +Zum Beispiel: [Rubinius](https://github.com/rubinius/rubinius/) beginnt [den Kontributionsratgeber](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) mit: > Zum Einstieg möchten wir Dir erstmal unseren Dank aussprechen, dass Du Rubinius nutzt. Dieses Projekt wurde mit viel Liebe aufgebaut und wir schätzen alle Benutzer\*innen, die Fehler aufspüren, Geschwindigkeitsverbesserungen vornehmen und bei der Dokumentation helfen. Jeder Beitrag bedeutet uns etwas, also vielen Dank für Ihre Teilnahme! Wir bitten Sie jedoch, einige Richtlinien zu befolgen, damit wir Ihr Issue erfolgreich bearbeiten können. > @@ -173,23 +173,23 @@ Zum Beispiel: [Rubinius](https://github.com/rubinius/rubinius/) beginnt [den Kon

-Leute sind begeistert davon, an Projekten mitzuwirken, wenn sie ein Gefühl für Verantwortung bekommen. Das bedeutet nicht, dass Sie Ihre Projektvision umdrehen müssen, oder Beiträge annehmen, die Sie nicht wollen. Je mehr Anerkennung Sie anderen Menschen jedoch zollen, desto eher werden diese bei Ihrem Projekt bleiben. +Leute sind begeistert davon, an Projekten mitzuwirken, wenn sie ein Gefühl für Verantwortung bekommen. Das bedeutet nicht, dass Sie Ihre Projektvision umdrehen müssen, oder Beiträge annehmen, die Sie nicht wollen. Je mehr Anerkennung Sie anderen Menschen jedoch schenken, desto eher werden diese bei Ihrem Projekt bleiben. -Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie möglich mit Ihren Projektteilnehmer\*innen zu teilen: +Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie möglich mit Ihren Projektteilnehmern\*innen zu teilen: * **Lassen Sie einfache (unkritische) Bugs unangetastet.** Nutzen Sie diese stattdessen als Gelegenheit, neue Mitwirkende zu rekrutieren, oder helfen Sie einem hilfsbereiten Neuling, den Prozess eines Bug-Fixes zu durchlaufen. Es mag zunächst unnatürlich erscheinen, aber Ihre Investition wird sich im Laufe der Zeit auszahlen. @michaeljoseph hat zum Beispiel einen Mitwirkenden gebeten, einen Pull Request zu einem der folgenden Probleme in [Cookiecutter](https://github.com/audreyr/cookiecutter) zu stellen, anstatt es selbst zu beheben. ![Cookiecutter-Issue](/assets/images/building-community/cookiecutter_submit_pr.png) -* **Führen Sie eine CONTRIBUTORS- oder AUTHORS-Datei in Ihrem Projekt**, die alle Leute aufzählt, die einen Beitrag geleistet haben, wie z.B. bei [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md). +* **Führen Sie eine CONTRIBUTORS- oder AUTHORS-Datei in Ihrem Projekt**, die alle Leute aufzählt, die einen Beitrag geleistet haben, wie z.B. bei [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). * Wenn Sie schon eine etwas größere Gemeinschaft versammelt haben, **senden Sie eine Rundmail oder schreiben ins Blog**, dass Sie Kontributor\*innen danken. Rusts [This Week in Rust](https://this-week-in-rust.org/) und Hoodies [Shoutout-Grüße](http://hood.ie/blog/shoutouts-week-24.html) sind zwei gute Beispiele dafür. -* **Geben Sie allen Kontributor\*innen Schreibzugriff.** @felixge fand heraus, dass dies Leute [zu mehr Feinschliff ihrer Beiträge anspornt](https://felixge.de/2013/03/11/the-pull-request-hack.html), und gewann sogar neue Maintainer\*innen für Projekte, an denen er selbst schon eine Weile nicht mehr arbeitete. +* **Geben Sie allen Mitwirkenden Schreibzugriff.** @felixge fand heraus, dass dies Leute [zu mehr Feinschliff ihrer Beiträge anspornt](https://felixge.de/2013/03/11/the-pull-request-hack.html), und gewann sogar neue Maintainer\*innen für Projekte, an denen er selbst schon eine Weile nicht mehr arbeitete. * Wenn Ihr Projekt auf GitHub liegt, **verschieben Sie es von Ihrem Privat-Konto in das einer [Organisation](https://help.github.com/articles/creating-a-new-organization-account/)** und fügen Sie zur Sicherheit mindestens eine\*n weitere\*n Administrator\*in hinzu. Organisationen machen die Zusammenarbeit mit externen Mithelfenden einfacher. -Realistischerweise haben [die meisten Projekte](https://peerj.com/preprints/1233.pdf) nur einen oder zwei Verantwortliche, welche die meiste Arbeit erledigen. Ja größer Ihr Projekt, und je größer seine Nutzer\*innengemeinschaft, desteo einfacher wird es sein, Hilfe zu finden. +Realistischerweise haben [die meisten Projekte](https://peerj.com/preprints/1233/) nur einen oder zwei Verantwortliche, welche die meiste Arbeit erledigen. Ja größer Ihr Projekt, und je größer seine Nutzer\*innengemeinschaft, desto einfacher wird es sein, Hilfe zu finden. Während Sie vielleicht nicht immer Leute finden, die einem Aufruf folgen, erhöht so ein Signals doch die Wahrscheinlichkeit, dass Andere mitmachen. Je früher Sie damit anfangen, desto eher können die Leute helfen. @@ -211,13 +211,13 @@ In der Anfangsphase Ihres Projekts ist es einfach, wichtige Entscheidungen zu tr Je beliebter Ihr Projekt wird, desto mehr Menschen werden sich für von Ihnen getroffene Entscheidungen interessieren. Selbst wenn Sie keine große Gemeinschaft von Mitwirkenden haben: Wenn Ihr Projekt viele Benutzer\*innen hat, werden darunter Leute sein, die sich über Entscheidungen auslassen oder ihre eigenen Themen ansprechen. -Wenn Sie eine freundliche, respektvolle Gemeinschaft gepflegt und Ihre Prozesse offen dokumentiert haben, sollten Alle zur Lösungsfindung in der Lage sein. Aber manchmal stoßen Sie auf ein Problem, das etwas schwieriger zu lösen ist. +Wenn Sie eine freundliche, respektvolle Gemeinschaft gepflegt und Ihre Prozesse offen dokumentiert haben, sollten alle zur Lösungsfindung in der Lage sein. Aber manchmal stoßen Sie auf ein Problem, das etwas schwieriger zu lösen ist. ### Setzen Sie die Messlatte für Freundlichkeit -Wenn sich Ihre Gemeinschaft mit einem schwierigen Thema auseinandersetzt, können sich Gemüter schnell mal erhitzen. Menschen können wütend oder frustriert werden und es an Anderen oder an Ihnen auslassen. +Wenn sich Ihre Gemeinschaft mit einem schwierigen Thema auseinandersetzt, können sich Gemüter schnell mal erhitzen. Menschen können wütend oder frustriert werden und es an anderen oder an Ihnen auslassen. -Ihre Aufgabe als Maintainer\*in ist es, solche Situationen vor einer Eskalation zu bewahren. Selbst wenn Sie eine klare eigene Meinung zu diesem Thema haben, versuchen Sie, die moderierende Position einzunehmen, anstatt sich in den Kampf zu stürzen und Ihre Ansichten durchzusetzen. Wenn jemand unfreundlich wird oder das Gespräch an sich reißt, [handeln Sie sofort](../building-community/#dulden-sie-keine-destruktiven-akteure), um die Diskussionen zivil und produktiv zu halten. +Ihre Aufgabe als Maintainer\*in ist es, solche Situationen vor einer Eskalation zu schützen. Selbst wenn Sie eine klare eigene Meinung zu diesem Thema haben, versuchen Sie, die moderierende Position einzunehmen, anstatt sich in den Kampf zu stürzen und Ihre Ansichten durchzusetzen. Wenn jemand unfreundlich wird oder das Gespräch an sich reißt, [handeln Sie sofort](../building-community/#dulden-sie-keine-destruktiven-akteure), um die Diskussionen zivil und produktiv zu halten. Andere Leute erwarten von Ihnen, ein gutes Beispiel abzugeben. Sie können immer noch Enttäuschung, Unzufriedenheit oder Besorgnis ausdrücken, aber tun Sie dies auf eine ruhige Art und Weise. -Es ist nicht einfach, einen kühlen Kopf zu bewahren, aber Führung zu zeigen, verbessert die Gesundheit der Gemeinschaft. Das Internet wird es Ihnen danken! +Es ist nicht einfach, einen kühlen Kopf zu bewahren, aber Führung zu zeigen, verbessert die Gesundheit der Gemeinschaft. Das Internet wird Ihnen dafür danken! ### Nutzen Sie die README als Verfassung @@ -241,41 +241,41 @@ Ihre README-Datei ist [mehr als nur eine Anleitung](../starting-a-project/#eine- ### Der Weg ist das Ziel -Einige Projekte nutzen einen Abstimmungsprozess, um wichtige Entscheidungen zu treffen. Auf den ersten Blick ist es sinnvoll, so eine Antwort zu finden, anstatt sich gegenseitig zuzuhören und auf die Sichtweisen Anderer einzugehen. +Einige Projekte eigene "Abstimmungsprozesse", um wichtige Entscheidungen zu treffen. Auf den ersten Blick ist es sinnvoll, so eine Antwort zu finden, anstatt sich gegenseitig zuzuhören und auf die Sichtweisen anderer einzugehen. -Abstimmungen können aber politisch werden, wenn sich die Community-Mitglieder unter Druck gesetzt fühlen, sich gegenseitig einen Gefallen zu tun oder auf eine bestimmte Wahl zu treffen. Außerdem stimmt nicht jede\*r mit ab, z.B. weil es ein [stille Mehrheit](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in Ihrer Gemeinschaft geben könnte, oder neue Benutzer\*innen einfach nicht wussten, dass eine Abstimmung stattfindet. +Abstimmungen können aber politisch werden, wenn sich die Community-Mitglieder unter Druck gesetzt fühlen, sich gegenseitig einen Gefallen zu tun oder eine bestimmte Wahl zu treffen. Außerdem stimmt nicht jeder mit ab, z.B. weil es ein [stille Mehrheit](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in Ihrer Gemeinschaft geben könnte, oder neue Benutzer\*innen einfach nicht wussten, dass eine Abstimmung stattfindet. -Manchmal ist eine Abstimmung notwendig, um ein Patt aufzulösen. Aber soviel Sie können, betonen Sie die [Konsensfindung](https://de.wikipedia.org/wiki/Konsensprinzip) statt des Konsenses an sich. +Manchmal ist eine Abstimmung notwendig, um ein Patt aufzulösen. Versuchen Sie daher - so gut es geht - die [Konsensfindung](https://de.wikipedia.org/wiki/Konsensprinzip) statt den Konsens selbst zu betonen. -Im Rahmen der Konsensfindungsprozesses diskutieren die Mitglieder der Gemeinschaft wichtige Anliegen, bis sie das Gefühl haben, angemessen gehört worden zu sein, und wenn nur noch geringe Bedenken bestehen, kommt die Gemeinschaft voran. Die Konsensfindung erkennt an, dass eine Gemeinschaft möglicherweise keine perfekte Antwort finden kann. Stattdessen priorisiert sie das Zuhören und die Diskussion. +Im Rahmen der Konsensfindungsprozesses diskutieren die Mitglieder der Gemeinschaft wichtige Anliegen, bis sie das Gefühl haben, angemessen gehört worden zu sein. Wenn dann nur noch geringe Bedenken bestehen, kommt die Gemeinschaft voran. Die Konsensfindung erlaubt auch, dass eine Gemeinschaft möglicherweise keine perfekte Antwort finden kann. Stattdessen priorisiert sie das Zuhören und die Diskussion. Auch wenn Sie als Projektbetreuer\*in keine Konsensfindung betreiben möchten, ist es wichtig, dass die Leute ein offenes Ohr bei Ihnen finden. Anderen zuzuhören, und sich für die Lösung ihrer Probleme einzusetzen, hilft beim Entschärfen sensibler Situationen sehr. Lassen Sie Ihren Worten aber auch Taten folgen. -Überstürzen Sie Entscheidungen nicht, nur um eine Lösung herbeizuführen. Stellen Sie sicher, dass jede\*r sich gehört fühlt und dass alle Informationen öffentlich gemacht wurden, bevor Sie sich auf eine Entscheidung zubewegen. +Überstürzen Sie Entscheidungen nicht, nur um eine Lösung herbeizuführen. Stellen Sie sicher, dass jeder sich gehört fühlt und dass alle Informationen öffentlich gemacht wurden, bevor Sie sich auf eine Entscheidung zubewegen. ### Halten Sie Diskussionen fokussiert auf Aktionen Diskussionen sind wichtig, aber es gibt einen Unterschied zwischen produktiven und unproduktiven Gesprächen. -Fördern Sie Diskussionen, die sich aktiv auf eine Lösung zubewegen: Wenn klar ist, dass Dinge zerredet werden, oder die Konversation vom Thema abweicht, persönliche Anfeindungen passieren, oder die Leute sich über kleine Details streiten, ist es Zeit für eine Beendigung der Diskussion. +Fördern Sie Diskussionen, die sich aktiv auf eine Lösung zubewegen: Wenn klar wird, dass Dinge zerredet werden, oder die Konversation vom Thema abweicht, persönliche Anfeindungen passieren, oder die Leute sich über kleine Details streiten, ist es Zeit für eine Beendigung der Diskussion. Die Fortsetzung solcher Diskussionen ist nicht nur schlecht für das jeweilige Thema, sondern auch für die Gesundheit Ihrer Gemeinschaft. Die Botschaft zu vermitteln, dass unproduktive Diskussionen erlaubt oder sogar gefördert werden, könnte Leute zukünftig davon abgehalten werden, Probleme anzusprechen oder zu lösen. -Bei jedem Diskussionsbeitrag ihrerseits, oder von Anderen, sollten Sie sich fragen _"Wie bringt uns dies einer Lösung näher?"_ +Bei jedem Diskussionsbeitrag ihrerseits, oder von anderen, sollten Sie sich fragen _"Wie bringt uns dies einer Lösung näher?"_ -Falls die Diskussion abdriftet, fragen Sie die Teilnehmer\*innen: _"Welche Schritte sollten wir als nächstes gehen?"_ um sie wieder zu fokussieren. +Falls die Diskussion abdriftet, fragen Sie die Teilnehmer\*innen: _"Welche Schritte sollten wir als nächstes gehen?"_, um sie wieder zu fokussieren. Wenn eine Diskussion offensichtlich nirgendwo hinführt, es keine klaren Maßnahmen zu ergreifen gibt, oder schon welche ergriffen wurden, schließen Sie das Issue und erklären Sie, warum Sie es geschlossen haben. @@ -293,15 +293,15 @@ Wenn eine Diskussion offensichtlich nirgendwo hinführt, es keine klaren Maßnah ### Wählen Sie Auseinandersetzungen mit Bedacht -Der Kontext ist wichtig: Überlegen Sie, wer an der Diskussion beteiligt ist und wie die Diskutanten den Rest der Gemeinschaft repräsentieren. +Der Kontext ist wichtig: Überlegen Sie, wer an der Diskussion beteiligt ist und wie die Teilnehmer\*innen den Rest der Gemeinschaft repräsentieren. -Ist jeder in der Community verärgert oder gar mit diesem Thema beschäftigt? Oder ist er ein\*e einzelner Unruhestifter\*in? Berücksichtigen Sie nicht nur die Aktiven, sondern vergessen Sie Ihre stillen Community-Mitglieder nicht. +Ist jeder in der Community verärgert oder gar mit diesem Thema beschäftigt? Ist er oder sie ein\*e einzelne\*r Unruhestifter\*in? Berücksichtigen Sie nicht nur die Aktiven, sondern vergessen Sie Ihre stillen Community-Mitglieder\*innen nicht. Wenn das Thema nicht die breiteren Bedürfnisse Ihrer Gemeinschaft widerspiegelt, müssen Sie vielleicht nur die Sorgen einiger Weniger anerkennen. Wenn es sich um ein wiederkehrendes Problem ohne klare Lösung handelt, weisen Sie sie auf frühere Diskussionen hin und schließen Sie das Issue. ### Identifizieren Sie einen Community-Tiebreaker -Mit einer positiven Herangehensweise und klarer Kommunikation sind die schwierigsten Situationen lösbar. Aber auch in einem produktiven Gespräch kann es einfach zu Meinungsverschiedenheiten kommen. Identifizieren Sie dann eine Person oder Gruppe, die quasi als Schiedsrichter\*in fungieren kann. +Mit einer positiven Herangehensweise und klarer Kommunikation sind selbst die schwierigsten Situationen lösbar. Aber auch in einem produktiven Gespräch kann es einfach zu Meinungsverschiedenheiten kommen. Identifizieren Sie dann eine Person oder Gruppe, die als Schiedsrichter\*in fungieren kann. Ein\*e solche\*r Schiedsrichter\*in kann die oder der Hauptverantwortliche für das Projekt sein, oder eine kleine Gruppe von Leuten, die über eine Entscheidung abstimmen. Idealerweise haben Sie einen Tiebreaker und den damit verbundenen Prozess in einer GOVERNANCE-Datei identifiziert, bevor Sie diese verwenden müssen. diff --git a/_articles/de/code-of-conduct.md b/_articles/de/code-of-conduct.md index 18f9305542b..4b2c083c298 100644 --- a/_articles/de/code-of-conduct.md +++ b/_articles/de/code-of-conduct.md @@ -14,7 +14,7 @@ related: Ein Verhaltenskodex ist ein Dokument, das die Erwartungen an das Verhalten der Projektteilnehmer\*innen festlegt. Einen Verhaltenskodex festzulegen und durchzusetzen, kann dazu beitragen, eine positive soziale Atmosphäre für Ihre Community zu schaffen. -Verhaltenskodizes schützen nicht nur Ihre Teilnehmer\*innen, sondern auch Sie selbst. Wenn Sie ein Projekt pflegen, werden Sie vielleicht feststellen, dass unproduktive Einstellungen von anderen dazu führen können, dass Sie sich im Laufe der Zeit ausgelaugt oder unglücklich über Ihre Arbeit fühlen. +Verhaltenskodizes schützen nicht nur Ihre Mitwirkenden, sondern auch Sie selbst. Wenn Sie ein Projekt pflegen, werden Sie vielleicht feststellen, dass unproduktive Einstellungen von anderen dazu führen können, dass Sie sich im Laufe der Zeit ausgelaugt oder unglücklich über Ihre Arbeit fühlen. Ein Verhaltenskodex bevollmächtigt Sie, ein gesundes, konstruktives Miteinander zu fördern. Proaktiv zu sein, verringert die Wahrscheinlichkeit, dass Sie oder andere projektmüde werden, und hilft Ihnen, Maßnahmen gegen unerwünschtes Verhalten zu ergreifen. @@ -31,7 +31,7 @@ Neben der Klarstellung Ihrer Erwartungen beschreibt ein Verhaltenskodex Folgende Wo immer Sie können, nutzen Sie Vorhandenes. Der [Contributor Covenant](https://contributor-covenant.org/) ist ein Verhaltenskodex, der von über 40.000 Open-Source-Projekten wie Kubernetes, Rails und Swift verwendet wird. -Der [Django-Verhaltenskodex](https://www.djangoproject.com/conduct/) und der [Citizen Code of Conduct](http://citizencodeofconduct.org/) sind ebenfalls zwei gute Beispiele. +Der [Django-Verhaltenskodex](https://www.djangoproject.com/conduct/) und der [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sind ebenfalls zwei gute Beispiele. Legen Sie eine CODE_OF_CONDUCT-Datei in das Stammverzeichnis Ihres Projekts und machen Sie sie für Ihre Community sichtbar, indem Sie sie von Ihrer CONTRIBUTING- oder README-Datei verlinken. @@ -44,7 +44,7 @@ Legen Sie eine CODE_OF_CONDUCT-Datei in das Stammverzeichnis Ihres Projekts und _A code of conduct that isn't (or can't be) enforced is worse than no code of conduct at all: it sends the message that the values in the code of conduct aren't actually important or respected in your community._

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

@@ -58,7 +58,7 @@ Sie sollten erklären, wie Ihr Verhaltenskodex durchgesetzt wird, **_bevor_** es Sie sollten Leuten einen privaten Weg (z.B. eine E-Mail-Adresse) geben, um einen Verstoß gegen den Verhaltenskodex zu melden und erklären, wer diesen Bericht erhält. Es kann ein\*e Maintainer\*in, eine Gruppe von Maintainer\*innen oder eine Verhaltenskodex-Arbeitsgruppe sein. -Vergessen Sie nicht, dass jemand einen Verstoß über eine Person melden können möchte, die diese Berichte erhält. Bieten Sie in diesem Fall die Möglichkeit, Verstöße an eine andere Person zu melden. @ctb und @mr-c zum Beispiel [erklären zu ihrem Projekt](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Vergessen Sie nicht, dass jemand einen Verstoß über eine Person melden können möchte, die diese Berichte erhält. Bieten Sie in diesem Fall die Möglichkeit, Verstöße an eine andere Person zu melden. @ctb und @mr-c zum Beispiel [erklären zu ihrem Projekt](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Fälle von missbräuchlichem, belästigendem oder anderweitig inakzeptablem Verhalten können per E-Mail an **khmer-project@idyll.org** gemeldet werden, die nur an C. Titus Brown und Michael R. Crusoe geht. Um ein Problem zu melden, das einen von ihnen betrifft, senden Sie bitte eine E-Mail an **Judi Brown Clarke, Ph.D.** den Diversity Director am BEACON Center for the Study of Evolution in Action, einem NSF Center for Science and Technology.* > @@ -103,7 +103,7 @@ Es gibt einige Möglichkeiten, wie Sie auf einen Verstoß gegen den Verhaltensko Manchmal kann keine Lösung erreicht werden. Die gemeldete Person kann aggressiv oder feindselig werden, wenn er oder sie damit konfrontiert wird oder das Verhalten nicht ändert. In dieser Situation sollten Sie vielleicht stärkere Maßnahmen in Betracht ziehen. Zum Beispiel: -* **zeitweise Suspendierung** in Form eines vorübergehenden Verbots, sich an den Aspekten des Projekts zu beteiligen. +* **zeitweise Suspendierung** in Form eines vorübergehenden Verbots, sich in irgendeiner Art am Projekt zu beteiligen. * Die Person **dauerhaft aus dem Projekt verbannen**. diff --git a/_articles/de/finding-users.md b/_articles/de/finding-users.md index f0279bdc380..6a801f55ef3 100644 --- a/_articles/de/finding-users.md +++ b/_articles/de/finding-users.md @@ -26,7 +26,7 @@ Code-Beispiele wie @robb sie verwendet, können klar kommunizieren, warum sein P ![Cartography README](/assets/images/finding-users/cartography.jpg) -Tiefere Einblicke in das Thema "Botschaften", finden Sie in Mozillas ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)-Übung zur Entwicklung von Personas. +Tiefere Einblicke in das Thema "Botschaften" finden Sie in Mozillas ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)-Übung zur Entwicklung von Personas. ## Helfen Sie Menschen dabei, Ihr Projekt zu finden und zu beobachten @@ -73,7 +73,7 @@ Nun, da Sie die Botschaft Ihres Projekt klargestellt haben, und seine einfache A Internetkommunikation ist ein großartiger Weg, um die Botschaft Ihres Projektes schnell zu verbreiten und verteilen zu lassen: Online-Kanälen bieten das Potenzial, ein sehr breites Publikum zu erreichen. -Nutzen Sie die Vorteile bestehender Online-Communities und -Plattformen, um Ihr Publikum zu erreichen. Wenn es sich bei Ihrem Open Source Projekt um ein Softwareprojekt handelt, erreichen Sie Ihr Publikum wahrscheinlich auf [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), oder [Quora](https://www.quora.com/). Finden Sie die Kanäle, von denen Sie denken, dass die Menschen am meisten von Ihrer Arbeit profitieren werden, oder sich begeistern lassen. +Nutzen Sie die Vorteile bestehender Online-Communities und -Plattformen, um Ihr Publikum zu erreichen. Wenn es sich bei Ihrem Open-Source-Projekt um ein Softwareprojekt handelt, erreichen Sie Ihr Publikum wahrscheinlich auf [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), oder [Quora](https://www.quora.com/). Finden Sie die Kanäle, von denen Sie denken, dass die Menschen am meisten von Ihrer Arbeit profitieren werden, oder sich begeistern lassen. -Większość współpracowników open source to „przypadkowi współpracownicy”: ludzie, którzy przyczyniają się do projektu tylko sporadycznie. Przypadkowy współpracownik może nie mieć czasu, aby w pełni przyspieszyć swój projekt, więc Twoim zadaniem jest ułatwienie im wnoszenia wkładu. +Większość współpracowników open source to „przypadkowi współpracownicy”: ludzie, którzy przyczyniają się do projektu tylko sporadycznie. Przypadkowy współpracownik może nie mieć czasu, aby w pełni przyspieszyć Twój projekt, więc Twoim zadaniem jest ułatwienie im wnoszenia wkładu. -Zachęcanie innych współpracowników to także inwestycja w ciebie. Gdy umożliwisz swoim największym fanom bieganie z pracą, którą są podekscytowani, zmniejszysz presję, aby zrobić wszystko sam. +Zachęcanie innych współpracowników to także inwestycja w ciebie. Gdy umożliwisz swoim największym fanom bieganie z pracą, którą są podekscytowani, zmniejszysz presję, aby robić wszystko sam. ### Wszystko dokumentuj @@ -59,7 +59,7 @@ Zachęcanie innych współpracowników to także inwestycja w ciebie. Gdy umożl Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.

-— @janl, ["Sustainable Open Source"](https://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)

@@ -67,21 +67,21 @@ Kiedy zaczynasz nowy projekt, naturalne może być zachowanie prywatności w pra Kiedy spisujesz rzeczy, więcej osób może brać udział na każdym etapie. Możesz uzyskać pomoc dotyczącą czegoś, o czym nawet nie wiedziałeś, że potrzebujesz. -Zapisywanie rzeczy to coś więcej niż dokumentacja techniczna. Za każdym razem, gdy poczujesz potrzebę napisania czegoś lub prywatnie przedyskutuj swój projekt, zadaj sobie pytanie, czy możesz to upublicznić. +Zapisywanie rzeczy to coś więcej niż dokumentacja techniczna. Za każdym razem, gdy poczujesz potrzebę coś zapisać lub prywatnie przedyskutować swój projekt, zadaj sobie pytanie, czy możesz to upublicznić. Zachowaj przejrzystość na temat planu projektu, rodzajów wkładów, których szukasz, sposobu ich sprawdzania lub powodów, dla których podjąłeś określone decyzje. Jeśli zauważysz, że wielu użytkowników napotyka ten sam problem, udokumentuj odpowiedzi w pliku README. -W przypadku spotkań rozważ opublikowanie notatek lub wynos w odpowiednim numerze. Informacje zwrotne uzyskane z tego poziomu przejrzystości mogą Cię zaskoczyć. +W przypadku spotkań rozważ opublikowanie swoich notatek lub treści w odpowiednim wydaniu. Uzyskane informacje zwrotne mogą Cię zaskoczyć. Dokumentowanie wszystkiego dotyczy także wykonywanej pracy. Jeśli pracujesz nad istotną aktualizacją projektu, prześlij ją do pull requesta i oznacz jako trwającą (WIP). W ten sposób inne osoby mogą wcześnie poczuć się zaangażowane w ten proces. ### Bądź responsywny -Jak [promujesz swój projekt](../finding-users/), ludzie będą mieli dla ciebie opinie. Mogą mieć pytania dotyczące sposobu działania lub potrzebują pomocy na początku. +Gdy [promujesz swój projekt](../finding-users/), ludzie będą mieli dla ciebie opinie. Mogą mieć pytania dotyczące sposobu działania lub potrzebują pomocy na początku. -Postaraj się reagować, gdy ktoś zgłosi problem, prześle pull request lub zadaje pytanie o Twój projekt. Gdy odpowiesz szybko, ludzie poczują, że są częścią dialogu i będą bardziej entuzjastycznie nastawieni do uczestnictwa. +Postaraj się reagować, gdy ktoś zgłosi problem, prześle pull request lub zadaje pytanie o Twój projekt. Gdy odpowiesz szybko, ludzie poczują, że są częścią dialogu i będą bardziej entuzjastycznie nastawieni do uczestnictwa w projekcie. Nawet jeśli nie możesz natychmiast przejrzeć żądania, jego wcześniejsze potwierdzenie pomaga zwiększyć zaangażowanie. Oto jak @tdreyno odpowiedział na pull request na [Middleman](https://github.com/middleman/middleman/pull/1466): @@ -95,11 +95,11 @@ Rozmowy na temat Twojego projektu mogą odbywać się również w innych miejsca Istnieją dwa powody, aby dać społeczności możliwość gromadzenia się. -Pierwszy powód jest dla nich. Pomóż ludziom się poznać. Ludzie o wspólnych zainteresowaniach nieuchronnie będą chcieli o tym porozmawiać. A gdy komunikacja jest publiczna i dostępna, każdy może czytać poprzednie archiwa, aby przyspieszyć i wziąć udział. +Pierwszy powód jest dla nich. Pomóż ludziom się poznać. Ludzie o wspólnych zainteresowaniach będą chcieli o tym porozmawiać. A gdy komunikacja jest publiczna i dostępna, każdy może czytać archiwa, aby zapoznać się z projektem i wziąć w nim udział. -Drugi powód jest dla ciebie. Jeśli nie dasz ludziom publicznego miejsca na rozmowę o twoim projekcie, prawdopodobnie skontaktują się z tobą bezpośrednio. Na początku może wydawać się dość łatwe odpowiadanie na prywatne wiadomości „tylko raz”. Ale z czasem, szczególnie jeśli twój projekt stanie się popularny, poczujesz się wyczerpany. Oprzyj się pokusie prywatnego komunikowania się z ludźmi na temat twojego projektu. Zamiast tego skieruj je do wyznaczonego kanału publicznego. +Drugi powód jest dla ciebie. Jeśli nie dasz ludziom publicznego miejsca na rozmowę o twoim projekcie, prawdopodobnie skontaktują się z tobą bezpośrednio. Na początku może wydawać się dość łatwe odpowiadanie na prywatne wiadomości „tylko raz”. Ale z czasem, szczególnie jeśli twój projekt stanie się popularny, poczujesz się wyczerpany. Oprzyj się pokusie prywatnego komunikowania się z ludźmi na temat twojego projektu. Zamiast tego skieruj ich do wyznaczonego kanału publicznego. -Komunikacja publiczna może być tak prosta, jak nakłanianie ludzi do otwarcia problemu zamiast bezpośredniego wysyłania e-maili lub komentowania na blogu. Możesz także skonfigurować listę mailingową lub utworzyć konto na Twitterze, Slack lub kanał IRC, aby ludzie mogli porozmawiać o twoim projekcie. Lub wypróbuj wszystkie powyższe! +Komunikacja publiczna może być tak prosta, jak nakłanianie ludzi do otwarcia problemu zamiast bezpośredniego wysyłania e-maili lub komentowania na blogu. Możesz także skonfigurować listę mailingową lub utworzyć konto na Twitterze, Slack lub kanał IRC, aby ludzie mogli rozmawiać o twoim projekcie. Lub wypróbuj wszystkie powyższe! [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) co drugi tydzień przeznacza godziny urzędowania, aby pomóc członkom społeczności: @@ -109,13 +109,13 @@ Ważnymi wyjątkami od komunikacji publicznej są: 1) kwestie bezpieczeństwa i ## Rozwijanie społeczności -Społeczności są niezwykle potężne. Ta moc może być błogosławieństwem lub przekleństwem, w zależności od tego, jak ją władasz. Gdy społeczność twojego projektu rośnie, istnieją sposoby, aby pomóc mu stać się siłą budowy, a nie zniszczenia. +Społeczności są niezwykle potężne. Ta moc może być błogosławieństwem lub przekleństwem, w zależności od tego, jak ją władasz. Gdy społeczność twojego projektu rośnie, istnieją sposoby, aby pomócjej stać się siłą kontruktywną, a nie destruktywną. ### Nie toleruj złych aktorów -Każdy popularny projekt nieuchronnie przyciągnie ludzi, którzy krzywdzą, a nie pomagają twojej społeczności. Mogą rozpocząć niepotrzebne debaty, pokłócić się z trywialnymi funkcjami lub zastraszyć innych. +Każdy popularny projekt nieuchronnie przyciągnie ludzi, którzy bardziej szkodzą niż pomagają twojej społeczności. Mogą rozpocząć niepotrzebne debaty, spierać się o trywialne funkcje lub zastraszać innych. -Staraj się przyjąć politykę zerowej tolerancji dla tego rodzaju ludzi. Jeśli pozostanie niezaznaczone, negatywni ludzie sprawią, że inni ludzie w Twojej społeczności będą się niekomfortowo Mogą nawet odejść. +Staraj się przyjąć politykę zerowej tolerancji dla tego rodzaju ludzi. Jeśli takie zachowanie pozostanie niezauważone, negatywni ludzie sprawią, że inni ludzie w Twojej społeczności będą czuć się niekomfortowo. Mogą nawet odejść. -Regularne debaty na temat trywialnych aspektów projektu odwracają uwagę innych, w tym ciebie, od koncentrowania się na ważnych zadaniach. Nowe osoby, które przybędą do Twojego projektu, mogą zobaczyć te rozmowy i nie chcą brać udziału. +Regularne debaty na temat trywialnych aspektów projektu odwracają uwagę innych, w tym ciebie, od koncentrowania się na ważnych zadaniach. Nowe osoby, które przybędą do Twojego projektu, mogą zobaczyć te rozmowy i nie chcą brać w nich udziału. Kiedy zobaczysz negatywne zachowanie w twoim projekcie, wywołaj to publicznie. Wyjaśnij, życzliwym, ale zdecydowanym tonem, dlaczego ich zachowanie jest nie do przyjęcia. Jeśli problem będzie się powtarzał, być może będziesz musiał [poprosić ich o odejście](https://github.com/mbiesiad/opensource.guide/blob/pl/_articles/code-of-conduct.md/#enforcing-your-code-of-conduct). Twój [kodeks postępowania](../code-of-conduct/) może być konstruktywnym przewodnikiem dla tych rozmów. @@ -145,7 +145,7 @@ Na koniec skorzystaj z dokumentacji, aby ludzie czuli się mile widziani na każ Nigdy nie będziesz wchodzić w interakcje z większością ludzi, którzy wylądują na twoim projekcie. Mogą istnieć kontrybucje, których nie otrzymałeś, ponieważ ktoś czuł się zastraszony lub nie wiedział, od czego zacząć. Nawet kilka miłych słów może zniechęcić kogoś do opuszczenia projektu. -Na przykład oto jak [Rubinius](https://github.com/rubinius/rubinius/) zaczyna [jego pomocny przewodnik](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md): +Na przykład oto jak [Rubinius](https://github.com/rubinius/rubinius/) zaczyna [jego pomocny przewodnik](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): > We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue. @@ -161,7 +161,7 @@ Na przykład oto jak [Rubinius](https://github.com/rubinius/rubinius/) zaczyna [

-Ludzie są podekscytowani, że mogą uczestniczyć w projektach, kiedy mają poczucie własności. Nie oznacza to, że musisz zmienić wizję swojego projektu lub zaakceptować wkład, którego nie chcesz. Ale im więcej dajesz uznanie innym, tym bardziej będą się trzymać. +Ludzie są podekscytowani, że mogą uczestniczyć w projektach, kiedy mają poczucie własności. Nie oznacza to, że musisz zmienić wizję swojego projektu lub zaakceptować wkład, którego nie chcesz. Ale im więcej dajesz uznania innym, tym bardziej będą się trzymać. Sprawdź, czy możesz w jak największym stopniu znaleźć sposób na dzielenie się własnością ze społecznością. Oto kilka pomysłów: @@ -169,15 +169,15 @@ Sprawdź, czy możesz w jak największym stopniu znaleźć sposób na dzielenie ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) -* **Uruchom plik CONTRIBUTORS lub AUTHORS w swoim projekcie** zawiera listę wszystkich, którzy przyczynili się do twojego projektu, takich jak [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md). +* **Uruchom plik CONTRIBUTORS lub AUTHORS w swoim projekcie** zawiera listę wszystkich, którzy przyczynili się do twojego projektu, takich jak [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). * Jeśli masz sporą społeczność, **wyślij biuletyn lub napisz post na blogu** dziękując autorom. Rusta [This Week in Rust](https://this-week-in-rust.org/) i Hoodie'ego [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) są dwoma dobrymi przykładami -* **Daj dostęp każdemu współautorowi.** @felixge stwierdził, że to sprawiło, że ludzie [bardziej podekscytowani polerowaniem swoich łat](https://felixge.de/2013/03/11/the-pull-request-hack.html), a nawet znalazł nowych opiekunów dla projektów, nad którymi on od jakiegoś czasu nie pracował. +* **Daj dostęp każdemu współautorowi.** @felixge stwierdził, że to sprawiło, że ludzie są [bardziej podekscytowani dopracowywaniem swoich łat](https://felixge.de/2013/03/11/the-pull-request-hack.html), a nawet znalazł nowych opiekunów dla projektów, nad którymi on od jakiegoś czasu nie pracował. * Jeśli Twój projekt jest w serwisie GitHub, **przenieś swój projekt z konta osobistego do [Organizacji](https://help.github.com/articles/creating-a-new-organization-account/)** i dodaj co najmniej jednego administratora kopii zapasowych. Organizacje ułatwiają pracę nad projektami z zewnętrznymi współpracownikami. -Rzeczywistość jest taka, że [większość projektów ma tylko](https://peerj.com/preprints/1233.pdf) jednego lub dwóch opiekunów, którzy wykonują większość pracy. Im większy projekt i większa społeczność, tym łatwiej jest znaleźć pomoc. +Rzeczywistość jest taka, że [większość projektów ma tylko](https://peerj.com/preprints/1233/) jednego lub dwóch opiekunów, którzy wykonują większość pracy. Im większy projekt i większa społeczność, tym łatwiej jest znaleźć pomoc. Chociaż nie zawsze możesz znaleźć kogoś, kto odbierze połączenie, wysłanie sygnału zwiększa szanse na pojawienie się innych osób. Im wcześniej zaczniesz, tym szybciej ludzie mogą pomóc. @@ -203,7 +203,7 @@ W większości przypadków, jeśli kultywujesz przyjazną, pełną szacunku spo Gdy Twoja społeczność zmaga się z trudnym problemem, temperament może wzrosnąć. Ludzie mogą się złościć lub sfrustrować i wyładowywać się na sobie nawzajem lub na tobie. -Twoim zadaniem jako opiekuna jest zapobieganie eskalacji tych sytuacji. Nawet jeśli masz silną opinię na ten temat, spróbuj zająć stanowisko moderatora lub facylitatora, zamiast skakać do walki i popychać swoje poglądy. Jeśli ktoś jest nieuprzejmy lub monopolizuje rozmowę, [działaj natychmiast](https://github.com/mbiesiad/opensource.guide/blob/pl/_articles/building-community.md/#dont-tolerate-bad-actors) aby dyskusje były spokojne i owocne. +Twoim zadaniem jako opiekuna jest zapobieganie eskalacji tych sytuacji. Nawet jeśli masz silną opinię na ten temat, spróbuj zająć stanowisko moderatora lub facylitatora, zamiast wskakiwać do walki i forsować swoje poglądy. Jeśli ktoś jest nieuprzejmy lub monopolizuje rozmowę, [działaj natychmiast](https://github.com/mbiesiad/opensource.guide/blob/pl/_articles/building-community.md/#dont-tolerate-bad-actors) aby dyskusje były spokojne i owocne. @@ -225,7 +225,7 @@ Twój plik README to [więcej niż tylko zestaw instrukcji](../starting-a-projec ### Skoncentruj się na podróży, a nie na celu -Niektóre projekty wykorzystują proces głosowania do podejmowania ważnych decyzji. Na pierwszy rzut oka rozsądne, ale głosowanie kładzie nacisk na dotarcie do „odpowiedzi”, a nie na wzajemne słuchanie i rozwiązywanie problemów. +Niektóre projekty wykorzystują proces głosowania do podejmowania ważnych decyzji. Na pierwszy rzut oka to jest rozsądne, ale głosowanie kładzie nacisk na dotarcie do „odpowiedzi”, a nie na wzajemnym słuchaniu i rozwiązywaniu problemów. Głosowanie może mieć charakter polityczny, w którym członkowie społeczności czują się zmuszeni do wzajemnego wyświadczania przysług lub głosowania w określony sposób. Nie wszyscy też głosują, czy też jest to [cicha większość](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) w Twojej społeczności lub obecni użytkownicy, którzy nie wiedzieli, że głosowanie ma miejsce. @@ -239,21 +239,21 @@ W ramach procesu poszukiwania konsensusu członkowie społeczności omawiają g Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.

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

-Nawet jeśli tak naprawdę nie przyjmujesz procesu poszukiwania konsensusu, jako opiekun projektu ważne jest, aby ludzie wiedzieli, że słuchasz. Sprawienie, by inni poczuli się wysłuchani i zobowiązanie się do rozwiązania swoich problemów, znacznie przyczynia się do rozproszenia wrażliwych sytuacji. Następnie postępuj zgodnie ze swoimi słowami za pomocą działań. +Nawet jeśli tak naprawdę nie przyjmujesz procesu poszukiwania konsensusu, jako opiekun projektu ważne jest, aby ludzie wiedzieli, że słuchasz. Sprawienie, by inni poczuli się wysłuchani i zobowiązanie się do rozwiązania ich obaw, znacznie przyczynia się do rozproszenia wrażliwych sytuacji. Następnie postępuj zgodnie ze swoimi słowami za pomocą działań. -Nie spiesz się z decyzją ze względu na rozwiązanie. Upewnij się, że wszyscy czują się słyszani i że wszystkie informacje zostały upublicznione przed przejściem do rozwiązania. +Nie spiesz się z decyzją. Upewnij się, że wszyscy czują się wysłuchani i że wszystkie informacje zostały upublicznione przed przejściem do rozwiązania. ### Skoncentruj rozmowę na działaniu Dyskusja jest ważna, ale istnieje różnica między produktywnymi i nieproduktywnymi rozmowami. -Zachęcaj do dyskusji, o ile aktywnie dąży do rozwiązania. Jeśli jest oczywiste, że rozmowa gubi się lub odchodzi od tematu, dźgnięcia stają się osobiste lub ludzie kłócą się o drobne szczegóły, nadszedł czas, aby je zamknąć. +Zachęcaj do dyskusji, o ile aktywnie dąży ona do rozwiązania problemu. Jeśli jest oczywiste, że rozmowa gubi się lub odchodzi od tematu, dźgnięcia stają się osobiste lub ludzie kłócą się o drobne szczegóły, nadszedł czas, aby ją zamknąć. -Zezwolenie na kontynuowanie tych rozmów jest nie tylko szkodliwe dla omawianego problemu, ale także niekorzystne dla zdrowia Twojej społeczności. Wysyła wiadomość, że tego rodzaju rozmowy są dozwolone, a nawet zachęcane, i może zniechęcać ludzi do podnoszenia lub rozwiązywania przyszłych problemów. +Zezwolenie na kontynuowanie tych rozmów jest nie tylko szkodliwe dla omawianego problemu, ale także niekorzystne dla Twojej społeczności. Wysyła wiadomość, że tego rodzaju rozmowy są dozwolone, a nawet zachęcane, i może zniechęcać ludzi do podnoszenia lub rozwiązywania przyszłych problemów. W każdym punkcie przedstawionym przez ciebie lub przez innych zadawaj sobie pytanie: _"W jaki sposób zbliża nas to do rozwiązania?"_ @@ -271,9 +271,9 @@ Jeśli rozmowa najwyraźniej nigdzie się nie kończy, nie ma wyraźnych działa

-### Wybierz mądrze swoje bitwy +### Mądrze wybieraj swoje bitwy -Kontekst jest ważny. Zastanów się, kto jest zaangażowany w dyskusję i jak reprezentują resztę społeczności. +Kontekst jest ważny. Zastanów się, kto jest zaangażowany w dyskusję i jak reprezentuje resztę społeczności. Czy wszyscy w społeczności są zaniepokojeni, czy nawet zaangażowani w ten problem? A może samotny problemator? Nie zapomnij wziąć pod uwagę swoich cichych członków społeczności, a nie tylko aktywnych głosów. @@ -289,4 +289,4 @@ Twój remis powinien być ostatecznością. Problemy dzielące są szansą dla T ## Społeczność jest ❤️ open source -Zdrowe, dobrze prosperujące społeczności napędzają tysiące godzin wkładanych w open source każdego tygodnia. Wielu współautorów wskazuje inne osoby jako powód do pracy - lub nie - pracy na otwartym oprogramowaniu. Ucząc się, jak konstruktywnie wykorzystać tę moc, pomożesz komuś, aby doświadczył niezapomnianych wrażeń open source. +Zdrowe, dobrze prosperujące społeczności napędzają tysiące godzin wkładanych w open source każdego tygodnia. Wielu współautorów wskazuje inne osoby jako powód do pracy - lub nie - nad otwartym oprogramowaniem. Ucząc się, jak konstruktywnie wykorzystać tę moc, pomożesz komuś, aby doświadczył niezapomnianych wrażeń open source. diff --git a/_articles/pl/code-of-conduct.md b/_articles/pl/code-of-conduct.md index ae8f18cfed0..781994c4a09 100644 --- a/_articles/pl/code-of-conduct.md +++ b/_articles/pl/code-of-conduct.md @@ -1,7 +1,7 @@ --- lang: pl title: Twój kodeks postępowania -description: Ułatwienie zdrowego i konstruktywnego zachowania społeczności poprzez przyjęcie i egzekwowanie kodeksu postępowania. +description: Promowanie przyjaznych i konstruktywnych zachowań poprzez przyjęcie i egzekwowanie kodeksu postępowania. class: coc order: 8 image: /assets/images/cards/coc.png @@ -12,63 +12,63 @@ related: ## Dlaczego potrzebuję kodeksu postępowania? -Kodeks postępowania to dokument, który określa oczekiwania dotyczące zachowania uczestników projektu. Przyjęcie i egzekwowanie kodeksu postępowania może pomóc stworzyć pozytywną atmosferę społeczną dla społeczności. +Kodeks postępowania to dokument, który określa oczekiwania dotyczące zachowania uczestników projektu. Przyjęcie i egzekwowanie kodeksu postępowania może pomóc stworzyć pozytywną atmosferę wśród społeczności. -Kodeksy postępowania chronią nie tylko uczestników, ale i ciebie. Jeśli utrzymasz projekt, może się okazać, że nieproduktywne postawy innych uczestników mogą z czasem powodować wyczerpanie lub niezadowolenie z pracy. +Kodeksy postępowania chronią nie tylko uczestników, ale i ciebie. Jeśli utrzymujesz projekt, może się okazać, że nieproduktywne postawy innych uczestników mogą z czasem powodować wyczerpanie lub niezadowolenie z pracy. -Kodeks postępowania umożliwia ci zdrowe, konstruktywne zachowanie społeczności. Aktywne podejście zmniejsza prawdopodobieństwo zmęczenia twojego projektu i pomaga podejmować działania, gdy ktoś robi coś, z czym się nie zgadzasz. +Kodeks postępowania umożliwia ci przyjazne i konstruktywne zachowania wśród społeczności projektu. Aktywne podejście zmniejsza prawdopodobieństwo zmęczenia się swoim projektem i pomaga podejmować działania, gdy ktoś robi coś, z czym się nie zgadzasz. ## Ustanowienie kodeksu postępowania -Postaraj się ustalić kodeks postępowania tak wcześnie, jak to możliwe: najlepiej przy pierwszym tworzeniu projektu. +Postaraj się ustalić kodeks postępowania tak wcześnie, jak to możliwe: najlepiej na samym początku projektu. Oprócz przekazywania swoich oczekiwań kodeks postępowania opisuje następujące kwestie: -* Gdzie obowiązuje kodeks postępowania _(tylko w przypadku problemów i wniosków lub działań społeczności, takich jak wydarzenia?)_ -* Do kogo odnosi się kodeks postępowania _(członkowie społeczności i opiekunowie, ale co ze sponsorami?)_ +* Gdzie obowiązuje kodeks postępowania _(tylko w przypadku problemów i pull requestów lub przy różnych wydarzeniach społeczności)_ +* Do kogo odnosi się kodeks postępowania _(członków społeczności i opiekunów, ale także na przykład sponsorów)_ * Co się stanie, jeśli ktoś naruszy kodeks postępowania * Jak ktoś może zgłaszać naruszenia -Gdziekolwiek możesz, skorzystaj ze stanu techniki. [Przymierze współautorów](https://contributor-covenant.org/) to rozwijany kodeks postępowania używany przez ponad 40 000 projektów open source, w tym Kubernetes, Rails i Swift. +Gdziekolwiek możesz, skorzystaj z istniejących szablonów. [Przymierze współautorów](https://contributor-covenant.org/) to rozwijany kodeks postępowania używany przez ponad 40 000 projektów open source, w tym Kubernetes, Rails i Swift. -[Kodeks postępowania Django](https://www.djangoproject.com/conduct/) oraz [Kodeks postępowania obywatelskiego](http://citizencodeofconduct.org/) to także dwa przykłady dobrego kodeksu postępowania. +[Kodeks postępowania Django](https://www.djangoproject.com/conduct/) oraz [Kodeks postępowania obywatelskiego](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) to także dwa przykłady dobrych kodeksów postępowania. Umieść plik CODE_OF_CONDUCT w katalogu głównym projektu i uczyń go widocznym dla społeczności, łącząc go z plikiem CONTRIBUTING lub README. -## Decydowanie o tym, jak będziesz egzekwować swój kodeks postępowania +## Zdecyduj, jak będziesz egzekwować swój kodeks postępowania -Musisz wyjaśnić, w jaki sposób Twój kodeks postępowania będzie egzekwowany **_zanim_** nastąpi naruszenie. Istnieje kilka powodów: +Musisz wyjaśnić, w jaki sposób Twój kodeks postępowania będzie egzekwowany **_zanim_** nastąpi naruszenie. Istnieje kilka powodów, dla których warto to zrobić: * To pokazuje, że poważnie podchodzisz do działania, gdy jest to potrzebne. * Twoja społeczność poczuje się bardziej pewnie, że skargi faktycznie zostaną rozpatrzone. -* Zapewnisz swoją społeczność, że proces sprawdzania jest uczciwy i przejrzysty, jeśli kiedykolwiek zostaną zbadani pod kątem naruszenia. +* Zapewnisz swoją społeczność, że proces sprawdzania jest uczciwy i przejrzysty, jeśli kiedykolwiek zostaną sprawdzeni pod kątem naruszenia. -Powinieneś dać ludziom prywatny sposób (np. Adres e-mail), aby zgłosić naruszenie zasad postępowania i wyjaśnić, kto otrzyma to zgłoszenie. Może to być opiekun, grupa opiekunów lub grupa robocza ds. Kodeksu postępowania. +Powinieneś dać ludziom poufny sposób (np. Adres e-mail), do zgłoszenia naruszenia zasad postępowania i wyjaśnić, kto otrzyma to zgłoszenie. Może to być opiekun, grupa opiekunów lub grupa robocza ds. Kodeksu postępowania. -Nie zapominaj, że ktoś może chcieć zgłosić naruszenie dotyczące osoby, która je otrzyma. W takim przypadku daj im możliwość zgłaszania naruszeń komuś innemu. Na przykład, @ctb oraz @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Nie zapominaj, że ktoś może chcieć zgłosić naruszenie dotyczące osoby, która je otrzyma. W takim przypadku daj im możliwość zgłaszania naruszeń komuś innemu. Na przykład tak jak, @ctb oraz @mr-c [tłumaczą w swoim projekcie](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Przypadki obraźliwych, nękających lub w inny sposób niedopuszczalnych zachowań można zgłaszać, wysyłając wiadomość e-mail na adres **khmer-project@idyll.org**, który jest wysyłany tylko do C. Titusa Browna i Michaela R. Crusoe. Aby zgłosić problem dotyczący któregokolwiek z nich, wyślij wiadomość e-mail **dr Judi Brown Clarke** dyrektor ds. Różnorodności w Centrum Badań nad Ewolucją w Działaniu BEACON, Centrum Nauki i Technologii NSF.* -Aby uzyskać inspirację, zapoznaj się z [instrukcją egzekwowania Django](https://www.djangoproject.com/conduct/enforcement-manual/) (chociaż możesz nie potrzebować czegoś tak kompleksowego, w zależności od wielkości twojego projektu). +Możesz zainspirować się także [instrukcją egzekwowania Django](https://www.djangoproject.com/conduct/enforcement-manual/) (chociaż możesz nie potrzebować czegoś tak kompleksowego, w zależności od wielkości twojego projektu). -## Egzekwowanie Twojego kodeksu postępowania +## Egzekwowanie twojego kodeksu postępowania -Czasami, pomimo twoich starań, ktoś zrobi coś, co narusza ten kod. Istnieje kilka sposobów przeciwdziałania negatywnym lub szkodliwym zachowaniom. +Czasami, pomimo twoich starań, ktoś zrobi coś, co narusza ten kodeks. Istnieje kilka sposobów przeciwdziałania negatywnym lub szkodliwym zachowaniom. ### Zbierz informacje o sytuacji -Traktuj głos każdego członka społeczności tak samo ważny jak własny. Jeśli otrzymasz zgłoszenie, że ktoś naruszył kodeks postępowania, podejmij go poważnie i zbadaj sprawę, nawet jeśli nie pasuje on do twoich doświadczeń z tą osobą. Takie postępowanie sygnalizuje społeczności, że cenisz ich perspektywę i ufasz ich osądowi. +Traktuj głos każdego członka społeczności tak samo ważny jak własny. Jeśli otrzymasz zgłoszenie, że ktoś naruszył kodeks postępowania, podejmij się go na poważnie i zbadaj sprawę, nawet jeśli naruszenie nie pasuje do twoich doświadczeń z tą osobą. Takie postępowanie sygnalizuje społeczności, że cenisz ich perspektywę i ufasz ich osądowi. -Członek społeczności, o którym mowa, może być wielokrotnym przestępcą, który konsekwentnie sprawia, że inni czują się niekomfortowo, lub mogą powiedzieć coś lub zrobić tylko raz. Oba mogą być podstawą do podjęcia działania, w zależności od kontekstu. +Członek społeczności, o którym mowa, może wieloktrotnie sprawiać, że inni członkowie czują się niekomfortowo lub zrobić to tylko jeden raz. Oba mogą być podstawą do podjęcia działania, w zależności od kontekstu. Zanim odpowiesz, daj sobie czas na zrozumienie, co się stało. Przeczytaj wcześniejsze komentarze i rozmowy tej osoby, aby lepiej zrozumieć, kim ona jest i dlaczego mogła postąpić w taki sposób. Spróbuj zebrać inne niż własne opinie na temat tej osoby i jej zachowania. @@ -81,17 +81,17 @@ Zanim odpowiesz, daj sobie czas na zrozumienie, co się stało. Przeczytaj wcze ### Podejmij odpowiednie działania -Po zebraniu i przetworzeniu wystarczających informacji musisz zdecydować, co robić. Rozważając kolejne kroki, pamiętaj, że Twoim celem jako moderatora jest promowanie bezpiecznego, pełnego szacunku i współpracy środowiska. Zastanów się nie tylko, jak poradzić sobie z daną sytuacją, ale także, w jaki sposób twoja reakcja wpłynie na dalsze zachowania i oczekiwania twojej społeczności. +Po zebraniu i przetworzeniu wystarczających informacji musisz zdecydować, co robić. Rozważając kolejne kroki, pamiętaj, że twoim celem jako moderatora jest promowanie bezpiecznego, pełnego szacunku i współpracy środowiska. Zastanów się nie tylko, jak poradzić sobie z daną sytuacją, ale także, w jaki sposób twoja reakcja wpłynie na dalsze zachowania i oczekiwania twojej społeczności. -Gdy ktoś zgłosi naruszenie kodeksu postępowania, jego zadaniem jest zająć się nim, a nie jego obowiązkiem. Czasami reporter ujawnia informacje z dużym ryzykiem dla ich kariery, reputacji lub bezpieczeństwa fizycznego. Zmuszenie ich do konfrontacji z napastnikiem może postawić reportera w kompromitującej sytuacji. Należy obsługiwać bezpośrednią komunikację z daną osobą, chyba że reporter wyraźnie zażąda inaczej. +Gdy ktoś zgłosi naruszenie kodeksu postępowania, to twoim obowiązkiem jest wyjaśnić sprawę. Czasami osoba zgłaszająca ujawnia informacje z dużym ryzykiem dla ich kariery, reputacji lub bezpieczeństwa fizycznego. Zmuszenie ich do konfrontacji z napastnikiem może postawić osobę zgłaszającą w kompromitującej sytuacji. Należy komunikować się bezpośrednio z daną osobą, chyba że osoba zgłaszająca wyraźnie zażąda inaczej. Istnieje kilka sposobów reagowania na naruszenie kodeksu postępowania: * **Daj osobie, o której mowa, publiczne ostrzeżenie** i wyjaśnij, w jaki sposób ich zachowanie wpłynęło negatywnie na innych, najlepiej w kanale, w którym miało miejsce. Tam, gdzie to możliwe, komunikacja publiczna przekazuje reszcie społeczności, że poważnie podchodzisz do kodeksu postępowania. Bądź miły, ale stanowczy w swojej komunikacji. -* **Prywatnie skontaktuj się z osobą** w celu wyjaśnienia, w jaki sposób ich zachowanie wpłynęło negatywnie na innych. Możesz skorzystać z prywatnego kanału komunikacji, jeśli sytuacja dotyczy poufnych danych osobowych. Jeśli komunikujesz się z kimś prywatnie, dobrym pomysłem jest skontaktowanie się z osobami, które jako pierwsze zgłosiły sytuację, aby wiedziały, że podjąłeś działania. Poproś osobę zgłaszającą o zgodę przed jej wysłaniem. +* **Prywatnie skontaktuj się z osobą** w celu wyjaśnienia, w jaki sposób ich zachowanie wpłynęło negatywnie na innych. Możesz skorzystać z prywatnego kanału komunikacji, jeśli sytuacja dotyczy poufnych danych osobowych. Jeśli komunikujesz się z kimś prywatnie, dobrym pomysłem jest skontaktowanie się z osobami, które jako pierwsze zgłosiły sytuację, aby wiedziały, że podjąłeś działania. Poproś osobę zgłaszającą o zgodę o ujawnienie jej przed wysłaniem wiadomości. -Czasami nie można osiągnąć rozdzielczości. Dana osoba może stać się agresywna lub wroga, gdy zostanie skonfrontowana lub nie zmieni swojego zachowania. W tej sytuacji możesz rozważyć podjęcie silniejszych działań. Na przykład: +Czasami nie można osiągnąć rozwiązania. Dana osoba może stać się agresywna lub wroga, gdy zostanie skonfrontowana lub nie zmieni swojego zachowania. W tej sytuacji możesz rozważyć podjęcie silniejszych działań. Na przykład: * **Zawieś osobę** w kwestii projektu, egzekwowane przez tymczasowy zakaz uczestnictwa w jakimkolwiek aspekcie projektu @@ -101,14 +101,14 @@ Zbanowanych członków nie należy lekceważyć, stanowią trwałą i niemożliw ## Twoje obowiązki jako opiekuna -Kodeks postępowania nie jest prawem egzekwowanym arbitralnie. Jesteś podmiotem egzekwującym kodeks postępowania i Twoim obowiązkiem jest przestrzegać zasad ustanowionych w tym kodeksie postępowania. +Kodeks postępowania nie jest prawem egzekwowanym arbitralnie. Jesteś podmiotem egzekwującym kodeks postępowania i twoim obowiązkiem jest przestrzegać zasad ustanowionych w tym kodeksie postępowania. Jako opiekun ustalasz wytyczne dla swojej społeczności i egzekwujesz je zgodnie z zasadami określonymi w kodeksie postępowania. Oznacza to poważne potraktowanie każdego zgłoszenia naruszenia kodeksu postępowania. Zgłaszającemu należy się dokładna i rzetelna ocena jego skargi. Jeśli stwierdzisz, że zgłoszone przez nich zachowanie nie stanowi naruszenia, przekaż im to jasno i wyjaśnij, dlaczego nie zamierzasz podjąć działań w związku z tym. To, co zrobią z tym, zależy od nich: tolerować zachowanie, z którym mieli problem, lub przestać uczestniczyć w społeczności. -Raport o zachowaniu, który nie narusza kodeksu postępowania technicznego, może nadal wskazywać na problem w Twojej społeczności i powinieneś zbadać ten potencjalny problem i podjąć odpowiednie działania. Może to obejmować rewizję twojego kodeksu postępowania w celu wyjaśnienia dopuszczalnego zachowania i / lub rozmowę z osobą, której zachowanie zostało zgłoszone i poinformowanie ich, że chociaż nie naruszyli kodeksu postępowania, omijają granicę oczekiwań i upewniają się uczestnicy czują się niekomfortowo. +Zgłoszenie zachowania, które nie narusza kodeksu postępowania, może nadal wskazywać na problem w twojej społeczności i powinieneś zbadać ten potencjalny problem i podjąć odpowiednie działania. Może to obejmować rewizję twojego kodeksu postępowania w celu wyjaśnienia dopuszczalnego zachowania i / lub rozmowę z osobą, której zachowanie zostało zgłoszone i poinformowanie ich, że chociaż nie naruszyli kodeksu postępowania, omijają granicę oczekiwań i sprawiają, że uczestnicy czują się niekomfortowo. W końcu, jako opiekun, ustalasz i egzekwujesz standardy dotyczące akceptowalnego zachowania. Masz możliwość kształtowania wartości społeczności w ramach projektu, a uczestnicy oczekują, że egzekwujesz te wartości w uczciwy i zrównoważony sposób. ## Zachęcaj do zachowań, które chcesz zobaczyć na świecie 🌎 -Kiedy projekt wydaje się wrogi lub niechciany, nawet jeśli jest to tylko jedna osoba, której zachowanie jest tolerowane przez innych, ryzykujesz utratą znacznie większej liczby współpracowników, z którymi niektórzy mogą nawet nie spotkać. Przyjęcie lub egzekwowanie kodeksu postępowania nie zawsze jest łatwe, ale promowanie przyjaznego środowiska pomoże Twojej społeczności w rozwoju. +Kiedy projekt wydaje się wrogi lub niechciany, nawet jeśli jest to tylko jedna osoba, której zachowanie jest tolerowane przez innych, ryzykujesz utratą znacznie większej liczby współpracowników, a niektórzy nigdy nie dołączą do społeczności twojego projektu. Przyjęcie lub egzekwowanie kodeksu postępowania nie zawsze jest łatwe, ale promowanie przyjaznego środowiska pomoże twojej społeczności w rozwoju. diff --git a/_articles/pl/finding-users.md b/_articles/pl/finding-users.md index 35ec46f700d..0049f58f8f5 100644 --- a/_articles/pl/finding-users.md +++ b/_articles/pl/finding-users.md @@ -1,7 +1,7 @@ --- lang: pl -title: Znajdowanie użytkowników dla twojego projektu -description: Pomóż rozwijać projekt open source, przekazując go w ręce szczęśliwych użytkowników. +title: Jak znaleźć użytkowników dla twojego projektu +description: Rozwijaj projekt open source, przekazując go w ręce odpowiednich użytkowników. class: finding order: 3 image: /assets/images/cards/finding.png @@ -10,25 +10,25 @@ related: - building --- -## Szerzyć wieści +## Rozpowszechnianie informacji -Nie ma reguły, która mówi, że musisz promować projekt open source podczas uruchamiania. Istnieje wiele satysfakcjonujących powodów do pracy w open source, które nie mają nic wspólnego z popularnością. Zamiast mieć nadzieję, że inni znajdą i wykorzystają Twój projekt open source, musisz rozpowszechnić informacje o swojej ciężkiej pracy! +Nie ma reguły, która mówi, że musisz promować swój projekt open source podczas jego wypuszczania. Istnieje wiele satysfakcjonujących powodów do pracy w open source, które nie mają nic wspólnego z popularnością. Zamiast liczyć na to, że inni znajdą i wykorzystają twój projekt open source, lepiej jest rozpowszechnić informacje o swojej ciężkiej pracy! -## Sprawdź swoją wiadomość +## Zastanów się nad komunikatem -Przed rozpoczęciem faktycznej pracy nad promocją projektu powinieneś być w stanie wyjaśnić, co robi i dlaczego ma to znaczenie. +Przed rozpoczęciem faktycznej pracy nad promocją projektu powinieneś być w stanie wyjaśnić, co robi i dlaczego ma on znaczenie. -Co sprawia, że Twój projekt jest inny lub interesujący? Dlaczego to stworzyłeś? Odpowiedzi na te pytania pomogą ci przekazać znaczenie twojego projektu. +Co sprawia, że twój projekt jest inny lub interesujący? Dlaczego go stworzyłeś? Odpowiedzi na te pytania pomogą ci przekazać informację dlaczego twój projekt może być przydatny dla innych. -Pamiętaj, że ludzie angażują się jako użytkownicy i ostatecznie stają się współpracownikami, ponieważ Twój projekt rozwiązuje dla nich problem. Gdy myślisz o przesłaniu i wartości projektu, spróbuj spojrzeć na nie z perspektywy potencjalnych użytkowników i współpracowników. +Pamiętaj, że ludzie angażują się jako użytkownicy i ostatecznie stają się współpracownikami, ponieważ twój projekt rozwiązuje dla nich dany problem. Gdy myślisz o przesłaniu i wartości projektu, spróbuj spojrzeć na niego z perspektywy potencjalnych użytkowników i współpracowników. Na przykład @robb używa przykładów kodu, aby jasno przekazać, dlaczego jego projekt [Cartography](https://github.com/robb/Cartography) jest przydatny: ![Cartography README](/assets/images/finding-users/cartography.jpg) -Aby głębiej zagłębić się w wiadomości, sprawdź Mozilli ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/), ćwiczenie rozwijające osobowości użytkowników. +Aby zagłębić się w tworzenie odpowiednich komunikatów, sprawdź artykuł Mozilli ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/), o personach użytkowników. -## Pomóż ludziom znaleźć i śledzić Twój projekt +## Pomóż ludziom znaleźć i śledzić twój projekt -Pomóż innym znaleźć i zapamiętać Twój projekt, wskazując je w jednej przestrzeni nazw. +Pomóż innym znaleźć i zapamiętać twój projekt, poprzez utworzenie odpowiedniej nazwy firmowej która będzie reprezentować cały projekt. -**Miej wyraźny uchwyt, aby promować swoją pracę.** Twitter handle, adres URL GitHub lub kanał IRC to łatwy sposób wskazywania ludziom Twojego projektu. Te sklepy zapewniają także rosnącej społeczności projektu możliwość zwołania spotkania. +**Znajdź odpowiednie miejsce do promowania swojej pracy.** Twitter, GitHub URL lub kanał IRC to łatwy sposób promowania twojego projektu. Te miejsca pozwolą także na zbieranie się rosnącej społeczności twojego projektu. -Jeśli nie chcesz jeszcze zakładać punktów sprzedaży dla swojego projektu, promuj swój własny uchwyt Twittera lub GitHub we wszystkim, co robisz. Promowanie swojego uchwytu na Twitterze lub GitHub pozwoli ludziom wiedzieć, jak się z tobą skontaktować lub śledzić twoją pracę. Jeśli przemawiasz na spotkaniu lub wydarzeniu, upewnij się, że Twoje dane kontaktowe znajdują się w biografii lub slajdach. +Jeśli nie chcesz jeszcze zakładać takich punktów dla swojego projektu, promuj go na swoim własnym koncie Twitter lub GitHub. Promowanie swojego projektu na Twitterze lub GitHub pozwoli ludziom wiedzieć, jak się z tobą skontaktować lub śledzić twoją pracę. Jeśli przemawiasz na spotkaniu lub wydarzeniu, upewnij się, że twoje dane kontaktowe znajdują się w prezentacji. -**Rozważ utworzenie strony internetowej dla swojego projektu.** Strona internetowa sprawia, że projekt jest łatwiejszy w obsłudze i łatwiejszy w nawigacji, szczególnie gdy jest połączony z przejrzystą dokumentacją i samouczkami. Posiadanie strony internetowej sugeruje również, że Twój projekt jest aktywny, co sprawi, że Twoi odbiorcy poczują się bardziej komfortowo z niego korzystający. Podaj przykłady, aby dać ludziom pomysły, jak korzystać z twojego projektu. +**Rozważ utworzenie strony internetowej dla swojego projektu.** Strona internetowa sprawia, że projekt jest łatwiejszy w obsłudze i łatwiejszy w nawigacji, szczególnie gdy jest połączony z przejrzystą dokumentacją i samouczkami. Posiadanie strony internetowej sugeruje również, że twój projekt jest aktywny, co sprawi, że twoi odbiorcy poczują się bardziej komfortowo z niego korzystając. Podawaj przykłady użycia, aby ludzie wiedzieli, jak korzystać z twojego projektu. -[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), współtwórca Django powiedział, że strona internetowa była _"zdecydowanie najlepszą rzeczą, jaką zrobiliśmy z Django we wczesnych dniach"_. +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), współtwórca Django powiedział, że strona internetowa była _"zdecydowanie najlepszą rzeczą, jaką zrobiliśmy dla Django we wczesnych dniach projektu"_. Jeśli Twój projekt jest hostowany na GitHub, możesz użyć [GitHub Pages](https://pages.github.com/) aby łatwo stworzyć stronę internetową. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), oraz [Middleman](https://middlemanapp.com/) to [kilka przykładów](https://github.com/showcases/github-pages-examples) doskonałych, kompleksowych stron internetowych. ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) -Teraz, gdy masz wiadomość dla swojego projektu i łatwy sposób, aby ludzie mogli znaleźć Twój projekt, chodźmy i porozmawiaj z publicznością! +Teraz, gdy już masz odpowiedni komunikat dla swojego projektu oraz miejsce w którym możesz go promować, chodźmy porozmawiać z publicznością! -## Idź tam, gdzie są odbiorcy Twojego projektu (online) +## Idź tam, gdzie znajdziesz odbiorców twojego projektu (online) -Internetowy zasięg to świetny sposób na szybkie udostępnianie i rozpowszechnianie wiadomości. Korzystając z kanałów online, możesz dotrzeć do bardzo szerokiego grona odbiorców. +Internetowy zasięg to świetny sposób na szybkie udostępnianie i rozpowszechnianie treści. Korzystając z kanałów online, możesz dotrzeć do bardzo szerokiego grona odbiorców. -Skorzystaj z istniejących społeczności i platform internetowych, aby dotrzeć do odbiorców. Jeśli twój projekt open source jest projektem oprogramowania, prawdopodobnie znajdziesz odbiorców [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), lub [Quora](https://www.quora.com/). Znajdź kanały, w których Twoim zdaniem ludzie najbardziej skorzystają lub będą podekscytowani Twoją pracą. +Skorzystaj z istniejących społeczności i platform internetowych, aby dotrzeć do odbiorców. Jeśli twój projekt open source jest projektem oprogramowania, prawdopodobnie znajdziesz odbiorców [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), lub [Quora](https://www.quora.com/). Znajdź kanały, w których twoim zdaniem ludzie najbardziej skorzystają lub będą podekscytowani twoją pracą. -Sprawdź, czy możesz znaleźć sposoby na udostępnienie swojego projektu w odpowiedni sposób: +Określ odpowiednie sposoby na udostępnienie swojego projektu: -* **Poznaj odpowiednie projekty i społeczności o otwartym kodzie źródłowym.** Czasami nie musisz bezpośrednio promować swojego projektu. Jeśli Twój projekt jest idealny dla naukowców zajmujących się danymi, którzy używają Pythona, poznaj społeczność nauki danych w Pythonie. Gdy ludzie Cię poznają, pojawią się naturalne okazje do rozmowy i dzielenia się twoją pracą. -* **Znajdź osoby, które mają problem z rozwiązaniem twojego projektu.** Przeszukuj powiązane fora osób, które należą do grupy docelowej Twojego projektu. Odpowiedz na ich pytanie i znajdź taktowny sposób, w stosownych przypadkach, aby zaproponować swój projekt jako rozwiązanie. -* **Poproś o opinię.** Przedstaw siebie i swoją pracę publiczności, która uznałaby ją za przydatną i interesującą. Sprecyzuj, kto według Ciebie skorzystałby na twoim projekcie. Spróbuj dokończyć zdanie: _"Myślę, że mój projekt naprawdę pomógłby X, który próbuje zrobić Y"_. Słuchaj opinii innych i odpowiadaj na nie, zamiast po prostu promować swoją pracę. +* **Poznaj odpowiednie projekty i społeczności opensource.** Czasami nie musisz bezpośrednio promować swojego projektu. Jeśli twój projekt jest idealny dla programistów zajmujących się danymi, którzy używają Pythona, poznaj społeczności data science w Pythonie. Gdy ludzie cię poznają, pojawią się naturalne okazje do rozmowy i dzielenia się twoją pracą. +* **Znajdź osoby, które mają jakiś problem którego rozwiązaniem może być twój projekt** Przeszukuj powiązane fora osób, które należą do grupy docelowej twojego projektu. Odpowiedz na ich pytania i znajdź taktowny sposób, w stosownych przypadkach, aby zaproponować swój projekt jako rozwiązanie. +* **Poproś o opinię.** Przedstaw siebie i swoją pracę publiczności, która uznałaby ją za przydatną i interesującą. Sprecyzuj, kto według ciebie skorzystałby na twoim projekcie. Spróbuj dokończyć zdanie: _"Myślę, że mój projekt naprawdę pomógłby X, który próbuje zrobić Y"_. Słuchaj opinii innych i odpowiadaj na nie, zamiast po prostu promować swoją pracę. -Ogólnie rzecz biorąc, skup się na pomaganiu innym, zanim poprosisz o coś w zamian. Ponieważ każdy może z łatwością promować projekt online, będzie dużo hałasu. Aby wyróżnić się z tłumu, daj ludziom kontekst, kim jesteś, a nie tylko to, czego chcesz. +Ogólnie rzecz biorąc, skup się na pomaganiu innym, zanim poprosisz o coś w zamian. Ponieważ każdy może z łatwością promować projekt online, ale by wyróżnić się z tłumu, daj ludziom kontekst, kim jesteś, a nie tylko to, czego chcesz. -Jeśli nikt nie zwraca uwagi lub nie reaguje na twoje pierwsze działanie, nie zniechęcaj się! Większość uruchomień projektów jest procesem iteracyjnym, który może potrwać miesiące lub lata. Jeśli nie otrzymasz odpowiedzi za pierwszym razem, wypróbuj inną taktykę lub poszukaj sposobów, aby w pierwszej kolejności zwiększyć wartość pracy innych. Promowanie i uruchomienie projektu wymaga czasu i poświęcenia. +Jeśli nikt nie zwraca uwagi lub nie reaguje na twoje pierwsze działania, nie zniechęcaj się! Większość wprowadzeń projektów jest procesem iteracyjnym, który może potrwać miesiące lub lata. Jeśli nie otrzymasz odpowiedzi za pierwszym razem, wypróbuj inną taktykę lub poszukaj sposobów, aby w pierwszej kolejności zwiększyć wartość pracy innych. Promowanie i uruchomienie projektu wymaga czasu i poświęcenia. -## Idź tam, gdzie są odbiorcy Twojego projektu (offline) +## Idź tam, gdzie są odbiorcy dla twojego projektu (offline) ![Public speaking](/assets/images/finding-users/public_speaking.jpg) Wydarzenia offline są popularnym sposobem promowania nowych projektów wśród odbiorców. To świetny sposób na dotarcie do zaangażowanej publiczności i budowanie głębszych kontaktów międzyludzkich, szczególnie jeśli chcesz dotrzeć do programistów. -Jeśli jesteś [nowy w wystąpieniach publicznych](https://speaking.io/), zacznij od znalezienia lokalnego spotkania związanego z językiem lub ekosystemem twojego projektu. +Jeśli jesteś [nowy w wystąpieniach publicznych](https://speaking.io/), zacznij od znalezienia lokalnego spotkania związanego z językiem lub ekosystemem powiązanym z twoim projektem. diff --git a/_articles/pt/code-of-conduct.md b/_articles/pt/code-of-conduct.md index 99417090d0c..bc54236b47a 100644 --- a/_articles/pt/code-of-conduct.md +++ b/_articles/pt/code-of-conduct.md @@ -31,7 +31,7 @@ Além de comunicar aquilo que você espera, um código de conduta descreve o seg Sempre que possível, use exemplos passados. O [Contributor Covenant](https://contributor-covenant.org/) é um código de conduta que é usado por mais de 40.000 projetos _open source_, incluindo Kubernetes, Rails, e Swift. -O [Django Code of Conduct](https://www.djangoproject.com/conduct/) e o [Citizen Code of Conduct](http://citizencodeofconduct.org/) são, tambémm, outros dois bons exemplos de códigos de conduta. +O [Django Code of Conduct](https://www.djangoproject.com/conduct/) e o [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) são, tambémm, outros dois bons exemplos de códigos de conduta. Coloque um arquivo CODE_OF_CONDUCT no diretório raiz do seu projeto, e faça-o visivel a sua comunidade criando um link para ele no arquivo CONTRIBUTING ou README. @@ -40,7 +40,7 @@ Coloque um arquivo CODE_OF_CONDUCT no diretório raiz do seu projeto, e faça-o @@ -54,7 +54,7 @@ Você deve explicar como o seu código de conduta será aplicado **_antes_** que Você deve sempre dar as pessoas um modo privado (como um endereço de e-mail) para relatarem uma violação do código de conduta e informar os reponsáveis por receber as queixas. Pode ser um mantenedor, um grupo de mantenedores, ou um grupo de trabalho do código de conduta. -Não se esqueça de que alguém pode querer relatar uma violação sobre alguém que receba esses relatos. Neste caso, dê a eles uma opção para relatar violações a outra pessoa. Por exemplo, @ctb e @mr-c [explicam em seu projeto](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Não se esqueça de que alguém pode querer relatar uma violação sobre alguém que receba esses relatos. Neste caso, dê a eles uma opção para relatar violações a outra pessoa. Por exemplo, @ctb e @mr-c [explicam em seu projeto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Casos de comportamento abusivo, de assédio, ou de outra forma inaceitável podem ser relatados enviando um e-mail para **khmer-project@idyll.org**, chegando somente a C. Titus Brown e Michael R. Crusoe. Para relatar um problema envolvendo algum deles, por favor envie um e-mail para **Judi Brown Clarke, Ph.D.**, o Diretor de Diversidade no Centro BEACON para o Estudo da Evolução em Ação, um Centro NSF para Ciência e Tecnologia.* diff --git a/_articles/pt/finding-users.md b/_articles/pt/finding-users.md index 3ea6cf6fb88..2db6d191baa 100644 --- a/_articles/pt/finding-users.md +++ b/_articles/pt/finding-users.md @@ -143,14 +143,6 @@ Nunca é cedo demais ou tarde demais para iniciar a construir sua reputação. M Não há uma solução instantânea para a construção de uma audiência. Ganhar a confiança e o respeito dos outros leva tempo, e a construção de sua reputação nunca acaba. - - ## Continue assim! Pode levar um longo tempo antes das pessoas notarem seu projeto open source. Está tudo bem! Alguns dos projetos mais populares hoje levaram anos para atingir os níveis mais altos de atividade. Concentre-se em construir relacionamentos em vez de esperar que seu projeto espontâneamente ganhe popularidade. Seja paciente, e mantenha-se compartilhando seu trabalho com aqueles que o apreciam. diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md index 52ac7839efd..23c350710da 100644 --- a/_articles/pt/getting-paid.md +++ b/_articles/pt/getting-paid.md @@ -66,14 +66,6 @@ Hoje, muitas pessoas são pagas para trabalhar parcial ou integralmente com open É mais fácil convencer o seu empregador se sua empresa, de fato, utilizar o seu projeto, mas seja criativo com a sua proposta. Talvez seu projeto não seja utilizado, mas Python sim, e manter um projeto Python popular ajude a atrair novos desenvolvedores Python. Pode fazer com que sua empresa pareça mais developer-friendly, de um modo geral. - - Se você não tem um projeto open source no qual gostaria de contribuir, mas contribuiria se o que fosse produzido no seu trabalho fosse de open source, convença o seu empregador a abrir o código de alguns dos softwares internos da empresa. Muitas empresas estão desenvolvendo programas open source para construir suar marca e recrutar talentos de qualidade. @@ -101,12 +93,13 @@ Projetos que se originaram em uma grande empresa, como o [Go](https://github.com Dependendo de suas circunstâncias pessoais, você pode tentar conseguir dinheiro independentemente para financiar o seu trabalho open source. Por exemplo: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon financiou seu trabalho no [Redux](https://github.com/reactjs/redux) através de uma [campanha de crowdfunding no Patreon](https://redux.js.org/) * @andrewgodwin financiou seu trabalho no Django schema migrations [através de uma campanha no Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) -Finalmente, as vezes, projetos open source põem recompensas em issues que você pode considerar ajudar a resolver. +Finalmente, as vezes, projetos open source põem recompensas em issues que você pode considerar ajudar a resolver. -* @ConnorChristie conseguiu ser pago por [ajudar](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol a trabalhar em sua biblioteca javascript [através de uma recompensa em gitcoin](https://gitcoin.co/). +* @ConnorChristie conseguiu ser pago por [ajudar](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol a trabalhar em sua biblioteca JavaScript [através de uma recompensa em gitcoin](https://gitcoin.co/). * @mamiM fez traduções para o Japonês para @MetaMask após a [issue ser financiada na Bounties Network](https://explorer.bounties.network/bounty/134). ## Encontrando financiamento para o seu projeto @@ -123,7 +116,6 @@ Encontrar patrocínio funciona bem se você já tem uma forte audiência ou repu Alguns exemplos de patrocínio incluem: * O **[webpack](https://github.com/webpack)** arrecada dinheiro de empresas e indivíduos [através do OpenCollective](https://opencollective.com/webpack) -* O **[Vue](https://github.com/vuejs/vue)** é [financiado através do Patreon](https://github.com/open-source/stories/yyx990803) * A **[Ruby Together](https://rubytogether.org/),** é uma organização sem fins lucrativos que paga pelo trabalho no [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), e outros projetos de infraestrutura do Ruby. ### Crie um fluxo de receita @@ -134,7 +126,7 @@ Dependendo do seu projeto, você pode ser capaz de cobrar por suporte comercial, * **[Travis CI](https://github.com/travis-ci)** oferece versões pagas de seu produto * **[Ghost](https://github.com/TryGhost/Ghost)** é uma organização sem fins lucrativos, com um serviço gerenciado pago -Alguns projetos populares, como o [npm](https://github.com/npm/npm) e o [Docker](https://github.com/docker/docker), conseguem até mesmo capital de risco para dar suporte ao crescimento de seu negócio. +Alguns projetos populares, como o [npm](https://github.com/npm/cli) e o [Docker](https://github.com/docker/docker), conseguem até mesmo capital de risco para dar suporte ao crescimento de seu negócio. ### Solicite financiamento de subsídio diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md index 64faefa4df3..cf301825273 100644 --- a/_articles/pt/how-to-contribute.md +++ b/_articles/pt/how-to-contribute.md @@ -30,7 +30,7 @@ Seja codificando, desenhando interface do usuário, desenhando gráfico, escreve ### Encontre pessoas que estão interessadas em coisas parecidas -Projetos open source com comunidades calorosas e acolhedoras mantêm as pessoas voltando por anos. Muitas pessoas formam amizades duradouras através da participação em open source, seja em reuniões em conferências ou conversas online sobre burritos. +Projetos open source com comunidades calorosas e acolhedoras mantêm as pessoas voltando por anos. Muitas pessoas formam amizades duradouras através da participação em open source, seja em reuniões, em conferências ou conversas online sobre burritos. ### Encontre mentores e ensine outras pessoas @@ -68,14 +68,6 @@ Um equívoco comum sobre contribuir para o open source é que você precisa cont Mesmo se você gosta de escrever código, outros tipos de contribuições são uma ótima maneira de se envolver com um projeto e conhecer outros membros da comunidade. Construir esses relacionamentos lhe dará oportunidades de trabalhar em outras partes do projeto. - - ### Você gosta de planejar eventos? * Organize workshops ou encontros sobre o projeto, [como @fzamperin fez para NodeSchool](https://github.com/nodeschool/organizers/issues/406) @@ -94,7 +86,7 @@ Mesmo se você gosta de escrever código, outros tipos de contribuições são u * Escreva e melhore a documentação do projeto * Organize uma pasta de exemplos mostrando como o projeto é usado * Inicie uma newsletter para o projeto ou selecione resumos da lista de discussão -* Escreva tutoriais para o projeto, [como os crontribuidore do PyPA fizeram](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Escreva tutoriais para o projeto, [como os contribuidores do PyPA fizeram](https://packaging.python.org/) * Escreva uma tradução para a documentação do projeto @@ -281,7 +277,7 @@ Uneori, votarea este o departajare necesară. Totuși, cât de mult poți, accen

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

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

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

@@ -67,10 +61,10 @@ Ar trebui să explici cum codul tău de conduită va fi impus **_înainte_** ca Ar trebui să oferi oamenilor o cale privată (cum ar fi o adresă de email) pentru a raporta o încălcare a codului de conduită și să explici cine primește raportul. Ar putea fi un întreținător, un grup de întreținători, sau un grup de lucru pentru codul de conduită. -Nu uita că cineva ar putea să vrea să raporteze o încălcare despre o persoană care primește aceste rapoarte. În acest caz, dă-le o opțiune să raporteze încălcările altcuiva. De exemplu @ctb și @mr-c [explică despre proiectul lor](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Nu uita că cineva ar putea să vrea să raporteze o încălcare despre o persoană care primește aceste rapoarte. În acest caz, dă-le o opțiune să raporteze încălcările altcuiva. De exemplu @ctb și @mr-c [explică despre proiectul lor](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Exemple de comportament abuziv, hărțuitor, sau altfel inacceptabil pot fi raportate scriind email către **khmer-project@idyll.org** care ajung doar la C. Titus Brown și Michael R. Crusoe. Pentru a raporta o problemă care implică pe oricare din aceștia te rugăm să scrii email către **Judi Brown Clarke, Ph.D.** Directorul pentru Diversitate la Centrul BEACON pentru Studiul Evoluției în Acțiune, un Centru NSF pentru Știință și Tehnologie. -> +> > Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology. Pentru inspirație, aruncă o privire la [manualul impunerii](https://www.djangoproject.com/conduct/enforcement-manual/) al Django (deși poate nu vei avea nevoie de ceva atât de cuprinzător, depinzând de dimensiunea proiectului tău). diff --git a/_articles/ro/finding-users.md b/_articles/ro/finding-users.md index c9173a5268e..991646f871f 100644 --- a/_articles/ro/finding-users.md +++ b/_articles/ro/finding-users.md @@ -3,13 +3,6 @@ lang: ro title: Găsirea de utilizatori pentru proiectul tău description: Ajută-ți proiectul cu sursă deschisă să crească punându-l în mâinile utilizatorilor fericiți. class: finding -toc: - spreading-the-word: "Răspândirea cuvântului" - figure-out-your-message: "Găsește-ți mesajul" - help-people-find-and-follow-your-project: "Ajută oamenii să-ți găsească și să-ți urmeze proiectul" - go-where-your-projects-audience-is-online: "Mergi acolo unde este audiența proiectului tău (online)" - go-where-your-projects-audience-is-offline: "Mergi acolo unde este audiența proiectului tău (offline)" - build-a-reputation: "Construiește-ți o reputație" order: 3 image: /assets/images/cards/finding.png related: @@ -199,21 +192,6 @@ Nu este niciodată prea devreme, sau prea tâziu, să începi să-ți construie Nu există o soluție peste noapte de a construi un public. Obținerea încrederii și respectului celorlalți ia timp, și construirea reputației tale nu se sfârșește niciodată. - - ## Continuă! Este posibil să dureze mult înainte ca utilizatorii să observe proiectul tău cu sursă deschisă. Este în regulă! Unele dintre cele mai populare proiecte de astăzi au avut nevoie de ani pentru a atinge nivele înalte de activitate. Concentrează-te pe a construi relații în loc de a spera că proiectul tău va câștiga popularitate în mod spontan. Fii răbdător, și continuă să împărtășești munca ta cu cei care o apreciază. diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md index 52613240764..9e8f3fda107 100644 --- a/_articles/ro/getting-paid.md +++ b/_articles/ro/getting-paid.md @@ -3,11 +3,6 @@ lang: ro title: Cum să fii plătit pentru muncă open source description: Susține-ți munca în open source obținând sprijin financiar pentru timpul sau proiectul tău. class: getting-paid -toc: - why-some-people-seek-financial-support: "De ce unii oameni caută sprijin financiar" - funding-your-own-time: "Finanțarea propriului tău timp" - finding-funding-for-your-project: "Găsirea de finanțare pentru proiectul tău" - building-a-case-for-financial-support: "Construirea unui caz pentru sprijin financiar" order: 7 image: /assets/images/cards/getting-paid.png related: @@ -23,7 +18,7 @@ O mare parte din munca open source este voluntară. De exemplu, cineva ar putea avatar

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

+

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

- Dacă nu ai un proiect cu sursă deschisă existent pe care ți-ar plăcea să lucrezi, dar preferi ca să se deschidă sursa rezultatelor muncii tale curente, fă un caz pentru angajatorul tău să deschidă sursa unei părți din software-urile sale interne. Multe companii dezvoltă programe open source pentru a-și construi marca și a recruta talent de calitate. @@ -121,7 +101,7 @@ Multe companii dezvoltă programe open source pentru a-și construi marca și a @hueniverse, de exemplu, a constatat că există motive financiare pentru a justifica [investiția Walmart în open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Și @jamesgpearce a constatat că programul open source al Facebook [a făcut o diferență](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) în recrutare: > Este strâns aliniată cu cultura noastră a hackerilor, și cu felul în care organizația noastră a fost percepută. Ne-am întrebat angajații, „Ai fost conștient de programul software open source la Facebook?”. Două treimi au zis „Da”. O jumătate a zis că programul a contribuit în mod pozitiv la decizia de a lucra pentru noi. Acestea nu sunt numere marginale, ci, sper eu, o tendință care continuă. -> +> > It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues. Dacă compania ta coboară pe acest traseu, este important să păstrezi granițele între comunitate și activitatea corporativă clare. În fine, open source se susține pe sine prin contribuții de la oameni din întreaga lume, și aceasta este mai mare decât oricare companie sau locație. @@ -150,6 +130,7 @@ Proiectele care provin de la o companie mare, cum ar fi [Go](https://github.com/ În funcție de circumstanțele tale personale, poți încerca să strângi bani în mod independent pentru a-ți finanța munca open source. De exemplu: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon și-a finanțat munca pe [Redux](https://github.com/reactjs/redux) printr-o [campanie de finanțare colectivă Patreon](https://redux.js.org/) * @andrewgodwin a finanțat munca pe migrațiile de scheme Django [printr-o campanie Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) @@ -172,7 +153,6 @@ Găsirea sponsorizărilor funcționează bine dacă ai deja un public puternic s Câteva exemple de proiecte sponsorizate includ: * **[webpack](https://github.com/webpack)** strânge bani de la companii și indivizi [prin OpenCollective](https://opencollective.com/webpack) -* **[Vue](https://github.com/vuejs/vue)** este [finanțat prin Patreon](https://github.com/open-source/stories/yyx990803) * **[Ruby Together](https://rubytogether.org/),** o organizație nonprofit care plătește pentru munca pe [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), și alte proiecte de infrastructură Ruby ### Creează un flux de venit @@ -183,7 +163,7 @@ Depinzând de proiectul tău, ai putea să taxezi sprijin comercial, opțiuni de * **[Travis CI](https://github.com/travis-ci)** oferă versiuni plătite ale produsului său * **[Ghost](https://github.com/TryGhost/Ghost)** este un nonprofit cu un serviciu gestionat plătit -Unele proiecte populare, cum ar fi [npm](https://github.com/npm/npm) și [Docker](https://github.com/docker/docker), chiar strâng capital de risc pentru a susține creșterea afacerii lor. +Unele proiecte populare, cum ar fi [npm](https://github.com/npm/cli) și [Docker](https://github.com/docker/docker), chiar strâng capital de risc pentru a susține creșterea afacerii lor. ### Aplicați pentru finanțare nerambursabilă diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md index 7a52bde8b7f..232e425d4ad 100644 --- a/_articles/ro/how-to-contribute.md +++ b/_articles/ro/how-to-contribute.md @@ -3,13 +3,6 @@ lang: ro title: Cum să contribui la open source? description: Dorești să contribui la open source? Un ghid pentru facerea de contribuții open source, pentru începători și pentru veterani. class: contribute -toc: - why-contribute-to-open-source: "De ce să contribui la open source?" - what-it-means-to-contribute: "Ce înseamnă să contribui" - orienting-yourself-to-a-new-project: "Orientându-te către un nou proiect" - finding-a-project-to-contribute-to: "Găsind un proiect la care să contribui" - how-to-submit-a-contribution: "Cum să trimiți o contribuție?" - what-happens-after-you-submit-a-contribution: "Ce are loc după ce trimiți o contribuție?" order: 1 image: /assets/images/cards/contribute.png related: @@ -89,21 +82,6 @@ O neînțelegere comună despre contribuirea la open source este că trebuie să Chiar dacă îți place să scrii cod, alte tipuri de contribuții sunt o cale grozavă de a te implica într-un proiect și de a întâlni alți membri ai comunității. Construind aceste relații îți va da oportunități de a lucra pe alte părți ale proiectului. - - ### Îți place să planifici evenimente? * Organizează ateliere sau întâlniri despre proiect, [precum @fzamperin a făcut pentru NodeSchool](https://github.com/nodeschool/organizers/issues/406) @@ -122,7 +100,7 @@ Chiar dacă îți place să scrii cod, alte tipuri de contribuții sunt o cale g * Scrie și îmbunătățește documentația proiectului * Selectează un dosar de exemple arătând cum este folosit proiectul * Începe un buletin informativ pentru proiect, sau selectează sublinieri din lista de email-uri -* Scrie tutoriale pentru proiect, [cum au făcut contribuitorii PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Scrie tutoriale pentru proiect, [cum au făcut contribuitorii PyPA](https://packaging.python.org/) * Scrie o traducere pentru documentația proiectului -Echipele de conducere ar putea dori să creeze un canal desemnat (cum ar fi pe IRC) sau să se întâlnească periodic să discute despre proiect (cum ar fi pe Gitter sau Google Hangouts). Poți chiar face aceste întâlniri publice astfel încât alți oameni pot asculta. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), de exemplu, [găzduiește ore de lucru săptămânal](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs). +Echipele de conducere ar putea dori să creeze un canal desemnat (cum ar fi pe IRC) sau să se întâlnească periodic să discute despre proiect (cum ar fi pe Gitter sau Google Hangouts). Poți chiar face aceste întâlniri publice astfel încât alți oameni pot asculta. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), de exemplu, [găzduiește ore de lucru săptămânal](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). Odată ce ai stabilit roluri de conducere, nu uita să documentezi modul în care oamenii pot să le atingă! Stabilește un proces clar pentru cum cineva poate deveni un întreținător sau să se alăture unui subcomitet în cadrul proiectului tău, și scrie aceasta în GOVERNANCE.md-ul tău. diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md index 4c405604fa2..bc152be4c9d 100644 --- a/_articles/ro/legal.md +++ b/_articles/ro/legal.md @@ -3,14 +3,6 @@ lang: ro title: Latura juridică a open source description: Tot ce te-ai întrebat vreodată de latura juridică a open source, și câteva lucruri de care nu te-ai întrebat. class: legal -toc: - why-do-people-care-so-much-about-the-legal-side-of-open-source: "De ce oamenilor le pasă atât de mult de partea juridică a open source?" - are-public-github-projects-open-source: "Sunt proiectele GitHub publice open source?" - just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Doar dă-mi TL;DR-ul a ce-mi trebuie pentru a-mi proteja proiectul." - which-open-source-license-is-appropriate-for-my-project: "Ce licență open source este potrivită pentru proiectul meu?" - what-if-i-want-to-change-the-license-of-my-project: "Ce se întâmplă dacă vreau să schimb licența proiectului meu?" - does-my-project-need-an-additional-contributor-agreement: "Proiectul meu are nevoie de o înțelegere cu contributorii în plus?" - what-does-my-companys-legal-team-need-to-know: "Ce trebuie să știe echipa juridică a companiei mele?" order: 10 image: /assets/images/cards/legal.png related: @@ -40,7 +32,7 @@ Când tu [creezi un proiect nou](https://help.github.com/articles/creating-a-new ![Creează depozit](/assets/images/legal/repo-create-name.png) -**A face proiectul tău GitHub public nu este același lucru cu licențierea proiectului tău.** Proiectele publice sunt acoperite de [Termenii serviciului GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), care permite altora să vadă și să bifurce proiectul tău, dar munca ta în rest vine fără permisiuni. +**A face proiectul tău GitHub public nu este același lucru cu licențierea proiectului tău.** Proiectele publice sunt acoperite de [Termenii serviciului GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), care permite altora să vadă și să bifurce proiectul tău, dar munca ta în rest vine fără permisiuni. Dacă dorești ca alții să folosească, să distribuie, să modifice, sau să contribuie înapoi la proiectul tău, tu trebuie să incluzi o licență open source. De exemplu, cineva nu poate în mod legal folosi nicio parte a proiectului tău GitHub în codul lor, chiar dacă este public, decât dacă tu le dai în mod explicit dreptul să facă acest lucru. @@ -120,13 +112,13 @@ De asemenea, prin adăugarea de „hârtii” pe care unii le cred nenecesare, g

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

Unele situații în care ai putea dori să consideri un acord suplimentar de contributor pentru proiectul tău includ: -* Avocații tăi vor ca toți contributorii să accepte în mod expres (_semneze_, online sau offline) termenii de contribuție, poate deoarece ei simt că licența open source în sine nu este destul (chiar dacă este!). Dacă aceasta este singura îngrijorare, un acord de contributor care afirmă licența de sursă deschisă a proiectului ar trebui să fie destul. [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) este un exemplu bun de un acord suplimentar ușor de contributor. Pentru unele proiecte, un [Developer Certificate of Origin](https://github.com/probot/dco) poate fi o alternativă. +* Avocații tăi vor ca toți contributorii să accepte în mod expres (_semneze_, online sau offline) termenii de contribuție, poate deoarece ei simt că licența open source în sine nu este destul (chiar dacă este!). Dacă aceasta este singura îngrijorare, un acord de contributor care afirmă licența de sursă deschisă a proiectului ar trebui să fie destul. [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) este un exemplu bun de un acord suplimentar ușor de contributor. Pentru unele proiecte, un [Developer Certificate of Origin](https://github.com/probot/dco) poate fi o alternativă. * Proiectul tău folosește o licență de sursă deschisă care nu include o acordare expresă de brevet (cum ar fi MIT), și ai nevoie de o acordare de brevet de la toți contributorii, dintre care unii ar putea lucra pentru companii cu portofolii largi de brevete care ar putea să fie folosite să te țintească pe tine sau pe ceilalți contributori și utilizatori ai proiectului. [Individual Contributor License Agreement al Apache](https://www.apache.org/licenses/icla.pdf) este un acord suplimentar de contributor folosit în mod obișnuit care are o acordare de brevet oglindind-o pe cea găsită în Apache License 2.0. * Proiectul tău se află sub o licență copyleft, dar tu trebuie de asemenea să distribui o versiune de proprietate a proiectului. Îți va trebui ca fiecare contributor să-ți atribuie drepturile de autor ție sau să-ți acorde ție (dar nu publicului) o licență permisivă. [Contributor Agreement al MongoDB](https://www.mongodb.com/legal/contributor-agreement) este un exemplu de acest tip de acord. * Te gândești că proiectul tău ar putea necesita schimbarea licențelor de-a lungul duratei lui de viață și dorești ca acești contributori să fie de acord în avans cu asemenea schimbări. @@ -155,7 +147,7 @@ Dacă lansezi primul proiect cu sursă deschisă al companiei, ce este scris mai Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta compania să obțină mai mult din implicarea ei în open source, și pentru a rămâne în siguranță: -* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) al Rackspace. +* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) al Rackspace. * **Ce să lansezi:** [(Aproape) totul?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Dacă echipa voastră juridică înțelege și este investită în strategia open source a companiei voastre, ei vor fi cel mai bine capabili să te ajute în loc să împiedice eforturile tale. -* **Conformare:** Chiar dacă compania ta nu lansează niciun proiect cu sursă deschisă, ea folosește software open source al altora. [Conștientizarea și procesul](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) pot preveni dureri de cap, întârzieri de produs, și procese. +* **Conformare:** Chiar dacă compania ta nu lansează niciun proiect cu sursă deschisă, ea folosește software open source al altora. [Conștientizarea și procesul](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) pot preveni dureri de cap, întârzieri de produs, și procese. diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md new file mode 100644 index 00000000000..111bf483312 --- /dev/null +++ b/_articles/ru/best-practices.md @@ -0,0 +1,280 @@ +--- +lang: ru +title: Хорошие практики для мейнтейнеров +description: Облегчение вашей жизни в качестве мейнтейнера опенсорс-проекта — от документирования процессов до привлечения вашего сообщества. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Что значит быть мейнтейнером? + +Если вы поддерживаете опенсорс-проект, которым пользуется множество людей, возможно, вы заметили, что стали меньше писать код и больше отвечать на ишью. + +На ранних стадиях проекта вы экспериментируете с новыми идеями и принимаете решения, основываясь на собственных предпочтениях. По мере роста популярности вашего проекта вы будете больше работать со своими пользователями и контрибьюторами. + +Для поддержки проекта требуется нечто большее, чем просто код. Эти задачи часто бывают неожиданными, но они не менее важны для растущего проекта. Мы собрали несколько способов облегчить вашу жизнь — от документирования процессов до привлечения вашего сообщества. + +## Документирование процессов + +Как мейнтейнеру вам предстоит много писать, — это одна из наиболее главных ваших задач. + +Документация не только проясняет вашу голову, но и помогает другим людям понять, что вам нужно или чего вы ждете, еще до того, как они спросят. + +На письме легче сказать «нет», когда что-то не вписывается в рамки проекта. Это также поможет людям присоединиться и помочь вам. Ведь никогда не знаешь, кто может интересоваться или использовать ваш проект. + +Даже если вы не собираетесь писать много текста, наброска с основными тезисами будет вполне достаточно, по крайней мере это лучше, чем ничего. + +Не забывайте обновлять документацию. Если не всегда получается это сделать, удалите устаревшую документацию или укажите, что она устарела, таким образом участники могут помочь с этим. + +### Запишите видение проекта + +Начните с составления целей вашего проекта. Добавьте их в свой README или создайте отдельный файл с именем VISION. Если есть другая похожая информация, которая может помочь, например план развития (дорожная карта) проекта, то также сделайте их общедоступными. + +Наличие четкого и задокументированной концепции проекта поможет вам сосредоточиться на главном и избежать «неконтролируемого роста проекта» от участия других людей. + +Например, @lord обнаружил, что видение проекта помогло ему понять правильно расставить приоритеты. Как новый мейнтейнер, он сожалел, что не проследил за расползанием границ проекта, когда получил свой первый запрос на реализацию новой функциональности в [Slate](https://github.com/lord/slate). + + + +### Сообщите о своих ожиданиях + +Написание правил может утомлять вас. Иногда вам может показаться, что вы следите за поведением других людей или убиваете все веселье. + +Однако справедливое выполнение хорошо составленных правил расширяют возможности мейнтейнеров. Это избавит вас от вовлечения в малоприятные дела. + +Большинство людей, сталкивающиеся с вашим проектом, ничего не знают о вас или ваших обстоятельствах. Они могут предположить, что вам платят за работу над проектом, особенно если они его регулярно используют и полагаются на него. Может быть, когда-то вы уделили много времени своему проекту, но теперь заняты новой работой или семейными занятиями. + +Всё это абсолютно нормально! Только дайте знать об этом другим людям. + +Если вы занимаетесь проектом нерегулярно или на добровольных началах, честно признайте, сколько у вас есть времени. Не стоит путать имеющиеся у вас время и время, которое, по вашему мнению, требуется для проекта или от вас ожидают другие. + +Вот несколько правил, которые стоит установить: + +* Как рассматривается и принимается вклад (_Нужно ли написать тесты? Шаблон ишью?_) +* Типы вкладов, которые вы принимаете (_Вам нужна помощь только с определенной частью вашего кода?_) +* Когда следует предпринять последующие действия (_например, «Вы можете ожидать ответа от мейнтейнера в течение 7 дней. Если после этого времени вы не получили ответ, не стесняйтесь поднимать тему»._) +* Сколько времени вы тратите на проект (_например, «Мы тратим на этот проект всего около 5 часов в неделю»_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) и [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) — это лишь несколько примеров проектов с основными правилами для мейнтейнеров и контрибьюторов. + +### Поддерживайте публичность обсуждений + +Не забывайте также фиксировать свои беседы. Там, где это возможно, делитесь информацией о своем проекте публично. Если кто-то пытается связаться с вами напрямую, чтобы обсудить реализацию новой функциональности или получить помощь, вежливо направьте его на общедоступный канал связи, такой как список рассылки или ишью. + +Если вы встречаетесь с другими мейнтейнерами или принимаете важное решение в частном порядке, записывайте всё, даже если это просто публикация ваших заметок. + +Таким образом, любой, кто присоединится к вашему сообществу, будет иметь доступ к той же информации, что и тот, кто был там годами. + +## Научитесь говорить «нет» + +Вы всё записали. В идеальном мире все бы прочитали документацию, но вот только в реальности вам придется напоминать людям об её существовании. + +Однако ссылка на письменные объяснения поможет обезличить ситуации, когда нужно обеспечить соблюдение правил. + +Также сам отказ следует сделать как можно менее личным, например, вместо _«Мне не нравится ваш вклад»_ намного лучше написать _«Ваш вклад не соответствует критериям этого проекта»_. + +Отказывать применимо во многих ситуациях, с которыми вы столкнетесь как мейнтейнер, например, когда кто-то просит реализовать новую функциональность, которая не вписывается в проект, или мешает обсуждению, либо выполняет ненужную для других работу. + +### Поддерживайте дружескую беседу + +Как правило, в ишью и пул-реквестах вы будете практиковаться отказывать людям. Как мейнтейнер проекта, вы неизбежно будете получать ненужные предложения. + +Возможно вклад сильно меняет суть проекта или не соответствует вашему видению. Может идея хорошая, но реализация оставляет желать лучшего. + +Независимо от причины, нужно с пониманием относится к предлагаемым изменениям, которые не соответствуют стандартам вашего проекта. + +Если видите вклад, который не собираетесь принимать, первой реакцией может быть проигнорировать его или притвориться, что его нет. Однако это может обидеть автора, и даже демотивировать потенциальных контрибьюторов. + + + +Не оставляйте ненужным вклад открытым из-за чувства вины или вежливости. Со временем все оставшиеся без ответа ишью и PR только усложнят и замедлят вашу работу над проектом. + +Если вы понимаете, что не сможете принять вклад, лучше сразу его закройте. Если в вашем проекте уже накопилось большое количество нерассмотренных заявок, у @steveklabnik есть предложения по [эффективной сортировке ишью](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +Кроме того, игнорирование вкладов оказывает отрицательное воздействие на ваше сообщество. Участие в проекте может быть пугающим, особенно в первый раз. Даже если вы не собираетесь принимать вклад, поблагодарите его автора за проявленный интерес. Это большой комплимент! + +Если вы не хотите принимать вклад: + +* **Поблагодарите автора** за работу +* **Объясните, почему он вписывается** в рамки проекта, и, если можете, подготовьте четкие предложения по улучшению. Будьте добрым, но строгим. +* **Прикрепите ссылку на соответствующую документацию**, если она у вас есть. Если вы замечаете повторяющиеся нежелательные пул-реквесты, напишите об этом в документации. +* **Закройте пул-реквест** + +Для ответа достаточно будет 1-2 предложений. Например, когда пользователь [celery](https://github.com/celery/celery/) сообщил об ошибке, связанной с Windows, @berkerpeksag [ответил](https://github.com/celery/celery/issues/3383): + +![Скриншот из Celery](/assets/images/best-practices/celery.png) + +Если мысль о том, чтобы сказать «нет», пугает вас, вы не одиноки. Как [выразился](https://blog.jessfraz.com/post/the-art-of-closing/) @jessfraz: + +> Я разговаривал с мейнтейнерами из нескольких различных опенсорс-проектов, Mesos, Kubernetes, Chromium, и все они согласны с тем, что одна из самых сложных частей работы мейнтейнера — это отказаться от ненужных патчей. + +Не чувствуйте себя виноватым из-за того, что не хотите принимать чей-то вклад. Первое правило опенсорса, [согласно](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _«Нет — временно, да — навсегда»._ Сочувствовать энтузиазму другого человека - это хорошо, отказываться от его вклада — не значит отвергать его автора. + +В конечном итоге, если вклад недостаточно хорош, вы не обязаны его принимать. Будьте добры и отзывчивы, когда люди вносят свой вклад в ваш проект, но принимайте только те изменения, которые, по вашему мнению, сделают ваш проект лучше. Чем чаще вы будете говорить «нет», тем легче будет это получаться. Обещаю. + +### Будьте инициативным(ой) + +Прежде всего, чтобы уменьшить количество нежелательных вкладов, распишите процесс отправки и принятия вкладов в своем руководстве по участию вашего проекта. + +Если вам приходят слишком много некачественных вкладов, потребуйте от контрибьюторов выполнить ряд условий, например: + +* Заполнить шаблон/контрольный список для в ишью или пул-реквесте +* Открыть ишью перед отправкой пул-реквеста + +Если люди не соблюдают ваши правила, немедленно закройте ишью и укажите им на предварительные требования. + +Поначалу такой подход может показаться суровым, но на самом деле проактивность полезна для обеих сторон. Это снижает вероятность того, что кто-то потратит впустую много часов работы на ненужный для вас пул-реквест. А ещё для вас снизится нагрузка. + + + +Иногда, когда вы говорите «нет», потенциальный контрибьютор может расстроиться или раскритиковать ваше решение. Если его поведение становится враждебным, [примите меры, чтобы разрядить ситуацию](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или даже удалите его из вашего сообщества, если он не готов к конструктивному сотрудничеству. + +### Примите наставничество + +Возможно, кто-то из вашего сообщества регулярно отправляет вклады, не соответствующие стандартам вашего проекта. Не только автор, но мейнтейнер может быть разочарован, если постоянно приходится отказывать в принятии вклада. + +Если вы видите, что кто-то с энтузиазмом подходит к вашему проекту, но его работа требует доработки, будьте терпеливы. Четко объясните в каждой ситуации, почему их вклад не соответствует ожиданиям проекта. Попробуйте предложить людям более легкую или менее расплывчатую задачу, например, ишью с ярлыком _"good first issue"_, чтобы набраться опыта и попробовать себя. Если у вас есть время, подумайте о наставничестве в их первом вкладе, или найдите кого-нибудь в вашем сообществе, кто согласился стать ментором. + +## Используйте силу сообщества + +Необязательно все делать самому. Сообщество вашего проекта существует не просто так! Даже если у вас еще нет активных контрибьюторов, но зато есть много пользователей, попробуйте привлечь их. + +### Распределите рабочую нагрузку + +Если вы ищете, кто мог бы помочь, начните с расспросов. + +Один из способов привлечь новых контрибьюторов — [добавить ярлык на те ишью, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем GitHub будет отображать их в различных местах сайта, делая тем самым их более заметными. + +Когда вы видите, что новые контрибьюторы неоднократно вносят свой вклад, признайте их работу, предложив больше ответственности. Задокументируйте, как люди могут занять руководящие роли, если захотят. + +Побуждение других [разделить владение проектом](../building-community/#совместное-владение-вашим-проектом) может значительно снизить вашу нагрузку, как обнаружила @lmccart в своем проекте [p5.js](https://github.com/processing/p5.js). + + + +Если вам нужно отойти от проекта, будь то сделать перерыв или навсегда покинуть его, нет ничего постыдного в том, чтобы попросить кого-то другого взять на себя ваши обязанности. + +Если другие люди полны энтузиазма относительно направления развития проекта, предоставьте им доступ к отправке коммитов или официально передайте контроль кому-то другому. Если кто-то форкнул ваш проект и начал активно заниматься его копией, подумайте о том, чтобы указать ссылку на него в уже вашем (оригинальном) проекте. Здорово, что так много людей хотят, чтобы ваш проект продолжал развиваться! + +@progrium [обнаружил, что](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) документирование видения его проекта [Dokku](https://github.com/dokku/dokku) помогло достичь этих целей даже после того, как он ушел из проекта: + +> Я написал вики-страницу с описанием того, что я хотел сделать и почему. Почему-то для меня стало неожиданностью, что мейнтейнеры начали двигать проект в этом направлении! Всё происходило именно так, как я хотел? Не всегда. Но все же приблизило проект к тому, что я написал. + +### Позвольте другим создавать нужные им решения + +Если потенциальный контрибьютор придерживается другого мнения, что должен делать ваш проект, вы можете мягко подтолкнуть его к работе над собственным форком. + +Не следует воспринимать копии проекта чем-то плохим. Возможность копировать и изменять проекты — одна из лучших особенностей опенсорса. Содействие членов вашего сообщества к работе над собственным форком может дать им необходимую творческую отдушину, без ущерба вашему проекту. + + + +То же самое относится к пользователю, которому действительно нужно решение, но для создания которого у вас просто нет ресурсов. Предлагая API-интерфейсы и хуки для кастомизации, можно помочь другим пользователям решить их задачи без необходимости напрямую изменять исходный код. @orta [обнаружил, что](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) поощрение плагинов для CocoaPods привело к «некоторым из самых интересных идей»: + +> Почти неизбежно, что когда проект становится большим, мейнтейнеры должны стать более консервативными касательно нового кода. Вы научитесь отказывать, несмотря, что у многих людей есть разумные причины. Так что в итоге вы превращаете свой инструмент в платформу. + +## Задействуйте роботов + +Подобно тому, как есть задачи, с которыми вам могут помочь другие люди, так и есть задачи, которые не должен выполнять ни один человек. Роботы — ваши друзья. Используйте их, чтобы облегчить себе жизнь в качестве мейнтейнера. + +### Требуйте тесты и другие проверки для улучшения качества кода + +Один из наиболее важных способов автоматизации проекта — это написание тестов. + +Тесты помогают участникам чувствовать себя уверенно в том, что в результате новых изменений ничего не было сломано. Они также облегчают рассмотрение и принятие вкладов. Чем активнее вы будете реагировать, тем более заинтересованным может быть ваше сообщество. + +Настройте автотесты, которые будут запускаться на всех входящих вкладов, и убедитесь, что они могут быть выполнены контрибьюторами локально. Требуйте, чтобы весь код от контрибьюторов проходил тесты, до того, как они отправлять сам вклад. Вы поможете установить минимальный стандарт качества для всех отправляемых вкладов. [Обязательные проверки статуса](https://help.github.com/articles/about-required-status-checks/) на GitHub помогут проследить за тем, что никакие изменения не будут объединены без прохождения тестов. + +Если вы добавляете тесты, обязательно объясните, как они работают в файле CONTRIBUTING. + + + +### Используйте инструменты для автоматизации основных задач сопровождения + +Что хорошо в поддержке популярного проекта, так это то, что другие мейнтейнеры, вероятно, сталкивались с аналогичными проблемами и решили их. + +Существует [множество инструментов](https://github.com/showcases/tools-for-open-source), которые помогают автоматизировать некоторые аспекты работ по сопровождению. Несколько примеров: + +* [semantic-release](https://github.com/semantic-release/semantic-release) автоматизирует ваши релизы +* [mention-bot](https://github.com/facebook/mention-bot) упоминает потенциальных ревьюеров для пул-реквеста +* [Danger](https://github.com/danger/danger) помогает автоматизировать проверку кода +* [no-response](https://github.com/probot/no-response) закрывает ишью, если автор не предоставил дополнительную информацию +* [dependabot](https://github.com/dependabot) ежедневно следует за актуальностью зависимостей, и если находит что-то новое, то открывает отдельные пул-реквесты + +Для сообщений об ошибках и других общих проблем на GitHub есть [шаблоны для ишью и пул-реквеста](https://github.com/blog/2111-issue-and-pull-request-templates), которые можно создать для упрощения взаимодействия с сообществом. @TalAter создал [руководство Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/), чтобы помочь вам написать собственные шаблоны ишью и пул-реквеста. + +Для управления уведомлениями по электронной почте вы можете настроить [фильтры электронной почты](https://github.com/blog/2203-email-updates-about-your-own-activity), чтобы отсортировать их по приоритету. + +Если вы хотите ещё немного продвинуться, руководства по стилю и линтеры помогут стандартизировать вклады в проект и упростить их просмотр и принятие. + +Однако, если ваши стандарты слишком сложные, они могут увеличить препятствия на пути к участию. Убедитесь, что вы добавляете только необходимые правила, чтобы облегчить всем жизнь. + +Если вы не знаете, какие инструменты использовать, посмотрите на опыт других популярных проектов, особенно в вашей экосистеме. Например, как выглядит процесс участия в других модулей Node? Использование похожих инструментов и подходов также сделает ваш процесс более знакомым для потенциальных контрибьюторов. + +## Взять паузу — это нормально + +Когда-то опенсорс-работа приносила вам радость. А возможно теперь вы начинаете чувствовать себя виноватым или не идите на контакт. + +Возможно, вы чувствуете себя разбитым или вас не покидает растущее чувство страха, когда думаете о своих проектах. А между тем ишью и пул-реквесты накапливаются. + +Выгорание — реальная и распространенная проблема при работе над опенсорсом, особенно среди мейнтейнеов. Ваше счастье как мейнтейнера — непреложное условие для выживания любого опенсорс-проекта. + +Хотя это само собой разумеется, но делайте перерыв! Не нужно ждать, пока вы почувствуете выгорание, чтобы взять отпуск. @brettcannon, разработчик ядра Python, решил взять [отпуск на месяц](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) после 14 лет волонтерской работы в опенсорсе. + +Как и любой другой вид работы, регулярные перерывы позволяют вам оставаться бодрым, счастливым и увлечённым своей работой. + + + +Иногда бывает трудно сделать перерыв в опенсорс-работе, когда кажется, что вы нужны всем. Люди могут даже попытаться заставить вас почувствовать себя виноватым за то, что вы временно отошли от дел. + +Постарайтесь найти поддержку для своих пользователей и сообщества на время вашего отсутствия в проекте. Если вы не можете найти необходимую поддержку, всё равно возьмите паузу. Но обязательно предупредите людей об вашем отпуске, чтобы их не смущало отсутствие вашей реакции. + +Перерывы относятся не только к отпуску. Если вы не хотите заниматься опенсорсом по выходным или в рабочее время, сообщите об этом людям, чтобы они знали, что вас не надо беспокоить. + +## Береги себя в первую очередь! + +Поддержка популярного проекта требует иных навыков, чем на ранних этапах развития, но это не уменьшает пользу описанных выше советов. Как мейнтейнер, вы будете практиковать лидерские и личные навыки на таком уровне, который мало кому удаётся испытать. Хотя управлять проектом не всегда легко, выстраивание чётких границ и адекватная оценка своих сил помогут вам оставаться счастливыми, бодрыми и продуктивными. diff --git a/_articles/ru/building-community.md b/_articles/ru/building-community.md new file mode 100644 index 00000000000..d36599b4600 --- /dev/null +++ b/_articles/ru/building-community.md @@ -0,0 +1,276 @@ +--- +lang: ru +title: Создание дружного сообщества +description: Создание сообщества, которое побуждает людей использовать, вносить свой вклад и распространять ваш проект. +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Настройка вашего проекта на успех + +Вы запустили свой проект, распространяете информацию, и люди пробуют его. Потрясающе! Как убедить их остаться? + +Доброжелательное сообщество — это инвестиция в будущее и репутацию вашего проекта. Если ваш проект только начинает получать сторонний вклад, начните с того, чтобы дать первым участникам положительный опыт, чтобы им хотелось возвращаться. + +### Сделайте так, чтобы люди чувствовали себя желанными гостями + +Один из способов подумать о сообществе вашего проекта — это то, что @MikeMcQuaid называет [воронкой участников](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Воронка участников](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +Создавая свое сообщество, подумайте, как кто-то наверху воронки (потенциальный пользователь) теоретически может добраться до конца вниз (активный сопровождающий). Ваша цель — уменьшить трение на каждом этапе взаимодействия с участником. Когда у людей легкие победы, они будут чувствовать стимул делать больше. + +Начните с вашей документации: + +* **Облегчите использование вашего проекта для любого желающего.** [Дружественное README](../starting-a-project/#написание-readme) и понятные примеры кода помогут любому, кто заинтересуется вашим проектом, начать работу. +* **Объясните, как участвовать**, используя [руководство для участников](../starting-a-project/#написание-руководства-для-участников) и оперативно отвечая на вопросы (issues). +* **Хорошие первые вопросы (issues)**: чтобы помочь новым участникам начать работу, явно рассмотрите [ярлыки вопросов, которые достаточно просты для начинающих](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). Затем GitHub выведет эти вопросы в различных местах платформы, увеличивая полезный вклад и уменьшая трение пользователей, решающих проблемы, которые слишком сложны для их уровня. + +[Обзор открытого исходного кода GitHub за 2017 год](http://opensourcesurvey.org/2017/) показал, что неполная или запутанная документация является самой большой проблемой для пользователей открытого исходного кода. Хорошая документация побуждает людей взаимодействовать с вашим проектом. В конце концов, кто-то откроет вопрос или пул-реквест. Используйте эти взаимодействия как возможности для продвижения их по воронке. + +* **Когда кто-то новый попадает в ваш проект, поблагодарите его за проявленный интерес!** Достаточно одного негативного опыта, чтобы кто-то не захотел возвращаться. +* **Будьте отзывчивы.** Если вы не отвечаете на их вопрос в течение месяца, скорее всего, они уже забыли о вашем проекте. +* **Будьте открыты в отношении помощи, которую вы примете.** Многие участники начинают с отчета об ошибке или небольшого исправления. Есть [много способов внести свой вклад](../how-to-contribute/#что-значит-внести-свой-вклад) в проект. Позвольте людям помочь так, как они хотят помочь. +* **Если есть предложение, с которым вы не согласны,** поблагодарите их за идею и [объясните, почему](../best-practices/#научитесь-говорить-нет) она не вписывается в рамки проекта, дав ссылку на соответствующую документацию, если она у вас есть. + + + +Большинство участников открытого исходного кода являются «случайными»: людьми, которые вносят свой вклад в проект лишь от случая к случаю. У случайного участника может не быть времени, чтобы полностью освоить ваш проект, поэтому ваша задача - упростить для него участие. + +Поощрение других участников - тоже вложение в себя. Когда вы позволяете своим самым большим поклонникам заниматься тем, чем они увлечены, становится меньше необходимости делать все самостоятельно. + +### Документируйте все + + + +Когда вы начинаете новый проект, может показаться естественным сохранить конфиденциальность своей работы. Но проекты с открытым исходным кодом процветают, когда вы публично документируете свой процесс. + +Когда вы что-то записываете, больше людей могут участвовать на каждом этапе пути. Вы можете получить помощь в том, о чем даже не подозревали. + +Запись означает больше, чем просто техническая документация. Каждый раз, когда вы чувствуете желание записать что-то или обсудить свой проект в частном порядке, спросите себя, можете ли вы сделать это публично. + +Будьте прозрачны в отношении дорожной карты вашего проекта, типов вкладов, которые вы ищете, того, как оцениваются вклады, или почему вы приняли определенные решения. + +Если вы заметили, что несколько пользователей сталкиваются с одной и той же проблемой, задокументируйте ответы в README. + +Для встреч рассмотрите возможность публикации заметок или выводов по актуальному вопросу. Отзывы, которые вы получите от такого уровня прозрачности, могут вас удивить. + +Документирование всего относится и к вашей работе. Если вы работаете над существенным обновлением своего проекта, поместите его в пул-реквест и отметьте как незавершенное (WIP). Таким образом, другие люди могут почувствовать себя вовлеченными в процесс на ранней стадии. + +### Будьте отзывчивы + +По мере того, как вы [продвигаете свой проект](../finding-users), люди будут получать от вас обратную связь. У них могут быть вопросы о том, как все работает, или им может потребоваться помощь для начала работы. + +Постарайтесь оперативно реагировать, когда кто-то задаёт вопрос, отправляет запрос на перенос или задает вопрос о вашем проекте. Если вы ответите быстро, люди почувствуют себя участниками диалога и будут с большим энтузиазмом участвовать. + +Даже если вы не можете сразу просмотреть запрос, заблаговременное признание его поможет повысить вовлеченность. Вот как @tdreyno ответил на пул-реквест в [Middleman](https://github.com/middleman/middleman/pull/1466): + +![Пул-ревест Middleman](/assets/images/building-community/middleman_pr.png) + +[Исследование Mozilla показало, что](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) участники, чей код проверили в течение 48 часов, чаще возвращались и делали повторный вклад. + +Разговоры о вашем проекте также могут происходить в других местах в Интернете, таких как Stack Overflow, Twitter или Reddit. Вы можете настроить уведомления в некоторых из этих мест, чтобы получать их, когда кто-то упоминает ваш проект. + +### Дайте вашему сообществу место для собраний + +Есть две причины, чтобы дать вашему сообществу место для собраний. + +Первая причина для них. Помогите людям узнать друг друга. Люди с общими интересами неизбежно захотят об этом поговорить. А когда общение открыто и доступно, любой может прочитать прошлые архивы, чтобы быть в курсе и начать участвовать. + +Вторая причина для вас. Если вы не предоставите людям публичное место для обсуждения вашего проекта, они, скорее всего, свяжутся с вами напрямую. Вначале может показаться достаточно простым ответить на личные сообщения «только один раз». Но со временем, особенно если ваш проект станет популярным, вы почувствуете себя истощенным. Не поддавайтесь искушению поговорить с людьми о своем проекте наедине. Вместо этого направьте их на назначенный общедоступный канал. + +Публичное общение может быть таким же простым, как указание людям открыть проблему вместо того, чтобы писать вам напрямую или комментировать ваш блог. Вы также можете настроить список рассылки или создать учетную запись Twitter, Slack или IRC-канал, чтобы люди говорили о вашем проекте. Или попробуйте все вышеперечисленное! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) каждые две недели выделяет рабочие часы, чтобы помочь участникам сообщества: + +> Копы также выделяют время раз в две недели, чтобы предложить помощь и руководство сообществу. Сопровождающие Копов согласились выделить время, специально предназначенное для работы с новичками, помощи с PR и обсуждения новых функций. + +Заметными исключениями из публичного общения являются: 1) проблемы безопасности и 2) конфиденциальные нарушения кодекса поведения. У вас всегда должна быть возможность сообщить об этих проблемах в частном порядке. Если вы не хотите использовать свою личную электронную почту, создайте специальный адрес электронной почты. + +## Развитие вашего сообщества + +Сообщества чрезвычайно сильны. Эта сила может быть благословением или проклятием, в зависимости от того, как вы ею владеете. По мере роста сообщества вашего проекта есть способы помочь ему стать силой созидания, а не разрушения. + +### Не терпите плохих участников + +Любой популярный проект неизбежно привлечет людей, которые скорее вредят, чем помогают вашему сообществу. Они могут начать ненужные споры, спорить о тривиальных особенностях или запугивать других. + +Сделайте все возможное, чтобы принять политику нулевой терпимости по отношению к этим типам людей. Если оставить это без внимания, негативные люди создадут дискомфорт другим людям в вашем сообществе. Которые могут даже уйти. + + + +Регулярные дебаты о тривиальных аспектах вашего проекта отвлекают других, в том числе вас, от сосредоточения на важных задачах. Новые люди, которые приходят на ваш проект, могут видеть эти разговоры и не хотят участвовать. + +Когда вы видите негативное поведение в своем проекте, объявите об этом публично. Объясните добрым, но твердым тоном, почему их поведение неприемлемо. Если проблема не исчезнет, вам может потребоваться [попросить их уйти](../code-of-conduct/#обеспечение-соблюдения-вашего-кодекса-поведения). Ваш [кодекс поведения](../code-of-conduct/) может быть конструктивным руководством для таких разговоров. + +### Познакомьтесь с участниками там, где они есть + +Хорошая документация становится только важнее по мере роста вашего сообщества. Случайные участники, которые иначе могут не быть знакомы с вашим проектом, читают вашу документацию, чтобы быстро получить контекст, в котором они нуждаются. + +В вашем файле CONTRIBUTING явным образом сообщите новым участникам, как начать работу. Возможно, вы даже захотите создать для этой цели специальный раздел. [Django](https://github.com/django/django), например, имеет специальную целевую страницу, чтобы приветствовать новых участников. + +![Страница новых участников Django](/assets/images/building-community/django_new_contributors.png) + +В очереди задач пометьте ошибки, которые подходят для разных типов участников: например, [_"только для новичков"_](https://kentcdodds.com/blog/first-timers-only), _"как составить первый вопрос"_, или _"документацию"_. [Эти ярлыки](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) упрощают быстрое сканирование ваших вопросов для новичков в вашем проекте, чтобы начать действовать. + +Наконец, используйте свою документацию, чтобы люди чувствовали себя желанными на каждом этапе пути. + +Вы никогда не будете взаимодействовать с большинством людей, которые попадают в ваш проект. Могут быть вклады, которые вы не получили, потому что кто-то испугался или не знал, с чего начать. Даже несколько добрых слов могут удержать кого-то от разочарования. + +Например, вот как [Rubinius](https://github.com/rubinius/rubinius/) начинает [свое руководство](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> Мы хотим начать с того, чтобы поблагодарить вас за использование Rubinius. Этот проект — плод любви, и мы ценим всех пользователей, которые вылавливают ошибки, улучшают производительность и помогают с документацией. Каждый вклад значим, поэтому спасибо за участие. При этом вот несколько рекомендаций, которым мы просим вас следовать, чтобы мы могли успешно решить вашу проблему. + +### Совместное владение вашим проектом + + + +Люди рады вносить свой вклад в проекты, когда они чувствуют свою причастность. Это не значит, что вам нужно изменить видение своего проекта или принимать нежелательные вклады. Но чем больше вы доверяете другим, тем больше они остаются с вами. + +Посмотрите, сможете ли вы найти способы как можно больше поделиться собственностью со своим сообществом. Вот несколько идей: + +* **Не поддавайтесь исправлению простых (некритических) ошибок.** Вместо этого используйте их как возможности для привлечения новых участников или наставничества тех, кто хотел бы внести свой вклад. Сначала это может показаться неестественным, но со временем ваши вложения окупятся. Например, @michaeljoseph попросил участника отправить пул-реквест по проблеме [Cookiecutter](https://github.com/audreyr/cookiecutter), а не исправлять ее самому. + +![Проблема с Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Запустите файл CONTRIBUTORS или AUTORS в своем проекте**, в котором перечислены все, кто внес свой вклад в ваш проект, как, например, [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Если у вас большое сообщество, **разошлите информационный бюллетень или напишите сообщение в блоге** с благодарностью участникам. [This Week in Rust](https://this-week-in-rust.org/) от Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) от Hoodie — два хороших примера. + +* **Предоставьте каждому участнику доступ к коммитам.** @felixge обнаружил, что это заставило людей [с большим энтузиазмом оттачивать свои патчи](https://felixge.de/2013/03/11/the-pull-request-hack.html), и он даже нашел новых сопровождающих для проектов, над которыми давно не работал. + +* Если ваш проект размещен на GitHub, **переместите его из своей личной учетной записи в [Организацию](https://help.github.com/articles/creating-a-new-organization-account/)** и добавьте хотя бы одного резервного администратора. Организации упрощают работу над проектами с внешними соавторами. + +Реальность такова, что [в большинстве проектов есть](https://peerj.com/preprints/1233/) один или два сопровождающих, которые делают большую часть работы. Чем крупнее ваш проект и чем больше ваше сообщество, тем легче найти помощь. + +Хотя вы не всегда можете найти кого-то, кто ответит на призыв, подача сигнала увеличивает шансы, что другие люди вмешаются. И чем раньше вы начнете, тем скорее люди смогут помочь. + + + +## Разрешение конфликтов + +На ранних стадиях проекта легко принимать важные решения. Когда вы хотите что-то сделать, вы просто делаете это. + +По мере того, как ваш проект становится более популярным, все больше людей будут интересоваться вашими решениями. Даже если у вас нет большого сообщества участников, если у вашего проекта много пользователей, вы найдете людей, которые взвешивают решения или поднимают собственные проблемы. + +По большей части, если вы создали дружелюбное, уважительное сообщество и открыто задокументировали свои процессы, ваше сообщество должно найти решение. Но иногда вы сталкиваетесь с проблемой, которую немного сложнее решить. + +### Установите планку доброты + +Когда ваше сообщество борется с трудной проблемой, может подняться накал страстей. Люди могут рассердиться или расстроиться и обидеться друг на друга или на вас. + +Ваша задача как сопровождающего — не допустить обострения подобных ситуаций. Даже если у вас есть твердое мнение по теме, постарайтесь занять позицию модератора или фасилитатора, вместо того, чтобы вступать в борьбу и продвигать свои взгляды. Если кто-то ведет себя недоброжелательно или монополизирует беседу, [действуйте немедленно](../building-community/#не-терпите-плохих-участников), чтобы обсуждение было вежливым и продуктивным. + + + +Другие люди ждут от вас совета. Подавайте хороший пример. Вы по-прежнему можете выражать разочарование, несчастье или беспокойство, но делайте это спокойно. + +Сохранять хладнокровие непросто, но демонстрация лидерства улучшает здоровье вашего сообщества. Интернет благодарит вас. + +### Относитесь к README как к конституции + +Ваш README — это [больше, чем просто набор инструкций](../starting-a-project/#написание-readme). Это также место, где можно поговорить о ваших целях, видении продукта и планах развития. Если люди слишком сосредоточены на обсуждении достоинств той или иной функции, возможно, будет полезно вернуться к README и поговорить о более высоком видении вашего проекта. Сосредоточение внимания на README также обезличивает разговор, поэтому вы можете вести конструктивное обсуждение. + +### Сосредоточьтесь на путешествии, а не на пункте назначения + +В некоторых проектах для принятия важных решений используется процесс голосования. Хотя на первый взгляд это выглядит разумно, голосование делает упор на поиске «ответа», а не на том, чтобы выслушивать и решать проблемы друг друга. + +Голосование может стать политическим, когда участники сообщества чувствуют давление, оказывая друг другу услуги или проголосовав определенным образом. Не все голосуют, будь то [молчаливое большинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) в вашем сообществе или пользователи, которые не знали, что проходит голосование. + +Иногда голосование является необходимым условием разрешения конфликтов. Однако, насколько вы можете, сделайте упор на [«поиске консенсуса»](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсусе. + +В процессе поиска консенсуса члены сообщества обсуждают основные проблемы до тех пор, пока не почувствуют, что их должным образом выслушали. Когда остаются лишь незначительные проблемы, сообщество движется вперед. «Поиск консенсуса» признает, что сообщество может не прийти к идеальному ответу. Вместо этого он отдает приоритет слушанию и обсуждению. + + + +Даже если вы на самом деле не применяете процесс поиска консенсуса, как сопровождающий проекта, важно, чтобы люди знали, что вы их слушаете. Заставить других почувствовать себя услышанными и что вы стараетесь разрешить их проблемы в значительной степени помогает избавиться от деликатных ситуаций. Затем подкрепите свои слова действиями. + +Не торопитесь с решением ради разрешения. Убедитесь, что все чувствуют себя услышанными и что вся информация предана гласности, прежде чем переходить к решению. + +### Сосредоточьте разговор на действии + +Обсуждение важно, но есть разница между продуктивным и непродуктивным разговором. + +Поощряйте обсуждение, пока оно активно движется к разрешению. Если ясно, что разговор вялится или уходит не по теме, уколы становятся личными или люди придираются к мелочам, пора его закрыть. + +Продолжение этих разговоров плохо не только для решения рассматриваемой проблемы, но и для здоровья вашего сообщества. Он посылает сообщение о том, что такие разговоры разрешены или даже поощряются, и может оттолкнуть людей поднимать или решать будущие проблемы. + +С каждым замечанием, сделанным вами или другими, спрашивайте себя: _"Как это приближает нас к решению?"_ + +Если разговор начинает распадаться, спросите группу: _«Какие шаги мы должны предпринять дальше?»_, чтобы переориентировать разговор. + +Если разговор явно никуда не придёт, нет четких действий, которые нужно предпринять, или соответствующие действия уже были предприняты, закройте проблему и объясните, почему вы ее закрыли. + + + +### Выбирайте битвы с умом + +Контекст важен. Подумайте, кто участвует в обсуждении и как они представляют остальную часть сообщества. + +Все ли в сообществе расстроены или вовлечены в эту проблему? Или это одинокий нарушитель спокойствия? Не забывайте принимать во внимание молчаливых членов вашего сообщества, а не только активные голоса. + +Если проблема не отражает более широкие потребности вашего сообщества, возможно, вам просто нужно признать озабоченность нескольких человек. Если это повторяющаяся проблема без четкого решения, укажите на предыдущие обсуждения по этой теме и закройте ветку. + +### Определите, кто разрешает конфликты в сообществе + +При хорошем отношении и четком общении самые сложные ситуации разрешимы. Однако даже в продуктивной беседе могут просто быть разные мнения о том, как действовать дальше. В этих случаях определите человека или группу людей, которые могут решить проблему. + +Решающим фактором может быть основной сопровождающий проекта или небольшая группа людей, которые принимают решение на основе голосования. В идеале вы определили средство разрешения конфликтов и связанный с ним процесс в файле GOVERNANCE, прежде чем вам когда-либо придется его использовать. + +Тай-брейк должен быть последним средством. Спорные вопросы - это возможность для вашего сообщества расти и учиться. Воспользуйтесь этими возможностями и используйте совместный процесс, чтобы найти решение везде, где это возможно. + +## Сообщество — это ❤️ открытого исходного кода + +Здоровые и процветающие сообщества каждую неделю тратят тысячи часов на разработку программного обеспечения с открытым исходным кодом. Многие участники указывают на других людей как на причину работы - или не работы - над открытым исходным кодом. Узнав, как использовать эту силу конструктивно, вы поможете кому-то получить незабываемый опыт работы с открытым исходным кодом. diff --git a/_articles/ru/code-of-conduct.md b/_articles/ru/code-of-conduct.md new file mode 100644 index 00000000000..bbd32c5f52c --- /dev/null +++ b/_articles/ru/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: ru +title: Ваш кодекс поведения +description: Содействуйте здоровому и конструктивному поведению в сообществе, приняв и обеспечив соблюдение кодекса поведения. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Зачем мне нужен кодекс поведения? + +Кодекс поведения - это документ, который устанавливает ожидания в отношении поведения участников вашего проекта. Принятие и соблюдение кодекса поведения может помочь создать позитивную социальную атмосферу в вашем сообществе. + +Кодексы поведения помогают защитить не только участников, но и вас самих. Если вы поддерживаете проект, вы можете обнаружить, что непродуктивное отношение других участников со временем может привести вас к истощению или недовольству своей работой. + +Кодекс поведения дает вам возможность способствовать здоровому и конструктивному поведению в обществе. Проактивность снижает вероятность того, что вы или другие люди устанете от своего проекта, и помогает вам действовать, когда кто-то делает что-то, с чем вы не согласны. + +## Установление кодекса поведения + +Постарайтесь установить кодекс поведения как можно раньше: в идеале, когда вы впервые создаете свой проект. + +Кодекс поведения описывает не только ваши ожидания, но и следующее: + +* Где вступает в силу кодекс поведения _(только в отношении issues и pull requests, или действий сообщества, таких как мероприятия?)_ +* К кому применяется кодекс поведения _(члены сообщества и сопровождающие (maintainers), а как насчет спонсоров?)_ +* Что произойдет, если кто-то нарушит кодекс поведения +* Как можно сообщить о нарушениях + +Везде, где можно, используйте прошлые достижения. [Соглашение авторов](https://contributor-covenant.org/) - это готовый кодекс поведения, используется более чем 40 000 проектов с открытым исходным кодом, включая Kubernetes, Rails и Swift. + +[Кодекс поведения Django](https://www.djangoproject.com/conduct/) и [Кодекс поведения гражданина](http://citizencodeofconduct.org/) также являются двумя хорошими примерами кодекса поведения. + +Поместите файл CODE_OF_CONDUCT в корневой каталог вашего проекта и сделайте его видимым для вашего сообщества, связав его из файла CONTRIBUTING или README. + +## Решите, как вы будете обеспечивать соблюдение своего кодекса поведения + + + +Вы должны объяснить, как будет применяться ваш кодекс поведения, **_прежде чем_** произойдет нарушение. Для этого есть несколько причин: + +* Это демонстрирует, что вы серьезно относитесь к действиям, когда это необходимо. + +* Ваше сообщество будет более уверено, что жалобы действительно будут рассмотрены. + +* Вы убедите свое сообщество, что процесс проверки является справедливым и прозрачным, если они когда-либо обнаружат, что их расследуют на предмет нарушения. + +Вы должны предоставить людям возможность в частном порядке (например, на адрес электронной почты) сообщить о нарушении кодекса поведения и объяснить, кто получает это сообщение. Это может быть сопровождающий, группа сопровождающих или рабочая группа по кодексу поведения. + +Не забывайте, что кто-то может захотеть сообщить о нарушении в отношении человека, получившего эти сообщения. В этом случае дайте им возможность сообщить о нарушениях кому-то другому. Например, @ctb и @ mr-c [объясняют свой проект](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> О случаях оскорбления, домогательства или иного неприемлемого поведения можно сообщать по электронной почте **khmer-project@idyll.org**, которая отправляется только К. Титусу Брауну и Майклу Р. Крузо. Чтобы сообщить о проблеме, связанной с любым из них, отправьте электронное письмо **Джуди Браун Кларк, доктору философии**, директору по разнообразию Центра изучения эволюции в действии BEACON, Центра науки и технологий NSF.\* + +Для вдохновения ознакомьтесь с [руководством по применению](https://www.djangoproject.com/conduct/enforcement-manual/) Django (хотя в зависимости от размера вашего проекта вам может не понадобиться что-то настолько всеобъемлющее). + +## Обеспечение соблюдения вашего кодекса поведения + +Иногда, несмотря на все ваши усилия, кто-то будет делать что-то, нарушающее этот код. Есть несколько способов справиться с негативным или вредным поведением, когда оно возникает. + +### Соберите информацию о ситуации + +Относитесь к голосу каждого члена сообщества так же важно, как и к своему собственному. Если вы получили сообщение о том, что кто-то нарушил кодекс поведения, отнеситесь к этому серьезно и расследуйте этот вопрос, даже если он не соответствует вашему собственному опыту общения с этим человеком. Это сигнализирует вашему сообществу, что вы цените их точку зрения и доверяете их мнению. + +Рассматриваемый член сообщества может быть рецидивистом, который постоянно заставляет других чувствовать себя некомфортно, или он мог сказать или сделать что-то только один раз. И то, и другое может быть основанием для принятия мер, в зависимости от контекста. + +Прежде чем ответить, дайте себе время понять, что произошло. Прочтите прошлые комментарии и разговоры этого человека, чтобы лучше понять, кто он и почему он мог поступить таким образом. Постарайтесь собрать другие точки зрения об этом человеке и его поведении. + + + +### Примите соответствующие меры + +После сбора и обработки достаточного количества информации вам нужно будет решить, что делать. Обдумывая свои следующие шаги, помните, что ваша цель как модератора - создать безопасную, уважительную среду для совместной работы. Подумайте не только о том, как поступить в рассматриваемой ситуации, но и о том, как ваш ответ повлияет на поведение и ожидания остальной части вашего сообщества в будущем. + +Когда кто-то сообщает о нарушении кодекса поведения, это ваша, а не их работа - разбираться с этим. Иногда репортер раскрывает информацию с большим риском для своей карьеры, репутации или физической безопасности. Принуждение их к противостоянию преследователям может поставить репортера в компромиссное положение. Вам следует вести прямое общение с этим человеком, если репортер явно не потребует иного. + +Есть несколько способов отреагировать на нарушение кодекса поведения: + +* **Сделайте этому человеку публичное предупреждение** и объясните, как его поведение негативно повлияло на других, желательно в том канале, где оно произошло. По возможности, публичная коммуникация сообщает остальной части сообщества о том, что вы серьезно относитесь к кодексу поведения. Будьте добры, но тверды в общении. + +* **Наедине поговорите с человеком**, о котором идет речь, и объясните, как его поведение негативно повлияло на других. Вы можете использовать частный канал связи, если ситуация связана с конфиденциальной личной информацией. Если вы общаетесь с кем-то в частном порядке, рекомендуется отправить копию ваших сообщений тем, кто первым сообщил о ситуации, чтобы они знали, что вы приняли меры. Прежде чем отправлять им копию, попросите согласие того, с кем вы переписывались. + +Иногда решение не может быть достигнуто. Человек, о котором идет речь, может стать агрессивным или враждебным при столкновении или не изменит своего поведения. В этой ситуации вы можете подумать о более решительных действиях. Например: + +* **Отстранить лицо** от участия в проекте с помощью временного запрета на участие в любом аспекте проекта. + +* **Забанить навсегда** человека из проекта + +К запрету членов нельзя относиться легкомысленно, поскольку это представляет собой постоянное и непримиримое различие точек зрения. Вы должны принимать эти меры только тогда, когда ясно, что решение не может быть достигнуто. + +## Ваши обязанности как сопровождающего + +Кодекс поведения - это не закон, который применяется произвольно. Вы являетесь исполнителем кодекса поведения и обязаны соблюдать правила, установленные кодексом поведения. + +Как сопровождающий, вы устанавливаете правила для своего сообщества и обеспечиваете их соблюдение в соответствии с правилами, изложенными в вашем кодексе поведения. Это означает серьезное отношение к любому сообщению о нарушении кодекса поведения. Репортер должен тщательно и беспристрастно перепроверить свою жалобу. Если вы решите, что поведение, о котором они сообщили, не является нарушением, четко сообщите им об этом и объясните, почему вы не собираетесь принимать меры по этому поводу. Что они будут с этим делать, зависит от них: терпеть поведение, с которым у них возникла проблема, или прекращать участие в жизни сообщества. + +Сообщение о поведении, которое _технически_ не нарушает кодекс поведения, может указывать на наличие проблемы в вашем сообществе, и вам следует изучить эту потенциальную проблему и действовать соответствующим образом. Это может включать пересмотр вашего кодекса поведения, чтобы прояснить приемлемое поведение и/или поговорить с человеком, о поведении которого было сообщено, и сообщить ему, что, хотя он и не нарушал кодекс поведения, он выходит за рамки и создаёт дискомфорт другим участникам. + +В конце концов, как сопровождающий, вы устанавливаете и обеспечиваете соблюдение стандартов приемлемого поведения. У вас есть возможность формировать общественные ценности проекта, и участники ожидают, что вы будете придерживаться этих ценностей справедливо и беспристрастно. + +## Поощряйте поведение, которое вы хотите видеть в мире 🌎 + +Когда проект кажется враждебным или нежелательным, даже если это всего лишь один человек, поведение которого терпят другие, вы рискуете потерять гораздо больше участников, с некоторыми из которых вы, возможно, даже никогда не встретитесь. Не всегда легко принять или обеспечить соблюдение кодекса поведения, но создание благоприятной атмосферы поможет вашему сообществу расти. diff --git a/_articles/ru/finding-users.md b/_articles/ru/finding-users.md new file mode 100644 index 00000000000..f28f88e542c --- /dev/null +++ b/_articles/ru/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: ru +title: Поиск пользователей для вашего проекта +description: Помогите своему опенсорс-проекту расти, передав его в руки счастливых пользователей. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Распространение информации + +Нет правила, согласно которому вы должны продвигать опенсорс-проект при запуске. Есть много веских причин для работы с опенсорсом, которые не имеют ничего общего с популярностью. Вместо того, чтобы надеяться, что люди найдут и воспользуются вашим опенсорсом-проектом, вы следует самому рассказать о своей тяжелой работе! + +## Разберитесь в своем послании + +Прежде чем приступить к работе по продвижению своего проекта, вам нужно уметь объяснить, для чего он нужен и почему так важен. + +Что делает ваш проект особенным или интересным? Почему его создали? Ответив на эти вопросы для себя, вы сможете донести важность вашего проекта до остальных. + +Помните, что люди сначала приходят в ваш проекте в качестве пользователей, а затем становятся его контрибьюторами, если проект решает их проблему. Размышляя о послании и ценности вашего проекта, попробуйте взглянуть на них через призму того, что могут захотеть _пользователи и контрибьюторы_. + +Например, @robb приводит примеры кода, чтобы четко объяснить, почему его проект [Cartography](https://github.com/robb/Cartography) полезен: + +![README-файл Cartography](/assets/images/finding-users/cartography.jpg) + +Чтобы глубже погрузиться в послание, ознакомьтесь с упражнением Mozilla [«Personas and Pathways»](https://mozillascience.github.io/working-open-workshop/personas_pathways/) по развитию образов пользователей. + +## Помогите людям найти ваш проект и следить за ним + + + +Людям будет проще найти и запомнить ваш проект, если вы будете направлять их в одно русло. + +**Создайте ясные каналы связи для рекламы своей работы.** Аккаунт в Twitter, ссылка на GitHub или канал IRC — это простой способ направить людей на ваш проект. Эти площадки также дают возможность собраться растущему сообществу проекта. + +Если вы еще не хотите создавать каналы для своего проекта, продвигайте свой собственный Twitter или GitHub во всех своих начинаниях. Продвижение аккаунта в Twitter или GitHub позволит людям узнать, как с вами связаться или следить за вашей работой. Если вы выступаете на митапе или конференции, расскажите о себе или включите контактную информацию в слайдах. + + + +**Подумайте о создании сайта для вашего проекта.** Сайт делает ваш проект более дружелюбным и легким для поиска, особенно если он дополнен понятной документацией и обучающими руководствами. Наличие сайта также указывает на активность вашего проекта, заставляя пользователей чувствовать себя более увереннее при его использовании. Добавьте примеры, которые помогут пользователям понять, как использовать ваш проект. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), соавтор Django, сказал, что сайт был _"безусловно самым правильным решением в первые дни Django"_. + +Если ваш проект размещён на GitHub, вы можете использовать [GitHub Pages](https://pages.github.com/) при создании сайта. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) — только [несколько примеров](https://github.com/showcases/github-pages-examples) отличных, полноценных сайтов. + +![Главная страница Vagrant](/assets/images/finding-users/vagrant_homepage.png) + +Теперь, когда вы знаете, что рассказать о своём проекте, и вы создали канал для связи, самое время выйти и поговорить с вашими пользователями! + +## Ищите пользователей для вашего проекта (онлайн) + +Через интернет можно быстро поделиться и распространить информацию. Используя онлайн-каналы, можно выйти на очень широкую аудиторию. + +Воспользуйтесь преимуществами существующих онлайн-сообществ и платформ, чтобы охватить свою аудиторию. Если ваш опенсорс-проект представляет собой программу, вы, вероятно, сможете найти заинтересованных пользователей на [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Найдите каналы, где, по вашему мнению, люди получат наибольшую пользу от вашей работы или будут в восторге от неё. + + + +Попробуйте рассказать о своём проекте следующими способами: + +* **Познакомьтесь с соответствующими опенсорс-проектами и сообществами.** Необязательно всегда напрямую продвигать свой проект. Если проект идеально подходит для специалистов по обработке данных, использующих Python, познакомьтесь с сообществом специалистов по науке о данных на Python. Когда люди будут знакомиться с вами, вы слово за слово можете рассказать о своей работе. +* **Найдите людей, сталкивающихся с проблемой, которую решает ваш проект.** Поищите на соответствующих форумах людей, которые попадают в целевую аудиторию вашего проекта. Отвечайте на их вопросы и найдите тактичный способ (когда это уместно) предложить свой проект в качестве решения. +* **Попросите обратную связь.** Представьте себя и свою работу пользователям, которые сочтет её актуальной и интересной. Чётко обозначьте, кому, по вашему мнению, принесет пользу ваш проект. Попытайтесь закончить предложение: _"Я думаю, что мой проект действительно поможет X, который пытается сделать Y_". Слушайте и отвечайте на отзывы других, а не просто рекламируйте свою работу. + +Вообще говоря, сосредоточьтесь на помощи другим, прежде чем просить что-то взамен. Поскольку каждый может легко продвигать проект в интернете, то ваше детище может потеряться в информационном шуме. Чтобы выделиться из толпы, дайте людям понять, кто вы есть, а не только то, чего вы хотите. + +Если никто не обращает внимания или не отвечает на вашу первоначальную просьбу, не расстраивайтесь! Запуск большинства проектов — это итеративный процесс, который может занять месяцы или даже годы. Если не удалось добиться ответа с первого раза, попробуйте другую тактику или сначала найдите способы помочь повысить эффективность другим. Продвижение и запуск проекта требует времени и преданности делу. + +## Ищите пользователей для вашего проекта (офлайн) + +![Публичное выступление](/assets/images/finding-users/public_speaking.jpg) + +Офлайн-мероприятия — популярный способ продвижения новых проектов перед публикой. Это отличная возможность привлечь заинтересованных людей и наладить более глубокие человеческие отношения, особенно если вы заинтересованы в привлечении разработчиков. + +Если вы [новичок в публичных выступлениях](https://speaking.io/), начните с поиска местного митапа, связанного с языком или экосистемой вашего проекта. + + + +Если вы никогда раньше не выступали перед публикой, вы можете нервничать, — это совершенно нормально! Помните, что люди собрались, потому что они искренне хотят послушать о вашей работе. + +Когда вы пишете доклад, сосредоточьтесь на том, что будет интересно и полезно слушателям. Сохраняйте дружелюбный тон и говорите доступным языком. Улыбайтесь, дышите и получайте удовольствие. + + + +Когда вы будете готовы, подумайте о выступлении на конференции, чтобы прорекламировать собственный проект. Через конференции можно донести свою мысль до большого количества людей, иногда со всего мира. + +Ищите конференции, посвященные вашему языку или экосистеме. Перед подачей заявки на доклад, изучите конференцию, чтобы адаптировать доклад для участников и повысить свои шансы к выступлению на конференции. Часто составить представление о своей аудитории можно по докладчикам конференции. + + + +## Заработайте репутацию + +В дополнение к стратегиям, описанным выше, лучший способ побудить людей делиться вашим проектом и вносить в него вклад — это делиться их проектами и вносить в них свой вклад. + +Помощь новичкам, обмен ресурсами и содержательный вклад в проекты других людей помогут вам заработать положительную репутацию. Активное участие в опенсорс-сообществе поможет людям понять суть вашей работы и с большей вероятностью обратить внимание на ваш проект и поделится им. Развитие отношений с другими опенсорс-проектами может даже привести к официальному партнерству. + + + +Никогда не рано и не поздно начать укреплять свою репутацию. Даже если вы уже запустили собственный проект, стремитесь разными способами помогать другим. + +Невозможно в одночасье нарастить аудиторию. Чтобы заслужить доверие и уважение окружающих нужно время, а созданию репутации нет конца и края. + +## Не останавливайтесь на достигнутом! + +Может пройти много времени, прежде чем люди заметят ваш опенсорс-проект. Это нормально! Некоторым из самых популярных сегодня проектов потребовались годы, чтобы достичь высокого уровня активности. Сосредоточьтесь на выстраивании отношений, а не на надежде, что ваш проект внезапно станет популярным. Будьте терпеливы и продолжайте делиться своей работой с теми, кто её ценит. diff --git a/_articles/ru/getting-paid.md b/_articles/ru/getting-paid.md new file mode 100644 index 00000000000..24d12aedf6b --- /dev/null +++ b/_articles/ru/getting-paid.md @@ -0,0 +1,177 @@ +--- +lang: ru +title: Получение денег за работу над открытым кодом +description: Подкрепите свою работу над открытым кодом, получая финансовую поддержку за ваше время и ваш проект +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Почему некоторые люди ищут финансовую поддержку + +Большая часть работы с открытым кодом осуществляется добровольцами. Например, кто-то может столкнуться с ошибкой в используемом им проекте и отправить исправление. А кому-то нравится заниматься проектом в свободное время. + + + +Есть много причин, по которым человек не хотел бы получать деньги за свою работу с открытым исходным кодом. + +* **Возможно, у них уже есть любимая работа на полный рабочий день,** которая позволяет им вносить свой вклад в разработку открытого исходного кода в свободное время. +* **Им нравится думать об открытом исходном коде как об увлечении** или творческом пути, и они не хотят чувствовать себя финансово обязанными работая над своими проектами. +* **Они получают другие преимущества от участия в разработке открытого исходного кода**, такие как создание своей репутации или портфолио, обучение новым навыкам или чувство близости к сообществу. + + + +Для других, особенно когда сообщество активно пишет код и требуется тратить много времени, получение оплаты за участие в проекте с открытым кодом - единственный способ участвовать, либо потому, что этого требует проект, либо по личным причинам. + +Поддержка популярных проектов может стать серьезной обязанностью, занимающей 10 или 20 часов в неделю вместо нескольких часов в месяц. + + + +Оплачиваемая работа также позволяет людям из разных слоев общества вносить значимый вклад. Некоторые люди не могут позволить себе тратить неоплачиваемое время на проекты с открытым исходным кодом из-за своего текущего финансового положения, долга, семейных или других обязанностей по уходу. Это означает, что мир никогда не увидит вклада талантливых людей, которые не могут позволить себе добровольно тратить свое время. Это имеет этические последствия, как @ashedryden [описал](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), поскольку выполняемая работа смещена в пользу тех, кто уже имеет преимущества в жизни, которые затем получают дополнительные преимущества на основе их добровольного вклада, в то время как другие, которые не могут быть волонтерами, не получают более поздних возможностей, что усиливает текущий недостаток разнообразия в сообществе открытого исходного кода. + + + +Если вам нужна финансовая поддержка, можно рассмотреть два пути. Вы можете финансировать свое собственное время в качестве участника или можете найти организационное финансирование для проекта. + +## Финансирование собственного времени + +Сегодня многим людям платят за работу над открытым кодом неполный или полный рабочий день. Самый распространенный способ получить деньги за свое время - поговорить со своим работодателем. + +Если ваш работодатель действительно использует проект, будет проще обосновать необходимость работы над открытым кодом, но подойдите к делу творчески. Возможно, ваш работодатель не использует этот проект, но он использует питон, а поддержка популярного проекта питон помогает привлечь новых разработчиков питон. Может быть, это в целом делает вашего работодателя более дружелюбным к разработчикам. + +Если у вас нет существующего проекта с открытым кодом, над которым вы хотели бы работать, но вы предпочитаете, чтобы ваши текущие результаты работы были с открытым кодом, попросите вашего работодателя открыть код некоторых внутренних программ. + +Многие компании разрабатывают программы с открытым кодом, чтобы создать свой бренд и нанять квалифицированных специалистов. + +@hueniverse, например, обнаружил финансовые причины [инвестиций Walmart в открытый код](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). А @jamesgpearce обнаружил, что инициативы открытого кода Facebook [изменили](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) кадровую политику: + +> Это тесно связано с нашей хакерской культурой и тем, как воспринималась наша организация. Мы спросили наших сотрудников: «Вы знали о программе с открытым исходным кодом Facebook?». Две трети ответили «Да». Половина сказала, что программа положительно повлияла на их решение работать на нас. Это не маргинальные цифры, и я надеюсь, что тенденция сохранится. + +Если ваша компания идет по этому пути, важно сохранять четкие границы между общественной и корпоративной деятельностью. В конечном итоге открытый код поддерживает себя за счет вклада людей со всего мира, и это больше, чем любая другая компания или место. + + + +Если не получается убедить работодателя в важности работы над открытым кодом, можете подумать о поиске нового работодателя, который будет поощрять вклад сотрудников в разработку открытого кода. Ищите компании, которые открыто заявляют о своей приверженности работе с открытым кодом. Например: + +* Некоторые компании как [Netflix](https://netflix.github.io/) или [PayPal](https://paypal.github.io/), имеют веб-сайты, которые подчеркивают их участие в открытых проектах +* [Zalando](https://opensource.zalando.com) опубликовали свою [политику участия в открытых проектах](https://opensource.zalando.com/docs/using/contributing/) для работников. + +Проекты, инициированные крупной компанией вроде [Go](https://github.com/golang) или [React](https://github.com/facebook/react), также, вероятно, будут нанимать людей для работы с открытым кодом. + +В зависимости от ваших личных обстоятельств вы можете попытаться собрать деньги самостоятельно для финансирования своей работы с открытым исходным кодом. Например: + +* @gaearon нашёл финансирование для [Redux](https://github.com/reactjs/redux) через [кампанию краудфайндинга на Patreon](https://redux.js.org/) +* @andrewgodwin нашёл финансирование миграции схемы Django [через кампанию на Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django). + +Иногда открытые проекты размещают вознаграждение за задачи, над которыми вы могли бы поработать. + +* @ConnorChristie получал оплату, [помогая](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol над иж JavaScript библиотекой через [gitcoin.co](https://gitcoin.co/). +* @mamiM сделал перевод на японский @MetaMask за вознаграждение на [Bounties Network](https://explorer.bounties.network/bounty/134). + +## Поиск финансирования для вашего проекта + +Помимо договоренностей с отдельными разработчиками, иногда проекты собирают деньги от компаний и частных лиц для финансирования текущей работы. + +Организационное финансирование может быть направлено на оплату текущим разработчикам, покрытие расходов на ведение проекта (например, плату за хостинг) или инвестирование в новые функции или идеи. + +Поскольку популярность открытого исходного кода растет, поиск финансирования для проектов все еще является экспериментальным, но есть несколько общих доступных вариантов. + +### Краудфайндинг и спонсоры + +Поиск спонсоров хорошо работает, если к вам есть сильный интерес, или у вас есть репутация, или ваш проект очень популярен. +Вот несколько примеров спонсируемых проектов: + +* **[webpack](https://github.com/webpack)** привлекает деньги от компаний и частных лиц [through OpenCollective](https://opencollective.com/webpack) +* **[вместе с Ruby](https://rubytogether.org/),** - некоммерческая организация, которая платит за работу над [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), и над другими проектами инфраструктуры Ruby + +### Создайте поток доходов + +В зависимости от вашего проекта вы можете взимать плату за коммерческую поддержку, варианты размещения или дополнительные функции. Вот несколько примеров: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** предлагает платные версии за дополнительную плату +* **[Travis CI](https://github.com/travis-ci)** предлагает платные версии своего продукта +* **[Ghost](https://github.com/TryGhost/Ghost)** - это некоммерческая организация с платными услугами + +Некоторые популярные проекты как [npm](https://github.com/npm/npm) и [Docker](https://github.com/docker/docker), даже привлекают венчурные инвестиции для поддержания роста своих проектов. + +### Подайте заявку на грант + +Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** получил [грант поддержки открытого кода Mozilla](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** был профинансирован [приютом открытого кода от Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** получил грант от [Sloan Foundation](https://sloan.org/programs/digital-technology) +* **[Python Software Foundation](https://www.python.org/psf/grants/)** предлагает гранты на работу, связанную с питоном + +Более подробные варианты и тематические исследования вы можете прочитать в [руководстве](https://github.com/nayafia/lemonade-stand) по получению оплаты за работу с открытым кодом от @nayafia. Для разных типов финансирования требуются разные навыки, поэтому определите свои сильные стороны, чтобы выяснить, какой вариант лучше всего подходит для вас. + +## Создание аргументов в пользу финансовой поддержки + +Независимо от того, является ли ваш проект новой идеей или уже существует много лет, вы должны серьезно подумать, чтобы определить своего целевого спонсора и представить убедительные доводы. + +Независимо от того, хотите ли вы оплачивать свое собственное время или собрать средства для проекта, вы должны ответить на следующие вопросы. + +### Влияние + +Чем полезен этот проект? Почему вашим пользователям или потенциальным пользователям он так нравится? Где он будет через пять лет? + +### Притягательность для людей + +Постарайтесь собрать доказательства того, что ваш проект значимый, будь то показатели, анекдоты или отзывы. Есть ли какие-нибудь компании или известные люди, использующие ваш проект прямо сейчас? Если нет, то одобрил ли это известный человек? + +### Ценность для спонсора + +К спонсорам, будь то ваш работодатель или грантодательский фонд, часто обращаются с предложениями. Почему они должны поддерживать именно ваш проект? Какую выгоду они получат лично? + +### Использование денежных средств + +Чего именно вы добьетесь с предложенным финансированием? Сосредоточьтесь на вехах или результатах проекта, а не на зарплате. + +### Как вы получите средства + +Есть ли у спонсора какие-либо требования относительно выплаты грантов? Например, вам может потребоваться быть некоммерческой организацией или иметь некоммерческого финансового спонсора. Или, возможно, средства должны быть переданы индивидуальному подрядчику, а не организации. Эти требования различаются в зависимости от спонсора, поэтому не забудьте заранее изучить вопрос. + + + +## Экспериментируйте и не сдавайтесь + +Собирать деньги непросто, будь то проект с открытым кодом, некоммерческая организация или стартап программного обеспечения, и в большинстве случаев от вас требуется проявить творческий подход. Определив, как вы хотите получать деньги, проведя исследования и поставив себя на место спонсора, вы сможете убедительно обосновать необходимость финансирования. diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md new file mode 100644 index 00000000000..f06ea729330 --- /dev/null +++ b/_articles/ru/how-to-contribute.md @@ -0,0 +1,519 @@ +--- +lang: ru +title: Как участвовать в опенсорс-проектах +description: Хотите внести свой вклад в опенсорс? Руководство по участию для новичков и не только. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Зачем участвовать в опенсорс-проектах? + + + +Участие в опенсорс-проектах может быть полезным способом изучать, обучать и приобретать опыт практически в любом навыке, который вы можете себе представить. + +Зачем люди участвуют в опенсорсе? На то есть множество причин! + +### Улучшить используемые проекты + +Многие опенсорс-контрибьюторы перед тем, как внести свой вклад в продукт, были обычными его пользователями. Если вы обнаружите баг в используемой вами опенсорс-программе, вы, возможно, захотите заглянуть в её исходный код, чтобы узнать, сможете ли вы исправить его самостоятельно. Если это так, то отправка патча — лучший способ убедиться, что ваши друзья (и вы сами, когда вы обновитесь до следующего релиза) смогут извлечь из него пользу. + +### Улучшить существующие навыки + +Будь то программирование, дизайн пользовательского интерфейса, графический дизайн, написание текста или организационная работа, если вы ищете практику, для вас найдётся задача в проекте с открытым исходным кодом. + +### Познакомиться с людьми с общими интересами + +Опенсорс-проекты с теплыми, гостеприимными сообществами заставляют людей возвращаться долгие годы. Многие люди завязывают дружбу на всю жизнь благодаря участию в открытых проектах, будь то встреча друг с другом на конференциях или поздних ночных онлайн-чатах о буррито. + +### Найти наставников и научить других + +Работа с другими над общим проектом означает, что вам придется объяснять, как вы это делаете, а также просить помощи у других. Акты обучения и преподавания могут быть полезными для всех участников. + +### Создать общедоступные проекты, которые помогут вам повысить репутацию (и карьеру) + +По определению, вся ваша работа с открытым исходным кодом является общедоступной, это значит, что у вас появляются примеры, которые можно использовать где угодно в качестве демонстрации того, что вы можете делать. + +### Изучить навыки работы с людьми + +Опенсорс предлагает возможности практиковать лидерские и управленческие навыки, такие как разрешение конфликтов, организация групп людей и определение приоритетов в работе. + +### Возможность внести изменения, пусть даже небольшие + +Необязательно становиться контрибьютором на протяжении всей жизни, чтобы получать удовольствие от участия в опенсорс-проектах. Вы когда-нибудь видели опечатку на сайте и хотели бы, чтобы кто-нибудь её исправил? В проекте с открытым исходным кодом вы можете это сделать. Опенсорс помогает людям чувствовать себя хозяевами своей жизни и того, как они воспринимают мир, и это само по себе отрадно. + +## Что значит внести свой вклад + +Если вы новичок в опенсорсе, процедура участия в нём может быть пугающей. Как найти подходящий проект? Что делать, если вы не умеете программировать? Что если что-то пойдет не так? + +Не беспокойтесь! Много чем можно заняться в опенсорс-проекте, и вот несколько подсказок, которые помогут вам определиться, чтобы извлечь максимальную пользу. + +### Необязательно помогать кодом + +Распространенное заблуждение, касающееся участия в опенсорсе, состоит в том, что вам нужно писать код. Зачастую есть другие части проекта, которыми [наиболее всего пренебрегают или упускают из виду](https://github.com/blog/2195-the-shape-of-open-source). Вы окажете проекту _огромную_ услугу, предложив поработать над ними! + + + +Даже если вам нравится писать код, другие виды помощи — отличный способ поучаствовать в проекте и познакомиться с другими членами сообщества. Налаживание таких отношений даст вам возможность работать над другими частями проекта. + +### Нравится планировать мероприятия? + +* Организуйте семинары или митапы по проекту, [что и сделал @fzamperin в NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Организуйте конференцию проекта (если она есть) +* Помогите участникам сообщества найти подходящие конференции и подать заявку на доклад + +### Нравится дизайнить? + +* Переделайте макеты, чтобы повысить удобство использования проекта +* Проведите исследование поведения пользователей, чтобы реорганизовать и улучшить навигацию или меню проекта, [например, как предлагает Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Составьте руководство по стилю оформления, чтобы помочь проекту с соблюдением единообразного визуального дизайна +* Создайте принты для футболок или новый логотип, [как это сделали участники hapi.js](https://github.com/hapijs/contrib/issues/68) + +### Нравится писать? + +* Напишите и улучшите документацию по проекту +* Создайте папку с примерами по использованию проекта +* Запустите рассылку новостей по проекту или освещайте самое важное из списка рассылки +* Составьте обучающие руководства по проекту, [как это сделали участники PyPA](https://packaging.python.org/) +* Переведите документацию проекта + + + +### Нравится организовывать? + +* Давайте ссылки на повторяющиеся ишью, предлагайте новые ярлыки для ишью, чтобы они были лучше огранизованы +* Пройдитесь по открытым ишью и предложите закрыть старые, как, [например, сделал @nzakas в ESLint](https://github.com/eslint/eslint/issues/6765) +* Задавайте уточняющие вопросы по недавно открывшимся ишью, чтобы продвинуть обсуждение вперед + +### Нравится кодить? + +* Найдите открытую проблему для решения, что, [например, @dianjin сделал в Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Спросите, можете ли вы помочь с разработкой новой функциональности +* Автоматизируйте настройку проекта +* Улучшите инструменты и тестирование + +### Нравится помогать людям? + +* Ответьте на вопросы о проекте, например, на Stack Overflow ([как в этом примере с Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) или Reddit +* Отвечайте на вопросы людей по открытым ишью +* Помогите модерировать доски обсуждений или каналы в чатах + +### Нравится ли вам помогать другим кодить? + +* Проверяйте код других людей +* Напишите учебные руководства по использованию проекта +* Предложите наставничество другому контрибьютору, [как @ereichert сделал для @bronzdoc в Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Можно работать не только над программными проектами! + +Хотя «опенсорс» часто относится к программному обеспечению, вы можете совместно работать практически над чем угодно. Есть книги, рецепты, списки и курсы, которые разрабатываются как опенсорс-проекты. + +Например: + +* @sindresorhus курирует [список "классных" списков](https://github.com/sindresorhus/awesome) +* @h5bp ведет [список потенциальных вопросов на собеседовании](https://github.com/h5bp/Front-end-Developer-Interview-Questions) для кандидатов в разработчики интерфейсов +* @stuartlynn и @nicole-a-tesla сделали [сборник забавных фактов о тупиках](https://github.com/stuartlynn/puffin_facts) + +Даже если вы разработчик программного обеспечения, работа над документацией проекта может помочь вам войти в опенсорс. Зачастую работа над проектами, не связанными с кодом, не так пугает, а процесс совместной работы поможет вам обрести уверенность и опыт. + +## Подготовка к новому проекту + + + +Для чего-то большего, чем исправление опечатки, участие в открытом проекте похоже на поход к группе незнакомцев на вечеринке. Если вы начнете говорить о ламах, когда они были увлечены дискуссией о золотых рыбках, они, вероятно, будут смотреть на вас немного странно. + +Прежде чем вслепую приступить к своим собственным предложениям, начните с изучения обстановки в сообществе. Это увеличивает шансы на то, что ваши идеи будут замечены и услышаны. + +### Анатомия опенсорс-проекта + +Каждое сообщество с открытым исходным кодом отличается. + +Потратить годы на один открытый проект означает, что вы познакомились с одним открытым проектом. Переходите к другому проекту, и вы можете обнаружить, что терминология, нормы и стили общения совершенно другие. + +Тем не менее многие проекты с открытым исходным кодом следуют схожей организационной структуре. Понимание различных ролей сообщества и общего процесса поможет вам быстро сориентироваться в любом новом проекте. + +Типичный проект с открытым исходным кодом состоит из следующих типов людей: + +* **Автор:** Человек или организация, создавшие проект. +* **Владелец:** Лицо, которое имеет административные права на организацию или репозиторий (не всегда те же самые, что и первоначальный автор). +* **Мейнтейнеры:** Контрибьюторы, которые несут ответственность за формирование видения и управление организационными аспектами проекта (они также могут быть авторами или владельцами проекта). +* **Контрибьюторы:** Все, кто внес свой вклад в проект. +* **Участники сообщества:** Люди, использующие проект. Они могут быть активными в беседах или высказывать свое мнение о направлении проекта. + +В более крупных проектах также могут быть подкомитеты или рабочие группы, занимающиеся различными задачами, такими как инструменты, сортировка, модерация сообщества и организация мероприятий. Поищите на сайте проекта или в репозитории "командную" или "организационную" страницу, чтобы найти эту информацию. + +У проекта также есть документация. Эти файлы обычно находятся в корне репозитория. + +* **LICENSE:** По определению, каждый опенсорс-проект должен иметь [соответствующую лицензию](https://choosealicense.com). Если у проекта нет лицензии, его нельзя причислить к опенсорсу. +* **README:** README — это руководство-инструкция, которая приветствует новых членов сообщества в проекте. В этом файле объясняется назначение и применение проекта. +* **CONTRIBUTING:** В то время как README помогают людям _использовать_ проект, документация по участию помогает людям _вносить_ вклад в проект. В нем объясняется, какие виды помощи необходимы и как устроен процесс. Хотя не у каждого проекта есть файл CONTRIBUTING, его наличие свидетельствует о дружелюбном отношении к участникам. +* **CODE_OF_CONDUCT:** Кодекс поведения устанавливает основные правила поведения участников и помогает создать дружелюбную, гостеприимную атмосферу. Хотя не в каждом проекте есть файл CODE_OF_CONDUCT, его наличие свидетельствует о том, что это хороший проект, в который можно внести свой вклад. +* **Другая документация:** Может быть дополнительная документация, например обучающие материалы, пошаговые руководства или политики управления, особенно для более крупных проектов. + +Наконец, в проектах с открытым исходным кодом для организации обсуждения используются следующие инструменты. Чтение архивов даст вам хорошее представление о том, как сообщество думает и работает. + +* **Список ишью (issue tracker):** Место, где происходят обсуждения, связанные с проектом. +* **Пул-реквесты (pull requests):** Место, где рассматриваются запросы на изменение кода. +* **Дискуссионные форумы или списки рассылки:** Некоторые проекты могут использовать эти каналы для разговорных тем (например, _"Как мне ..."_ или _"Что вы думаете о ..."_ вместо отчётов об ошибках и внесения предложений с новыми возможностями). Другие используют ишью для всех дискуссий. +* **Синхронный чат-канал:** Некоторые проекты используют чаты (например, Slack или IRC) для спонтанного общения, совместной работы и быстрого обмена информацией. + +## Поиск проекта, в котором можно поучаствовать + +Теперь, когда вы разобрались, как устроены опенсорс-проекты, пришло время найти проект, в который вы сможете внести свой вклад! + +Если вы никогда раньше не имели дела с опенсорсом, прислушайтесь к совету президента США Джона Ф. Кеннеди, который однажды сказал: _«Не спрашивайте, что ваша страна может сделать для вас, спросите, что вы можете сделать для своей страны»_. + +Участвовать в опенсорсе могут все, независимо от уровня подготовки. Не ломайте сильно голову над тем, каким будет ваш первый вклад в опенсорс. + +Вместо этого подумайте о проектах, которые вы уже используете или собираетесь использовать. Проекты, в которых вы будете активно участвовать, — это те, к которым вы будете возвращаться. + +В этих проектах всякий раз, когда вы ловите себя на мысли, что что-то может быть лучше или иначе, действуйте в соответствии со своим инстинктом. + +Опенсорс — это не закрытый клуб; им занимаются такие же люди, как вы. «Опенсорс» — это всего лишь причудливый термин для обозначения решаемых мировых проблем. + +Можно просмотреть файл README, чтобы найти неработающую ссылку или опечатку. Или вы как новый пользователь заметили, что что-то работает неправильно, либо есть неточность в документации. Вместо игнорирования таких проблем или просьбы к кому-нибудь их исправить, посмотрите, удастся ли вам помочь и тем самым поучаствовать в проекте. В этом как раз и смысл опенсорса! + +> [28% случайных вкладов](https://www.igor.pro.br/publica/papers/saner2016.pdf) в опенсорс представляют собой документацию, например, исправление опечатки, переформатирование или перевод. + +Если вы ищете существующие ишью, которые можно исправить, то в каждом опенсорс-проекте есть страница `/contribute`, где перечислены ишью, специально предназначенные для начинающих. Перейдите на главную страницу репозитория на GitHub и добавьте в конец URL-адреса `/contribute` (например, [https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +Вы также можете использовать один из следующих ресурсов, чтобы открыть для себя новые проекты и внести свой вклад в них: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) + +### Чеклист перед тем, как принять участие + +Когда вы нашли проект, в который хотели бы внести свой вклад, бегло осмотрите проект, чтобы убедиться, что он принимает стороннюю помощь. В противном случае ваш упорный труд может остаться незамеченным. + +Вот удобный чеклист список, чтобы понять, подходит ли проект для новых контрибьюторов. + +**Попадает под определение опенсорса** + +
+ + +
+ +**Проект активно принимает стороннюю помощь** + +Посмотрите на коммиты в основной ветке. Узнать это вы можете на главной странице репозитория на GitHub. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Затем посмотрите на ишью проекта. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Теперь выясните такую информацию про пул-реквесты проекта. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Проект приветливый** + +Дружелюбный и доброжелательный проект свидетельствует о том, что в нём будут с пониманием относиться к новым контрибьюторам. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## Как сделать вклад + +Вы нашли понравившийся проект и уже готовы поучаствовать в нём. Наконец-то! И вот как правильно это сделать. + +### Эффективное общение + +Независимо от того, поучаствуете ли вы только один раз или же попытаетесь присоединиться к сообществу, совместная работа с другими людьми — один из самых важных навыков, который вы приобретете, занимаясь опенсорсом. + + + +Прежде чем открыть ишью, пул-реквест или задать вопрос в чате, запомните эти советы, которые помогут эффективно воплотить ваши идеи в жизнь. + +**Дайте контекст.** Помогите другим быстро освоиться. Если вы столкнулись с ошибкой, объясните, что вы пытаетесь сделать и как ее воспроизвести. Если вы предлагаете новую идею, объясните, почему вы думаете, что она будет полезна для проекта (не только для вас!). + +> 😇 _"Х не происходит, когда я делаю Y"_ +> +> 😢 _"X не работает! Исправьте это."_ + +**Попробуйте сначала разобраться сами.** Не знать чего-то — это нормально, но покажите, что вы пробовали разобраться. Прежде чем обращаться за помощью, обязательно изучите README-файл проекта, документацию, ишью (открытые или закрытые), список рассылки и поищите ответ в Интернете. Люди оценят, если вы продемонстрируете, что попытались что-то узнать. + +> 😇 _"Я не знаю, как реализовать X. Я посмотрел документацию и не нашел никаких упоминаний об этом."_ +> +> 😢 _"Как мне сделать X?"_ + +**Пишите коротко и по делу.** Как и при отправке электронного письма, каждая сторонняя работа, независимо от того, насколько она была простой или полезной, требует чьей-то проверки. Во многих проектах входящих запросов больше, чем людей, готовых помочь. Будьте лаконичны. Так вы увеличите вероятность того, что кто-то сможет вам помочь. + +> 😇 _"Я хотел бы написать руководство по API."_ +> +> 😢 _"На днях я ехал по шоссе и остановился заправиться, и тогда у меня возникла замечательная идея, чем мы должны заняться, но прежде чем я это объясню, позвольте мне показать вам ..."_ + +**Ведите все обсуждения публично.** Хотя это заманчиво, не обращайтесь к мейнтейнерам напрямую, если вам не нужно делиться конфиденциальной информацией (например, о проблеме безопасности или серьезном нарушении поведения). Если вы сделаете беседу публичной, больше людей смогут узнать о ней и извлечь из неё пользу. Обсуждения сами по себе могут быть вкладом. + +> 😇 _(в качестве комментария) «@-мейнтейнер Привет! Как нам поступить с этим пул-реквестом?»_ +> +> 😢 _(по электронной почте) «Привет, извини, что побеспокоил тебя по электронной почте, но мне было интересно, была ли у тебя возможность просмотреть мой PR»_ + +**Не стесняйтесь задавать вопросы (но будьте терпеливы!).** В какой-то момент каждый был новичком в проекте, и даже опытным контрибьюторам нужно время освоиться, когда они приходят в новый проект. Точно так же мейнтейнеры, давно поддерживающие проект, не всегда знакомы со всеми его частями. Проявите к ним такое же терпение, какое вы бы хотели, чтобы они проявили к вам. + +> 😇 _"Спасибо, что разобрались с этой ошибкой. Я последовал вашим предложениям. Вот результат."_ +> +> 😢 _"Почему вы не можете решить мою проблему? Разве это не ваш проект?"_ + +**Уважайте решения сообщества.** Ваши идеи могут отличаться от приоритетов или видения сообщества. Члены сообщества могут высказать свои мнения или отказаться от реализации вашей идеи. Хотя всегда нужно обсуждать и искать компромисс, последнее слово за мейнтейнерами, потому что им в дальнейшем предстоит работать с вашим кодом. Если вы не согласны с их направлением, вы всегда можете работать над собственным ответвлением проекта (форком) или начать собственный проект. + +> 😇 _"Я разочарован, что вы не можете поддержать мой вариант использования, но, как вы объяснили, он затрагивает только небольшую часть пользователей, я понимаю почему. Спасибо за внимание."_ +> +> 😢 _"Почему вы не поддерживаете мой вариант использования? Это недопустимо!"_ + +**Главное, держите себя в руках.** Опенсорсом занимаются люди со всего мира. Контекст теряется из-за разных языков, культур, регионов и часовых поясов. Кроме того, письменное общение затрудняет передачу тона или настроения. В таких обсуждениях исходите из благих намерений. Нет ничего плохого в том, чтобы вежливо оттолкнуться от идеи, попросить больше информации или дополнительно прояснить свою позицию. Просто постарайтесь сделать интернет лучше, чем когда вы его нашли. + +### Изучение обстановки + +Прежде чем что-либо делать, убедитесь, что это больше нигде не обсуждалось. Пройдитесь по README-файлу проекта, ишью (открытые и закрытые), списку рассылки и Stack Overflow. Не тратьте много времени на это, достаточно поискать по нескольким ключевым словам. + +Если вы не нашли обсуждение вашей идеи, можно начать действовать. Если проект находится на GitHub, вы, скорее всего, будете общаться, открывая ишью или пул-реквест: + +* **Ишью** отлично подходят, чтобы завести беседу или обсуждение +* **Запросы на изменение** предназначены для начала работы над решением. +* **Для легкого общения**, например, уточняющего или практического вопроса, попробуйте задать вопрос в Stack Overflow, IRC, Slack или других чат-каналах, если они есть в проекте + +Прежде чем открывать ишью или пул-реквест, ознакомьтесь с руководством по участию (обычно ему посвящен отдельный файл с именем CONTRIBUTING или соответствующий раздел в файле README), чтобы сделать всё правильно. Например, вас могут попросить представить информацию согласно шаблону или потребовать, чтобы вы написали тесты. + +Если вы планируете сделать большое изменение, перед этим лучше откройте ишью. Полезно некоторое время понаблюдать за проектом (на GitHub [для этого можно кликнуть по кнопке «Watch»](https://help.github.com/articles/watching-repositories/), чтобы получать уведомления обо всех активностях), а также познакомиться с некоторыми участниками сообщества. + + + +### Открытие ишью + +Как правило, следует создать ишью, чтобы: + +* Сообщить об ошибке, которую вы не можете исправить самостоятельно +* Обсудить общую тему или идею (например, связанную с сообществом, развитием или политикой проекта) +* Предложить реализовать новую функциональность или другую идею проекта + +Советы по общению в ишью: + +* **Если видите открытую ишью, которую хотите решить**, прокомментируйте её, чтобы люди знали, что вы занимаетесь ею. Таким образом, снизится вероятность, что кто-то ещё будет работать над ней. +* **Если ишью была открыта давно,** возможно, что она рассматривается в другом месте, либо уже решена, поэтому прокомментируйте её, чтобы подтвердить её актуальность. +* **Если вы открыли ишью, но позже самостоятельно нашли ответ,** прокомментируйте её, чтобы сообщить об этом людям, а затем закройте её. Даже фиксирование такого результата является вкладом в проект. + +### Открытие пул-реквеста + +Как правило, следует создать пул-реквест, чтобы: + +* Сделать незначительное исправление (например, исправить опечатку, неработающую ссылку или очевидную ошибку) +* Начать работать над тем, о чём уже было договорено или что обсуждалось в ишью + +Пул-реквест не обязательно должен представлять законченную работу. Обычно лучше открывать пул-реквест на раннем этапе, чтобы люди могли наблюдать за вашим прогрессом или оставлять отзывы о нем. Только в названии такого пул-реквеста укажите "WIP" (от англ. Work in Progress — в процессе выполнения). Всегда позже можно отправить дополнительные коммиты. + +Если проект находится на GitHub, выполните следующие шаги, чтобы создать пул-реквест: + +* **[Форкните репозиторий](https://guides.github.com/activities/forking/)** и склонируйте его к себе локально. Затем в этом локальном репозитории добавьте оригинальный (upstream) репозиторий. Почаще загружайте изменения из исходного репозитория, чтобы ваш локальный репозиторий оставался в актуальном состоянии, — это снизит вероятность возникновения конфликтов при создании пул-реквеста. (См. более подробные инструкции [здесь](https://help.github.com/articles/syncing-a-fork/).) +* **[Создайте ветку](https://guides.github.com/introduction/flow/)** для ваших правок. +* **Ссылайтесь на любые относящиеся к делу ишью** или подтверждающую документацию в своем PR (например, «Closes #37»). +* **Добавьте скриншоты до и после**, если ваши изменения затрагивают файлы HTML/CSS. Перетащите изображения в текстовую область пул-реквеста. +* **Протестируйте свои изменения!** Например, запустите тесты, если они есть, и при необходимости напишите новые. Даже если тестов нет, проверьте сами, что после ваших изменений всё работает, как и раньше. +* **Соблюдайте стиль написания кода проекта** в меру своих возможностей. Это может быть использование отступов, точек с запятой или комментариев иначе, чем вы привыкли, но мейнтейнерам это упростит слияние вашего пул-реквеста, а другим — облегчит понимание и поддержку в будущем. + +Если это ваш первый пул-реквест, ознакомьтесь с сайтом [Make a Pull Request](http://makeapullrequest.com/), который @kentcdodds сделал в виде пошагового видео-руководства. Вы также можете попрактиковаться в создании пул-реквеста в репозитории [First Contributions](https://github.com/Roshanjossey/first-contributions), созданном @Roshanjossey. + +## Что будет дальше после принятия участия + +Вы сделали это! Поздравляем, вы стали контрибьютором в опенсорс. Надеемся, это будет далеко не первый раз. + +После того, как вы отправите вклад, произойдет одно из следующих событий: + +### 😭 Вы не получите ответ. + +Предполагаем, вы [проверили проект на наличие признаков активности](#чеклист-перед-тем-как-принять-участие) перед тем, как внести свою лепту. Однако даже в активном проекте возможно, что ваш вклад не получит отклика. + +Если вы не получили ответа в течение недели, вполне нормально вежливо ответить в той же теме и попросить кого-нибудь проверить вашу работу. Если вы знаете, кто может посмотреть ваш пул-реквест, упомяните его через @ в этой ветке. + +**Не** обращайтесь напрямую к этому человеку; помните, что публичное общение жизненно важно для опенсорс-проектов. + +Если после вежливого напоминания так никто и не ответил, есть вероятность, что никто и никогда не ответит. Это не самое приятное ощущение, но пусть оно вас не расстраивает. Такое с каждым случалось! Есть множество возможных причин, по которым вам могли не ответить, в том числе личные обстоятельства, на которые вы не можете повлиять. Попробуйте найти другой проект или способ участия. В любом случае, нет смысла тратить время на проект, пока члены его сообщества не проявят должного уровня вовлеченности и отзывчивости. + +### 🚧 У вас могут запросить внести изменения. + +Зачастую вас могут попросить что-то изменить, это может быть связано с самой идеей или её реализацией. + +Когда кто-то запрашивает сделать изменения, относитесь к этому с пониманием и воспринимайте это должным образом. Люди нашли время, чтобы оценить ваш вклад. Открывать PR и бросать его на произвол судьбы — дурной тон. Если вы не знаете, как внести изменения, изучите проблему, а затем обратитесь за помощью, если она вам нужна. + +Если у вас больше нет времени работать над проблемой (например, обсуждение длится уже несколько месяцев, а за это время обстоятельства поменялись), сообщите об этом мейнтейнеру, чтобы он не ожидал ответа. Возможно, кто-то другой с радостью завершит начатую вами работу. + +### 👎 Ваш вклад не принят. + +В итоге ваш вклад будет либо принят, либо нет. Надеюсь, вы потратили не слишком много усилий на него. Если вы не поняли, почему он не был принят, разумно попросить мейнтейнера дать пояснения. В конечном итоге, однако, вам стоит понять и смириться с их решением. Не спорьте и не злитесь по этому поводу. В случае чего вы всегда можете форкнуть репозиторий, чтобы работать над своей собственной версией продукта! + +### 🎉 Ваш вклад принят. + +Ура! Вы успешно сделали вклад в опенсорс! + +## Вы сделали это! + +Независимо от того, сделали ли вы свой первый вклад в опенсорс или ищете новые способы сделать это, мы надеемся, что вы вдохновитесь на действия. Даже если ваш вклад был отклонён, не забудьте сказать спасибо, когда мейнтейнер постарался вам помочь. Опенсорс создается такими же людьми, которые создают ишью, отправляют пул-реквест, оставляют комментарии или приветствуют друг друга одновременно. diff --git a/_articles/ru/index.html b/_articles/ru/index.html new file mode 100644 index 00000000000..095fca6f0ef --- /dev/null +++ b/_articles/ru/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: Руководство по открытому программному обеспечению +lang: ru +permalink: /ru/ +--- diff --git a/_articles/ru/leadership-and-governance.md b/_articles/ru/leadership-and-governance.md new file mode 100644 index 00000000000..c5c59c15f29 --- /dev/null +++ b/_articles/ru/leadership-and-governance.md @@ -0,0 +1,144 @@ +--- +lang: ru +title: Лидерство и управление +description: Растущие проекты с открытым исходным кодом могут выиграть от формализации правил принятия решений. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Понимание механизмов управления вашим растущим проектом + +Ваш проект растет, люди вовлечены в него, и вы полны решимости поддерживать его. На этом этапе вы, возможно, задаетесь вопросом, как включить постоянных участников проекта в свой рабочий процесс, будь то предоставление кому-то доступа к правкам кода (commit) или модерацию дебатов в сообществе. Если у вас есть вопросы, у нас есть ответы. + +## Какие примеры формальных ролей используются в проектах с открытым исходным кодом? + +Многие проекты имеют схожую структуру распределения ролей и признания заслуг участников. + +Однако что на самом деле означают эти роли, зависит только от вас. Вот несколько типов ролей, которые вы можете узнать: + +* **Сопровождающий (maintainer)** +* **Участник (contributor)** +* **Правщик (committer)** + +**Для некоторых проектов "сопровождающие"** - это единственные люди в проекте, имеющие доступ к правкам (commit). В других проектах это просто люди, которые указаны в README как сопровождающие. + +Сопровождающий не обязательно должен быть тем, кто пишет код для вашего проекта. Это может быть человек, который проделал большую работу по пропаганде вашего проекта или написал документацию, которая сделала проект более доступным для других. Независимо от того, чем он занимается ежедневно, сопровождающий - это человек, который чувствует ответственность за направление развития проекта и стремится его улучшить. + +**"Участником" может быть любой**, кто комментирует проблему (issue) или запрос на перенос (pull request), люди, которые добавляют ценность проекту (будь то устранение проблем, написание кода или организация мероприятий), или любой, у кого есть принятый запрос на перенос (возможно, это самое узкое определение участника). + + + +**Термин "правщик"** может быть использован для того, чтобы отличить доступ к правкам, который является особым видом ответственности, от других форм вклада. + +Хотя вы можете определять роли в проекте как угодно, [рассмотрите возможность использования более широких определений](../how-to-contribute/#что-значит-внести-свой-вклад), чтобы воодушевить людей на большее количество разновидностей вклада. Вы можете использовать лидерские роли для официального признания людей, которые внесли выдающийся вклад в ваш проект, независимо от их технических навыков. + + + +## Как формализовать эти лидерские роли? + +Формализация лидерских ролей помогает людям почувствовать свою сопричастность и подсказывает другим членам сообщества, к кому обращаться за помощью. + +В небольших проектах назначение лидеров может быть простым - достаточно добавить их имена в README или текстовый файл CONTRIBUTORS. + +Для более крупного проекта, если у вас есть веб-сайт, создайте страницу команды или перечислите на ней руководителей проекта. Например, у [Postgres](https://github.com/postgres/postgres/) есть [страница полной команды](https://www.postgresql.org/community/contributors/) с краткими профилями для каждого участника. + +Если ваш проект имеет очень активное сообщество участников, вы можете сформировать "ядро" сопровождающих (maintainers) или даже группы людей, которые будут отвечать за различные области проблем (например, безопасность, устранение проблем или поведение сообщества). Позвольте людям самоорганизоваться и стать добровольцами на те роли, которые им больше всего нравятся, а не назначайте их. + + + +Команды руководителей могут захотеть создать специальный канал (например, на IRC) или регулярно встречаться для обсуждения проекта (например, на Gitter или Google Hangout). Вы даже можете сделать эти встречи публичными, чтобы другие люди могли послушать. Например, [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)[проводит офисные часы каждую неделю](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +После того как вы установили руководящие роли, не забудьте задокументировать, как люди могут их получить! Установите четкий процесс того, как кто-то может стать сопровождающим или присоединиться к группе в вашем проекте, и запишите его в файле GOVERNANCE.md. + +Такие инструменты, как [Vossibility](https://github.com/icecrime/vossibility-stack), могут помочь вам публично отслеживать, кто вносит (или не вносит) вклад в проект. Документирование этой информации позволяет избежать восприятия сообществом того, что сопровождающие - это клика, которая принимает решения втайне от всех. + +Наконец, если ваш проект находится на GitHub, подумайте о переносе проекта из личного аккаунта в Организацию и добавлении хотя бы одного резервного администратора. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) облегчают управление разрешениями и несколькими репозиториями и защищают наследие вашего проекта благодаря [общему владению](../building-community/#совместное-владение-вашим-проектом). + +## Когда я должен предоставить кому-то доступ на правки (commit)? + +Некоторые люди считают, что вы должны предоставлять доступ на правки всем, кто вносит свой вклад. Это может способствовать тому, что больше людей будут чувствовать себя причастными к вашему проекту. + +С другой стороны, особенно для больших, более сложных проектов, вы можете захотеть предоставить commit доступ только тем людям, которые продемонстрировали свою приверженность. Не существует единственно правильного способа - делайте то, что вам удобнее всего! + +Если ваш проект находится на GitHub, вы можете использовать [защищенные ветки](https://help.github.com/articles/about-protected-branches/), чтобы управлять тем, кто и при каких обстоятельствах может отправлять правки (push) в определенную ветку. + + + +## Какие существуют структуры управления для проектов с открытым исходным кодом? + +Существуют три общие структуры управления, связанные с проектами с открытым исходным кодом. + +* **BDFL:** (Benevolent dictator for life) - "пожизненный доброжелательный диктатор". При такой структуре один человек (обычно первоначальный автор проекта) имеет право окончательного голоса при принятии всех основных решений по проекту. [Python](https://github.com/python) - классический пример. Небольшие проекты, вероятно, по умолчанию являются BDFL, потому что в них есть только один или два сопровождающих (maintainer). Проект, созданный в компании, также может попасть в категорию BDFL. + +* **Меритократия:** (Примечание: термин "меритократия" несет негативные коннотации для некоторых сообществ и имеет [сложную социальную и политическую историю](http://geekfeminism.wikia.com/wiki/Meritocracy).) При меритократии активным участникам проекта (тем, кто демонстрирует "заслуги") отводится формальная роль в принятии решений. Решения обычно принимаются на основе чистого консенсусного голосования. Концепция меритократии была впервые предложена [Apache Foundation](https://www.apache.org/); [все проекты Apache](https://www.apache.org/index.html#projects-list) являются меритократиями. Вклад может быть сделан только людьми, представляющими самих себя, а не компанию. + +* **Либеральный вклад:** Согласно модели либерального вклада, наиболее влиятельными признаются люди, которые делают больше всего работы, но это основано на текущей работе, а не на историческом вкладе. Основные решения по проекту принимаются на основе процесса поиска консенсуса (обсуждение основных претензий), а не прямого голосования, и стремятся охватить как можно больше точек зрения сообщества. Популярные примеры проектов, использующих либеральную модель вклада, включают [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/). + +Какой из них использовать? Это зависит от вас! У каждой модели есть свои преимущества и компромиссы. И хотя поначалу они могут показаться совершенно разными, все три модели имеют больше общего, чем кажется. Если вы заинтересованы в принятии одной из этих моделей, ознакомьтесь с этими шаблонами: + +* [шаблон модели BDFL](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Шаблон модели меритократии](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Либеральная политика Node.js в отношении вклада участников](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## Нужна ли мне документация по управлению, когда я запускаю свой проект? + +Не существует подходящего времени для написания документации для вашего проекта, но его гораздо легче определить, когда вы увидите динамику развития вашего сообщества. Самое лучшее (и самое трудное) в управлении открытым исходным кодом - это то, что оно формируется сообществом! + +Однако некоторая ранняя документация неизбежно будет способствовать управлению проектом, поэтому начинайте записывать все, что можно. Например, вы можете определить четкие ожидания в отношении поведения или того, как работает ваш процесс привлечения участников, еще на этапе запуска проекта. + +Если вы являетесь частью компании, запускающей проект с открытым исходным кодом, стоит провести внутреннее обсуждение перед запуском о том, как ваша компания собирается поддерживать проект и принимать решения по его дальнейшему развитию. Возможно, вы также захотите публично объяснить все особенности того, как ваша компания будет (или не будет!) участвовать в проекте. + + + +## Что если сотрудники корпорации участвуют в проекте? + +Успешные проекты с открытым исходным кодом используются многими людьми и компаниями, и некоторые компании в конечном итоге могут иметь потоки доходов, связанные с проектом. Например, компания может использовать код проекта в качестве одного из компонентов коммерческого предложения услуг. + +По мере того как проект получает все более широкое распространение, люди, обладающие опытом в этой области, становятся более востребованными - вы можете быть одним из них! - и иногда будут получать деньги за работу, которую они выполняют в проекте. + +Важно относиться к коммерческой деятельности как к норме и как к еще одному источнику энергии для развития. Конечно, платные разработчики не должны получать особое отношение к себе по сравнению с бесплатными; каждый вклад должен оцениваться по его техническим достоинствам. Однако люди должны чувствовать себя комфортно, занимаясь коммерческой деятельностью, и не стесняться приводить свои примеры использования, аргументируя свою позицию в пользу того или иного усовершенствования или функции. + +"Коммерческое" полностью совместимо с "открытым исходным кодом". "Коммерческий" означает лишь то, что где-то вовлечены деньги - что программное обеспечение используется в коммерции, что становится все более вероятным по мере того, как проект получает распространение. (Когда программное обеспечение с открытым исходным кодом используется как часть продукта без открытого исходного кода, общий продукт все равно является "проприетарным" программным обеспечением, хотя, как и открытый исходный код, он может использоваться в коммерческих или некоммерческих целях). + +Как и любой другой человек, коммерчески мотивированные разработчики приобретают влияние в проекте за счет качества и количества своего вклада. Очевидно, что разработчик, которому платят за его время, может сделать больше, чем тот, кому не платят, но это нормально: оплата - это лишь один из многих возможных факторов, которые могут повлиять на то, как много кто-то делает. Обсуждая проект, сосредоточьтесь на вкладе, а не на внешних факторах, которые позволяют людям делать этот вклад. + +## Нужно ли мне юридическое лицо для поддержки моего проекта? + +Вам не нужно юридическое лицо для поддержки вашего проекта с открытым исходным кодом, если только вы не работаете с деньгами. + +Например, если вы хотите создать коммерческий бизнес, вам нужно будет учредить C Corp или LLC (если вы находитесь в США). Если вы просто выполняете контрактную работу, связанную с вашим проектом с открытым исходным кодом, вы можете принимать деньги как индивидуальный предприниматель или учредить LLC (если вы находитесь в США). + +Если вы хотите принимать пожертвования для своего проекта с открытым исходным кодом, вы можете установить кнопку для пожертвований (например, с помощью PayPal или Stripe), но деньги не будут подлежать налогообложению, если вы не являетесь квалифицированной некоммерческой организацией (501c3, если вы находитесь в США). + +Многие проекты не хотят заниматься созданием некоммерческой организации, поэтому вместо этого они находят фискального спонсора некоммерческой организации. Фискальный спонсор принимает пожертвования от вашего имени, обычно в обмен на процент от пожертвования. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) и [Open Collective](https://opencollective.com/opensource) являются примерами организаций, выступающих в качестве фискальных спонсоров проектов с открытым исходным кодом. + + + +Если ваш проект тесно связан с определенным языком или экосистемой, может существовать и соответствующий фонд программного обеспечения, с которым вы можете работать. Например, [Python Software Foundation](https://www.python.org/psf/) помогает поддерживать [PyPI](https://pypi.org/), менеджер пакетов Python, а [Node.js Foundation](https://foundation.nodejs.org/) помогает поддерживать [Express.js](https://expressjs.com/), фреймворк на основе Node. diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md new file mode 100644 index 00000000000..30681090907 --- /dev/null +++ b/_articles/ru/legal.md @@ -0,0 +1,158 @@ +--- +lang: ru +title: Юридические аспекты открытого программного кода +description: Все, что вас когда-либо интересовало о правовой стороне открытого исходного кода, и кое-что, чего вы не знали. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## Понимание юридических последствий открытого исходного кода + +Поделиться своим творчеством со всем миром может быть захватывающим и полезным опытом. Это также может означать множество юридических аспектов, о которых вы даже не подозревали. К счастью, вам не нужно начинать с нуля. Мы позаботились о ваших юридических потребностях. (Прежде чем углубляться, обязательно прочтите наш [отказ от ответственности](/notices/).) + +## Почему людей так волнует правовая сторона открытого кода? + +Рады, что вы спросили! Когда вы выполняете творческую работу (например, текст, графику или код), эта работа по умолчанию находится под исключительным авторским правом. То есть закон предполагает, что как автор своей работы вы имеете право голоса в отношении того, что другие могут с ней делать. + +В общем, это означает, что никто другой не может использовать, копировать, распространять или изменять вашу работу, не подвергаясь риску разбирательства, изъятия или судебного разбирательства. + +Однако открытый исходный код — это необычная ситуация, поскольку автор ожидает, что другие будут использовать, изменять и делиться работой. Но поскольку юридически законным по умолчанию по-прежнему остется исключительное авторское право, вам нужна лицензия, в которой явно указаны эти разрешения. + +Если вы не примените лицензию для открытого исходного кода, каждый, кто вносит свой вклад в ваш проект, также становится эксклюзивным правообладателем своей работы. Это означает, что никто не может использовать, копировать, распространять или изменять их материалы — и этот «никто» включает вас. + +Наконец, ваш проект может иметь зависимости от лицензионных требований, о которых вы не знали. Сообщество вашего проекта или политика вашего работодателя также могут требовать от вашего проекта использования определенных лицензий открытого исходного кода. Мы рассмотрим эти ситуации ниже. + +## Открыты ли общедоступные проекты GitHub? + +Когда вы [создаете новый проект](https://help.github.com/articles/creating-a-new-repository/) на GitHub, у вас есть возможность сделать репозиторий **приватным** (частным) или **публичным** (общедоступным). + +![Создать репозиторий](/assets/images/legal/repo-create-name.png) + +**Сделать ваш проект GitHub публичным — это не то же самое, что лицензировать ваш проект**. На общедоступные проекты распространяются [Условия использования GitHub](https://help.github.com/en/github/site-policy/github-terms-of-service#3-owner-of-content-right-to-post-and-license-grants), которые позволяют другим просматривать и делать ответвление (fork) вашего проекта. Но в остальном ваша работа не имеет разрешений. + +Если вы хотите, чтобы другие могли использовать, распространять, изменять или вносить свой вклад в ваш проект, вам необходимо включить лицензию открытого исходного кода. Например, кто-то не может законно использовать какую-либо часть вашего проекта GitHub в своем коде, даже если он общедоступен, если вы явно не дадите ему на это право. + +## Просто дайте мне ЧтоБыТоНиБыло, что нужно для защиты моего проекта. + +Вам повезло, потому что сегодня лицензии открытого исходного кода стандартизированы и просты в использовании. Вы можете скопировать и вставить существующую лицензию прямо в свой проект. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) — самые популярные лицензии открытого исходного кода, но на выбор есть и другие варианты. Вы можете найти полный текст этих лицензий и инструкции по их использованию на сайте [choosealicense.com](https://choosealicense.com/). + +Когда вы создаете новый проект на GitHub, вас [попросят добавить лицензию](https://help.github.com/articles/open-source-licensing/). + + + +## Какая лицензия открытого исходного кода подходит для моего проекта? + +Если вы начинаете с чистого листа, трудно ошибиться с [лицензией MIT](https://choosealicense.com/licenses/mit/). Она короткая, очень простая для понимания и позволяет любому делать всё, что угодно, если у него есть копия лицензии и упоминание вашего авторского права. Вы сможете выпустить проект под другой лицензией, если понадобится. + +В противном случае выбор правильной лицензии для открытого исходного кода вашего проекта зависит от ваших целей. + +Ваш проект, скорее всего, имеет (или будет иметь) **зависимости**. Например, если вы откроете исходный код проекта Node.js, вы, вероятно, будете использовать библиотеки из Node Package Manager (npm). Каждая из этих библиотек, от которых вы зависите, будет иметь собственную лицензию открытого исходного кода. Если каждая из их лицензий является «разрешающей» (дает общедоступное разрешение на использование, изменение и совместное использование без каких-либо условий для последующего лицензирования), вы можете использовать любую лицензию, которую хотите. Общие разрешительные лицензии включают MIT, Apache 2.0, ISC и BSD. + +С другой стороны, если какая-либо из лицензий ваших зависимостей является «строгим авторским левом» (strong copyleft) (также дает такие же общедоступные разрешения при условии использования той же лицензии в дальнейшем), тогда ваш проект должен будет использовать ту же лицензию. Общие лицензии со строгим авторским левом включают GPLv2, GPLv3 и AGPLv3. + +Вы также можете рассмотреть **сообщества**, которые, как вы надеетесь, будут использовать и вносить свой вклад в ваш проект: + +* **Вы хотите, чтобы ваш проект использовался в качестве зависимости другими проектами?** Вероятно, лучше всего использовать самую популярную лицензию в вашем соответствующем сообществе. Например, [MIT](https://choosealicense.com/licenses/mit/) — самая популярная лицензия для [библиотек npm](https://libraries.io/search?platforms=NPM). +* **Вы хотите, чтобы ваш проект понравился крупным предприятиям?** Крупному бизнесу, скорее всего, потребуется явная патентная лицензия от всех участников. В этом случае [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) поможет вам (и им). +* **Вы хотите, чтобы ваш проект привлек участников, которые не хотят, чтобы их вклад использовался в программном обеспечении с закрытым исходным кодом?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (если они также не хотят участвовать в службах с закрытым исходным кодом) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) подойдет. + +Ваша **компания** может иметь особые лицензионные требования для проектов с открытым исходным кодом. Например, может потребоваться разрешительная лицензия, чтобы компания могла использовать ваш проект в продукте компании с закрытым исходным кодом. Или ваша компания может потребовать строгую лицензию с авторским левом и дополнительное соглашение с участниками (см. ниже), чтобы только ваша компания и никто другой могли использовать ваш проект в программном обеспечении с закрытым исходным кодом. Или у вашей компании могут быть определенные потребности, связанные со стандартами, социальной ответственностью или прозрачностью, любая из которых может потребовать определенной стратегии лицензирования. Поговорите с [юридическим отделом вашей компании](#что-нужно-знать-юридическому-отделу-моей-компании). + +Когда вы создаете новый проект на GitHub, вам предоставляется возможность выбрать лицензию. Включение одной из упомянутых выше лицензий сделает ваш проект на GitHub открытым. Если вы хотите увидеть другие варианты, посетите [choosealicense.com](https://choosealicense.com), чтобы найти подходящую лицензию для своего проекта, даже если это [не программное обеспечение](https://choosealicense.com/non-software/). + +## Что, если я хочу изменить лицензию своего проекта? + +Большинству проектов не потребуется менять лицензии. Но иногда обстоятельства меняются. + +Например, по мере роста вашего проекта он добавляет зависимости или пользователей, или ваша компания меняет стратегии, для любой из которых может потребоваться другая лицензия. Кроме того, если вы пренебрегали лицензированием своего проекта с самого начала, добавление лицензии фактически аналогично изменению лицензий. При добавлении или изменении лицензии на проект необходимо учитывать три основных момента: + +**Это сложно.** Определение совместимости и соответствия лицензий, а также обладателей авторских прав может очень быстро стать сложным и запутанным. Переход на новую, но совместимую лицензию для новых выпусков и дополнений отличается от перелицензирования всех существующих дополнений. Привлекайте свою команду юристов при первом намеке на желание сменить лицензию. Даже если у вас есть или вы можете получить разрешение от правообладателей вашего проекта на изменение лицензии, учитывайте влияние этого изменения на других пользователей и участников вашего проекта. Думайте о смене лицензии как об «управленческом событии» для вашего проекта, которое, скорее всего, пройдет гладко при четком общении и консультациях с заинтересованными сторонами вашего проекта. Еще одна причина выбрать и использовать соответствующую лицензию для вашего проекта с самого начала! + +**Существующая лицензия вашего проекта.** Если существующая лицензия вашего проекта совместима с лицензией, на которую вы хотите перейти, вы можете просто начать использовать новую лицензию. Это потому, что если лицензия A совместима с лицензией B, вы будете соблюдать условия A, соблюдая условия B (но не обязательно наоборот). Поэтому, если вы в настоящее время используете разрешительную лицензию (например, MIT), вы можете перейти на лицензию с дополнительными условиями, при условии, что вы сохраняете копию лицензии MIT и любые связанные уведомления об авторских правах (т.е. продолжаете соблюдать минимальные условия лицензии MIT). Но если ваша текущая лицензия не разрешающая (например, авторское лево или у вас нет лицензии) и вы не являетесь единственным владельцем авторских прав, вы не можете просто изменить лицензию вашего проекта на MIT. По сути, с разрешающей лицензией правообладатели проекта заранее дали разрешение на изменение лицензий. + +**Существующие правообладатели вашего проекта.** Если вы являетесь единственным участником своего проекта, то вы или ваша компания являетесь единственным правообладателем проекта. Вы можете добавить или изменить любую лицензию, которую захотите вы или ваша компания. В противном случае могут быть другие правообладатели, с которыми вам потребуется согласие для изменения лицензий. Кто они? Люди, у которых есть коммиты в вашем проекте, — хорошее место для начала. Но в некоторых случаях авторские права принадлежат работодателям этих людей. В некоторых случаях люди будут вносить только минимальный вклад, но не существует жесткого правила, согласно которому вклады с использованием определенного количества строк кода не подлежат авторскому праву. Что делать? Это зависит. Для относительно небольшого и молодого проекта может оказаться целесообразным убедить всех существующих участников согласиться на изменение лицензии в ишью или пул-реквесте. Для крупных и долгоживущих проектов вам, возможно, придется искать множество участников и даже их наследников. Mozilla потребовались годы (2001-2006), чтобы перелицензировать Firefox, Thunderbird и сопутствующее программное обеспечение. + +В качестве альтернативы вы можете попросить участников заранее согласиться (посредством дополнительного соглашения с участниками - см. Ниже) на определенные изменения лицензии при определенных условиях, помимо тех, которые разрешены вашей существующей лицензией с открытым исходным кодом. Это немного меняет сложность изменения лицензий. Вам заранее понадобится дополнительная помощь юристов, и вы все равно захотите четко общаться с заинтересованными сторонами вашего проекта при изменении лицензии. + +## Требуется ли для моего проекта дополнительное соглашение с участниками? + +Возможно нет. Для подавляющего большинства проектов лицензия для открытого исходного кода неявно служит как входящей (от участников), так и исходящей (для других участников и пользователей) лицензией. Если ваш проект размещен на GitHub, то Условия использования GitHub делают "inbound = outbound" [явным значением по умолчанию](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +Дополнительное соглашение с участником, часто называемое лицензионным соглашением участника (CLA), может создавать административную работу для сопровождающих проект. Сколько работы добавляет соглашение, зависит от проекта и реализации. Простое соглашение может требовать, чтобы участники подтвердили одним щелчком мыши, что у них есть права, необходимые для внесения вклада в соответствии с лицензией проекта с открытым исходным кодом. Более сложное соглашение может потребовать юридической проверки и подписи со стороны работодателей участников. + +Кроме того, добавление «бумажной работы», которая, по мнению некоторых, является ненужной, трудной для понимания или несправедливой (когда получатель соглашения получает больше прав, чем участники или общественность через лицензию проекта с открытым исходным кодом), дополнительное соглашение с участниками может быть воспринято как недружественное к сообществу проекта. + + + +Вот некоторые ситуации, когда вы можете захотеть рассмотреть вопрос о дополнительном соглашении с участниками для вашего проекта: + +* Ваши юристы хотят, чтобы все участники явным образом приняли (подписать, онлайн или офлайн) условия вклада, возможно, потому, что они считают, что самой лицензии с открытым исходным кодом недостаточно (даже если это так!). Если это единственная проблема, должно быть достаточно соглашения с участником, подтверждающего лицензию проекта с открытым исходным кодом. [Лицензионное соглашение с индивидуальным участником jQuery](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) является хорошим примером облегченного соглашения с дополнительным участником. +* Вы или ваши юристы хотите, чтобы разработчики доказали, что каждое совершаемое ими действие санкционировано. Требование [Сертификата разработчика](https://developercertificate.org/) — это количество проектов, которые это обеспечивают. Например, сообщество Node.js [использует](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) их предыдущего CLA. Простым вариантом автоматизации принудительного применения DCO в вашем репозитории является [DCO Probot](https://github.com/probot/dco). +* В вашем проекте используется лицензия с открытым исходным кодом, которая не включает прямую выдачу патента (например, MIT), и вам нужен патент от всех участников, некоторые из которых могут работать в компаниях с большими портфелями патентов, которые могут быть использованы для вашего таргетинга. или других участников и пользователей проекта. [Лицензионное соглашение с индивидуальным участником Apache](https://www.apache.org/licenses/icla.pdf) является часто используемым соглашением с дополнительным участником, в котором выдача патента является копией той, которая содержится в лицензии Apache License 2.0. +* Ваш проект находится под лицензией с авторским левом, но вам также необходимо распространять проприетарную версию проекта. Вам потребуется, чтобы каждый участник назначил вам авторские права или предоставил вам (но не общественности) разрешительную лицензию. [Соглашение с участником MongoDB](https://www.mongodb.com/legal/contributor-agreement) является примером такого типа соглашения. +* Вы думаете, что вашему проекту может потребоваться изменить лицензии в течение его срока службы, и хотите, чтобы участники заранее согласились на такие изменения. + +Если вам действительно нужно заключить с вашим проектом дополнительное соглашение с участниками, рассмотрите возможность использования такой интеграции, как [помощник CLA](https://github.com/cla-assistant/cla-assistant), чтобы свести к минимуму отвлечение участников. + +## Что нужно знать юридическому отделу моей компании? + +Если вы выпускаете проект с открытым исходным кодом в качестве сотрудника компании, во-первых, ваша юридическая группа должна знать, что вы открываете исходный код проекта. + +Хорошо это или плохо, пусть они знают, даже если это личный проект. У вас, вероятно, есть «соглашение об интеллектуальной собственности сотрудников» с вашей компанией, которое дает им некоторый контроль над вашими проектами, особенно если они вообще связаны с бизнесом компании или вы используете какие-либо ресурсы компании для разработки проекта. Ваша компания _должна_ легко дать вам разрешение, и, возможно, оно уже было получено в рамках благоприятного для сотрудников соглашения об интеллектуальной собственности или политики компании. В противном случае вы можете вести переговоры (например, объяснить, что ваш проект служит целям профессионального обучения и вашего развития в целях компании) или не работать над своим проектом, пока не найдете лучшую компанию. + +**Если вы открываете исходный код проекта своей компании,** обязательно сообщите им об этом. У вашей юридической группы, вероятно, уже есть политика в отношении того, какую лицензию с открытым исходным кодом (и, возможно, дополнительное соглашение с участником) использовать, в зависимости от бизнес-требований и опыта компании в отношении обеспечения соответствия вашего проекта лицензиям зависимостей. Если нет, то вам с ними повезло! Ваша юридическая команда должна быть готова работать с вами, чтобы разобраться в этом вопросе. Некоторые вещи для размышления: + +* **Сторонние материалы:** Содержит ли ваш проект зависимости, созданные другими, или иным образом включает или использует чужой код? Если это открытый исходный код, вам необходимо соблюдать лицензии на открытый исходный код материалов. Это начинается с выбора лицензии, которая работает со сторонними лицензиями с открытым исходным кодом (см. Выше). Если ваш проект изменяет или распространяет сторонние материалы с открытым исходным кодом, то ваша юридическая группа также захочет знать, что вы выполняете другие условия сторонних лицензий с открытым исходным кодом, такие как сохранение уведомлений об авторских правах. Если в вашем проекте используется чужой код, не имеющий лицензии с открытым исходным кодом, вам, вероятно, придется попросить сторонних разработчиков [добавить лицензию с открытым исходным кодом](https://choosealicense.com/no-license/#for-users), а если вы не можете его получить, прекратите использовать их код в своем проекте. + +* **Коммерческая тайна:** Подумайте, есть ли в проекте что-то, что компания не хочет делать доступным для широкой публики. Если это так, вы можете открыть исходный код остальной части вашего проекта после извлечения материала, который хотите сохранить конфиденциальным. + +* **Патенты:** Подает ли ваша компания заявку на патент, открытый исходный код которого ваш проект будет представлять собой [публичное раскрытие](https://en.wikipedia.org/wiki/Public_disclosure)? К сожалению, вас могут попросить подождать (или, возможно, компания пересмотрит мудрость приложения). Если вы ожидаете участия в своем проекте сотрудников компаний с большим портфелем патентов, ваша группа юристов может пожелать, чтобы вы использовали лицензию с явным предоставлением патента от участников (например, Apache 2.0 или GPLv3) или дополнительное соглашение с участником (см. выше). + +* **Торговые марки:** Дважды проверьте, что название вашего проекта [не конфликтует с существующими торговыми марками](../starting-a-project/#конфликт-имён). Если вы используете в проекте товарные знаки собственной компании, убедитесь, что это не вызывает конфликтов. [FOSSmarks](http://fossmarks.org/) — это практическое руководство по пониманию товарных знаков в контексте проектов с бесплатным и открытым исходным кодом. + +* **Конфиденциальность:** Собирает ли ваш проект данные о пользователях? «Звонит домой» на серверы компании? Ваш юридическая команда может помочь вам в соблюдении политики компании и внешних нормативных требований. + +Если вы выпускаете первый проект своей компании с открытым исходным кодом, вышеуказанного более чем достаточно для выполнения (но не волнуйтесь, большинство проектов не должны вызывать серьезных проблем). + +В долгосрочной перспективе ваша команда юристов может сделать больше, чтобы помочь компании получить больше от своего участия в проектах с открытым исходным кодом и оставаться в безопасности: + +* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Типовая политика в отношении интеллектуальной собственности и открытого исходного кода](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). + + + +* **Что выпустить:** [(Почти) все](http://tom.preston-werner.com/2011/11/22/open-source-everything.html)? Если ваша юридическая команда понимает и вкладывается в стратегию открытого исходного кода вашей компании, они смогут намного лучше помочь, чем препятствовать вашим усилиям. +* **Соответствие:** Даже если ваша компания не выпускает проекты с открытым исходным кодом, она использует чужое программное обеспечение с открытым исходным кодом. [Осведомленность и процесс](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) могут предотвратить головные боли, задержки продукта и судебные иски. + + + +* **Патенты:** Ваша компания может пожелать присоединиться к [Открытой сети изобретений](https://www.openinventionnetwork.com/), общему защищенному пулу патентов, чтобы защитить использование участниками крупных проектов с открытым исходным кодом, или изучить другое [альтернативное лицензирование патентов](https://www.eff.org/document/hacking-patent-system-2016). +* **Управление:** Когда имеет смысл передать проект [юридическому лицу за пределами компании](../leadership-and-governance/#нужно-ли-мне-юридическое-лицо-для-поддержки-моего-проекта). diff --git a/_articles/ru/maintaining-balance-for-open-source-maintainers.md b/_articles/ru/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..d13f69173da --- /dev/null +++ b/_articles/ru/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,220 @@ +--- +lang: ru +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/browse11/l-m/en#/http://id.who.int/icd/entity/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://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid +* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) 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/ru/metrics.md b/_articles/ru/metrics.md new file mode 100644 index 00000000000..63f5b9d5743 --- /dev/null +++ b/_articles/ru/metrics.md @@ -0,0 +1,126 @@ +--- +lang: ru +title: Метрики проектов с открытым исходным кодом +description: Принимайте обоснованные решения, чтобы помочь вашему проекту с открытым исходным кодом процветать, измеряя и отслеживая его успех. +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Зачем что-то измерять? + +Данные, при разумном использовании, могут помочь вам принимать лучшие решения в качестве сопровождающего (maintainer) открытого исходного кода. + +Имея больше информации, вы можете: + +* Понять, как пользователи реагируют на новую функцию +* Выяснить, откуда приходят новые пользователи +* Определить и решить, стоит ли поддерживать новую функциональность +* Оценить популярность вашего проекта +* Понять, как используется ваш проект +* Привлечь инвестиции через спонсорство и гранты + +Например, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) обнаружил, что Google Analytics помогает ему определять приоритеты в работе: + +> Homebrew предоставляется бесплатно и управляется исключительно добровольцами в свободное время. В результате у нас нет ресурсов для проведения детальных исследований пользователей Homebrew, чтобы решить, как лучше разработать будущие функции и определить приоритеты текущей работы. Анонимная совокупная аналитика пользователей позволяет нам определять приоритетность фиксов и фич на основе того, как, где и когда люди используют Homebrew. + +Популярность — это еще не всё. Все приходят в окрытые проекты по разным причинам. Если ваша цель как сопровождающего открытый исходный код — продемонтсрировать свою работу, быть прозрачным в работе с кодом или просто развлечься, то метрики могут быть для вас не важны. + +Если вы _заинтересованы_ в более глубоком понимании своего проекта, читайте дальше, чтобы узнать, как проанализировать деятельность вашего проекта. + +## Обнаруживаемость + +Прежде чем кто-то сможет воспользоваться вашим проектом или внести в него свой вклад, он должен узнать о его существовании. Спросите себя: _могут ли люди найти этот проект?_ + +![График трафика](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +Если ваш проект размещён на GitHub, [вы можете посмотреть](https://help.github.com/articles/about-repository-graphs/#traffic), сколько людей попадают в ваш проект и откуда они приходят. На странице вашего проекта нажмите **Insights**, затем **Traffic**. На этой странице вы можете увидеть: + +* **Общее количество просмотров страниц:** показывает, сколько раз был просмотрен ваш проект. + +* **Общее количество уникальных посетителей:** показывает, сколько человек просмотрело ваш проект. + +* **Сайты-источники:** рассказывает о том, откуда пришли посетители. Эта метрика может помочь вам определить, где можно привлечь аудиторию и работают ли ваши усилия по продвижению. + +* **Популярный контент:** рассказывает о том, куда заходят посетители вашего проекта, в разбивке по просмотрам страниц и уникальным посетителям. + +[GitHub stars](https://help.github.com/articles/about-stars/) также может помочь определить базовый показатель популярности. Хотя звезды GitHub не обязательно коррелируют с загрузками и использованием, они могут сказать вам, сколько людей обращают внимание на вашу работу. + +Вы также можете захотеть [отслеживать открываемость в определенных местах](https://opensource.com/business/16/6/pirate-metrics): например, Google PageRank, реферальный трафик с сайта вашего проекта или рефералы с других проектов с открытым исходным кодом или сайтов. + +## Использование + +Люди находят ваш проект в этой дикой и безумной штуке, которую мы называем Интернетом. В идеале, когда они увидят ваш проект, у них возникнет желание что-то сделать. Второй вопрос, который вы хотите задать, это: _используют ли люди этот проект?_ + +Если вы используете менеджер пакетов, такой как npm или RubyGems.org, для распространения вашего проекта, вы можете отслеживать скачивания пакета. + +Каждый пакетный менеджер может использовать несколько иное определение "скачивания", и скачивания не обязательно коррелируют с установками или использованием, но это даёт некоторую базу для сравнения. Попробуйте использовать [Libraries.io](https://libraries.io/) для отслеживания статистики использования многих популярных менеджеров пакетов. + +Если ваш проект находится на GitHub, снова перейдите на страницу **Traffic**. Вы можете использовать [clone graph](https://github.com/blog/1873-clone-graphs), чтобы увидеть, сколько раз ваш проект был клонирован в определенный день, с разбивкой по общему количеству клонирований и уникальным клонирователям. + +![График git clone](/assets/images/metrics/clone_graph.png) + +Если использование низкое по сравнению с количеством людей, которые находят ваш проект, есть два аспекта, которые следует рассмотреть. Либо: + +* Ваш проект плохо конвертирует вашу аудиторию, либо +* Вы привлекаете не ту аудиторию + +Например, если ваш проект попадет на первую страницу Hacker News, вы, вероятно, увидите всплеск посещений (трафика), но более низкий коэффициент конверсии, поскольку вы охватите всех пользователей Hacker News. Однако если ваш Ruby-проект будет представлен на конференции Ruby, вы, скорее всего, получите высокий коэффициент конверсии от целевой аудитории. + +Попытайтесь понять, откуда приходит ваша аудитория, и попросите других людей оставить отзыв на странице вашего проекта, чтобы выяснить, с какой из этих двух проблем вы столкнулись. + +Как только вы узнаете, что люди используют ваш проект, вы можете попытаться выяснить, что они с ним делают. Создают ответвления (fork) вашего кода и добавляют функции? Используют для науки или бизнеса? + +## Удержание + +Люди находят ваш проект и используют его. Следующий вопрос, который вы захотите задать себе: _участвуют (contribute) ли люди в этом проекте?_ + +Никогда не рано начинать думать об участниках (contributors). Без участия других людей вы рискуете оказаться в нездоровой ситуации, когда ваш проект _популярен_ (многие используют его), но не _поддерживается_ (не хватает времени сопровождающих (maintainers) для удовлетворения спроса). + +Для удержания также необходим [приток новых участников](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), так как ранее активные участники со временем переходят на другие виды деятельности. + +Вот ещё показатели для отслеживания: + +* **Общее количество участников и количество правок (commit) на одного участника:** позволяет узнать, сколько у вас участников и кто из них более или менее активен. На GitHub это можно посмотреть в разделе **Insights** -> **Contributors**. В настоящее время этот график учитывает только тех участников, которые сделали правку (commit) в ветку репозитория по умолчанию. + +![График участников](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **Первоначальные, случайные и повторные участники:** помогает вам отслеживать, привлекаете ли вы новых участников и возвращаются ли они. (Случайные участники - те, у кого мало правок (commit). Будет ли это одна правка, менее пяти или что-то другое - решать вам). Без новых участников сообщество вашего проекта может стать застойным. + +* **Количество текущих открытых проблем (issue) и запросов на перенос (pull request):** если эти показатели слишком высоки, вам может понадобиться помощь в устранении проблем и проверке кода. + +* **Общее количество проблем (issues) и запросов на перенос (pull request) (включая закрытые):** открытые когда-то проблемы (issues) означают, что ваш проект кому-то достаточно интересен, чтобы он открыл проблему (issue). Если это число увеличивается со временем, это говорит о том, что люди заинтересованы в вашем проекте. + +* **Типы вклада (contribution):** например, правки (commit), исправление опечаток или ошибок, или комментирование проблемы (issue). + + + +## Активность сопровождающих + +Наконец, вы захотите замкнуть цикл, убедившись, что участники вашего проекта в состоянии справиться с объёмом получаемых вкладов (contributions). Последний вопрос, который вы хотите задать себе, это: _отвечаю ли я (или мы) на запросы нашего сообщества?_ + +Неотзывчивые сопровождающие становятся узким местом для проектов с открытм кодом. Если кто-то вносит свой вклад, но так и не получает ответа от сопровождающего, он может разочароваться и уйти. + +[Исследование компании Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) предполагает, что отзывчивость сопровождающих является критическим фактором поощрения повторного участия. + +Отслеживайте, сколько времени требуется вам (или другому сопровождающему), чтобы ответить на вклад, будь то проблема (issue) или запрос на перенос (pull request). Для ответа не обязательно предпринимать какие-либо действия. Можно просто сказать: _"Спасибо за ваш вклад! Я рассмотрю его в течение следующей недели."_ + +Можно также измерять время, необходимое для перехода от одного этапа процесса внесения вклада к другому, например: + +* Среднее время, в течение которого проблема (issue) остаётся открытой +* Закрываются ли проблемы (issue) в запросе на перенос (pull request) +* Закрываются ли неактуальные проблемы (issue) +* Среднее время для слияния запроса на перенос (pull request) + +## Используйте 📊, чтобы узнать о людях + +Понимание метрик поможет вам построить активный, растущий проект с открытым исходным кодом. Даже если вы не отслеживаете каждую метрику на панели инструментов, используйте описанный выше алгоритм действий, чтобы сосредоточить свое внимание на том типе поведения, который поможет вашему проекту процветать. + +[CHAOSS](https://chaoss.community/) — это гостеприимное сообщество с открытым исходным кодом, ориентированное на аналитику, показатели и программное обеспечение для здоровья сообщества. diff --git a/_articles/ru/starting-a-project.md b/_articles/ru/starting-a-project.md new file mode 100644 index 00000000000..1389cecd585 --- /dev/null +++ b/_articles/ru/starting-a-project.md @@ -0,0 +1,356 @@ +--- +lang: ru +title: Запуск опенсорс-проекта +description: Узнайте подробнее о мире опенсорса и подготовьте к запуску собственный проект. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## Опенсорс — что это и зачем? + +Итак, вы думаете о запуске своего опенсорс-проекта? Поздравляем! Мир ценит ваше участие. Давайте поговорим о том, что такое опенсорс и почему люди им занимаются. + +### Что означает "опенсорс"? + +Опенсорс-проект означает, что **кто-угодно может свободного его использовать, изучать, изменять и распространять независимо от цели.** Эти разрешения даются через [опенсорс-лицензию](https://opensource.org/licenses). + +Преимущество опенсорса в том, что он снижает барьеры для выбора и сотрудничества, позволяя людям быстро распространять и улучшать проекты. Кроме того, по сравнению с закрытым кодом, он дает пользователям возможность контролировать код. Компания, использующая программное обеспечение (ПО) с открытым исходным кодом, может нанять кого-то для доработки этого ПО, а не полагаться исключительно на решение поставщика с закрытым кодом. + +_Свободное ПО_ относится к тем же проектам, что и _опенсорс_. Иногда вы можете встретить комбинации этих [терминов](https://en.wikipedia.org/wiki/Free_and_open-source_software): "Свободное и открытое ПО" (free and open source software FOSS или free, libre, and open source software FLOSS). Слова free и libre здесь означают "свободное", а не ["бесплатное"](#опенсорс--значит-бесплатно). + +### Почему люди делают свою работу открытой? + + + +[Есть много причин](https://ben.balter.com/2015/11/23/why-open-source/) почему человек или организация открывают исходники своего проекта. Вот некоторые из них: + +* **Сотрудничество:** В опенсорс-проект может внести изменения любой человек, где бы он ни находился. Например, платформа для упражнений по программированию [Exercism](https://github.com/exercism/) насчитывает 350 контрибьюторов. + +* **Адаптация и доработки:** Опенсорс-проекты могут использоваться кем угодно практически для любой цели. Люди могут использовать ваш проект для создания чего-то нового. [WordPress](https://github.com/WordPress), например, стартовал как форк (ответвление) уже существовавшего проекта [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md). + +* **Прозрачность:** Любой может проверить опенсорс-проект на наличие ошибок и несоответствий. Прозрачность важна даже на государственном уровне. Например, правительство [Болгарии](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) и [США](https://sourcecode.cio.gov/) законодательно предписали прозрачность для таких отраслей как банковское дело, здравоохранение, и программ безопасности, вроде [Let's Encrypt](https://github.com/letsencrypt). + +Опенсорсом может быть не только ПО, но и многое другое: от наборов данных до книг. В разделе [GitHub Explore](https://github.com/explore) можно ознакомится с идеями проектов, которые можно заопенсорсить. + +### Опенсорс — значит бесплатно? + +Бесплатность опенсорс — это одно из самых больших преимуществ, которое скорее является побочным продуктом его совокупной ценности. + +Поскольку [опенсорс-лицензия предполагает](https://opensource.org/osd-annotated), что кто угодно может использовать, модифицировать, и распространять ваш проект почти для любых целей, то в большинстве случаев это означает бесплатность. Потому что, если бы проект стоит денег, то любой мог абсолютно легально скопировать его и тем самым использовать его бесплатно. + +Поэтому большинство опенсорс-проектов бесплатны, хотя это свойство не входит в определение само опенсорса. Есть способы оплаты взимания оплаты за пользование опенсорс-проектов косвенным образом через двойное лицензирование или ограничение функциональности, при этом такие проекты по-прежнему будут соответствовать официальному определению опенсорса. + +## Стоит ли мне запускать свой опенсорс-проект? + +Краткий ответ — да, потому что независимо от результата, запуск собстенного проекта — это отличный способ узнать, как работает опенсорс. + +Если вы никогда ранее не запускали подобных проектов, вы можете переживать по поводу того, что скажут люди, и заметит ли кто-нибудь его вообще. Если вам знакомо это ощущение, не беспокойтесь, вы не один такой! + +Опенсорс похож на любую другую творческую работу, будь то писательство или рисование. Может быть страшно показывать свою работу всему миру. Но как известно, практика — это путь к совершенству, даже если у вас пока нет своей аудитории. + +Если вы ещё не решились, найдите время подумать о ваших возможных целях. + +### Постановка целей + +Цели помогут вам определиться, над чем работать, от чего отказаться, и где вам понадобится помощь со стороны. Спросите себя: _"зачем мне нужен этот опенсорс-проект?"_. + +Единого ответа на этот вопрос не существует. Может быть сразу несколько целей на один проект, или разные проекты с разными целями. + +Если ваша единственная цель — показать свою работу, скорее всего вы не нуждаетесь в сторонней помощи, о чём стоит явно можно указать в файле README. С другой стороны, если вы заинтересованы в помощниках, то следует потратить время на написание понятной документации и проявить заботу о новичках. + + + +По мере роста проекта ваше сообщество будет нуждаться не только в коде. Ответы в ишью, проверка кода и реклама собственного проекта — всё это важные задачи любого опенсорс-проекта. + +Хотя количество времени на непрограммистские задачи зависит от размера и масштаба вашего проекта, вы должны быть готовы решать их сами или найти для этого помощника. + +**Если вы работаете в компании, запускающей опенсорс-проект,**, убедитесь заранее, у вас есть внутренние ресурсы для его развития. Вам нужно определить, кто будет отвечать за поддержку проекта после его запуска, и как будете распределять задачи внутри сообщества. + +Если вам нужен выделенный бюджет или люди для продвижения, работы и поддержки проекта, обговорите это как можно раньше. + + + +### Участие в чужих проектах + +Если ваша цель — понять как взаимодействовать с другими и как работает опенсорс, рассмотрите возможность участия в уже существующем проекте, который вы используете и любите. Вашим участием может быть что-то простое, вроде исправление опечаток и обновление документации. + +Если вы не понимаете, как войти в чужой проект, ознакомьтесь с нашим руководством [Как участвовать в опенсорс-проекте](../how-to-contribute/). + +## Запуск собственного опенсорс-проекта + +Нет идеального момента, когда нужно открывать исходники своей работы. Вы можете открыть их на стадии идеи, в процессе работы или после нескольких лет закрытости. + +В общем случае, открывать исходники можно, когда вы чувствуете себя уверенно настолько, что посторонние люди будут смотреть вашу работу и высказываться о ней. + +В каждом проекте вне зависимости от стадии, на которой вы решили открыть исходники, должна быть следующая документация: + +* [Опенсорс-лицензию](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Руководство для участников](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Нормы поведения](../code-of-conduct/) + +Эти файлы помогут вам донести ожидания, определить процесс по участию, и защитить законные права всех, включая вас самих. Всё это значительно увеличивает шансы, что всё пойдёт хорошо. + +Если ваш проект на GitHub и вы разместите эти файлы в корневой категории с рекомендованными названиями, GitHub распознает их и автоматически отобразит посетителям репозитория. + +### Выбор лицензии + +Лицензия для открытого исходного кода гарантирует, что другие могут использовать, копировать, изменять и вносить правки в ваш проект без каких-либо последствий. Она также защищает вас от неприятных юридических ситуаций. **Вы должны добавить лицензию при запуске опенсорс-проекта.** + +Юридическая работа — не из легких. Но есть хорошие новости: вы можете скопировать существующую лицензию и разместить её в своём репозитории, за одну минуту защитив ваш тяжелый труд. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) — это самые популярные лицензии, но [есть и другие варианты](https://choosealicense.com). + +Когда вы создаёте новый проект на GitHub, вам дается на выбор несколько лицензий. Выбрав опенсорс-лицензию, вы сделаете свой проект открытым. + +![Выберете лицензию](/assets/images/starting-a-project/repository-license-picker.png) + +Если у вас есть другие вопросы или беспокойства относительно юридических аспектов опенсорса, [мы описали их здесь](../legal/). + +### Написание README + +Файл README ("прочитай меня") не только рассказывает, как использовать ваш проект, но и объясняет, почему он важен, и что пользователи могут с ним делать. + +Постарайтесь ответить в README на следующие вопросы: + +* Что делает этот проект? +* Чем этот проект полезен? +* Как начать работать с ним? +* Где получить помощь, если понадобится? + +Также можно в README можно дать ответы на другие вопросы, например, как поучаствовать в проекте, каковы его цели, а также рассказать о лицензии и авторстве. Если вы не планируете принимать помощь от других людей, или он ещё не готов для запуска — так и напишите об этом. + + + +Иногда люди откладывают написание README, потому что чувствуют, что проект не завершен, или не хотят, чтобы другие в нём участвовали. Но это как раз хороший повод написать об этом. + +Для вдохновения, можете ознакомиться с [руководством "Сделай README"](https://www.makeareadme.com/) от @dguo или взять на вооружение [Шаблон README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) от @PurpleBooth. + +Если вы добавите файл README в корневую директорию проекта, GitHub автоматически заметит его и покажет на главной странице репозитория. + +### Написание руководства для участников + +Файл CONTRIBUTING говорит вашей аудитории, как стать участником вашего проекта. Например: + +* Как сообщить об ошибке (попробуйте использовать [шаблоны для ишью и пул-реквестов](https://github.com/blog/2111-issue-and-pull-request-templates)) +* Как предложить реализацию новой функциональности +* Как настроить среду выполнения и запустить тесты + +Помимо технических деталей, в файле CONTRIBUTING только приветствуется изложить свои ожидания относительно участия других людей. Например: + +* Какого рода участие вы ждёте? +* Ваши планы и видение развития проекта +* Как участники могут (и не могут) связываться с вами + +Ваш тёплый дружеский тон и конкретные предложения по участию, вроде написания документации или создания сайта, могут иметь большое значение для привлечения новичков к работе над проектом. + +Например, [Active Admin](https://github.com/activeadmin/activeadmin/) начинает [своё руководство по участию](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) с таких слов: + +> В первую очередь хотим выразить вам благодарность за то, что подумываете об участии в развитии Active Admin. Именно такие люди как вы делают Active Admin прекрасным инструментом. + +На ранних стадиях проекта ваш файл CONTRIBUTING может быть простым. Вы всегда следует объяснить, как сообщать о багах и оформлять ишью, а также описать технические требования к контрибьюторам (например, написание тестов). + +Со временем вы можете дополнить его ответами на часто задаваемые вопросы. Благодаря этому меньше людей будут спрашивать вас об одном и том же снова и снова. + +Чтобы вам было проще написать файл CONTRIBUTING, ознакомьтесь с [шаблоном руководства по сотрудничеству](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) от @nayafia или прочтите ["Как создать файл CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) от @mozilla. + +Поставьте ссылку на файл CONTRIBUTING внутри README, так больше людей увидят его. Если вы [разместите файл CONTRIBUTING.md в корне вашего проекта](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), то GitHub автоматически предложит ознакомиться с ним когда кто-то открывает ишью или отправляет пул-реквест. + +![Руководство по сотрудничеству](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Разработка норм поведения + + + +В итоге, нормы поведения определяют базовые правила поведения участников вашего проекта. Это особенно важно, если вы запускаете проект для компании или сообщества. Нормы поведения способствует установлению здорового, конструктивного поведения в сообществе, снижая стресс для вас, как для мейнтейнера проекта. + +Подробнее смотрите на странице [Руководство по нормам поведения](../code-of-conduct/). + +Помимо описания _каким_ вы хотите видеть поведение участников, нормы поведения также разъясняют, к кому и когда они применяется, и что будет в случае их нарушения. + +По аналогии с лицензией, вам не обязательно писать нормы самим, а можно скопировать один из существующих вариантов. [Contributor Covenant](https://contributor-covenant.org/) используется в [более 40.000 опенсорс-проектах](https://www.contributor-covenant.org/adopters), включая Kubernetes, Rails, и Swift. Какие бы нормы вы не выбрали, будьте готовы применить их при необходимости. + +Вставьте текст в файл CODE_OF_CONDUCT.md в корне проекта, так его будет проще находить и ссылаться на него, например, из README. + +## Название и брендирование вашего проекта + +Брендинг — это не только броский логотип и запоминающееся название, но и то, как вы говорите о своём проекте и кому хотите обратиться с ним. + +### Выбор правильного названия + +Придумайте название, которое легко запоминается и, в идеале, даёт представление о сути проекта. Например: + +* [Sentry](https://github.com/getsentry/sentry) (с англ. — караул) — сервис для мониторинга приложения +* [Thin](https://github.com/macournoyer/thin) (с англ. — худой) — быстрый и простой веб-сервер на Ruby + +Если вы создаете что-то, опираясь на уже существующий проект, то добавьте его название в виде префикса к своему проекту, — это даст больше деталей о нём. Например [node-fetch](https://github.com/bitinn/node-fetch) реализует `window.fetch` в Node.js. + +Выбирайте понятное название проекта прежде всего. Каламбуры могут быть забавными, но подумайте о людях из других культур или опытом, которые могут не понять шутку. Ваши потенциальные пользователи могут быть работниками компаний, которые будут рассказывать о проекте на работе. Не заставляйте их краснеть при этом! + +### Конфликт имён + +[Проверьте наличие опенсорс-проектов с таким же названием](http://ivantomic.com/projects/ospnc/), особенно если вы используете один и тот же язык или экосистему. Если ваше название совпадёт с популярным существующим проектом, вы можете запутать свою аудиторию. + +Если вы планируете завести сайт, твиттер или любую площадку для публикаций, убедитесь, что нужное вам название там свободно. Лучше всего [зарегистрируйте все аккаунты сейчас](https://instantdomainsearch.com/), хотя просто для душевного спокойствия, даже если пока не планируете ими пользоваться. + +Убедитесь, что вы не посягаете на торговую марку какой-нибудь компании. В будущем она сможет попросить вас закрыть проект или даже подать в суд на вас. Это неоправданный риск. + +Проверьте имя во [всемирной базе брендов WIPO](http://www.wipo.int/branddb/en/), чтобы избежать конфликта по поводу авторских прав. Если вы делаете проект от лица компании, то [юридический отдел может помочь вам с этим](../legal/). + +Напоследок, выполнит быстрый поиск в Google по названию вашего проекта. Смогут ли люди по нему легко найти ваш проект? А может быть, по этому запросу появляется что-то нежелательное? + +### То, как вы пишите (и кодите) тоже влияет на ваш бренд! + +За всю жизнь проекта вы будете много писать: README, руководства, документы сообщества, ответы на вопросы, возможно даже информационные бюллетени и списки рассылки. + +Будь то официальная документация или обычное сообщение, стиль письма также является частью бренда проекта. Подумайте о том, в каком свете вы выглядите перед аудиторией, и правильный ли подобрали тон. + + + +Добрый и вежливый тон создаст приятную атмосферу для новых участников. Следите так же за простотой изложения, так как для многих читателей английский может быть не родным. + +Не только слова, что вы пишете, но и стиль кода может стать частью бренда вашего проекта. [Angular](https://angular.io/guide/styleguide) и [jQuery](https://contribute.jquery.org/style-guide/js/) — только два примера проектов со строгими стилями написания кода и рекомендациями. + +Нет необходимости составлять руководство по стилю, когда вы только начинаете, возможно вам понравится совмещать в своём проекте разные стили. Но стоит заранее предвидеть, что стиль написания и кода может как привлекать, так и отталкивать людей. На ранних стадиях проекта формируется то, каким в дальнейшем станет ваш проект, и зависит от вас, каким вы хотите его видеть. + +## Чеклист перед запуском + +Вы готовы открыть свой проект? Вот вам проверочный лист в помощь. Когда отметите все пункты, [откройте ваш проект](https://help.github.com/articles/making-a-private-repository-public/) и похвалите себя. + +**Документация** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Код** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Люди** + +Если вы частное лицо: + +
+ + +
+ +Если вы компания или организация: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## Вы сделали это! + +Поздравляем с открытием исходников вашего первого проекта! Вне зависимости от результата, работа на виду у людей — это подарок для сообщества. Каждый коммит, комментарий и запрос на правку — это возможность учиться и расти для себя и других. diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md index 9b1140f59be..713b8df38d1 100644 --- a/_articles/starting-a-project.md +++ b/_articles/starting-a-project.md @@ -3,12 +3,6 @@ lang: en title: Starting an Open Source Project description: Learn more about the world of open source and get ready to launch your own project. class: beginners -toc: - the-what-and-why-of-open-source: "The what and why of open source" - should-i-launch-my-own-open-source-project: "Should I launch my own open source project?" - launching-your-own-open-source-project: "Launching your own open source project" - naming-and-branding-your-project: "Naming and branding your project" - your-pre-launch-checklist: "Your pre-launch checklist" order: 2 image: /assets/images/cards/beginner.png related: @@ -42,7 +36,7 @@ _Free software_ refers to the same set of projects as _open source_. Sometimes y * **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors. -* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md). +* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). * **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt). @@ -52,7 +46,7 @@ Open source isn't just for software, either. You can open source everything from One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value. -Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. +Because [an open source license requires](https://opensource.org/definition-annotated/) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source. @@ -178,7 +172,7 @@ In addition to technical details, a CONTRIBUTING file is an opportunity to commu Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. -For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: +For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with: > First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. @@ -186,7 +180,7 @@ In the earliest stages of your project, your CONTRIBUTING file can be simple. Yo Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again. -For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). +For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. @@ -229,7 +223,7 @@ Consider clarity above all. Puns are fun, but remember that some jokes might not ### Avoiding name conflicts -[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. +[Check for open source projects with a similar name](https://namechecker.vercel.app/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet. @@ -249,7 +243,7 @@ Whether it's official documentation or a casual email, your writing style is par avatar I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.

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

diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md index 1bed55f9bbf..c41c8e01805 100644 --- a/_articles/ta/best-practices.md +++ b/_articles/ta/best-practices.md @@ -103,7 +103,7 @@ related:

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

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

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

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

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

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

diff --git a/_articles/ta/code-of-conduct.md b/_articles/ta/code-of-conduct.md index 3d70fc9a6c2..9908515abf3 100644 --- a/_articles/ta/code-of-conduct.md +++ b/_articles/ta/code-of-conduct.md @@ -31,7 +31,7 @@ related: நீங்கள் எங்கு வேண்டுமானாலும், முந்தைய உபாயத்தை பயன்படுத்தவும். [பங்களிப்பாளரின் உடன்படிக்கை](https://contributor-covenant.org/) என்பது ஒரு நடத்தை விதியாகும், இது குபெர்னீஸ், ரெயில்ஸ் மற்றும் ஸ்விஃப்ட் உள்ளிட்ட 40,000 திறந்த மூல திட்டங்களில் பயன்படுத்தப்படுகிறது. -[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும். +[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும். உங்கள் திட்டத்தின் மூலம் கோப்பகத்தில் CODE_OF_CONDUCT கோப்பை வைக்கவும், மேலும் உங்கள் CONTRIBUTING அல்லது README கோப்பில் இருந்து அதை இணைப்பதன் மூலம் அதை உங்கள் சமூகத்திற்குத் தெரியப்படுத்தவும். @@ -40,7 +40,7 @@ related: @@ -54,7 +54,7 @@ related: நடத்தை மீறல்களை மக்கள் தனிப்பட்ட முறையில் புகாரளிக்க (மின்னஞ்சல் முகவரியைப் போன்ற) கொடுக்க வேண்டும், மற்றும் அந்த அறிக்கையை யார் பெறுகிறார்கள் என்பதை விளக்கவும். இது ஒரு பராமரிப்பாளர், பராமரிப்பாளர்களின் குழு, அல்லது நடத்தை விதி குழுவாக இருக்கலாம். -அந்த அறிக்கையைப் பெறும் நபரைப் பற்றி ஒருவர் மீறல் குறித்து புகாரளிக்க விரும்புவதை மறந்துவிடாதீர்கள். இந்த வழக்கில், வேறு யாரிடாமவது மீறல்களைப் புகாரளிக்க அவர்களுக்கு விருப்பத்தெரிவு கொடுங்கள். உதாரணத்திற்கு, @ctb and @mr-c [தங்கள் திட்டத்தை விளக்குகிறார்கள்](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +அந்த அறிக்கையைப் பெறும் நபரைப் பற்றி ஒருவர் மீறல் குறித்து புகாரளிக்க விரும்புவதை மறந்துவிடாதீர்கள். இந்த வழக்கில், வேறு யாரிடாமவது மீறல்களைப் புகாரளிக்க அவர்களுக்கு விருப்பத்தெரிவு கொடுங்கள். உதாரணத்திற்கு, @ctb and @mr-c [தங்கள் திட்டத்தை விளக்குகிறார்கள்](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > துஷ்பிரயோகம், தொந்தரவு, அல்லது ஏற்றுக்கொள்ள முடியாத தன்மை ஆகியவற்றின் நிகழ்வுகள் **khmer-project@idyll.org** என்ற மின்னஞ்சல் மூலம் புகாரளிக்கலாம். டைட்டஸ் பிரவுன் மற்றும் மைக்கேல் ஆர். க்ரூஸோ. அவர்களில் ஒருவர் சம்பந்தப்பட்ட ஒரு சிக்கலைப் புகாரளிக்க மின்னஞ்சல் **ஜுடி பிரவுன் கிளார்க், Ph.D.** பரிணாம வளர்ச்சிக்கான ஆய்விற்கான BEACON மையத்தில் பல்வகைமை பணிப்பாளர், அறிவியல் மற்றும் தொழில்நுட்பத்திற்கான NSF மையம்.* diff --git a/_articles/ta/finding-users.md b/_articles/ta/finding-users.md index 45fa862ffe9..f1cbf3561d4 100644 --- a/_articles/ta/finding-users.md +++ b/_articles/ta/finding-users.md @@ -143,14 +143,6 @@ related: பார்வையாளர்களை உருவாக்குவதற்கு ஒரே இரவில் தீர்வு இல்லை. நம்பிக்கையையும் மற்றவர்களுடைய மரியாதையையும் பெற்றுக்கொள்வது நேரம் எடுக்கும், உங்கள் நற்பெயரைக் கட்டி முடிக்காது. - - ## பொறுமை காக்கவும் உங்கள் திறந்த மூல திட்டத்தை மக்கள் கவனிக்க முன் நீண்ட நேரம் எடுக்கலாம். பரவாயில்லை! மிக பிரபலமான சில திட்டங்கள் இன்று அதிக அளவில் நடவடிக்கைகளை எட்டுவதற்கு பல ஆண்டுகள் எடுத்தன. உங்கள் திட்டம் தன்னிச்சையாக புகழ் பெறும் என்று நம்புவதற்குப் பதிலாக உறவுகளை மேம்படுத்தவதில் கவனம் செலுத்துங்கள். பொறுமையாக இருங்கள், உங்கள் வேலையைப் பாராட்டுபவர்களுடன் பகிர்ந்து கொள்ளுங்கள். diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md index 3267c7af00b..246d0195899 100644 --- a/_articles/ta/getting-paid.md +++ b/_articles/ta/getting-paid.md @@ -66,14 +66,6 @@ related: உங்கள் முதலாளி உண்மையிலேயே திட்டத்தை பயன்படுத்துகிறார்களானால், திறந்த மூல வேலைக்கு ஒரு விஷயத்தை எளிதாக்கலாம், ஆனால் உங்கள் சுருதிடன் ஆக்கப்பூர்வமாகப் பெறலாம். ஒருவேளை உங்கள் முதலாளி இந்த திட்டத்தை பயன்படுத்தவில்லை, ஆனால் பைதான் பயன்படுத்தப்படுகிறது, மேலும் பிரபலமான பைத்தான் திட்டத்தை பராமரிக்க புதிய பைத்தான் நிரல் உருவாக்குபவர்களை ஈர்க்கிறது. ஒருவேளை அது உங்கள் முதலாளி பொதுவாக நிரலர் நட்புக்கு மிகவும் பொருத்தமானதாக இருக்கும். - - நீங்கள் வேலை செய்ய உங்களிடம் திறந்த மூல திட்டப்பணி இல்லை என்றால், தற்போதைய பணி வெளியீடு திறந்த மூலமாக்க, உங்கள் சொந்த மென்பொருளில் சிலவற்றை திறக்க உங்கள் முதலாளிக்கு ஒரு வழக்கு உருவாக்கவும். பல நிறுவனங்கள் திறந்த மூல திட்டங்களை தங்கள் வியாபாரக் குறி உருவாக்க மற்றும் செயல் திறனை மிக்கவர்களை பணியமர்த்துவதற்கு உருவாக்குகின்றன. @@ -101,6 +93,7 @@ related: இறுதியாக, உங்களுடைய தனிப்பட்ட சூழ்நிலைகளை பொறுத்து, நீங்கள் உங்கள் திறந்த மூல வேலைக்கு நிதி திரட்ட முயற்சி செய்யலாம். உதாரணத்திற்கு: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon தனது [Redux](https://github.com/reactjs/redux) திட்டத்திற்கான நிதியை [பேட்ரியன் கூட்டல் நிதி பிரச்சாரத்தின்](https://redux.js.org/) மூலம் திரட்டினார். * @andrewgodwin டிஜாங்க் திட்ட அமைப்புமுறைகளை [kickstarter பிரச்சாரத்தின்](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) மூலம் திரட்டினார். @@ -118,7 +111,6 @@ related: நிதியளிக்கும் திட்டங்களின் சில உதாரணங்கள் பின்வருமாறு: * **[வெப்பேக்](https://github.com/webpack)** நிறுவனங்கள் மற்றும் தனிநபர்களிடமிருந்து [OpenCollective மூலம்](https://opencollective.com/webpack) நிதி திரட்டுகிறது -* **[Vue](https://github.com/vuejs/vue)** [பேட்ரன் மூலம் நிதியளிக்கப்பட்டது](https://github.com/open-source/stories/yyx990803) * **[ரூபி டுகேதர்](https://rubytogether.org/),** [பண்ட்லர்](https://github.com/bundler/bundler), [ரூபிஜெம்ஸ்](https://github.com/rubygems/rubygems), மற்றும் பிற ரூபி உள்கட்டமைப்பு திட்டங்களுக்கு பணிக்கு பணம் செலுத்துகின்ற ஒரு இலாப நோக்கமற்ற அமைப்பு ### வருவாய் நீரோடை உருவாக்கவும் @@ -129,7 +121,7 @@ related: * **[டிராவிஸ் சிஐ](https://github.com/travis-ci)** அதன் தயாரிப்பின் கட்டண பதிப்புகள் வழங்குகிறது * **[கோஸ்ட்](https://github.com/TryGhost/Ghost)** ஒரு இலாப நோக்கமற்றத பணம் செலுத்திய நிர்வகிக்கப்பட்ட சேவை -[என்பிஎம்](https://github.com/npm/npm) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன. +[என்பிஎம்](https://github.com/npm/cli) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன. ### மானிய நிதிக்கு விண்ணப்பிக்கவும் diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md index 4e49aeb57c5..193a4102653 100644 --- a/_articles/ta/how-to-contribute.md +++ b/_articles/ta/how-to-contribute.md @@ -68,14 +68,6 @@ related: நீங்கள் குறியீட்டை எழுத விரும்பினால் கூட, பிற வகையான பங்களிப்புகள் ஒரு திட்டத்துடன் தொடர்பு கொள்ளவும் மற்ற சமூக உறுப்பினர்களை சந்திக்கவும் சிறந்த வழியாகும். அந்த உறவுகளை கட்டியெழுப்புதல் திட்டத்தின் மற்ற பகுதிகளிலும் வேலை செய்ய உங்களுக்கு வாய்ப்பளிக்கும். - - ### நிகழ்வு திட்டமிடல்களை விரும்புகிறீர்களா? * திட்டம் பற்றி பட்டறைகள் அல்லது சந்திப்புகளை ஏற்பாடு செய்யுங்கள், [@fzamperin NodeSchoolக்கு செய்ததை போல](https://github.com/nodeschool/organizers/issues/406) @@ -94,12 +86,12 @@ related: * திட்டத்தின் ஆவணங்களை எழுதுவது மற்றும் மேம்படுத்துவது * திட்டம் எவ்வாறு பயன்படுத்தப்படுகிறது என்பதை காட்டும் உதாரணங்கள் ஒரு கோப்புறையை தொகுத்தல் * திட்டத்திற்கான ஒரு செய்திமடலைத் தொடங்கவும் அல்லது அஞ்சல் பட்டியலிலிருந்த சிறப்பம்சங்களைக் தொகுக்கவும் -* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](https://github.com/pypa/python-packaging-user-guide/issues/194) +* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](https://packaging.python.org/) * திட்டத்தின் ஆவணங்களுக்கான ஒரு மொழிபெயர்ப்பை எழுதுங்கள் உங்கள் திட்டத்திற்கான கூடுதலான பங்களிப்பு ஒப்பந்தத்தை நீங்கள் பரிசீலிக்க விரும்பும் சில சூழ்நிலைகளில் பின்வருவன அடங்கும்: -* உங்கள் வழக்கறிஞர்கள் பங்களிப்பவர்கள் எல்லோரும் பங்களிப்பு விதிமுறைகளை வெளிப்படையாக ஏற்றுக்கொள்ள வேண்டும் (_கையொப்பமிடல்_, இயக்கலை அல்லது முடக்கலை) திறந்த மூல உரிமம் தானே போதுமானது அல்ல (இருப்பினும் கூட!). இது மட்டுமே கவலையாக இருந்தால், திட்டத்தின் திறந்த மூல உரிமத்தை உறுதிப்படுத்தும் பங்களிப்பு ஒப்பந்தம் போதுமானதாக இருக்க வேண்டும். [JQuery தனிநபர் பங்களிப்பாளர் உரிம ஒப்பந்தம்](https://contribute.jquery.org/CLA/) இலகுரக கூடுதல் பங்களிப்பு ஒப்பந்தத்தின் சிறந்த உதாரணம். சில திட்டங்கள், ஒரு [உருவாக்குபவர் துவக்க சான்றிதழ்](https://github.com/probot/dco) ஒரு மாற்று இருக்க முடியும். +* உங்கள் வழக்கறிஞர்கள் பங்களிப்பவர்கள் எல்லோரும் பங்களிப்பு விதிமுறைகளை வெளிப்படையாக ஏற்றுக்கொள்ள வேண்டும் (_கையொப்பமிடல்_, இயக்கலை அல்லது முடக்கலை) திறந்த மூல உரிமம் தானே போதுமானது அல்ல (இருப்பினும் கூட!). இது மட்டுமே கவலையாக இருந்தால், திட்டத்தின் திறந்த மூல உரிமத்தை உறுதிப்படுத்தும் பங்களிப்பு ஒப்பந்தம் போதுமானதாக இருக்க வேண்டும். [JQuery தனிநபர் பங்களிப்பாளர் உரிம ஒப்பந்தம்](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) இலகுரக கூடுதல் பங்களிப்பு ஒப்பந்தத்தின் சிறந்த உதாரணம். சில திட்டங்கள், ஒரு [உருவாக்குபவர் துவக்க சான்றிதழ்](https://github.com/probot/dco) ஒரு மாற்று இருக்க முடியும். * உங்கள் திட்டம் ஒரு வெளிப்படையான ஆதார உரிமையைப் பயன்படுத்துகிறது, இது ஒரு வெளிப்படையான காப்புரிமை வழங்கலை (MIT போன்றவை) உள்ளடக்குவதில்லை, மேலும் அனைத்து பங்களிப்பாளர்களிடமிருந்தும் ஒரு காப்புரிமை வழங்கல் உங்களுக்கு தேவைப்படுகிறது, அவர்களில் சிலர் உங்களிடமுள்ள பெரிய காப்புரிமை பிரிவில் உள்ள நிறுவனங்களுக்கு வேலை செய்யலாம், உங்களை அல்லது திட்டத்தின் மற்ற பங்களிப்பாளர்கள் மற்றும் பயனர்கள் குறி வைக்கலாம். [அப்பாச்சி உரிமையாளர் உரிம ஒப்பந்தம்](https://www.apache.org/licenses/icla.pdf) பொதுவாகப் பயன்படுத்தப்படும் கூடுதலான பங்களிப்பு ஒப்பந்தம் ஆகும், இது அப்பாச்சி உரிமம் 2.0 இல் காணப்பட்ட ஒரு காப்புரிமை மானியத்தை பிரதிபலிக்கிறது. * உங்கள் திட்டம் நகலெடுப்பு உரிமத்தின் கீழ் உள்ளது, ஆனால் நீங்கள் திட்டத்தின் தனியுரிம பதிப்புகளை விநியோகிக்க வேண்டும். உங்களிடம் பதிப்புரிமையை வழங்குவதற்கு அல்லது பங்களிப்பு உரிமத்தை உங்களுக்கு வழங்க (ஆனால் பொதுமக்கள் அல்ல) உங்களுக்கு ஒவ்வொரு பங்காளருக்கும் தேவைப்படும். [மாங்கோ பங்களிப்பாளர் ஒப்பந்தம்](https://www.mongodb.com/legal/contributor-agreement) என்பது இந்த வகை ஒப்பந்தத்தின் ஒரு எடுத்துக்காட்டு. * உங்கள் திட்டம் அதன் வாழ்நாளில் உரிமங்களை மாற்ற வேண்டும் மற்றும் பங்களிப்பாளர்களுக்கு அத்தகைய மாற்றங்களுக்கு முன்கூட்டியே ஒப்புக் கொள்ள வேண்டும் என்று நீங்கள் நினைக்கிறீர்கள். @@ -133,18 +133,18 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ நீண்ட காலமாக, உங்கள் சட்ட குழு நிறுவனம், திறந்த மூலத்தில் அதன் ஈடுபாட்டிலிருந்து நிறுவனத்தின் உதவியை அதிகரிக்க உதவ முடியும், மேலும் பாதுகாப்பாக இருக்கவும்: -* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). +* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/). * **எதை வெளியிடுவது:** [(கிட்டத்தட்ட) எல்லாவற்றையும்?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) உங்கள் சட்ட குழு புரிந்துகொண்டு உங்கள் நிறுவனத்தின் திறந்த மூலோபாயத்தில் முதலீடு செய்திருந்தால், உங்கள் முயற்சிகளை தடுப்பதை காட்டிலும் உதவி செய்ய முடியும். -* **இணக்கம்:** உங்கள் நிறுவனம் திறந்த மூல திட்டங்களை வெளியிடாவிட்டாலும், அது மற்றவரின் திறந்த மூல மென்பொருள் பயன்படுத்துகிறது. [விழிப்புணர்வு மற்றும் செயல்முறை](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) தலைவலி, தயாரிப்பு தாமதங்கள் மற்றும் வழக்குகள் ஆகியவற்றை தடுக்கலாம். +* **இணக்கம்:** உங்கள் நிறுவனம் திறந்த மூல திட்டங்களை வெளியிடாவிட்டாலும், அது மற்றவரின் திறந்த மூல மென்பொருள் பயன்படுத்துகிறது. [விழிப்புணர்வு மற்றும் செயல்முறை](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) தலைவலி, தயாரிப்பு தாமதங்கள் மற்றும் வழக்குகள் ஆகியவற்றை தடுக்கலாம். diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md index f11b4367d19..5f698d8036a 100644 --- a/_articles/tr/best-practices.md +++ b/_articles/tr/best-practices.md @@ -3,18 +3,11 @@ lang: tr title: Geliştiriciler İçin Örnek Yöntemler description: Belgelendirme işlemlerinden topluluğunuzu güçlendirmeye kadar açık bir kaynak geliştiricisi olarak hayatınızı kolaylaştırın. class: best-practices -toc: - what-does-it-mean-to-be-a-maintainer: Geliştirici olmak ne demektir? - documenting-your-processes: İşlemlerinizi belgeleme - learning-to-say-no: Hayır demeyi öğrenme - leverage-your-community: Topluluğunuzdan yararlanma - bring-in-the-robots: Robotları kullanın - its-okay-to-hit-pause: Duraklatmak sorun değildir order: 5 image: /assets/images/cards/best-practices.png related: - - metrics - - leadership +- metrics +- leadership --- ## Geliştirici olmak ne demektir? @@ -72,7 +65,7 @@ Yazmaya değer birkaç kural: * Bekleme süresi ne kadardır (_örneğin, "7 gün içinde bir bakıcıdan bir yanıt bekleyebilirsiniz. O zamana kadar bir şey duymadıysanız, ipliğe ping atmaktan çekinmeyin."_) * Projeye ne kadar zaman harcıyorsunuz (_örneğin, "Bu projeye haftada sadece 5 saat harcıyoruz"_) -[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ve [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) geliştiriciler ve katkıda bulunanlar için temel kuralları olan projelere birkaç örnektir. +[Jekyll](https://github.com/jekyll/jekyll/tree/HEAD/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ve [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) geliştiriciler ve katkıda bulunanlar için temel kuralları olan projelere birkaç örnektir. ### İletişimi herkese açık tutun @@ -244,7 +237,7 @@ Bakım çalışmalarının bazı yönlerini otomatikleştirmeye yardımcı olaca * [mention-bot](https://github.com/facebook/mention-bot) PR talepleri için potansiyel denetçilerden bahseder * [Danger](https://github.com/danger/danger) kod incelemesini otomatikleştirmeye yardımcı olur * [no-response](https://github.com/probot/no-response) geliştiricilerin uzun süre yanıt vermediği sorunları kapatır -* [dependabot-preview](https://github.com/marketplace/dependabot-preview) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar +* [dependabot](https://github.com/dependabot) bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar Hata raporları ve diğer genel katkılar için GitHub, aldığınız iletişimi kolaylaştırmak için oluşturabileceğiniz [Sorun Şablonlarına ve PR İsteği Şablonlarına](https://github.com/blog/2111-issue-and-pull-request-templates) sahiptir. @TalAter sorununuzu ve PR şablonlarınızı yazmanıza yardımcı olmak için [Choose Your Own Adventure](https://www.talater.com/open-source-templates/#/) rehberini geliştirdi. @@ -272,7 +265,7 @@ Tıpkı diğer tüm işlerde olduğu gibi, düzenli molalar vermek de işinizi y avatar WP-CLI’yı geliştirirken, önce kendimi mutlu etmem gerektiğini ve katılımım konusunda net sınırlar koymam gerektiğini keşfettim. Bulduğum en iyi denge, normal çalışma programımın bir parçası olarak haftada 2-5 saat. Bu benim katılımımı bir tutku olarak kalmasını sağlıyor ve iş gibi hissetmekten koruyor. Üzerinde çalıştığım konulara öncelik verdiğim için, en önemli olduğunu düşündüğüm konuda düzenli ilerleme sağlayabiliyorum.

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

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

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

@@ -118,16 +114,16 @@ Herhangi bir popüler proje kaçınılmaz olarak topluluğunuza yardım etmek ye Bu tür insanlara karşı sıfır tolerans politikası benimsemek için elinizden geleni yapın. Denetlenmezse, negatif insanlar topluluğunuzdaki diğer insanları rahatsız eder. Hatta ayrılmalarına sebep olabilirler. Projenizin önemsiz yönleriyle ilgili düzenli tartışmalar, sizin de dahil olmak üzere diğerlerini önemli görevlere odaklanmaktan alıkoyuyor. Projenize gelen yeni insanlar bu konuşmaları görebilir ve katılmak istemeyebilir. -Projenizde olumsuz davranışlar olduğunu gördüğünüzde, herkese açık olarak uyarın. Nazikçe ama sert bir tonda, davranışlarının neden kabul edilebilir olmadığını açıklayın. Sorun devam ederse, [onlardan gitmelerini istemeniz](../code-of-conduct/#davranış-kural-listesini-güçlendirmek) gerekebilir. [Davranış kuralları listeniz](../code-of-conduct/) bu konuşmalar için yapıcı bir rehber olabilir. +Projenizde olumsuz davranışlar olduğunu gördüğünüzde, herkese açık olarak uyarın. Nazikçe ama sert bir tonda, davranışlarının neden kabul edilebilir olmadığını açıklayın. Sorun devam ederse, [onlardan gitmelerini istemeniz](../code-of-conduct/#davran%C4%B1%C5%9F-kurallar%C4%B1n%C4%B1z%C4%B1-g%C3%BC%C3%A7lendirmek) gerekebilir. [Davranış kuralları listeniz](../code-of-conduct/) bu konuşmalar için yapıcı bir rehber olabilir. ### Katkıda bulunan katılımcılarla oldukları yerde tanışın @@ -143,17 +139,17 @@ Son olarak, insanların yolun her aşamasında kendilerini rahat hissetmelerini Projenize ulaşan çoğu insanla asla etkileşime geçemeyeceksiniz. Biri kendini çekingen hissettiği veya nereden başlayacağını bilmediği için almadığınız katkılar olabilir. Birkaç nazik kelime bile, birisinin projenizde hayal kırıklığına uğratmasına engel olabilirsiniz. -Örneğin, [Rubinius](https://github.com/rubinius/rubinius/)[katkıda bulunan kılavuzuna](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md) {a2}şöyle{/a2} başlıyor: +Örneğin, [Rubinius](https://github.com/rubinius/rubinius/)[katkıda bulunan kılavuzuna](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) {a2}şöyle{/a2} başlıyor: > Rubinius'u kullandığınız için teşekkür ederek başlamak istiyoruz. Bu proje bir sevgi emeğidir ve hataları yakalayan, performans iyileştirmeleri yapan ve belgelere yardımcı olan tüm kullanıcıları takdir ediyoruz. Her katkı anlamlıdır, katılımınız için teşekkür ederiz. İşte sorununuzu başarıyla çözebilmemiz için izlemenizi istediğimiz birkaç kural. ### Projenizi paylaşın @@ -165,7 +161,7 @@ Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bul ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) -* Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) yaptığı gibi. +* Projenizde, projenize katkıda bulunan herkesi listeleyen **bir CONTRIBUTORS veya AUTHORS dosyası başlatın**,[Sinatra'nın](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) yaptığı gibi. * Oldukça büyük bir topluluğunuz varsa, **bülten gönderin veya katkıda bulunanlara teşekkür eden bir blog yazısı yazın**. Rust'ın [Rust'ta Bu Hafta](https://this-week-in-rust.org/) ve Hoodie'nin [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) bültenleri iki güzel örnek. @@ -173,7 +169,7 @@ Mülkiyetinizi topluluğunuzla mümkün olduğunca paylaşmanın yollarını bul * Projeniz GitHub'daysa, **projenizi kişisel hesabınızdan bir [Organizasyona](https://help.github.com/articles/creating-a-new-organization-account/) hesabına taşıyın** ve en az bir yedek yönetici ekleyin. Organizasyon hesapları, harici çalışanlarla projeler üzerinde çalışmayı kolaylaştırır. -Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.com/preprints/1233.pdf) bir veya iki geliştirici vardır. Projeniz büyüdükçe ve topluluğunuz büyüdükçe, yardım bulmak o kadar kolay olur. +Gerçek şu ki çoğu projede işlerin çoğunu yapan [yalnızca](https://peerj.com/preprints/1233/) bir veya iki geliştirici vardır. Projeniz büyüdükçe ve topluluğunuz büyüdükçe, yardım bulmak o kadar kolay olur. Çağrıya her zaman cevap verecek birini bulamayacak olsanız da, bir mesaj bırakmak, diğer kişilerin girme şansını arttırır. @@ -197,13 +193,13 @@ Projeniz popülerleştikçe, aldığınız kararlara daha fazla insan ilgi göst Topluluğunuz zor bir mesele ile boğuşurken, tansiyon artabilir. İnsanlar sinirlenebilir veya öfkelenebilir ve birbirlerine ya da size yönelebilirler. -Bir proje sorumlusu olarak işiniz, bu durumların tırmanmasını önlemektir. Konuyla ilgili güçlü bir fikriniz olsa bile, kavgaya atılmak ve görüşlerinizi dayatmak yerine, moderatör veya kolaylaştırıcı olarak yer almaya çalışın. Birisi kaba veya tartışmacı davranıyorsa, tartışmaları medeni ve üretken kılmak için [hemen harekete](../building-community/#kötü-karakterlere-müsamaha-göstermeyin) geçin. +Bir proje sorumlusu olarak işiniz, bu durumların tırmanmasını önlemektir. Konuyla ilgili güçlü bir fikriniz olsa bile, kavgaya atılmak ve görüşlerinizi dayatmak yerine, moderatör veya kolaylaştırıcı olarak yer almaya çalışın. Birisi kaba veya tartışmacı davranıyorsa, tartışmaları medeni ve üretken kılmak için [hemen harekete](../building-community/#k%C3%B6t%C3%BC-karakterlere-m%C3%BCsamaha-g%C3%B6stermeyin) geçin. @@ -226,10 +222,10 @@ Bazen oy vermek gerekli bir sonlandırıcıdır. Ancak, mümkün olduğu kadar, Bir uzlaşma arayışı sürecinde, topluluk üyeleri yeterince duyulduğunu hissedene kadar önemli endişelerini tartışırlar. Sadece küçük kaygılar kalırsa, topluluk ileriye doğru hareket eder. "Uzlaşma arayışı", bir topluluğun mükemmel bir cevaba ulaşamayabileceğini kabul eder. Bunun yerine, dinlemeye ve tartışmaya öncelik verir. @@ -252,8 +248,8 @@ Konuşma çözülmeye ulaştıysa, sohbeti yeniden odaklamak için gruba _"Bunda Bir konuşma açıkça bir yere gitmiyorsa, yapılacak net bir işlem yoksa veya uygun bir işlem yapılmamışsa, sorunu kapatın ve neden kapattığınızı açıklayın. @@ -150,14 +143,6 @@ Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projeler Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir. - - ## Devam et! İnsanların açık kaynaklı projenizi fark etmesi uzun zaman alabilir. Sorun yok! Bugün en popüler projelerden bazılarının yüksek düzeyde faaliyet göstermesi yıllar aldı. Projenizin kendiliğinden popülerlik kazanacağını ummak yerine ilişkiler kurmaya odaklanın. Sabırlı olun ve çalışmanızı takdir edenlerle paylaşmaya devam edin. diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md index 9ee1f837a2f..f46ae1ed6b8 100644 --- a/_articles/tr/getting-paid.md +++ b/_articles/tr/getting-paid.md @@ -3,16 +3,11 @@ lang: tr title: Açık Kaynak Çalışmalar İçin Ödeme Alma description: Zamanınız veya projeniz için maddi destek alarak açık kaynak çabanızı sürdürün. class: getting-paid -toc: - why-some-people-seek-financial-support: Neden bazı insanlar finansal destek ister? - funding-your-own-time: Kendi zamanınızı fonlamak - finding-funding-for-your-project: Projeniz için finansman bulma - building-a-case-for-financial-support: Finansal destek için bir süreç oluşturma order: 7 -image: "/assets/images/cards/getting-paid.png" +image: /assets/images/cards/getting-paid.png related: - - best-practices - - leadership +- best-practices +- leadership --- ## Neden bazı insanlar finansal destek ister? @@ -71,14 +66,6 @@ Bugün, birçok insana yarı zamanlı veya tam zamanlı olarak açık kaynak üz Eğer işvereniniz projeyi gerçekten kullanıyorsa, işiniz daha kolay, ancak adımınızda yaratıcı olun. Belki işvereniniz projeyi kullanmaz, ancak Python'u kullanır ve popüler bir Python projesini sürdürmek yeni Python geliştiricilerini çekmeye yardımcı olur. Belki işvereninizin genel olarak geliştirici dostu görünmesini sağlar. - - Üzerinde çalışmak istediğiniz bir açık kaynak projeniz yoksa, ancak mevcut iş çıktınızın açık kaynaklı olmasını tercih ederseniz, işvereninizin kendi iç yazılımlarının bir kısmının kaynağını açması için bir öneride bulunun. Birçok şirket markalarını geliştirmek ve kaliteli yetenekler kazanmak için açık kaynaklı programlar geliştiriyor. @@ -106,12 +93,13 @@ Mevcut işvereninizi açık kaynak çalışmasına öncelik vermeye ikna edemiyo Kişisel durumunuza bağlı olarak, açık kaynaklı işinize para yatırmak için bağımsız olarak para toplamayı deneyebilirsiniz. Örneğin: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon, [Redux](https://github.com/reactjs/redux) ile ilgili çalışmalarını bir [Patreon kitlesel fonlama kampanyası](https://redux.js.org/) yoluyla finanse etti * @andrewgodwin [, bir Kickstarter kampanyasıyla](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) Django şema göçleri konusundaki çalışmaları finanse etti Son olarak, bazen açık kaynaklı projeler, yardım etmeyi düşündüğünüz meselelere güçlükler getirir. -* @ConnorChristie, @MARKETProtocol'un javascript paketlerinde [yardımcı olarak](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) gitcoin'deki bir [ödülle{/a2} para kazanabildi.](https://gitcoin.co/) +* @ConnorChristie, @MARKETProtocol'un JavaScript paketlerinde [yardımcı olarak](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) gitcoin'deki bir [ödülle{/a2} para kazanabildi.](https://gitcoin.co/) * @mamiM, [sorun Bounties Network'te finanse](https://explorer.bounties.network/bounty/134) edildikten sonra @MetaMask için Japonca çeviriler yaptı. ## Projeniz için finansman bulma @@ -124,11 +112,9 @@ Açık kaynağın popülaritesi arttıkça, projelere fon bulmak için hala dene ### Topluluk fonlama kampanyaları veya sponsorluklarıyla işiniz için para toplayın -Sponsorluk bulmak, zaten güçlü bir kitleye veya şöhrete sahipseniz veya projeniz çok popülerse işe yarar. -Sponsorlu projelere birkaç örnek: +Sponsorluk bulmak, zaten güçlü bir kitleye veya şöhrete sahipseniz veya projeniz çok popülerse işe yarar. Sponsorlu projelere birkaç örnek: * **[webpack](https://github.com/webpack)** [OpenCollective](https://opencollective.com/webpack) üzerinden şirketler ve bireylerden para topladı -* **[Vue](https://github.com/vuejs/vue)** [Patreon aracılığıyla finanse edilmektedir](https://github.com/open-source/stories/yyx990803) * **[Ruby Together](https://rubytogether.org/) ,** [paketleyici](https://github.com/bundler/bundler) , [RubyGems](https://github.com/rubygems/rubygems) ve diğer Ruby altyapı projelerinde işe yarayan kar amacı gütmeyen bir organizasyon ### Bir gelir akışı oluşturun @@ -139,7 +125,7 @@ Projenize bağlı olarak, ticari destek, barındırılan seçenekler veya ek öz * **[Travis CI](https://github.com/travis-ci)** ürünlerinin ücretli sürümlerini sunuyor * **[Ghost](https://github.com/TryGhost/Ghost)** ücretli bir yönetim servisi olan kar amacı gütmeyen bir kurumdur. -[Npm](https://github.com/npm/npm) ve [Docker](https://github.com/docker/docker) gibi bazı popüler projeler iş büyümelerini desteklemek için risk sermayesini desteği arıyorlar. +[Npm](https://github.com/npm/cli) ve [Docker](https://github.com/docker/docker) gibi bazı popüler projeler iş büyümelerini desteklemek için risk sermayesini desteği arıyorlar. ### Hibe fonu için başvur @@ -152,7 +138,7 @@ Bazı yazılım kurumları ve şirketleri açık kaynak kodlu çalışmalar içi Daha ayrıntılı seçenekleri ve vaka çalışmaları için, açık kaynak çalışmalarına finansman bulma için @nayafia [bir rehber yazdı](https://github.com/nayafia/lemonade-stand). Farklı finansman türleri farklı beceriler gerektirir, bu nedenle hangi seçeneğin sizin için en uygun olduğunu bulmak için güçlü yönlerinizi değerlendirin. -## Finansal destek için bir yapı oluşturma +## Finansal destek için bir süreç oluşturma Projeniz yeni bir fikir olsun ya da yıllardır sürüyor olsun, hedef kitlenizi belirlemek ve teşvik edici bir öneri oluşturmak için kafa yormalısınız. @@ -189,5 +175,3 @@ Fon verenin ödeme çevresinde herhangi bir şartı var mı? Örneğin, kar amac ## Denemeyin ve pes etmeyin Açık kaynak kodlu bir proje, kar amacı gütmeyen veya bir yazılım başlangıcı olsanız da, para kazanmak kolay değildir ve çoğu durumda yaratıcı olmanızı gerektirir. Nasıl ödeme almak istediğinizi belirlemek, araştırmanızı yapmak ve kendinizi fon sağlayıcınızın yerine koymak, finansman için ikna edici bir durum oluşturmanıza yardımcı olacaktır. - -> diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index 38dde831d15..c6fc1f3f498 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -1,15 +1,8 @@ --- lang: tr title: Açık Kaynağa Nasıl Katkıda Bulunulur -description: Açık kaynağa katkıda bulunmak ister misiniz? İlk defa yapanlar ve tecrübeliler için katkı yapma rehberi. +description: Açık kaynağa katkıda bulunmak ister misiniz? İlk defa yapacaklar ve tecrübeliler için katkı yapma rehberi. class: contribute -toc: - why-contribute-to-open-source: Açık kaynağa neden katkıda bulunmalıyım? - what-it-means-to-contribute: Katkıda bulunmak ne demektir? - orienting-yourself-to-a-new-project: Kendinizi yeni bir projeye yönlendirmek - finding-a-project-to-contribute-to: Katkıda bulunacak bir proje bulma - how-to-submit-a-contribution: Nasıl katkı yapılır? - what-happens-after-you-submit-a-contribution: Bir katkı gönderdikten sonra ne olur? order: 1 image: "/assets/images/cards/contribute.png" related: @@ -20,24 +13,24 @@ related: ## Açık kaynağa neden katkıda bulunmalıyım? Açık kaynağa katkıda bulunmak, hayal edebileceğiniz herhangi bir konuyu öğrenmek, öğretmek ve deneyim geliştirmek için faydalı bir yol olabilir. -İnsanlar neden açık kaynağa katkıda bulunur? Bunun biir sürü sebep vardır! +İnsanlar neden açık kaynağa katkıda bulunur? Bunun bir sürü sebebi vardır! ### Güvendiğiniz yazılımı geliştirme -Açık kaynak projelere katkıda bulunanların birçoğu projeyle kullanıcısı olarak tanışırlar. Kullandığınız açık kaynaklı bir yazılımda bir hata bulduğunuzda, kendiniz yamalayıp düzeltip düzeltemeyeceğiniz görmek için kaynağa bakmak isteyebilirsiniz. Bu durumda, yamanın yapılmasına katkıda bulunmak, arkadaşlarınızın (ve bir sonraki sürüme geçtiğinizde kendinizin de) bundan faydalanmasını sağlamak için en iyi yoldur. +Açık kaynak projelere katkıda bulunanların birçoğu projeyle kullanıcısı olarak tanışırlar. Kullandığınız açık kaynak bir yazılımda bir hata bulduğunuzda, kendiniz yamalayıp düzeltip düzeltemeyeceğiniz görmek için kaynağa bakmak isteyebilirsiniz. Bu durumda, yamanın yapılmasına katkıda bulunmak, arkadaşlarınızın (ve bir sonraki sürüme geçtiğinizde kendinizin de) bundan faydalanmasını sağlamak için en iyi yoldur. ### Mevcut becerileri geliştirme -Kodlama, kullanıcı arayüzü tasarımı, grafik tasarımı, yazma veya düzenleme, pratik arıyorsanız, açık kaynak kodlu herhangi bir projede sizin için mutlaka bir görev vardır. +Kodlama, kullanıcı arayüzü tasarımı, grafik tasarımı, yazma veya düzenleme gibi konularda pratik arıyorsanız, herhangi bir açık kaynak projede sizin için mutlaka bir görev vardır. ### Benzer şeylerle ilgilenen insanlarla tanışma @@ -79,14 +72,6 @@ Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak ka Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir. - - ### Etkinlik planlamayı sever misiniz? * [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin @@ -103,9 +88,9 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d ### Yazmayı sever misin? * Proje dokümantasyonunu yazın ve geliştirin -* Projenin nasıl kullanıldığını gösteren bir örnek klasör oluşturun +* Projenin nasıl kullanıldığını gösteren örnekler oluşturun * Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın -* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın +* [PyPA'nın katılımcılarının yaptığı gibi](https://packaging.python.org/) proje için dersler yazın * Projenin dokümantasyonu için çeviri yapın -Bir yazım hatası düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. +Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. -Kendi önerilerinizle kör bir şekilde atlamadan önce, odanın nasıl okunacağını öğrenmeye başlayın. Bunu yapmak, fikirlerinizi fark etme ve duyma şansınızı arttırır. +Kendi önerilerinizle kör bir şekilde atlamadan önce, odanın neler konuştuğunu öğrenmekle başlayın. Bunu yapmak, fikirlerinizi fark ettirme ve duyurma şansınızı arttırır. ### Açık kaynak kodlu bir projenin anatomisi @@ -189,22 +174,22 @@ Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin * **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. * **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. -* **CONTRIBUTING** README dosyaları projeyi insanların _kullanmalarına_ yardımcı olurken, katkı dökümanları insanların projeye _katkıda_ bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. +* **CONTRIBUTING:** README dosyaları projeyi insanların _kullanmalarına_ yardımcı olurken, CONTRIBUTING dökümanları insanların projeye _katkıda_ bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. * **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. * **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir. * **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. -* **PR (Çekme) istekleri:** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. -* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine _"Nasıl? ..."_ veya _"Ne düşünüyorsunuz ..." gibi_). Diğerleri, tüm konuşmalar için sorun takipçisi kullanır. -* **Anlık sohbet kanalı:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. +* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. +* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine _"Nasıl ...?"_ veya _"Ne düşünüyorsunuz ...?" gibi_). Diğerleri, tüm konuşmalar için sorun listesini kullanır. +* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. ## Katkıda bulunacak bir proje bulma Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı! -Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, _"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"_ diyen ABD Başkanı John F. Kennedy'yi örnek alın. +Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, _"Ülkenizin sizin için neler yapabileceğini değil, ülkeniz için neler yapabileceğinizi sorun"_ diyen ABD Başkanı John F. Kennedy'yi örnek alın. Açık kaynağa katkıda bulunmak, farklı projelerde her seviyede gerçekleşir. İlk katkınızın tam olarak ne olacağını veya nasıl görüneceğini düşünmeniz gerekmez. @@ -228,11 +213,10 @@ Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aş * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) * [Up For Grabs](https://up-for-grabs.net/) -* [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) -### Katkıda bulunmadan önce üzerinden geçilebilcek bir kontrol listesi +### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kabul etmeye uygun olduğundan emin olmak için hızlı bir tarama yapın. Aksi takdirde, sıkı çalışmanız asla bir yanıt alamayabilirsiniz. @@ -243,7 +227,7 @@ Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kab
@@ -254,21 +238,21 @@ Ana daldaki geliştirici faaliyetine bakın. GitHub'da, bu bilgiyi bir kütüpha
+ Projenin kaç katılımcısı var? +
@@ -277,35 +261,35 @@ Ardından, projenin sorun listesine bakın.
@@ -314,14 +298,14 @@ Ardından, projenin sorun listesine bakın.
@@ -386,7 +370,7 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac

-## Katkı nasıl gönderilir? +## Nasıl katkı yapılır? Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonunda! İşte katkınızı doğru şekilde yapmanın yolu. @@ -408,13 +392,13 @@ Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan > 😇 _"Y yaptığımda X olmuyor"_ > -> X _"X çalışmıyor! Lütfen düzeltin."_ +> 😢 _"X çalışmıyor! Lütfen düzeltin."_ **Ödevini önceden yap.** Bir şeyleri bilmemek normaldir, ama denediğini göster. Yardım istemeden önce, bir projenin README'sini, belgelerini, sorun listesini (açık veya kapalı), e-posta listesini kontrol ettiğinizden ve bir cevap için interneti aradığınızdan emin olun. Öğrenmeye çalıştığını gösterdiğin zaman insanlar takdir edeceklerdir. -> X _"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."_ +> 😇 _"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."_ > -> 😢 _"X nasıl yapılır?"_ +> 😢 "X nasıl yapılır?" **İstekleri kısa ve öz tutun.** Bir e-posta göndermek gibi, ne kadar basit veya yararlı olursa olsun, her katkı başkasının incelemesini gerektirir. Birçok projenin, yardım için uygunların yapabileceklerinden daha fazla gelen talebi olur. Basit olun. Birinin size yardım edebilme şansını artıracaksınız. @@ -506,7 +490,7 @@ Katkınızı gönderdikten sonra, aşağıdakilerden biri olacaktır: ### 😭 Hiç bir cevap almazsınız. -Umarım bir katkı yapmadan önce [projeyi faaliyet belirtileri açısından kontrol](#katkıda-bulunmadan-önce-üzerinden-geçilebilcek-bir-kontrol-listesi) ettiniz. Ancak aktif bir projede bile, katkınızın yanıt alamaması olası. +Umarım bir katkı yapmadan önce [projeyi faaliyet belirtileri açısından kontrol](#katk%C4%B1da-bulunmadan-%C3%B6nce-%C3%BCzerinden-ge%C3%A7ilebilecek-bir-kontrol-listesi) ettiniz. Ancak aktif bir projede bile, katkınızın yanıt alamaması olası. Bir haftadan uzun bir süredir yanıt alamadıysanız, aynı konuya kibarca yorum yazmak, birinden inceleme istemek doğru olur. Katkınızı gözden geçirecek doğru kişinin adını biliyorsanız, bunları o konuya ekleyebilirsiniz (@). diff --git a/_articles/tr/index.html b/_articles/tr/index.html index fbec4f5f3f5..12cf403b695 100644 --- a/_articles/tr/index.html +++ b/_articles/tr/index.html @@ -1,6 +1,6 @@ --- layout: index lang: tr -title: Açık kaynak rehberleri +title: Açık Kaynak Rehberleri permalink: /tr/ --- diff --git a/_articles/tr/leadership-and-governance.md b/_articles/tr/leadership-and-governance.md index b0425577a83..2644b379a7c 100644 --- a/_articles/tr/leadership-and-governance.md +++ b/_articles/tr/leadership-and-governance.md @@ -3,15 +3,6 @@ lang: tr title: Liderlik ve Yönetim description: Büyüyen açık kaynak projeleri, karar almak için resmi kurallardan yararlanabilir. class: leadership -toc: - understanding-governance-for-your-growing-project: Büyüyen projeniz için yönetimi anlama - what-are-examples-of-formal-roles-used-in-open-source-projects: Açık kaynak projelerde kullanılan resmi rol türleri nelerdir? - how-do-i-formalize-these-leadership-roles: Bu liderlik rollerini nasıl formalize ederim? - when-should-i-give-someone-commit-access: Ne zaman birine commit izni vermeliyim? - what-are-some-of-the-common-governance-structures-for-open-source-projects: Açık kaynaklı projeler için ortak yönetim yapılarının bazıları nelerdir? - do-i-need-governance-docs-when-i-launch-my-project: Projemi başlattığımda yönetim belgelerine ihtiyacım var mı? - what-happens-if-corporate-employees-start-submitting-contributions: Şirket çalışanları katkı göndermeye başlarsa ne olur? - do-i-need-a-legal-entity-to-support-my-project: Projemi desteklemek için tüzel kişiliğe ihtiyacım var mı? order: 6 image: "/assets/images/cards/leadership.png" related: @@ -72,11 +63,11 @@ Projeniz çok aktif bir katılımcı topluluğa sahipse, farklı konu alanların -Liderlik ekipleri projeyi tartışmak için (Gitter veya Google Hangout'ta olduğu gibi) belirlenmiş bir kanal oluşturmak (IRC'deki gibi) veya düzenli olarak buluşmak isteyebilir. Hatta başkalarının dinleyebilmesi için bu toplantıları halka açabilirsiniz. Örneğin [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) [her hafta çalışma saatlerinde yayın yapar](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs) . +Liderlik ekipleri projeyi tartışmak için (Gitter veya Google Hangout'ta olduğu gibi) belirlenmiş bir kanal oluşturmak (IRC'deki gibi) veya düzenli olarak buluşmak isteyebilir. Hatta başkalarının dinleyebilmesi için bu toplantıları halka açabilirsiniz. Örneğin [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) [her hafta çalışma saatlerinde yayın yapar](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs) . Liderlik rolleri belirledikten sonra, insanların onlara nasıl ulaşabileceğini belgelemeyi unutmayın! Projenizde birisinin nasıl sorumlu olabileceği ya da bir alt komiteye katılabileceği konusunda net bir süreç belirleyin ve bunu GOVERNANCE.md'inize yazın. diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md index 7532bf3ca57..cf9aa183e2c 100644 --- a/_articles/tr/legal.md +++ b/_articles/tr/legal.md @@ -3,19 +3,11 @@ 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 -toc: - why-do-people-care-so-much-about-the-legal-side-of-open-source: İnsanlar neden açık kaynağın yasal tarafını bu kadar önemsiyorlar? - are-public-github-projects-open-source: Açık GitHub projeleri açık kaynak mı? - just-give-me-the-tldr-on-what-i-need-to-protect-my-project: Sadece bana projemi korumak için ihtiyacım olan karışık metni verin. - which-open-source-license-is-appropriate-for-my-project: Projem için hangi açık kaynak lisansı uygundur? - what-if-i-want-to-change-the-license-of-my-project: Projemin lisansını değiştirmek istersem ne olur? - does-my-project-need-an-additional-contributor-agreement: Projemin ek bir katkı sözleşmesine ihtiyacı var mı? - irketimin-hukuk-ekibinin-neleri-bilmesi-gerekiyor: Şirketimin hukuk ekibinin neleri bilmesi gerekiyor? order: 10 -image: "/assets/images/cards/legal.png" +image: /assets/images/cards/legal.png related: - - contribute - - leadership +- contribute +- leadership --- ## Açık kaynağın yasal etkilerini anlama @@ -40,7 +32,7 @@ GitHub'da [yeni bir proje oluşturduğunuzda](https://help.github.com/articles/c ![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://help.github.com/en/github/site-policy/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. +**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. @@ -56,7 +48,7 @@ GitHub'da yeni bir proje oluşturduğunuzda sizden [bir lisans eklemeniz istenir avatar Standartlaştırılmış bir lisans, yasal eğitim almayanların yazılımla neler yapabileceklerini ve yapamadıklarını tam olarak bilmeleri için bir vekil olarak hizmet eder. Kesinlikle gerekli olmadıkça, ajans kodunun akış aşağı kullanımına engel teşkil edecek özel, değiştirilmiş veya standart olmayan terimlerden kaçının.

-- @benbalter, ["Bir devlet avukatının açık kaynaklı yazılım lisanslama hakkında bilmesi gereken her şey"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/) +— @benbalter, ["Bir devlet avukatının açık kaynaklı yazılım lisanslama hakkında bilmesi gereken her şey"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)

@@ -106,16 +98,17 @@ Ayrıca, bazılarının gereksiz olduğuna, anlaşılmasının zor veya haksız avatar Node.js için CLA'yı kaldırdık. Bunu yapmak, Node.js katılımcısı için giriş engelini azalttı ve böylece katılımcı tabanını genişletti.

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

Projeniz için ek bir katılımcı sözleşmesi düşünmek isteyebileceğiniz bazı durumlar şunlardır: -* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!) tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir. +* Avukatlarınız açık kaynak lisanslarını yeterli bulmadıklarından (öyle olsa bile!) tüm katılımcıları katılımcı sözleşmelerimi açıkça kabul etmek (çevrimiçi veya çevrimdışı _işaretlemelerini_) isteyebilir. Bu tek endişe ise, projenin açık kaynaklı lisansını onaylayan bir katılımcı sözleşmesi yeterli olmalıdır. [JQuery Bireysel Katılımcı Lisans Sözleşmesi](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/), hafif bir ek katılımcı sözleşmesi için iyi bir örnektir. Bazı projeler için, [Developer Certificate of Origin](https://github.com/probot/dco) alternatif olabilir. * Projeniz, açık bir patent hibesi (MIT gibi) içermeyen bir açık kaynak lisansı kullanıyor ve bazıları sizi hedeflemek için kullanılabilecek büyük patent portföyleri olan şirketler için çalışabilecek tüm katılımcılardan bir patent hibesine ihtiyacınız var. [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) Apache License 2.0. lisansında bulunan ve çokça kullanılan bir katılımcı sözleşmesidir. * Projeniz bir copyleft lisansı altında, ancak aynı zamanda projenin tescilli bir versiyonunu da dağıtmanız gerekiyor. Size telif hakkı veren veya size (ancak halka değil) izin veren bir lisans veren her katılımcıya ihtiyacınız olacaktır. [MongoDB Katılımcı Anlaşması](https://www.mongodb.com/legal/contributor-agreement) bu tür bir anlaşma örneğidir. * Projenizin ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmesini isteyebileceğinizi düşünüyorsunuz. +* Projenizin kullanım ömrü boyunca lisansları değiştirmesi gerekebileceğini ve katkıda bulunanların bu tür değişiklikleri önceden kabul etmelerini isteyebilirsiniz. Projeniz için ek bir katılımcı sözleşmesi kullanmanız gerekiyorsa, katılımcıların dikkatini dağıtmayı en aza indirmek için [CLA yardımcısı](https://github.com/cla-assistant/cla-assistant) gibi bir entegrasyon kullanmayı düşünün. @@ -133,7 +126,7 @@ Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi d * **Patentler:** Şirketiniz, projenizin açık kaynak kodlu bir şekilde [kamuya açıklanmasını](https://en.wikipedia.org/wiki/Public_disclosure) sağlayacak bir patent başvurusu yapıyor mu? Ne yazık ki beklemeniz istenebilir (veya şirketten, uygulamanın bilgeliğini yeniden gözden geçirir). Projenize büyük patent portföyüne sahip şirketlerin çalışanlarından katkıda bulunmayı bekliyorsanız, yasal ekibiniz katkıda bulunanlardan (Apache 2.0 veya GPLv3 gibi) açık bir patent ödeneği olan bir lisans veya ek bir katılımcı sözleşmesini ( yukarıyı bakın) kullanmanızı isteyebilir. -* **Ticari Markalar:** Projenizin adının [mevcut hiçbir ticari marka ile çakışmadığından](../starting-a-project/#i̇sim-çatışmalarından-kaçınmak) emin olun. Projede kendi şirket ticari markalarınızı kullanıyorsanız, herhangi bir anlaşmazlık yaratmadığını kontrol edin. [FOSSmarks](http://fossmarks.org/) , markaları ücretsiz ve açık kaynaklı projeler bağlamında anlamak için pratik bir rehberdir. +* **Ticari Markalar:** Projenizin adının [mevcut hiçbir ticari marka ile çakışmadığından](../starting-a-project/#benzersiz-isim-bulmak) emin olun. Projede kendi şirket ticari markalarınızı kullanıyorsanız, herhangi bir anlaşmazlık yaratmadığını kontrol edin. [FOSSmarks](http://fossmarks.org/) , markaları ücretsiz ve açık kaynaklı projeler bağlamında anlamak için pratik bir rehberdir. * **Gizlilik:** Projeniz kullanıcılar hakkında veri topluyor mu? Şirket sunucularına "bağlanıyor" mu? Hukuk ekibiniz şirket politikalarına ve dış düzenlemelere uymanıza yardımcı olabilir. @@ -141,25 +134,25 @@ Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi d Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından daha fazlasını elde etmesi ve güvende kalması için daha fazlasını yapabilir: -* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır. +* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)'dır. * **Neyi yayınlama:** [(Neredeyse) her şey?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Eğer yasal ekibiniz şirketinizin açık kaynaklı stratejisini anlıyor ve yatırım yapıyorsa, çabalarınızı engellemekten ziyade en iyi şekilde yardım edebileceklerdir. -* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir. +* **Uyumluluk:** Şirketiniz herhangi bir açık kaynaklı proje yayınlamamış olsa bile, başkalarının açık kaynaklı yazılımını kullanır. [Farkındalık ve süreç](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) baş ağrısını, ürün gecikmelerini ve davaları önleyebilir. * **Patentler:** Şirketiniz, üyelerin büyük açık kaynaklı projeleri kullanmalarını korumak için ortak bir savunma patenti havuzu olan [Açık Buluşma Ağı](https://www.openinventionnetwork.com/)'na katılmak veya başka bir [alternatif patent lisansını](https://www.eff.org/document/hacking-patent-system-2016) keşfetmek isteyebilir. -* **Yönetişim:** Özellikle bir projeyi [şirket dışındaki](../leadership-and-governance/#projemi-desteklemek-için-tüzel-kişiliğe-ihtiyacım-var-mı) bir {a2}tüzel kişiliğe{/a2} taşımanın ne zaman anlamlı olacağı. +* **Yönetişim:** Özellikle bir projeyi [şirket dışındaki](../leadership-and-governance/#projemi-desteklemek-i%C3%A7in-t%C3%BCzel-ki%C5%9Fili%C4%9Fe-ihtiyac%C4%B1m-var-m%C4%B1) bir {a2}tüzel kişiliğe{/a2} taşımanın ne zaman anlamlı olacağı. diff --git a/_articles/tr/maintaining-balance-for-open-source-maintainers.md b/_articles/tr/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..1ac42c3058c --- /dev/null +++ b/_articles/tr/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,220 @@ +--- +lang: tr +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/browse11/l-m/en#/http://id.who.int/icd/entity/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://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid +* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) 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/tr/metrics.md b/_articles/tr/metrics.md index e77b511c247..753ff7060fd 100644 --- a/_articles/tr/metrics.md +++ b/_articles/tr/metrics.md @@ -3,12 +3,6 @@ lang: tr title: Açık Kaynak Ölçümleri description: Açık kaynaklı projenizin başarısını ölçüp izleyerek gelişmesine yardımcı olmak için bilinçli kararlar alın. class: metrics -toc: - why-measure-anything: Neden her şeyi ölçmeli? - discovery: Keşif - usage: Kullanım - retention: Akılda tutma - maintainer-activity: Geliştirici etkinliği order: 9 image: "/assets/images/cards/metrics.png" related: diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index 15b0df93311..1f19b0efcf1 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -1,14 +1,8 @@ --- lang: tr title: Açık Kaynaklı bir Projeye Başlamak -description: Açık kaynak dünyası hakkında daha fazla bilgi edinin ve kendi projenizi başlatmaya hazır olun. +description: Açık kaynak dünyası hakkında daha fazla bilgi edinin ve kendinizi proje başlatmaya hazırlayın. class: beginners -toc: - the-what-and-why-of-open-source: Açık kaynağın nediri ve nedeni - should-i-launch-my-own-open-source-project: Kendi açık kaynak projemi başlatmalı mıyım? - launching-your-own-open-source-project: Kendi açık kaynak projenizi başlatmak - naming-and-branding-your-project: Projenizi isimlendirme ve markalama - your-pre-launch-checklist: Lansman öncesi kontrol listeniz order: 2 image: "/assets/images/cards/beginner.png" related: @@ -24,16 +18,9 @@ Yani açık kaynak kodlu bir projeye başlamayı mı düşünüyorsun? Tebrikler Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için projenizi görüntüleyebilir, kullanabilir, değiştirebilir ve dağıtabilir.** Bu izinler [açık kaynaklı bir lisans](https://opensource.org/licenses) aracılığıyla uygulanmaktadır. -Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. +Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir. -Nasıl çalıştığını anlamak için, arkadaşınızın herkes yemek getirsin partisi verdiğini hayal edin ve vişneli turta götürmüşsünüz. - -* Herkes turta yemek istedi (_kullanma_) -* Turta çok popüler oldu! Sizden tarifi isterler (_görüntüleme_) -* Bir arkadaşın, pasta şefi Alex şekeri azaltmayı önerir (_değiştirme_) -* Başka bir arkadaş, Lisa gelecek hafta bir akşam yemeği için kullanmak istiyor (_dağıtma_) - -Buna karşılık, kapalı kaynak işlemi bir restorana gidip bir dilim vişneli turta siparişi vermek gibidir. Pasta yemek için bir ücret ödemeniz gerekir ve restoran muhtemelen size tariflerini vermez. Pastalarını aynen kopyalayıp kendi adınızla satarsanız, restoran size karşı dava açabilir. +_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. _Free_ ve _Libre_ özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor). ### İnsanlar neden işlerini açık kaynak olarak sunarlar? @@ -41,67 +28,67 @@ Buna karşılık, kapalı kaynak işlemi bir restorana gidip bir dilim vişneli avatar Açık kaynak kullanmaktan ve işbirliği yapmaktan kazandığım en değerli deneyimlerden biri, aynı problemlerle karşı karşıya kalan diğer geliştiricilerle kurduğum ilişkilerden geliyor.

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

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

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

diff --git a/_articles/zh-hant/code-of-conduct.md b/_articles/zh-hant/code-of-conduct.md index 22f76d3c878..d92260bbebf 100644 --- a/_articles/zh-hant/code-of-conduct.md +++ b/_articles/zh-hant/code-of-conduct.md @@ -32,7 +32,7 @@ redirect_from: /zh-tw/code-of-conduct/ 無論你們在哪裏，請使用已有的行爲守則。[貢獻者盟約](http://contributor-covenant.org/)是一個被超過40，000個開源專案（包括Kubernetes, Rails和Swift）所使用的行爲守則。 -[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](http://citizencodeofconduct.org/)都是非常好的行爲守則。 +[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)都是非常好的行爲守則。 請將CODE_OF_CONDUCT文件放在你們專案的根目錄，並在README中附上其鏈接，這樣對你們的社群是可見的。 @@ -41,7 +41,7 @@ redirect_from: /zh-tw/code-of-conduct/ @@ -55,7 +55,7 @@ redirect_from: /zh-tw/code-of-conduct/ 你們可以給大家一個私有的渠道（如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科學技術中心。 @@ -71,7 +71,7 @@ redirect_from: /zh-tw/code-of-conduct/ 有的社群成員可能是讓大家一直不舒服的慣犯，或者他們只是說了或做了一次。這都需要依據實際情況進行處理。 -在你們做出迴應之前，請認真思考發生了什麼事。通過閱讀他們過去的評論和對話可以更好地理解他們爲什麼要那樣做。儘量收集其他人對他們行爲的看法。 +在你們做出回應之前，請認真思考發生了什麼事。通過閱讀他們過去的評論和對話可以更好地理解他們爲什麼要那樣做。儘量收集其他人對他們行爲的看法。