From ead79b71d10b9ab6fd2fabdad1ecbfa52ffcea03 Mon Sep 17 00:00:00 2001 From: Frazer Smith <43814140+Fdawgs@users.noreply.github.com> Date: Wed, 24 Feb 2021 08:33:00 +0000 Subject: [PATCH 001/770] Add GitHub Actions to Dependabot config Dependabot has the ability to keep GitHub Actions used in `.github/workflows` up to date. See https://docs.github.com/en/github/administering-a-repository/keeping-your-actions-up-to-date-with-dependabot#example-dependabotyml-file-for-github-actions --- .github/dependabot.yml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 449976a6090..9417d2257f5 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -10,6 +10,16 @@ updates: separator: "-" open-pull-requests-limit: 99 rebase-strategy: disabled +- package-ecosystem: github-actions + directory: "/" + schedule: + interval: daily + time: "10:00" + timezone: Europe/Vienna + pull-request-branch-name: + separator: "-" + open-pull-requests-limit: 99 + rebase-strategy: disabled - package-ecosystem: npm directory: "/" schedule: From 528b5ed56a251f274cfbc596346bae8d53f93728 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 9 Mar 2021 19:54:23 +0000 Subject: [PATCH 002/770] Bump actions/cache from v1 to v2.1.4 Bumps [actions/cache](https://github.com/actions/cache) from v1 to v2.1.4. - [Release notes](https://github.com/actions/cache/releases) - [Commits](https://github.com/actions/cache/compare/v1...26968a09c0ea4f3e233fdddbafd1166051a095f6) Signed-off-by: dependabot[bot] --- .github/workflows/tests.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 401cc70771b..306ebe29798 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -17,7 +17,7 @@ jobs: uses: actions/setup-node@v1 - name: Restore bundler cache - uses: actions/cache@v1 + uses: actions/cache@v2.1.4 with: path: vendor/gems key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }} From cb0c16de17a5058d18476a1d75ef99f525bada61 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 9 Mar 2021 19:54:24 +0000 Subject: [PATCH 003/770] Bump actions/checkout from v1 to v2.3.4 Bumps [actions/checkout](https://github.com/actions/checkout) from v1 to v2.3.4. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/v1...5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f) Signed-off-by: dependabot[bot] --- .github/workflows/tests.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 401cc70771b..5c2940eecf3 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -8,7 +8,7 @@ jobs: runs-on: ubuntu-latest steps: - name: Set up Git repository - uses: actions/checkout@v1 + uses: actions/checkout@v2.3.4 - name: Set up Ruby uses: actions/setup-ruby@v1 From 3189010cabfaa6c6b430eb345d612b2dca772ec4 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 9 Mar 2021 19:54:36 +0000 Subject: [PATCH 004/770] Bump actions/setup-node from v1 to v2.1.5 Bumps [actions/setup-node](https://github.com/actions/setup-node) from v1 to v2.1.5. - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](https://github.com/actions/setup-node/compare/v1...46071b5c7a2e0c34e49c3cb8a0e792e86e18d5ea) Signed-off-by: dependabot[bot] --- .github/workflows/tests.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 401cc70771b..6a391a626f7 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -14,7 +14,7 @@ jobs: uses: actions/setup-ruby@v1 - name: Set up Node - uses: actions/setup-node@v1 + uses: actions/setup-node@v2.1.5 - name: Restore bundler cache uses: actions/cache@v1 From 0fd9c7358098c42cb113e627826247224e0bf85f Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Wed, 10 Mar 2021 09:05:42 +0000 Subject: [PATCH 005/770] Bump html-proofer from 3.18.6 to 3.18.8 Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.18.6 to 3.18.8. - [Release notes](https://github.com/gjtorikian/html-proofer/releases) - [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.18.6...v3.18.8) Signed-off-by: dependabot[bot] --- Gemfile.lock | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Gemfile.lock b/Gemfile.lock index ef99cafc9b8..42d5cd25d92 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -31,7 +31,7 @@ GEM multipart-post (>= 1.2, < 3) ruby2_keywords faraday-net_http (1.0.1) - ffi (1.14.2) + ffi (1.15.0) forwardable-extended (2.6.0) gemoji (3.0.1) github-pages (212) @@ -87,7 +87,7 @@ GEM html-pipeline (2.14.0) activesupport (>= 2) nokogiri (>= 1.4) - html-proofer (3.18.6) + html-proofer (3.18.8) addressable (~> 2.3) mercenary (~> 0.3) nokogumbo (~> 2.0) From 28335618e41ff73ddbdee6ba98d263143ec28b55 Mon Sep 17 00:00:00 2001 From: Mike McQuaid Date: Wed, 10 Mar 2021 13:19:06 +0000 Subject: [PATCH 006/770] Update documentation Make clear what the current procedures are for how we're running this repository. None of these are proposed changes; they are updates based on what we're already doing. --- CONTRIBUTING.md | 12 +++++------- README.md | 2 +- docs/translations.md | 4 ++-- 3 files changed, 8 insertions(+), 10 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ae95d763e11..a58a16a23fd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -18,11 +18,10 @@ 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! @@ -40,11 +39,10 @@ Before we get started, here are a few things we expect from you (and that you sh 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 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. ## Setting up your environment @@ -56,10 +54,10 @@ Once you have that set up, run: 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/README.md b/README.md index 5fbeac7ba24..df7704a20fc 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ Open Source Guides (https://opensource.guide/) are a collection of resources for ## 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. -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 diff --git a/docs/translations.md b/docs/translations.md index c964dcbd977..52364df202d 100644 --- a/docs/translations.md +++ b/docs/translations.md @@ -31,8 +31,8 @@ When tests find broken links, try to fix them across all translations. Ideally, ### Article updates -We're collecting [tips](https://github.com/github/opensource.guide/issues/1119) on how to check if a translation should be updated to account for improvements made to the English source articles. +Add the updated text in English to all translations to implicitly solicit pull requests to translate these strings. ### New articles -New articles are rare! When we have one, we'll probably do [some form](https://github.com/github/opensource.guide/issues/1120) of a call for translations. +We do not plan on ever adding any new articles. From 20b8a67e5eb445fb72e973ff1a0b2835538fc352 Mon Sep 17 00:00:00 2001 From: Mike McQuaid Date: Wed, 10 Mar 2021 13:41:14 +0000 Subject: [PATCH 007/770] getting-paid: add GitHub Sponsors reference I've taken the same approach as Homebrew uses for our translations here and added the English, non-translated string to the various articles so readers can submit pull requests to update these translations. --- _articles/de/getting-paid.md | 1 + _articles/es/getting-paid.md | 1 + _articles/fr/getting-paid.md | 1 + _articles/getting-paid.md | 3 ++- _articles/hu/getting-paid.md | 9 +++++---- _articles/id/getting-paid.md | 1 + _articles/ja/getting-paid.md | 1 + _articles/ko/getting-paid.md | 1 + _articles/ms/getting-paid.md | 1 + _articles/nl/getting-paid.md | 15 ++++++++++----- _articles/pl/getting-paid.md | 1 + _articles/pt/getting-paid.md | 3 ++- _articles/ro/getting-paid.md | 5 +++-- _articles/ta/getting-paid.md | 1 + _articles/tr/getting-paid.md | 1 + _articles/zh-hans/getting-paid.md | 1 + _articles/zh-hant/getting-paid.md | 1 + 17 files changed, 34 insertions(+), 13 deletions(-) diff --git a/_articles/de/getting-paid.md b/_articles/de/getting-paid.md index aa061f71f05..fb4a9413aba 100644 --- a/_articles/de/getting-paid.md +++ b/_articles/de/getting-paid.md @@ -127,6 +127,7 @@ Aus einer großen Firma stammende Projekte, wie z.B. [Go](https://github.com/gol Außerdem können Sie versuchen, abhängig von Ihren persönlichen Umständen, selbstständig Geld zu sammeln, um Ihre Open-Source-Arbeit zu finanzieren, zum Beispiel: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon finanzierte seine Arbeit an [Redux](https://github.com/reactjs/redux) mittels einer [Patreon-Crowdfunding-Kampagne](https://redux.js.org/) * @andrewgodwin finanzierte Arbeit an Djangos Schemamigrations [mittels einer Kickstarter-Kampagne](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) diff --git a/_articles/es/getting-paid.md b/_articles/es/getting-paid.md index 74dd16a930f..873b8bc7d36 100644 --- a/_articles/es/getting-paid.md +++ b/_articles/es/getting-paid.md @@ -101,6 +101,7 @@ Proyectos que se originaron en una empresa grande, como [Go](https://github.com/ Finalmente, dependiendo de tus circunstancias personales, puedes probar generar dinero de forma independiente para financiar tu trabajo de código abierto. Por ejemplo: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon financio su propio trabajo [Redux](https://github.com/reactjs/redux) a través de [Patreon crowdfunding campaign](https://redux.js.org/) * @andrewgodwin financió su trabajo de migración de esquemas de Django [a través de una campaña kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md index 4695e48695a..05862fd61f8 100644 --- a/_articles/fr/getting-paid.md +++ b/_articles/fr/getting-paid.md @@ -101,6 +101,7 @@ Les projets provenant d'une grande entreprise, tels que [Go](https://github.com/ Enfin, en fonction de votre situation personnelle, vous pouvez essayer de collecter des fonds de manière indépendante pour financer votre travail open source. Par exemple : +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon a fait financer son travail sur [Redux](https://github.com/reactjs/redux) via une [campagne de crowdfunding sur Patreon](https://redux.js.org/) * @andrewgodwin a fait financer le travail sur les migrations de schémas Django [à travers une campagne Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md index 0df5ca6ecda..42d75af5b33 100644 --- a/_articles/getting-paid.md +++ b/_articles/getting-paid.md @@ -106,10 +106,11 @@ Projects that originated at a large company, such as [Go](https://github.com/gol Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) * @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) * @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) -Finally, sometimes open source projects put bounties on issues that you might consider helping with. +Finally, sometimes open source projects put bounties on issues that you might consider helping with. * @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/). * @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md index 7fa29f1d3d4..6a5af345930 100644 --- a/_articles/hu/getting-paid.md +++ b/_articles/hu/getting-paid.md @@ -68,7 +68,7 @@ Egyszerűbb elérni ezt, ha az adott nyílt forráskódú projektet a munkaadód diff --git a/_articles/hu/code-of-conduct.md b/_articles/hu/code-of-conduct.md index b135eccca46..300fc1aaecc 100644 --- a/_articles/hu/code-of-conduct.md +++ b/_articles/hu/code-of-conduct.md @@ -31,7 +31,7 @@ Az elvárásaid mellett a magatartási kódex az alábbiakat írja még le: Lehetőség szerint használj már létező, publikus dokumentumot. A [Contributor Covenant](https://contributor-covenant.org/) egy azonnal használható magatartási kódex, amelyet már több mint 40,000 nyílt forráskódú projekt használ, mint például a Kubernetes, Rails, és a Swift. -A [Django Code of Conduct](https://www.djangoproject.com/conduct/) és a [Citizen Code of Conduct](http://citizencodeofconduct.org/) szintén nagyon jó minták. +A [Django Code of Conduct](https://www.djangoproject.com/conduct/) és a [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) szintén nagyon jó minták. Helyezd el a CODE_OF_CONDUCT állomány a projekt gyökérkönyvtárában, és hivatkozd meg őket a CONTRIBUTING és README állományokból, hogy mindenkinek látható legyen. diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md index 6a5af345930..ea0ac67f4d0 100644 --- a/_articles/hu/getting-paid.md +++ b/_articles/hu/getting-paid.md @@ -136,7 +136,7 @@ A projektedtől függően kérhetsz támogatást szupportért, új funkcióért, * **[Travis CI](https://github.com/travis-ci)** kínál fizetős verziót privát használatra * **[Ghost](https://github.com/TryGhost/Ghost)** alapvetően non-profit, de a felügyelt szolgáltatásért fizetni kell -Néhány híres projekt, mint az [npm](https://github.com/npm/npm) és a [Docker](https://github.com/docker/docker), még kockázati tőkét is bevontak a növekedés finanszírozásához. +Néhány híres projekt, mint az [npm](https://github.com/npm/cli) és a [Docker](https://github.com/docker/docker), még kockázati tőkét is bevontak a növekedés finanszírozásához. ### Jelentkezz pályázatokra diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md index 8c882058d7f..899a77272d0 100644 --- a/_articles/hu/how-to-contribute.md +++ b/_articles/hu/how-to-contribute.md @@ -220,7 +220,7 @@ Az alábbiakban találsz néhány oldalt, amelyek segítenek abban, hogy felfede * [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/) ### Egy ellenőrző lista, mielőtt részt vennél a projektben diff --git a/_articles/id/best-practices.md b/_articles/id/best-practices.md index 778a6100c7c..73a4b0e9ea1 100644 --- a/_articles/id/best-practices.md +++ b/_articles/id/best-practices.md @@ -259,7 +259,7 @@ Sama halnya seperti pekerjaan lainnya, mengambil liburan secara berkala akan mem avatar Dalam mengelola WP-CLI, Saya menemukan bahwa saya perlu membuat diri saya bahagia terlebih dahulu, dan menentukan batas keterlibatan saya dengan jelas. Keseimbangan terbaik yang saya temukan adalah 2-5 jam per minggu sebagai bagian dari jadwal pekerjaan normal saya. Hal ini menjaga keterlibatan saya sebagai sebuah gairah. Karena saya memprioritaskan masalah-masalah yang saya kerjakan, saya bisa membuat kemajuan berkala tentang apa yang saya anggap penting.

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

diff --git a/_articles/id/code-of-conduct.md b/_articles/id/code-of-conduct.md index 910858359b9..e52ed48e141 100644 --- a/_articles/id/code-of-conduct.md +++ b/_articles/id/code-of-conduct.md @@ -31,7 +31,7 @@ Selain mengkomunikasikan ekspektasi Anda, kode etik juga menjelaskan beberapa ha Apabila dimungkinkan, gunakan yang sudah ada. [Contributor Covenant](https://www.contributor-covenant.org/) adalah kode etik yang bisa digunakan dan sudah digunakan oleh lebih dari 40.000 proyek open source, termasuk Kubernetes, Rails, dan Swift. -[Kode etik Django](https://www.djangoproject.com/conduct/) dan [Kode etik Warga](http://citizencodeofconduct.org/) adalah dua contoh kode etik yang bagus. +[Kode etik Django](https://www.djangoproject.com/conduct/) dan [Kode etik Warga](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) adalah dua contoh kode etik yang bagus. Tempatkan dokumen CODE_OF_CONDUCT pada induk direktori proyek Anda, dan hubungkan dari dokumen README sehingga terlihat dengan jelas oleh komunitas Anda. diff --git a/_articles/id/getting-paid.md b/_articles/id/getting-paid.md index 7baf18e5dc5..d2b86acc681 100644 --- a/_articles/id/getting-paid.md +++ b/_articles/id/getting-paid.md @@ -129,7 +129,7 @@ Anda mungkin memberikan tambahan biaya untuk dukungan komersial, opsi hosting, a * **[Travis CI](https://github.com/travis-ci)** menawarkan versi berbayar untuk produknya * **[Ghost](https://github.com/TryGhost/Ghost)** bersifat nirlaba dengan layanan pembayaran -Beberapa proyek yang populer, seperti [npm](https://github.com/npm/npm) dan [Docker](https://github.com/docker/docker), bahkan mengajukan pendanaan pada venture capital untuk mendukung pertumbuhan bisnisnya. +Beberapa proyek yang populer, seperti [npm](https://github.com/npm/cli) dan [Docker](https://github.com/docker/docker), bahkan mengajukan pendanaan pada venture capital untuk mendukung pertumbuhan bisnisnya. ### Mengajukan hibah pendanaan diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md index 32fb5cdd575..f47582740dc 100644 --- a/_articles/id/how-to-contribute.md +++ b/_articles/id/how-to-contribute.md @@ -217,7 +217,7 @@ Anda juga bisa menggunakan salah satu dari beberapa sumber daya berikut untuk me * [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/) ### Daftar sebelum Anda berkontribusi diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md index f7e7aa3540b..c62c861826a 100644 --- a/_articles/ja/best-practices.md +++ b/_articles/ja/best-practices.md @@ -261,7 +261,7 @@ related: avatar WP-CLI をメンテナンスする中で、まずは自分自身を幸せにし、自分がどこまで関わるかの境界を明確にすることが必要であると気づきました。私が見つけた最も良いバランスは、私の通常の仕事時間の中で週に2 ~ 5時間を充てるというものです。このバランスで、私はプロジェクトに熱心に関わることができ、かつ仕事のようだと感じることもありません。取り掛かるイシューの優先順位付けをしているので、最も重要だと思うことで定期的に進捗を出すことができるのです。

-— @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://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md index 26a4dbf6b7c..ba6a7bb6f98 100644 --- a/_articles/ja/code-of-conduct.md +++ b/_articles/ja/code-of-conduct.md @@ -31,7 +31,7 @@ related: できる限り、既存の行動規範を使いましょう。 [Contributor Covenant](https://contributor-covenant.org/) は40,000以上のオープンソースプロジェクトで使われている行動規範で、 Kubernetes 、 Rails 、 Swift でも使われています。 -[Django Code of Conduct](https://www.djangoproject.com/conduct/) や [Citizen Code of Conduct](http://citizencodeofconduct.org/) の2つもよく使われる行動規範です。 +[Django Code of Conduct](https://www.djangoproject.com/conduct/) や [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) の2つもよく使われる行動規範です。 CODE_OF_CONDUCT ファイルをプロジェクトのルートディレクトリに置き、 CONTRIBUTING や README ファイルからリンクを張ってコミュニティの皆がすぐに見れるようにしましょう。 diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md index 225eb1340d1..78873974081 100644 --- a/_articles/ja/getting-paid.md +++ b/_articles/ja/getting-paid.md @@ -134,7 +134,7 @@ related: * **[Travis CI](https://github.com/travis-ci)** は、製品の有償版を提供しています。 * **[Ghost](https://github.com/TryGhost/Ghost)** は、有償のマネージドサービスを提供する非営利サービスです。 -[npm](https://github.com/npm/npm) や [Docker](https://github.com/docker/docker) のような有名なプロジェクトでは、ビジネスの成長を支えるためにベンチャーキャピタルから資金調達をしています。 +[npm](https://github.com/npm/cli) や [Docker](https://github.com/docker/docker) のような有名なプロジェクトでは、ビジネスの成長を支えるためにベンチャーキャピタルから資金調達をしています。 ### 助成金に応募する diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md index 43923ef4afc..1cfd6d87701 100644 --- a/_articles/ja/how-to-contribute.md +++ b/_articles/ja/how-to-contribute.md @@ -217,7 +217,7 @@ README を読んで、壊れたリンクやタイポを見つけるかもしれ * [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/) ### コントリビュートする前のチェックリスト diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md index 6ed20b13a3a..2295389f32f 100644 --- a/_articles/ko/best-practices.md +++ b/_articles/ko/best-practices.md @@ -261,7 +261,7 @@ GitHub에서는 버그 제보나 기타 평범한 기여에 사용할 [이슈 avatar 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://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/ko/code-of-conduct.md b/_articles/ko/code-of-conduct.md index 887ea9c8d1c..257f31a4a7f 100644 --- a/_articles/ko/code-of-conduct.md +++ b/_articles/ko/code-of-conduct.md @@ -31,7 +31,7 @@ related: 가능한 모든 곳에서 이전 기술을 사용하십시오. [기여자 규약](https://www.contributor-covenant.org/)은 Kubernetes, Rails 및 Swift를 포함하여 40,000 개 이상의 오픈소스 프로젝트에서 사용되는 행동강령입니다. -[Django 행동강령](https://www.djangoproject.com/conduct/)과 [Citizen 행동강령](http://citizencodeofconduct.org/)은 두가지 훌륭한 행동강령입니다. +[Django 행동강령](https://www.djangoproject.com/conduct/)과 [Citizen 행동강령](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)은 두가지 훌륭한 행동강령입니다. 프로젝트의 최상단 디렉토리에 CODE_OF_CONDUCT 파일을 놓고 CONTRIBUTING 또는 README 파일에서 링크하여 커뮤니티에 표시되게 하십시오. diff --git a/_articles/ko/getting-paid.md b/_articles/ko/getting-paid.md index d616df03581..edceba299f7 100644 --- a/_articles/ko/getting-paid.md +++ b/_articles/ko/getting-paid.md @@ -130,7 +130,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri * **[Travis CI](https://github.com/travis-ci)** 는 제품의 유료 버전을 제공합니다 * **[Ghost](https://github.com/TryGhost/Ghost)** 는 유료 관리 서비스가 있는 비영리 단체입니다 -[npm](https://github.com/npm/npm) 및 [Docker](https://github.com/docker/docker)와 같은 일부 인기있는 프로젝트는, 사업 성장을 지원하기 위해 벤처 캐피탈을 조성하기까지 합니다. +[npm](https://github.com/npm/cli) 및 [Docker](https://github.com/docker/docker)와 같은 일부 인기있는 프로젝트는, 사업 성장을 지원하기 위해 벤처 캐피탈을 조성하기까지 합니다. ### 보조금 신청하기 diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md index 8ba1371726b..99900325f70 100644 --- a/_articles/ko/how-to-contribute.md +++ b/_articles/ko/how-to-contribute.md @@ -217,7 +217,7 @@ README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또 * [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/) ### 기여하기 전 확인할 사항 diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md index 082754401f4..345d3a9ed91 100644 --- a/_articles/ms/best-practices.md +++ b/_articles/ms/best-practices.md @@ -265,7 +265,7 @@ Sama seperti jenis pekerjaan lain, berehat sebentar akan membuat anda segar, gem avatar Dalam mengekalkan WP-CLI, saya mendapati bahawa saya harus membuat diri saya bahagia terlebih dahulu, dan menetapkan batasan yang jelas mengenai penglibatan saya. Imbangan terbaik yang saya dapati adalah 2-5 jam seminggu, sebagai sebahagian daripada jadual kerja biasa saya. Ini menjadikan penglibatan saya menjadi minat, dan daripada merasa terlalu suka bekerja. Kerana saya mengutamakan masalah yang sedang saya jalankan, saya dapat membuat kemajuan secara berkala terhadap perkara yang saya rasa paling penting.

-— @danielbachhuber, ["Takziah, anda sekarang menjadi penyelenggara projek sumber terbuka yang popular"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["Takziah, anda sekarang menjadi penyelenggara projek sumber terbuka yang popular"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/ms/code-of-conduct.md b/_articles/ms/code-of-conduct.md index bb04a2b1996..fc1e3a051fa 100644 --- a/_articles/ms/code-of-conduct.md +++ b/_articles/ms/code-of-conduct.md @@ -37,7 +37,7 @@ Selain menyampaikan harapan anda, kod tingkah laku menerangkan perkara berikut: Di mana sahaja anda boleh, gunakan seni sebelumnya. [Contributor Covenant](https://contributor-covenant.org/) adalah tatakelakuan drop-in yang digunakan oleh lebih dari 40,000 projek sumber terbuka, termasuk Kubernetes, Rails, dan Swift. -[Django Code of Conduct](https://www.djangoproject.com/conduct/) dan [Citizen Code of Conduct](http://citizencodeofconduct.org/) juga merupakan dua contoh tatakelakuan yang baik. +[Django Code of Conduct](https://www.djangoproject.com/conduct/) dan [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) juga merupakan dua contoh tatakelakuan yang baik. Letakkan fail CODE_OF_CONDUCT di direktori root projek anda, dan jadikan ia dapat dilihat oleh komuniti anda dengan menghubungkannya dari fail CONTRIBUTING atau README anda. diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md index f9c2c3396d9..0a501476712 100644 --- a/_articles/ms/getting-paid.md +++ b/_articles/ms/getting-paid.md @@ -140,7 +140,7 @@ Bergantung pada projek anda, anda mungkin dapat mengenakan bayaran untuk sokonga * **[Travis CI](https://github.com/travis-ci)** menawarkan versi berbayar produknya * **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service -Beberapa projek popular, seperti [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker),malah mengumpulkan modal teroka untuk menyokong pertumbuhan perniagaan mereka. +Beberapa projek popular, seperti [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker),malah mengumpulkan modal teroka untuk menyokong pertumbuhan perniagaan mereka. ### Memohon pembiayaan geran diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md index 55cd3025be8..b50c6906bc5 100644 --- a/_articles/ms/how-to-contribute.md +++ b/_articles/ms/how-to-contribute.md @@ -230,7 +230,7 @@ Anda juga boleh menggunakan salah satu sumber berikut untuk membantu anda menemu * [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/) ### Senarai semak sebelum anda menyumbang diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md index be4fd139e47..c583c50dcc4 100644 --- a/_articles/nl/best-practices.md +++ b/_articles/nl/best-practices.md @@ -288,7 +288,7 @@ Net als bij elk ander soort werk, zal het nemen van regelmatige pauzes je verfri _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, ["Mijn condoleances, u bent nu de onderhouder (_maintainer_) van een populair open source-project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["Mijn condoleances, u bent nu de onderhouder (_maintainer_) van een populair open source-project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/nl/code-of-conduct.md b/_articles/nl/code-of-conduct.md index d59157706bf..f77c2c91613 100644 --- a/_articles/nl/code-of-conduct.md +++ b/_articles/nl/code-of-conduct.md @@ -37,7 +37,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. diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md index ae05b842255..7cc2851eff0 100644 --- a/_articles/nl/getting-paid.md +++ b/_articles/nl/getting-paid.md @@ -158,7 +158,7 @@ Afhankelijk van uw project kunt u mogelijk kosten in rekening brengen voor comme * **[Travis CI](https://github.com/travis-ci)** biedt betaalde versies van zijn product * **[Ghost](https://github.com/TryGhost/Ghost)** is een non-profitorganisatie met een betaalde beheerde service -Sommige populaire projecten, zoals [npm](https://github.com/npm/npm) en [Docker](https://github.com/docker/docker), halen zelfs risicokapitaal op om de groei van hun bedrijf te ondersteunen. +Sommige populaire projecten, zoals [npm](https://github.com/npm/cli) en [Docker](https://github.com/docker/docker), halen zelfs risicokapitaal op om de groei van hun bedrijf te ondersteunen. ### Subsidie ​​aanvragen diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md index dc7ee302cab..9b57e9aefa4 100644 --- a/_articles/nl/how-to-contribute.md +++ b/_articles/nl/how-to-contribute.md @@ -241,7 +241,7 @@ U kunt ook een van de volgende bronnen gebruiken om u te helpen bij het ontdekke * [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/) ### Een checklist voordat u bijdraagt diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md index 0049bc18bbd..3fed2f2d00f 100644 --- a/_articles/pl/best-practices.md +++ b/_articles/pl/best-practices.md @@ -271,7 +271,7 @@ Podobnie jak w przypadku każdego innego rodzaju pracy, regularne przerwy sprawi 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://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/pl/code-of-conduct.md b/_articles/pl/code-of-conduct.md index 3e39fbf0d6b..1a2d7a1ef2f 100644 --- a/_articles/pl/code-of-conduct.md +++ b/_articles/pl/code-of-conduct.md @@ -31,7 +31,7 @@ Oprócz przekazywania swoich oczekiwań kodeks postępowania opisuje następują 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. -[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 dobrego kodeksu 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. diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md index d5449946bd9..32a1ea63766 100644 --- a/_articles/pl/getting-paid.md +++ b/_articles/pl/getting-paid.md @@ -147,7 +147,7 @@ W zależności od projektu możesz być w stanie pobierać opłaty za wsparcie k * **[Travis CI](https://github.com/travis-ci)** oferuje płatne wersje swojego produktu * **[Ghost](https://github.com/TryGhost/Ghost)** jest organizacją non-profit z płatną usługą zarządzaną -Niektóre popularne projekty, takie jak [npm](https://github.com/npm/npm) oraz [Docker](https://github.com/docker/docker), nawet pozyskały kapitał wysokiego ryzyka w celu wsparcia rozwoju ich działalności. +Niektóre popularne projekty, takie jak [npm](https://github.com/npm/cli) oraz [Docker](https://github.com/docker/docker), nawet pozyskały kapitał wysokiego ryzyka w celu wsparcia rozwoju ich działalności. ### Złóż wniosek o dofinansowanie diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md index 3159d01da87..169f1f50112 100644 --- a/_articles/pl/how-to-contribute.md +++ b/_articles/pl/how-to-contribute.md @@ -233,7 +233,7 @@ Możesz także skorzystać z jednego z następujących zasobów, aby pomóc Ci o * [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/) ### Lista kontrolna przed wniesieniem wkładu diff --git a/_articles/pt/best-practices.md b/_articles/pt/best-practices.md index 8a26836b6a2..076c3377cb7 100644 --- a/_articles/pt/best-practices.md +++ b/_articles/pt/best-practices.md @@ -261,7 +261,7 @@ Assim como qualquer outro tipo de trabalho, fazer pausas regulares manterão voc avatar Na manutenção do WP-CLI, descobri que preciso me tornar feliz primeiro e estabelecer limites claros sobre meu envolvimento. O melhor equilíbrio que encontrei é 2-5 horas por semana, como parte de meu horário normal de trabalho. Isso mantém meu envolvimento uma paixão, e longe de me sentir como se estivesse no trabalho. Devido a priorização dos problemas que estou trabalhando, posso fazer progressos regulares naquilo que penso ser mais importante.

-— @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://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/pt/code-of-conduct.md b/_articles/pt/code-of-conduct.md index 00d4f305288..dc8554899da 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. diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md index 99df7d76e4e..057948160d4 100644 --- a/_articles/pt/getting-paid.md +++ b/_articles/pt/getting-paid.md @@ -135,7 +135,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 8d1cb746236..f1c4ffd678b 100644 --- a/_articles/pt/how-to-contribute.md +++ b/_articles/pt/how-to-contribute.md @@ -217,7 +217,7 @@ Você também pode usar um dos seguintes recursos para ajudá-lo a descobrir e c * [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/) ### Um checklist antes de você contribuir diff --git a/_articles/ro/best-practices.md b/_articles/ro/best-practices.md index 3cca2c80edf..97da1e968b6 100644 --- a/_articles/ro/best-practices.md +++ b/_articles/ro/best-practices.md @@ -323,7 +323,7 @@ Exact la fel ca oricare alt fel de muncă, luarea de pauze dese te va păstra re

-— @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://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/ro/code-of-conduct.md b/_articles/ro/code-of-conduct.md index 408c7c90fdf..75202870517 100644 --- a/_articles/ro/code-of-conduct.md +++ b/_articles/ro/code-of-conduct.md @@ -37,7 +37,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. diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md index d8443f20472..f27918d87b3 100644 --- a/_articles/ro/getting-paid.md +++ b/_articles/ro/getting-paid.md @@ -184,7 +184,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..27e6ea50206 100644 --- a/_articles/ro/how-to-contribute.md +++ b/_articles/ro/how-to-contribute.md @@ -261,7 +261,7 @@ Poți de asemenea folosi una dintre următoarele resurse pentru a te ajuta să d * [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/) ### O listă de verificare înainte de a contribui diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md index 1bed55f9bbf..d658f1f89c9 100644 --- a/_articles/ta/best-practices.md +++ b/_articles/ta/best-practices.md @@ -261,7 +261,7 @@ related: avatar WP-CLI ஐ பராமரிப்பதில், முதலில் நான் மகிழ்ச்சியடைந்தேன், என் ஈடுபாட்டின் மீது தெளிவான எல்லைகளை அமைத்தேன். என் சாதாரண பணி அட்டவணையின் ஒரு பகுதியாக, வாரத்திற்கு 2-5 மணிநேரத்தை நான் கண்டிருக்கிறேன். இது என் ஈடுபாடு ஒரு உணர்வு, மற்றும் மிகவும் வேலை உணர்கிறேன் இருந்து வைத்திருக்கிறது. நான் பணிபுரியும் பிரச்சினைகளுக்கு முன்னுரிமை அளிப்பதால், மிக முக்கியமானது என்னவென்று நான் நினைக்கிறேன். நான் பணிபுரியும் பிரச்சினைகளுக்கு முன்னுரிமை அளிப்பதால், நான் மிகவும் முக்கியம் என நினைப்பதில் நான் தொடர்ந்து முன்னேற்றம் செய்ய முடிகிறது.

-— @danielbachhuber, ["என் இரங்கல்கள், நீங்கள் இப்போது ஒரு பிரபலமான திறந்த மூல திட்டத்தின் பராமரிப்பாளர்"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["என் இரங்கல்கள், நீங்கள் இப்போது ஒரு பிரபலமான திறந்த மூல திட்டத்தின் பராமரிப்பாளர்"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/ta/code-of-conduct.md b/_articles/ta/code-of-conduct.md index 8b8f8c1b78c..33a8c45ff23 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 கோப்பில் இருந்து அதை இணைப்பதன் மூலம் அதை உங்கள் சமூகத்திற்குத் தெரியப்படுத்தவும். diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md index e1f8322e338..29a2861e9eb 100644 --- a/_articles/ta/getting-paid.md +++ b/_articles/ta/getting-paid.md @@ -130,7 +130,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 c27a34f7070..774154464c5 100644 --- a/_articles/ta/how-to-contribute.md +++ b/_articles/ta/how-to-contribute.md @@ -217,7 +217,7 @@ related: * [Up For Grabs](https://up-for-grabs.net/) * [பங்களிப்பாளர்-நிஞ்ஜா](https://contributor.ninja) * [முதல் பங்களிப்புகள்](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### பங்களிக்கும் முன் ஒரு சரிபார்ப்புப் பட்டியல் diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md index 5427fe39a07..3a264e8373a 100644 --- a/_articles/tr/best-practices.md +++ b/_articles/tr/best-practices.md @@ -272,7 +272,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://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md index 571fd442f74..afc8f06f843 100644 --- a/_articles/tr/code-of-conduct.md +++ b/_articles/tr/code-of-conduct.md @@ -37,7 +37,7 @@ Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdak Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir. -[Django Davranış Kuralları](https://www.djangoproject.com/conduct/) ve [Vatandaş Davranış Kuralları](http://citizencodeofconduct.org/) da aynı zamanda iki iyi davranış kural listesi örneğidir. +[Django Davranış Kuralları](https://www.djangoproject.com/conduct/) ve [Vatandaş Davranış Kuralları](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) da aynı zamanda iki iyi davranış kural listesi örneğidir. CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTING veya README dosyanızdan bağlantılayarak topluluğunuz tarafından görülebilir hale getirin. diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md index aad2f945d62..eb0cbd47221 100644 --- a/_articles/tr/getting-paid.md +++ b/_articles/tr/getting-paid.md @@ -139,7 +139,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 diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index e7b2934ae27..142b1f03e22 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -230,7 +230,7 @@ Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aş * [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çilebilecek bir kontrol listesi diff --git a/_articles/zh-hans/best-practices.md b/_articles/zh-hans/best-practices.md index fd8452e4267..c19caffa01a 100644 --- a/_articles/zh-hans/best-practices.md +++ b/_articles/zh-hans/best-practices.md @@ -255,7 +255,7 @@ fork 一个项目不什么坏事情。能复制并且修改别人的代码是开 avatar 我是 WP-CLI 的维护者，我发现我需要首先让自己开心，在开源项目和其他事情之间设定清楚的界限。我发现最好的平衡点就是每周在日常的工作安排中花 2-5 小时在这上面。这会让我从感觉太累到保持持续的激情。因为我给我需要解决的 issue 标上了优先级，从而我能够在我认为重要的事情上有所进展。

-— @danielbachhuber, ["我的悼文，你现在是一个非常流行的项目的维护者"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["我的悼文，你现在是一个非常流行的项目的维护者"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/zh-hans/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md index bdb8c7dc97c..6e2dcf9716d 100644 --- a/_articles/zh-hans/code-of-conduct.md +++ b/_articles/zh-hans/code-of-conduct.md @@ -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中附上其链接，这样对你们的社区是可见的。 diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md index 59d5093a133..239d3699336 100644 --- a/_articles/zh-hans/how-to-contribute.md +++ b/_articles/zh-hans/how-to-contribute.md @@ -218,7 +218,7 @@ redirect_from: /zh-cn/how-to-contribute/ * [Up For Grabs](https://up-for-grabs.net/) * [像忍者一样贡献](https://contributor.ninja) * [最初的贡献](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### 提交贡献之前的检查列表 diff --git a/_articles/zh-hant/best-practices.md b/_articles/zh-hant/best-practices.md index b0401a04f8e..1a3163e7092 100644 --- a/_articles/zh-hant/best-practices.md +++ b/_articles/zh-hant/best-practices.md @@ -255,7 +255,7 @@ fork一個專案不什麼壞事情。能複製並且修改別人的程式是開 avatar 我是WP-CLI的維護者，我發現我需要首先讓自己開心，在開源專案和其他事情之間設定清楚的界限。我發現最好的平衡點就是每週在日常的工作安排中花2-5小時在這上面。這會讓我從感覺太累到保持持續的激情。因爲我給我需要解決的issue表上了優先級，從而我能夠在我認爲重要的事情上有所進展。

-— @danielbachhuber, ["我的悼文，你現在是一個非常流行的專案的維護者"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["我的悼文，你現在是一個非常流行的專案的維護者"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/zh-hant/code-of-conduct.md b/_articles/zh-hant/code-of-conduct.md index 10649a5de71..fd0dfc14ea0 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中附上其鏈接，這樣對你們的社群是可見的。 diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md index 32d16ac5969..c6eb5d96d90 100644 --- a/_articles/zh-hant/how-to-contribute.md +++ b/_articles/zh-hant/how-to-contribute.md @@ -218,7 +218,7 @@ redirect_from: /zh-tw/how-to-contribute/ * [Up For Grabs](http://up-for-grabs.net/) * [貢獻忍者](https://contributor.ninja) * [最初的贡献](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### **提交貢獻前應做的檢查清單** From d4b7f76dcef991b7b23dd6413de73cc8742d6819 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Sun, 25 Apr 2021 21:35:04 +0430 Subject: [PATCH 030/770] Initial translation done. --- _articles/fa/getting-paid.md | 160 +++++++++++++++++------------------ 1 file changed, 78 insertions(+), 82 deletions(-) diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md index 42d75af5b33..ddb05d87f00 100644 --- a/_articles/fa/getting-paid.md +++ b/_articles/fa/getting-paid.md @@ -1,13 +1,8 @@ --- -lang: en -title: Getting Paid for Open Source Work -description: Sustain your work in open source by getting financial support for your time or your project. +lang: fa +title: گرفتن دستمزد برای کارهای متن باز +description: با دریافت پشتیبانی‌های مالی در ازای زمانی که می‌گذارید یا به خاطر پروژه‌ای که پیش می‌برید، کار متن باز خود را حمایت کنید. class: getting-paid -toc: - why-some-people-seek-financial-support: "Why some people seek financial support" - funding-your-own-time: "Funding your own time" - finding-funding-for-your-project: "Finding funding for your project" - building-a-case-for-financial-support: "Building a case for financial support" order: 7 image: /assets/images/cards/getting-paid.png related: @@ -15,178 +10,179 @@ related: - leadership --- -## Why some people seek financial support +## چرا برخی افراد به دنبال پشتیبانی‌های‌ مالی هستند -Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. +بیشتر کارهای متن باز داوطلبانه است. به عنوان مثال، کسی ممکن است در پروژه‌ای که از آن استفاده می‌کند با ایرادی (باگ) روبرو شود و راه‌حلی آسان برای ایراد ارائه کند، یا ممکن است کسی در اوقات فراغت خود از دستکاری در پروژه‌ی متن باز لذت ببرد. -There are many reasons why a person would not want to be paid for their open source work. +دلایل زیادی برای مایل نبودن شخص برای دریافت دستمزد در ازای کار متن باز خود، وجود دارد. -* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time. -* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects. -* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community. +* ممکن است از قبل، **کار تمام وقت مورد علاقه‌ی خود را داشته باشند** که به آن‌ها این امکان را می‌دهد تا در اوقات فراغت خود در کارهای متن باز مشارکت داشته باشند. +* آن‌ها از تصور کردن کارهای متن باز **به عنوان یک سرگرمی یا فرآیندی خلاقانه لذت می‌برند** و نمی‌خواهند از نظر مالی ملزم به کار در پروژه‌های خود باشند. +* آن‌ها از طریق مشارکت در کارهای متن باز **از مزایای دیگری برخوردار می‌شوند**، همچون ایجاد نمونه‌کار یا شهرت و اعتباری برای خود، یادگیری مهارت جدید یا احساس نزدیک‌تر بودن و صمیمیت بیشتر با اجتماع. -For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons. +برای دیگران، به ویژه هنگامی که مشارکت‌ها باید ادامه بیابد و یا به زمان قابل توجهی نیاز داشته باشد؛ اگر پروژه به آن‌ها نیاز داشته باشد یا به دلایل شخصی باید به کار ادامه دهند، پرداخت دستمزد برای مشارکت در کار متن باز، تنها راه برای مشارکت است. + +حفظ پروژه‌های پرطرفدار، می‌تواند مسئولیت سنگینی را بر روی دوش افراد بگذارد، می‌تواند بجای چند ساعت در ماه 10 یا 20 ساعت در هفته را به خود اختصاص دهد. -Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month. -Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community. +همچنین کارهای با دستمزد، این امکان برای افراد از اقشار مختلف جامعه را فراهم می‌آورد تا مشارکت‌های قابل‌توجه و معناداری انجام دهند. برخی از افراد، به سبب وضعیت مالی کنونی‌شان، بدهی یا خانواده یا سایر تعهدات، امکان مشارکت بدون دستمزد در پروژه‌های متن باز را ندارند. این بدان معناست که جهان هرگز مشارکت افراد مستعدی را که توانایی مالی برای مشارکت داوطلبانه را ندارند، نمی‌بیند. همانطور که @ashedryden [گفته است](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)، پیامدهایی اخلاقی در این میان وجود دارد، زیرا کسانی که از قبل در زندگی دارای مزایایی هستند، شانس بیشتری در کارهایی که انجام می‌شود دارند، درنتیجه بر اساس مشارکت‌های داوطلبانه‌ی خود مزایای بیشتری کسب می‌کنند، در حالی که سایر افرادی که قادر به داوطلب شدن نیستند، فرصت‌های آتی را از دست می‌دهند، که این عدم تنوع را در اجتماع کنونی (community) متن باز گسترش می‌دهد. -If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project. +اگر به دنبال حمایت‌های مالی هستید، دو راه وجود دارد. می‌توانید زمان مناسب را برای مشارکت پیدا کنید، یا می‌توانید بودجه‌ای برای پروژه‌ی خودتان پیدا کنید. -## Funding your own time +## وقت خود را سرمایه‌گذاری کنید -Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. +امروزه بسیاری از افراد برای کار به صورت پاره وقت یا تمام وقت در پروژه‌های متن باز دستمزد دریافت می‌کنند. متداول‌ترین راه برای دریافت دستمزد برای وقتی که صرف می‌کنید، صحبت کردن با کارفرمای خودتان است. -It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general. +متقاعد کردن کارفرما در پروژه‌ای که واقعا از آن استفاده ‌می‌کند آسان‌تر است، اما در مورد صحبتی که با او خواهید کرد، رویه‌ای خلاقانه در نظر بگیرید. شاید کارفرمای شما از این پروژه استفاده نکند، اما آن‌ها از پایتون استفاده می‌کنند و نگهداری از پروژه‌ی پایتون محبوب به جذب توسعه‌دهندگان جدید پایتون کمک می‌کند. شاید این امر باعث شود که کارفرمای شما به طور کلی در در ارتباط با توسعه‌دهندگان سازنده‌تر و دوستانه‌تر به نظر برسد. -If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software. +اگر در حال حاضر پروژه‌ای متن باز ندارید که بخواهید روی آن کار کنید، اما ترجیح می‌دهید که خروجی کار فعلی شما متن باز باشد، از کارفرمای خود درخواست کنید که برخی از نرم‌افزارهای داخلی خود را متن باز کند. -Many companies are developing open source programs to build their brand and recruit quality talent. +بسیاری از شرکت‌ها برنامه‌هایی متن باز توسعه می‌دهند تا اعتباری برای نام برند خود ایجاد کنند و افرادی با استعداد استخدام کنند. -@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting: +به عنوان مثال، @hueniverse دریافت که دلایلی تجاری برای توجیه [سرمایه‌گذاری والمارت (Walmart)] (https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html)در متن باز وجود دارد. و jamesgpearce@، دریافت که برنامه‌ی متن باز فیس‌بوک، [تفاوت‌هایی را در استخدام ایجاد کرده است](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) -> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues. +> کاملا با فرهنگ خلاقیت‌جویانه‌ی ما و آنچه که سازمان ما با آن شناخته می‌شود، سازگار و همسو است. ما از کارمندان خود پرسیدیم، «آیا از برنامه‌ی نرم‌افزاری متن باز فیس‌بوک آگاهی داشتید؟» دو سوم آن‌ها گفتند «بله» یک دوم آن‌ها گفتند که این برنامه به تصمیم‌شان برای کار کردن در فیس‌بوک تاثیر داشت. اینها اعداد کمی نیستند و امیدواریم که این روند ادامه داشته باشد. -If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location. +اگر شرکت شما این مسیر را طی می‌کند، مهم است که مرزهای بین اجتماع و فعالیت‌های شرکتی را روشن کنید. در آخر، پروژه‌های متن باز از طریق مشارکت‌های مردم در سرتاسر جهان از خود نگهداری می‌کند؛ این پروژه‌ها بزرگ‌تر از هر شرکت یا فضایی هستند. -If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example: +اگر نمی‌توانید کارفرمای کنونی خودتان را متقاعد به اولویت‌بندی کارهای متن باز بکنید، سعی کنید کارفرماهای جدیدی پیدا کنید که کارمندان را تشویق به مشارکت در متن باز می‌کنند. به دنبال شرکت‌هایی بگردید که تعهد صریحی برای کار با پروژه‌های متن باز داشته باشند. به عنوان مثال: + +* برخی شرکت‌ها مانند [Netflix](https://netflix.github.io/) یا [PayPal](https://paypal.github.io/)، وب‌سایت‌هایی دارند که مشارکت آن‌ها در متن باز را برجسته و نمایان می‌کند +* شرکت [Zalando](https://opensource.zalando.com)، «سیاست‌های مشارکت متن باز» خود برای کارمندان را منتشر کرد -* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source -* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees +پروژه‌هایی که از شرکت‌های بزرگی مانند [Go](https://github.com/golang) یا [React](https://github.com/facebook/react) سرچشمه گرفته‌اند و به آن وصل‌اند نیز احتمالاً افرادی را برای کار با متن باز استخدام خواهند کرد -Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. +بسته به شرایط شخصی خودتان، می‌توانید به طور مستقل برای تأمین هزینه‌های کار متن باز خود، پول جمع کنید. به عنوان مثال: -Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: -* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) -* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) -* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) +* نرم‌افزار متن باز @Homebrew ([و بسیاری از نگهدارندگان و سازمان‌ها](https://github.com/sponsors/community))، کار خودشان را از طریق حامیان مالی [GitHub](https://github.com/sponsors) تأمین می‌کنند +* @gaearon کار خود در [Redux](https://github.com/reactjs/redux) را از طریق کمپین سرمایه‌گذاری جمعی «Patreon» تأمین مالی کرد +* @andrewgodwin از [طریق کمپین Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) کارش در مورد مایگریشن‌های دیتابیس «Django» را تأمین مالی کرد. (Schema Migration) -Finally, sometimes open source projects put bounties on issues that you might consider helping with. +در آخر اینکه گاهی اوقات پروژه‌های متن باز درمورد موضوعاتی که ممکن است در آن بخواهید کمک کنید پاداش‌هایی قرار می‌دهند. -* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/). -* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). +* @ConnorChristie توانست بابت [کمک](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) به @MARKETProtocol در «JavaScript library» (کتابخانه‌ی جاوا اسکریپت) از طریق پاداشی‌ تعیین شده در [gitcoin](https://gitcoin.co/)، دستمزد بگیرد +* @mamiM پس از تأمین اعتبار مربوط به مشکلِ شبکه‌ی Bounties، ترجمه‌ی ژاپنی برای @MetaMask انجام داد. -## Finding funding for your project +## یافتن بودجه برای پروژه‌ -Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. +علاوه‌ بر توافق‌های اولیه با مشارکت‌کنندگان، گاهی اوقات پروژه‌ها از شرکت‌ها، افراد حقیقی یا دیگران برای تأمین بودجه‌ی کارهای جاری پول جمع‌آوری می‌کنند. -Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas. +بودجه‌های سازمانی ممکن است به پرداخت دستمزد مشارکت‌کنندگان، تأمین هزینه‌های اجرای پروژه (مانند هزینه‌های میزبانی) یا سرمایه‌گذاری بر روی ویژگی‌ها یا ایده‌های جدید اختصاص یابد. -As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. +با افزایش محبوبیت ‌متن باز، هنوز هم یافتن بودجه برای پروژه‌ها به صورت تجربی و آزمایشی است، اما چندین گزینه‌ی متداول در دسترس است. -### Raise money for your work through crowdfunding campaigns or sponsorships +### جمع‌آوری سرمایه از طریق کمپین‌های سرمایه‌گذاری جمعی یا حمایت‌های مالی -Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular. -A few examples of sponsored projects include: +اگر از قبل مخاطب یا اعتبار بالایی داشته باشید یا پروژه‌ی شما از محبوبیت بالایی برخوردار باشد، یافتن حمایت‌های مالی امکان‌پذیر است. چند نمونه از پروژه‌های حمایت شده: -* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack) -* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803) -* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects +* پروژه‌ی **[webpack](https://github.com/webpack)** از طریق [OpenCollective](https://opencollective.com/webpack) از شرکت‌ها و اشخاص پول جمع‌آوری می‌کند +* بودجه‌ی **[Vue](https://github.com/vuejs/vue)** از طریق [Patreon](https://github.com/open-source/stories/yyx990803) تأمین می‌شود +* **[Ruby Together](https://rubytogether.org/)،** یک سازمان غیر‌انتفاعی است که هزینه‌های کار در [bundler](https://github.com/bundler/bundler)، [RubyGems](https://github.com/rubygems/rubygems) و سایر پروژه‌های بر پایه‌ی زیرساختی «Ruby» را پرداخت می‌کند -### Create a revenue stream +### ایجاد یک منبع درآمدی -Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include: +بسته به پروژه‌ی خود، ممکن است بتوانید از طریق تبلیغات، گزینه‌های میزبانی شده یا ویژگی‌های اضافی کسب درآمد داشته باشید. چندین مثال در این زمینه: -* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support -* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product -* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service +* **[Sidekiq](https://github.com/mperham/sidekiq)**، نسخه‌هایی پولی به منظور پشتیبانی بیشتر ارائه می‌دهد +* **[Travis CI](https://github.com/travis-ci)**، نسخه‌های پولی محصولات خود را ارائه می‌دهد +* **[Ghost](https://github.com/TryGhost/Ghost)**، یک سازمان غیرانتفاعی است که خدمات مدیریتی پولی ارائه می‌دهد -Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. +بعضی از پروژه‌های محبوب مانند [npm](https://github.com/npm/npm) و [Docker](https://github.com/docker/docker)، برای حمایت از رشد کسب و کار خود، حتی سرمایه‌های مخاطره‌آمیزی را جمع‌آوری می‌کنند -### Apply for grant funding +### برای بودجه، درخواست کمک هزینه (بورسیه) دهید -Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project. +برخی از موسسات و شرکت‌های نرم‌افزاری، کمک‌هزینه‌های مالی برای کارهای متن باز ارائه می‌دهند. گاهی اوقات، بدون ایجاد نهاد قانونی‌ای برای پروژه، کمک‌هزینه‌های مالی به افراد حقیقی پرداخت می‌شود. -* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) -* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) -* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology) -* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work +* **نرم‌افزار [Read the Docs](https://github.com/rtfd/readthedocs.org)**، از پشتیبانی بخش متن باز [Mozilla](https://www.mozilla.org/en-US/grants/)، کمک‌هزینه دریافت کرد +* **بودجه‌ی کار [OpenMRS](https://github.com/openmrs)** توسط [Stripe’s Open Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) تأمین شد +* **[Libraries.io](https://github.com/librariesio)** از موسسه‌ی [Sloan](https://sloan.org/programs/digital-technology) کمک‌هزینه‌ دریافت کرد +* **موسسه‌ی نرم‌افزار پایتون (Python Software Foundation)**، کمک‌های مالی برای کارهای مرتبط با پایتون ارائه می‌دهد -For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you. +برای جزئیات دقیق‌تر و مطالعات موردی، @nayafia راهنمای دریافت دستمزد برای کارهای متن باز را [نوشت](https://github.com/nayafia/lemonade-stand). انواع بودجه‌ها به مهارت‌های مختلفی نیاز دارد، بنابراین نقاط قوت خود را در نظر بگیرید تا گزینه‌ی مناسب برای کار خودتان را دریابید. -## Building a case for financial support +## ایجاد پرونده‌ی موردی (فایل) به منظور دریافت حمایت مالی -Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case. +این که آیا پروژه‌ی شما ایده‌ی جدیدی است یا سال‌هاست که وجود دارد؛ باید برای شناسایی و مشخص کردن سرمایه‌گذار هدف و ایجاد یک پرونده‌‌ی اغواکننده، باید به خوبی راجع به آن فکر کنید. -Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions. +چه بخواهید هزینه‌ی زمانی که صرف می‌کنید را خودتان پرداخت کنید و یا موسسه‌ای هزینه‌ی پروژه‌ی شما را پرداخت کند، باید بتوانید به سوالات زیر پاسخ دهید. -### Impact +### تاثیرگذاری -Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years? +این پروژه به چه دردی می‌خورد؟ برای چه کاربران شما، یا کاربران بالقوه‌ی شما، پروژه‌ را دوست داشته باشند؟ پروژه‌ی خود را در پنج سال آینده چطور می‌بینید؟ -### Traction +### مقبولیت -Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it? +سعی کنید شواهدی را در مورد اهمیت پروژه‌ی خود جمع‌آوری کنید؛ چه بخواهد معیارهای سنجش، تجربه‌های گذشته، یا اظهارنظرهای مثبتی باشد. آیا شرکت‌ها یا افراد قابل ذکری وجود دارند که از پروژه‌ی شما استفاده بکنند؟ اگر نه، آیا شخص برجسته‌ای پروژه‌ی شما را تأیید کرده است؟ -### Value to funder +### ارزش آن برای سرمایه‌گذار -Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit? +سرمایه‌گذاران، چه کارفرمای شما باشد و یا چه یک موسسه‌ی اعطای کمک‌هزینه، اکثرا جذب فرصت‌ها می‌شوند. چرا آن‌ها باید از پروژه‌ی شما در برابر سایر فرصت‌ها حمایت کنند؟ از پروژه‌ی شما چه منفعت شخصی‌ای می‌برند؟ -### Use of funds +### مصارف بودجه -What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary. +با بودجه پیشنهادی، دقیقاً به چه نتیجه‌ای دست خواهید یافت؟ به جای فکر کردن به پرداخت حقوق و دستمزد، روی نقاط عطف یا نتایج پروژه متمرکز شوید. -### How you'll receive the funds +### چگونه بودجه را دریافت خواهید کرد -Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand. +آیا سرمایه‌گذار، الزاماتی در مورد پرداخت هزینه مدنظر دارد؟ به عنوان مثال، ممکن است لازم باشد شما سازمانی غیرانتفاعی باشید یا یک حامی مالی غیرانتفاعی داشته باشید. یا شاید بودجه باید به جای سازمان به یک پیمانکار حقیقی داده شود. هر شخص سرمایه‌گذاری الزامات متفاوتی دارد، بنابراین حتماً از قبل تحقیقات خود را انجام دهید. -## Experiment and don't give up +## آزمایش و تجربه کنید و تسلیم نشوید -Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding. +جمع‌آوری پول آسان نیست، چه پروژه‌ای متن باز باشید، چه یک سازمان غیرانتفاعی و یا یک استارت‌آپ نرم‌افزاری؛ باید در بیشتر موارد با دیدی خلاقانه به موضوع نگاه کنید. با مشخص کردن اینکه چگونه می‌خواهید دستمزد بگیرید، با تحقیقات خود و قرار دادن خود به جای سرمایه‌گذار، به شما کمک می‌کند تا پرونده‌ای قانع‌کننده برای تأمین بودجه بسازید. From 018d345ee9d8172c04594d3d9e609878ca25934c Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 3 May 2021 10:36:32 +0000 Subject: [PATCH 031/770] Bump html-proofer from 3.19.0 to 3.19.1 Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.19.0 to 3.19.1. - [Release notes](https://github.com/gjtorikian/html-proofer/releases) - [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.19.0...v3.19.1) Signed-off-by: dependabot[bot] --- Gemfile.lock | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Gemfile.lock b/Gemfile.lock index 4086bbc0959..86995d3742f 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -22,7 +22,7 @@ GEM em-websocket (0.5.2) eventmachine (>= 0.12.9) http_parser.rb (~> 0.6.0) - ethon (0.13.0) + ethon (0.14.0) ffi (>= 1.15.0) eventmachine (1.2.7) execjs (2.7.0) @@ -87,7 +87,7 @@ GEM html-pipeline (2.14.0) activesupport (>= 2) nokogiri (>= 1.4) - html-proofer (3.19.0) + html-proofer (3.19.1) addressable (~> 2.3) mercenary (~> 0.3) nokogumbo (~> 2.0) @@ -213,7 +213,7 @@ GEM rb-fsevent (~> 0.10, >= 0.10.3) rb-inotify (~> 0.9, >= 0.9.10) mercenary (0.3.6) - mini_portile2 (2.5.0) + mini_portile2 (2.5.1) minima (2.5.1) jekyll (>= 3.5, < 5.0) jekyll-feed (~> 0.9) From 2cb2fde9a42436ba8e4088c63caf909f7c1e2f4b Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Tue, 4 May 2021 20:21:59 +0430 Subject: [PATCH 032/770] Initial translation done. --- _articles/fa/leadership-and-governance.md | 127 +++++++++++----------- 1 file changed, 61 insertions(+), 66 deletions(-) diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md index b8006c30107..7c105727bc2 100644 --- a/_articles/fa/leadership-and-governance.md +++ b/_articles/fa/leadership-and-governance.md @@ -1,17 +1,8 @@ --- -lang: en -title: Leadership and Governance -description: Growing open source projects can benefit from formal rules for making decisions. +lang: fa +title: مدیریت و نظارت +description: وجود نقش‌های رسمی جهت تصمیم‌گیری، منافع زیادی برای پروژه‌های متن باز در حال رشد به همراه دارد. class: leadership -toc: - understanding-governance-for-your-growing-project: "Understanding governance for your growing project" - what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?" - how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?" - when-should-i-give-someone-commit-access: "When should I give someone commit access?" - what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?" - do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?" - what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?" - do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?" order: 6 image: /assets/images/cards/leadership.png related: @@ -19,147 +10,151 @@ related: - metrics --- -## Understanding governance for your growing project +## نظارت درست بر روی پروژه‌ی در حال رشد -Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers. +پروژه‌ی شما رشد می‌کند، مردم درگیر پروژه‌ی شما می‌شوند، و شما به ادامه دادن این کار متعهد می‌شوید. در این مرحله، ممکن است از خود بپرسید که چگونه می‌توانید مشارکت‌کنندگان پروژه‌ی خود را منسجم و یکپارچه کنید، خواه دادن دسترسی کامیت باشد یا حل و فصل کردن بحث‌ها و گفتگوهای درون اجتماع. اگر سوالاتی دارید، جواب‌ها پیش ماست. -## What are examples of formal roles used in open source projects? +## مثال‌هایی از نقش‌های رسمی مورد استفاده در پروژه های متن باز، چه هستند؟ -Many projects follow a similar structure for contributor roles and recognition. +بسیاری از پروژه‌ها، ساختار مشابهی را در حوزه‌ی نقش‌های مشارکتی و شناختی دنبال می‌کنند. -What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize: +مضمون و معنای این نقش‌ها، در واقع کاملا به شما بستگی دارد. در اینجا، چند نوع نقشی که ممکن است آن‌ها را تشخیص دهید، نام بردیم: -* **Maintainer** -* **Contributor** -* **Committer** +* **نگهدارنده (Maintainer)** +* **مشارکت‌کننده (Contributor)** +* **کامیت کننده (Committer)** -**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers. +**در برخی از پروژه‌ها، نگهدارندگان** تنها افرادی در پروژه هستند که دسترسی کامیت دارند. در برخی دیگر از پروژه‌ها، فقط افرادی دسترسی دارند که در «README» به عنوان نگهدارنده ذکر شده‌اند. -A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it. +نگهدارنده لزوماً کسی نیست که برای پروژه‌ی شما کد می‌نویسد. بلکه می‌تواند کسی باشد که در تبلیغ پروژه‌ی شما کارهای زیادی انجام داده باشد یا مستنداتی را نوشته باشد که پروژه را برای دیگران قابل دسترسی‌تر کرده است. صرف نظر از کاری که آن‌ها در طی روز انجام می‌دهند، نگهدارنده کسی است که نسبت به مسیر و اجرای پروژه احساس مسئولیت می‌کند و متعهد به بهبود بخشیدن آن است. -**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor). +**مشارکت‌کننده می‌تواند هر کسی باشد**: کسی که مسئله یا درخواست «Pull»ی را مطرح می‌کند، یا افرادی باشند که به پروژه ارزش می‌بخشند (خواه این که مسائل مربوط به اولویت‌بندی درخواست‌ها، نوشتن کد یا سازماندهی رویدادها باشد) یا هر کسی باشد که درخواست «pull»ی را ادغام (merge) بکند (جزئی‌ترین تعریف از مشارکت‌کننده) -**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution. +**اصطلاح «کامیت کننده»،** ممکن است برای وجه تمایز دسترسی کامیت، که نوع خاصی از مسئولیت در مقابل سایر اشکال مشارکت است، استفاده شود. -While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill. +در حالی که می‌توانید نقش‌ها را در پروژه‌ی خود به هر روشی که دوست دارید تعریف کنید، استفاده از تعاریف گسترده‌تر را برای تقویت اشکال بیشتری از مشارکت، [مد نظر خود قرار دهید](../how-to-contribute/#what-it-means-to-contribute). شما می‌توانید از نقش‌های مدیریتی برای شناسایی رسمی افرادی که مشارکت برجسته‌ای به پروژه‌ی شما کرده‌اند، صرف نظر از مهارت‌های فنی آن‌ها استفاده کنید -## How do I formalize these leadership roles? +## چگونه به این نقش‌های مدیریتی، رسمیت ببخشیم؟ -Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help. +رسمیت بخشیدن به نقش‌های مدیریتی، باعث می‌شود افراد احساس مالکیت کنند و به اعضای سایر اجتماع‌ها بگویند برای کمک به چه کسانی روی آورند. -For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file. +در پروژه‌های کوچک‌تر، تعیین کردن مدیران می‌تواند به سادگی افزودن نام آن‌ها به فایل‌های «README» یا به یک فایل متنی «CONTRIBUTORS» باشد. -For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor. +برای پروژه‌های بزرگ‌تر، اگر وب‌سایتی دارید، یک صفحه‌ی تیمی ایجاد کنید یا اسامی مدیران پروژه را در آنجا لیست کنید. به عنوان مثال، [Postgres](https://github.com/postgres/postgres/) یک [صفحه‌ی تیمی جامع](https://www.postgresql.org/community/contributors/) و فراگیر با مشخصاتی کوتاه برای هر مشارکت‌کننده دارد. -If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them. +اگر پروژه‌ی شما دارای جامعه‌ی مشارکت‌کننده‌ی بسیار فعالی است، شما می‌توانید یک «تیم اصلی» از نگهدارنده‌ها، یا حتی کمیته‌های فرعی از افرادی که مالکیت حوزه‌های موضوعات مختلف را دارند (به عنوان مثال، امنیت، اولویت‌بندی درخواست‌ها یا هدایت اجتماع) تشکیل دهید. به جای اینکه به هر کسی، وظایف خاصی را محول کنید، بگذارید افراد خودشان، برای نقش‌هایی که بیشتر از همه هیجان زده‌اند سازمان یابند و داوطلب شوند. -Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). +تیم‌های مدیریت، ممکن است بخواهند کانالی مشخص (مانند IRC) ایجاد کنند یا به طور منظم برای بحث درمورد پروژه با هم ملاقات کنند (مانند Gitter یا Google Hangout). حتی می‌توانید آن جلسات را علنی برگزار کنید تا سایر افراد بتوانند گوش دهند. به عنوان مثال، [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) همچین کاری می‌کند -Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md. +پس از اینکه نقش‌های مدیریتی را ایجاد کردید، ثبت چگونگی نحوه‌ی دسترسی افراد به آن‌ها را فراموش نکنید! فرآیند روشن و واضحی را برای چگونگی کسی که می‌خواهد نگهدارنده شود یا به کمیته‌ای فرعی در پروژه شما بپیوندد، ایجاد کنید و آن را در «GOVERNANCE.md» خود بنویسید. -Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately. +ابزارهایی مانند [Vossibility](https://github.com/icecrime/vossibility-stack)، می‌تواند به شما کمک کند تا به طور عمومی افرادی که در پروژه مشارکت می‌کنند (یا نمی‌کنند) را ردیابی کنید. ثبت این اطلاعات، جلوی این ذهنیت اجتماع که نگهدارندگان گروهی هستند که تصمیمات خود را به صورت خصوصی اتخاذ می‌کنند، می‌گیرد -Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project). +در آخر اینکه اگر پروژه‌ی شما در «GitHub» است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. [تشکل‌های «GitHub»](https://help.github.com/articles/creating-a-new-organization-account/)، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق [مالکیت مشترک](../building-community/#share-ownership-of-your-project) محافظت می‌کنند. -## When should I give someone commit access? +## چه موقع باید به کسی اجازه‌ی دسترسی کامیت بدهیم؟ -Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project. +برخی از افراد فکر می‌کنند که شما باید به هر کسی که در پروژه مشارکت می‌کند، دسترسی کامیت بدهید. با انجام این کار، افراد بیشتری ترغیب به داشتن احساس مالکیت نسبت به پروژه‌ی شما، می‌شوند. -On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable! +از طرف دیگر، به خصوص برای پروژه‌های بزرگتر و پیچیده‌تر، ممکن است بخواهید فقط به افرادی که تعهد خود را نشان داده و به اثبات رسانده‌اند، دسترسی کامیت بدهید. هیچ راه درستی برای انجام این کار وجود ندارد - هر جور که راحت‌تر هستید، عمل کنید! -If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances. +اگر پروژه‌ی شما در «GitHub» است، می توانید از شاخه‌های محافظت شده [protected branches](https://help.github.com/articles/about-protected-branches/) برای مدیریت افرادی که می‌توانند تحت شرایط خاصی در شاخه‌ای خاص عمل کنند، استفاده کنید -## What are some of the common governance structures for open source projects? +## برخی از ساختارهای نظارتی متداول برای پروژه‌های متن باز چیست؟ -There are three common governance structures associated with open source projects. +سه ساختار نظارتی متداول در ارتباط با پروژه‌های متن باز وجود دارد. -* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category. -* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company. +* **BDFL** مخفف «دیکتاتور خیرخواه جاویدان» است ( .(Benevolent Dictator for Lifeتحت این ساختار، یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت «BDFL» هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی «BDFL» قرار گیرند -* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). -Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates: +* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی ](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache»، به وجود آمد. تمامی پروژه‌های «Apache» بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت. + + +* **Liberal contribution:** (مشارکت آزادنه) تحت مدل مشارکت آزادانه، افرادی که بیشترین کار را انجام می‌دهند به عنوان تأثیرگذارترین افراد شناخته می‌شوند، اما این مدل براساس کاری که اکنون انجام می‌دهند است و نه مشارکت‌های که در گذشته داشته‌اند. تصمیمات بزرگ‌ پروژه بر اساس فرآیندی در اجتماع به صورت اجماعی (بحث‌ در مورد مسائل اساسی) به جای رأی‌گیری تنها گرفته می‌شود، و تلاش می‌شود تا آنجا که ممکن است دیدگاه‌های بیشتری از اجتماع را شامل شود. از جمله پروژه‌هایی که از مدل مشارکت آزادانه استفاده کردند، می‌توان [Node.js](https://foundation.nodejs.org/) و [Rust](https://www.rust-lang.org/) را نام برد. + +از کدام مدل بهتر است استفاده کنید؟ به خودتان بستگی دارد! هر مدل، شامل نکات منفی و مثبتی می‌شود. اگرچه ممکن است این مدل‌ها در ابتدا کاملاً متفاوت به نظر برسند؛ اما هر سه مدل، اشتراکات بیشتری از آنچه که به نظر می رسد دارند: * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) * [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) -## Do I need governance docs when I launch my project? +## آیا هنگام راه‌اندازی پروژه‌ی خود به اسناد نظارتی نیاز دارم؟ + +زمان مناسب و دقیقی برای نوشتن اسناد نظارتی پروژه وجود ندارد، اما هنگامی که شرایط اجتماع خود را دیدید و با جو آن آشنا گشتید، به ثبت رساندن اسناد بسیار ساده‌تر می‌شود. بهترین (و سخت‌ترین) بخش در مورد نظارت پروژه‌های متن باز این است که توسط خود اجتماع شکل می‌گیرد! -There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community! +هر چند برخی اسناد اولیه‌ی نظارتی به طور اجتناب ناپذیری در پروژه‌ی شما خواهد بود، ولی شروع به نوشتن آنچه می‌توانید بکنید. به عنوان مثال، شما می‌توانید حتی در زمان راه‌اندازی پروژه‌ی خود، انتظارات واضح و شفاف خودتان از رفتار یا فرآیند‌ مشارکت کاری را تعریف کنید. -Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch. +اگر شما عضوی از شرکتی هستید که پروژه‌ای متن باز راه‌اندازی می‌کند، بد نیست قبل از راه‌اندازی، بحثی درون‌سازمانی درباره نحوه‌ی نگهداری شرکت و تصمیم‌گیری در مورد پیشرفت پروژه داشته باشید. همچنین بهتر است در مورد مسیری که شرکت شما در رابطه با پروژه پیش خواهد گرفت، به صورت علنی صحبت دهید. -If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project. -## What happens if corporate employees start submitting contributions? +## اگر کارمندان شاغل در شرکت شروع به ارائه‌ی خدمات کنند، چه می‌شود؟ -Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering. +پروژه‌های متن باز موفق، توسط بسیاری از افراد و شرکت‌ها مورد استفاده قرار می‌گیرند و در نهایت ممکن است برخی از شرکت‌ها شروع به کسب درآمد از آن پروژه‌ها بکنند. به عنوان مثال، شرکتی ممکن است از کدهای پروژه به عنوان یک بخش سازنده‌ی محصولات خدمات تجاری استفاده کند. -As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project. +هنگامی که استفاده از پروژه بیشتر شود، افراد زیادی خواستار کسانی که در آن پروژه تخصص دارند می‌شوند؛ ممکن است شما یکی از آن‌ها باشید! و گاهی اوقات نیز به خاطر کاری که در پروژه‌ می‌کنید، حقوق دریافت کنید. -It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature. +بسیار مهم است که رفتاری عادی در قبال فعالیت‌های تجاری داشت؛ درست رفتاری مانند فعالیت‌های توسعه‌ای در پروژه‌های دیگر. البته نباید برخورد خاص و رفتار ویژه‌ای با توسعه‌دهندگانی که به آن‌ها پول داده می‌شود در برابر آن‌هایی که بدون دریافت پول به کارشان مشغول هستند، قائل شد. هر یک از مشارکت‌ها باید بر اساس شایستگی‌های فنی ارزیابی شود. با این حال، افرادی که مشغول به فعالیت‌های تجاری هستند، باید احساس راحتی داشته باشند و هنگام بحث و گفتگو در مورد پیشرفت یا ویژگی خاصی، در بیان موارد کاربردی و کارهایی که قبلا داشتند، باید احساس راحتی کنند. -"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.) +پروژه‌های «تجاری» هیچ فرقی با پروژه‌های «متن باز» ندارند. «تجاری» فقط به این معنی است که پول هم در کار است؛ به این معنی که نرم افزاری که در تجارت مورد استفاده قرار می‌گیرد، نرم‌افزاری در پروژه بوده است که در فعالیت تجاری پذیرفته شده است. (هنگامی که از یک نرم‌افزار «متن باز» به عنوان بخشی سازنده از محصولی «غیر متن باز» استفاده می‌شود، محصول نهایی همچنان نرم‌افزاری «دارای حقوق انحصاری» است، هرچند مانند «متن باز» ممکن است برای اهداف تجاری یا غیر تجاری استفاده شود.) -Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions. +مانند هر کس دیگری، توسعه‌دهندگانی که انگیزه‌های تجاری دارند از طریق کیفیت و کمیت مشارکت‌های خودشان است که در پروژه اهمیت می‌یابند و تاثیرگذار می‌شوند. بدیهی است که توسعه‌دهنده‌ای که برای کاری که می‌کند حقوق می‌گیرد، احتمالا بیشتر از شخصی که حقوق نمی‌گیرد، توانایی کار کردن دارد ولی اهمیتی ندارد: پرداخت حقوق فقط یکی از بسیار عامل‌های احتمالی است که می‌تواند بر میزان کاری که شخص می‌کند، تأثیر بگذارد. مشارکت‌ها رو معطوف به بحث‌های مربوط به پروژه بکنید، و نه معطوف به موضوعاتی خارج از پروژه. -## Do I need a legal entity to support my project? +## آیا برای حمایت و پشتیبانی از پروژه‌ی خود به نهاد قانونی نیاز خواهم داشت؟ -You don't need a legal entity to support your open source project unless you're handling money. +شما برای پشتیبانی از پروژه‌ی متن باز خود احتیاج به نهاد قانونی نخواهید داشت، مگر اینکه با پول سر و کار داشته باشید. -For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US). +به عنوان مثال، اگر می‌خواهید کسب و کاری ایجاد کنید، باید از طریق «C Corp» یا «LLC» (اگر در ایالات متحده مستقر هستید) اقدام کنید. اگر فقط کارهای پیمانکاری مربوط به پروژه متن باز خود را انجام می‌دهید، می‌توانید به عنوان یک مالک شخصی پول را بپذیرید یا یک «LLC» (اگر در ایالات متحده مستقر هستید) ایجاد کنید. -If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US). +اگر می‌خواهید کمک‌های مالی برای پروژه‌ی متن باز خود بپذیرید، می‌توانید بستری را برای کمک‌های مالی (مثلاً با استفاده از PayPal یا Stripe) ایجاد کنید، اما این مبلغ مشمول کسر مالیت می‌شود، مگر اینکه به عنوان یک سازمان غیرانتفاعی واجد شرایط باشید (اگر در ایالات متحده مستقر هستید). -Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. +بسیاری از پروژه‌ها مایل به پذیرفتن مشکلات ناشی از ایجاد سازمانی غیرانتفاعی نیستند، بنابراین در عوض یک حامی مالی غیرانتفاعی پیدا می‌کنند. یک حامی مالی، معمولاً در ازای درصدی از کمک مالی، کمک‌های مالی را از طرف شما قبول می‌کند. [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)، نمونه‌هایی از سازمان‌ها هستند که به عنوان حامی‌های مالی در پروژه‌های متن باز فعالیت می‌کنند -If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. +اگر پروژه‌ی شما رابطه‌ی نزدیکی با زبان یا اکوسیستم خاصی داشته باشد، ممکن است پیش‌زمینه‌ی نرم‌افزاری مرتبط با آن وجود داشته باشد که بتوانید با آن کار کنید. به عنوان مثال، [Python Software Foundation](https://www.python.org/psf/) از [PyPI](https://pypi.org/) پشتیبانی می‌کند، [Python package manager](https://www.python.org/psf/) و [Node.js Foundation](https://foundation.nodejs.org/) به [Express.js](https://expressjs.com/)، که مبتنی بر Node است، کمک می‌کند. \ No newline at end of file From 46d5e6a6563bd362f2e5c6505596594004013974 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Wed, 5 May 2021 14:49:31 +0430 Subject: [PATCH 033/770] Initial translation done. --- _articles/fa/starting-a-project.md | 275 ++++++++++++++--------------- 1 file changed, 137 insertions(+), 138 deletions(-) diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md index 1ace069082f..bc6c3717201 100644 --- a/_articles/fa/starting-a-project.md +++ b/_articles/fa/starting-a-project.md @@ -1,14 +1,8 @@ --- -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. +lang: fa +title: شروع یک پروژه‌ی متن باز / منبع باز / اوپن سورس +description: در این مقاله چیزهای زیادی درباره‌ی دنیای متن بازها می‌آموزید و آماده‌ی انتشار پروژه‌ی متن باز خودتان می‌شوید. 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: @@ -16,296 +10,300 @@ related: - building --- -## The "what" and "why" of open source +## چیستی و چرایی متن باز -So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it. +اگر در حال فکر کردن این هستید که پروژه‌ی متن باز خودتان را شروع کنید؟ به شما تبریک می‌گوییم! دنیا قدردان کمک و مشارکت شماست. اجازه دهید در ادامه درباره پروژه‌های متن باز بیشتر صحبت کنیم و ببینیم چرا مردم پروژه‌هایشان را متن باز می‌کنند. -### What does "open source" mean? +### متن باز به چه معناست؟ -When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses). +زمانی که یک پروژه متن باز یا اوپن سورس باشد، **هر کسی می‌تواند و اجازه دارد به صورت رایگان آن را استفاده، مطالعه، ویرایش و برای هر هدفی که می‌خواهد، توزیع کند**. این اجازه‌ها در [لایسنس متن باز](https://opensource.org/licenses) قید شده و قابل اجراست -Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions. +پروژه‌های متن باز قدرتمند هستند، چون موانعی که در اختیارات و مشارکت‌ها دیده می‌شود را کاهش و به افراد اجازه می‌دهد پروژه‌های خود را به سرعت گستردش و بهبود دهند. یکی دیگر از دلایل قدرتمند بودن متن بازها این است که پتانسیل کنترل محاسبه را بسته به منابع محدود به کاربران می‌دهد. اگر بخواهیم برای روشن شدن مطلب نمونه‌ای بیاوریم، می‌توانیم به کسب‌وکارهایی اشاره کنیم که به جای تکیه بر منابع محصور و محدود محصولات انحصاری فروشنده‌های نرم‌افزار، از نرم‌افزارهای متن بازی استفاده می‌کنند که به آن‌ها اجازه می‌دهد شخصی را استخدام کنند تا آن نرم‌افزار را برای آن‌ها شخصی‌سازی یا بهینه کند. -_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge). +_نرم‌افزارهای رایگان_ همچنین به پروژه‌های متن باز منسوب می‌شود. گاهی هم ممکن است برنامه‌هایی ببینید که [ترکیبی](https://en.wikipedia.org/wiki/Free_and_open-source_software) از اصلاحات «نرم‌افزار متن باز و رایگان» (FOSS) یا «نرم‌افزار متن باز، آزاد و رایگان» (FLOSS) استفاده می‌کنند. خب، باید بگوییم که کلمه‌ی _Free_ (رایگان) و _libre_ (آزاد / رایگان) هر دو به معنای آزادی در استفاده و دسترسی اطلاق می‌شود، [نه قیمت آن](#does-open-source-mean-free-of-charge) -### Why do people open source their work? +### چرا مردم پروژه‌های‌شان را متن باز می‌کنند؟ -[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include: +[دلایل زیادی وجود دارد](https://ben.balter.com/2015/11/23/why-open-source/) که یک شخص یا سازمان بخواهد پروژه‌های خود را متن باز کند. این دلایل عبارتند از: -* **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. +* **مشارکت:** هر فردی در دنیا می‌تواند پروژه‌های متن باز را تغییر دهد و در ویرایش آن مشارکت داشته باشد. به عنوان نمونه، Exercism که به عنوان یک پلتفرم متن باز برای تمرین برنامه‌نویسی شناخته می‌شود، با مشارکت افراد مختلف تا به الان بیش از 350 توزیع و ویرایش داشته است. -* **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). +* **اقتباس و تغییر مجدد:** هر فردی تقریباً با هر هدفی می‌تواند از پروژه‌های متن باز استفاده کند. افراد حتی می‌توانند از یک پروژه، پروژه‌های دیگری به وجود بیاورند. به عنوان مثال می‌توانیم به [وردپرس](https://github.com/WordPress) اشاره کنیم که از پروژه موجودی به نام [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). +* **شفافیت:** هرکسی می‌تواند خطاها و تناقض پروژه‌های متن باز را بازرسی کند. از این رو، شفافیت برای دولت‌هایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://sourcecode.cio.gov/) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرم‌افزار امنیتی مانند [Let’s Encrypt](https://github.com/letsencrypt) اهمیت بالایی پیدا می‌کند تا زمان بازرسی خطاها توسط افراد مختلف، دچار مشکل نشوند. -Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source. +ویژگی متن باز فقط مختص به نرم‌افزارها نیست، شما هر چیزی حتی مجموعه‌ای از داده‌های یک کتابخانه را می‌توانید متن باز کنید. اگر می‌خواهید بیشتر بدانید که چه چیزهای دیگری را می‌شود متن باز کرد، می‌توانید به [GitHub Explore](https://github.com/explore) مراجعه کنید. -### Does open source mean "free of charge"? +### آیا پروژ‌های متن باز «مجانی / رایگان» هستند؟ -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. +به عبارت دیگر، [در لایسنس و گواهینامه‌ی پروژه‌های متن بازها آورده شده است](https://opensource.org/osd-annotated) که هر کسی می‌تواند آن‌ها را استفاده، ویرایش و تقریباً با هر هدفی به اشتراک بگذارد. از این رو، پروژه‌های متن باز به صورت رایگان عرضه می‌شوند و اگر هم استفاده‌ از این پروژه‌ها پولی شود، هر کسی به صورت قانونی می‌تواند از آن کپی بگیرد و درعوض، از نسخه‌ی رایگان آن استفاده کند -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. +در نتیجه، بیشتر پروژه‌های متن باز به صورت رایگان ارائه می‌شوند و از طرفی هم «رایگان بودن / مجانی بودن» به عنوان بخشی از تعریف پروژه‌های متن باز به حساب نمی‌آید، یعنی پروژه‌های متن باز هم به صورت رایگان و هم به صورت پولی هستند. البته راههایی سازگار با مجوزهای متن باز مثل ارائه مجوز دوگانه یا محدودکردن ویژگی ها به دو دسته رایگان و پولی برای کسب درآمد غیرمستقیم از پروژه‌های متن باز وجود دارد. -## Should I launch my own open source project? +## آیا پروژه‌ی متن باز خودم را باید منتشر کنم؟ -The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works. +اگر بخواهیم کوتاه جواب بدهیم، بله. چون خروجی پروژه‌ی شما مهم نیست. مهم این است که پروژه‌تان منتشر شود و بهترین راه هم برای یاد گرفتن نحوه‌ی کار پروژه‌های متن باز انتشار آن‌هاست. -If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone! +اگر هیچوقت پروژه‌ی متن بازتان را منتشر نکردید، ممکن است این نگرانی برای‌تان پیش بیاید افراد مختلف چه چیزی درباره‌ی پروژه‌تان می‌گویند یا اصلا به پروژه‌ی شما توجه می‌کنند یا خیر. اگر چنین احساسی دارید، باید بگوییم که تنها نیستید. -Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience. +کار یک پروژه‌ی متن باز مانند هر فعالیت خلاقانه‌ی دیگری مثل نویسندگی و نقاشی است. زمانی که شما به عنوان یک هنرمند اولین اثر خود را با دنیا به اشتراک می‌گذارید، احساس ترس به سراغتان می‌آید. اما این کار را باید انجام دهید، چون تمرین تنها راه بهتر شدن است؛ حتی اگر یک مخاطب هم نداشته باشید. -If you're not yet convinced, take a moment to think about what your goals might be. -### Setting your goals +اگر هنوز هم متقاعد نشدید، به این فکر کنید که اهداف‌تان چه چیزهایی می‌توانند باشند. -Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_ +### اهداف‌تان را مشخص کنید -There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals. +اهداف می‌تواند به شما کمک کند تا متوجه شوید که بر روی چه چیزی کار کنید، به چه چیزی نه بگویید و کجا به کمک دیگران نیاز دارید. با سوال کردن از خودتان شروع کنید. از خودتان بپرسید: _چرا می‌خواهم این پروژه را متن باز کنم؟_ -If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome. +خب، واضح است که هیچ کس جواب درستی برای این سوال ندارد. چون ممکن است چندین هدف برای یک پروژه یا پروژه‌های مختلفی با اهداف متفاوتی وجود داشته باشد. + +اگر نمایش دادن کارتان تنها هدف برای متن باز کردن پروژه‌تان باشد، احتمالاً مشارکت دیگران را نمی‌خواهید و این نخواستن مشارکت را هم در فایل README پروژه‌تان نیز می‌آورید. از طرف دیگر، اگر واقعاً مشارکت دیگران را بخواهید، زمان خود را صرف مرتب کردن اسناد و صرف خوشامدگویی به افرادی می‌کنید که تازه وارد این حوزه شدند. -As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project. +وقتی که پروژه‌ی شما رشد می‌کند، جامعه‌ی مخاطب پروژه‌هایتان احتمالاً بیشتر از یک کد به شما نیاز خواهند داشت. وظایف مهمی که در یک پروژه‌ی متن باز به شما محول می‌شود این است که برای مشکلات پاسخی داشته باشید، کدها را بررسی کنید و مژده‌ی پروژه‌ی متن بازتان را به دیگران بدهید. + +اگرچه مدت زمانی که صرف کارهای غیرکدنویسی می‌کنید، به اندازه و دامنه‌ی پروژه‌یتان بستگی دارد، اما به عنوان یک مسئول‌نگهداری پروژه باید خودتان را آماده کنید آن‌ها را انجام دهید یا حداقل شخصی را پیدا کنید که در کارهای غیرکدنویسی به شما کمک کند. -While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you. -**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community. +**اگر جزئی از یک پروژه‌ی متن باز یک شرکت هستید،** مطمئن شوید پروژه‌یتان منابع لازم داخلی برای پیشرفت را داشته باشد. از این رو، باید بدانید که چه کسی مسئول نگهداری پروژه‌ی متن بازتان است و چگونه می‌خواهید این وظایف را با جامعه‌ی خود به اشتراک بگذارید -If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early. +اگر برای ارتقاء، بهره‌برداری و نگهداری پروژه به بودجه خاص یا کارمند نیاز دارید، می‌توانید این نیازها را در ابتدا اعلام کنید. -### Contributing to other projects +### مشارکت در سایر پروژه‌ها -If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation. +اگر هدف‌تان این باشد که با دیگران در پروژه‌های متن باز همکاری کنید یا می‌خواهید نحوه‌ی عملکرد یک پروژ‌ه‌ی متن باز را درک کنید، همکاری و مشارکت با پروژه‌های موجود را در نظر بگیرید. با پروژه‌ای شروع کنید که قبلا به آن علاقه‌مند بودید و از آن استفاده می‌کردید. مشارکت در یک پروژه‌ی متن باز می‌تواند به سادگی اصلاح یک کد اشتباه یا آپدیت / به‌روزرسانی اسناد باشد. -If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/). +اگر مطمئن نیستید که چگونه می‌توانید در سایر پروژه‌ها مشارکت کنید، به مقاله‌ی [راهنمای نحوه‌ی همکاری در پروژه‌ی متن باز](../how-to-contribute/) مراجعه کنید -## Launching your own open source project +## انتشار پروژه‌ی متن باز خودتان -There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source. +زمان مناسبی برای متن باز کردن پروژه‌تان وجود ندارد. از این رو، می‌توانید یک ایده، کارهایی در دست اقدام یا پروژه‌هایی که بعد از سال‌ها بسته ماندند، را متن باز کنید. -Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work. +به طور کلی، هر زمان که احساس کردید با دیدگاه‌ها و بازخوردهای دیگران راحت هستید، باید پروژه‌یتان را متن باز کنید. -No matter which stage you decide to open source your project, every project should include the following documentation: +مهم نیست در چه مرحله‌ای تصمیم گرفتید پروژه‌تان را متن باز کنید. هر پروژه‌ای باید حاوی اسناد زیر باشد: -* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [لایسنس متن باز](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) * [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) -* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) -* [Code of conduct](../code-of-conduct/) +* [راهنمای مشارکت](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [آیین نامه رفتار](../code-of-conduct/) + +این مؤلفه‌ها به شما به عنوان مسئول‌نگهداری پروژه کمک می‌کند تا انتظارات‌تان را بیان، مشارکت‌ها را مدیریت و از حقوق قانونی خود و دیگران محافظت کنید. این موارد شانس شما را برای داشتن یک تجربه‌ی خوب افزایش می‌دهد. -As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience. +اگر پروژه‌ی شما در GitHub قرار دارد، قرار دادن فایل‌های فوق به همراه نام فایل‌های توصیه‌شده در پوشه ریشه (root) می‌تواند به GitHub کمک کند تا آن‌ها را به صورت خودکار به مخاطبان‌تان شناسایی کند و نمایش دهد. -If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers. +### انتخاب لایسنس یا مجوز -### Choosing a license +لایسنسِ یا مجوز یک پروژه‌ی متن باز به دیگران ضمانت می‌دهد از پروژه‌ی متن باز استفاده، کپی، ویرایش و بدون هیچ عواقبی در آن مشارکت کنند. لایسنس همچنین از شما در برابر موقعیت‌های سخت قانونی محافظت می‌کند. **زمانی که می‌خواهید پروژه‌ی متن بازتان را منتشر کنید، حتما لایسنس آن را هم ضمیمه کنید**. -An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.** +کارهای ادارای و حقوقی برای گرفتن لایسنس هیچ جذابیتی ندارد، اما خبر خوب اینجاست که می‌توانید لایسنس‌های موجود و در دسترس را که از قبل توسط دیگران تدوین شده را در repository (مخزن) خود کپی و پیست کنید. برای محافظت از تلاشی که برای متن باز کردن پروژه‌تان انجام دادید، این کار تنها یک دقیقه وقت شما را می‌گیرد. -Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work. +[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) و [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) جزء محبوب‌ترین لایسنس‌های متن باز هستند. هرچند، لایسنس‌های دیگری هم وجود دارد که می‌توانید از آن‌ها استفاده کنید. -[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from. +زمانی که پروژه‌ی جدیدی در GitHub ایجاد می‌کنید، به شما امکان انتخاب لایسنس داده می‌شود. انتخاب کردن لایسنس باعث می‌شود GitHub پروژه‌ی شما را متن باز نشان دهد. -When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source. +![انتخاب مجوز](/assets/images/starting-a-project/repository-license-picker.png) -![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) +در ادامه‌ی مقاله، سایر سوالات و نگرانی‌هایتان درباره‌ی [جنبه‌های قانونی](../legal/) مدیریت پروژه‌ی متن بازتان را بررسی خواهیم کرد. -If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/). +### نوشتن فایل «README» (فایلی که توضیحات پروژه در آن آورده می‌شود) -### Writing a README +فایل README اطلاعات بیشتری نسبت به این دارد که نحوه‌ی استفاده از پروژه‌تان را به کاربر توضیح دهد. این فایل همچنین توضیح می‌دهد که پروژه‌ی شما چه اهمیتی دارد و کاربران‌تان با این پروژه چه کارهای می‌توانند انجام دهند. -READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it. +سعی کنید در فایل README خودتان به سوالات زیر پاسخ دهید و جواب آن‌ها را در فایل بیاورید: -In your README, try to answer the following questions: +* پروژه‌ی شما چه کاری انجام می‌دهد؟ +* چرا این پروژه مفید است؟ +* چگونه شروع کردم؟ +* در صورت نیاز، از کجا می‌توانم کمک بیشتری دریافت کنم؟ -* What does this project do? -* Why is this project useful? -* How do I get started? -* Where can I get more help, if I need it? -You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down. +شما با فایل README می‌توانید به سایر سوالات نیز پاسخ دهید؛ سوالاتی مانند اینکه چگونه مشارکت‌تان را مدیریت می‌کنید، اهداف پروژه‌تان چیست و اطلاعات لایسنس و اختیارات پروژه‌تان را هم می‌توانید بیاورید. اگر مشارکت کسی را نمی‌خواهید قبول کنید، یا پروژه‌ی شما هنوز برای ارائه آماده نشده باشد، می‌توانید این توضیحات را در فایل README بیاورید -Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one. +بعضی از افراد از نوشتن فایل README خودداری می‌کنند، چون فکر می‌کنند پروژه‌ی آن‌ها هنوز تکمیل نشده یا اینکه نمی‌خواهند کسی مشارکتی داشته باشد. همین‌ها دلایل خیلی خوبی برای نوشتن یک فایل README محسوب می‌شوند. -For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. +برای نوشتن یک فایل README کامل، می‌توانید به مقالات @dguo’s ["Make a README" guide](https://www.makeareadme.com/) یا @PurpleBooth’s [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) مراجعه کنید و از آن‌ها الهام بگیرید -When you include a README file in the root directory, GitHub will automatically display it on the repository homepage. +زمانی که فایل README را در دایرکتوری ریشه خود قرار می‌دهید، GitHub به صورت خودکار آن را در صفحه‌ی اصلی repository (انبار) نشان می‌دهد. -### Writing your contributing guidelines +### نوشتن راهنمای مشارکت -A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on: +فایل CONTRIBUTING (مشارکت) به مخاطبان‌تان می‌گوید که چگونه در پروژه‌ی شما مشارکت کنند. به عنوان مثال، می‌توانید اطلاعات زیر را در آن قید کنید: -* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates)) -* How to suggest a new feature -* How to set up your environment and run tests +* چگونه یک باگ یا مشکل گزارش شود +* چگونه ویژگی جدیدی پیشنهاد دهند +* چگونه محیط پروژه‌تان را تنظیم و آن را برای تست اجرا کنند -In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as: -* The types of contributions you're looking for -* Your roadmap or vision for the project -* How contributors should (or should not) get in touch with you +به علاوه، در فایل CONTRIBUTING می‌توانید جزئیات فنی و انتظارات‌تان را برای مشارکت‌کننده‌ها بیان کنید. به عنوان مثال: -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/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. +برای روشن شدن مطلب اجازه دهید نمونه‌ای بیاوریم. به عنوان مثال، [Active Admin](https://github.com/activeadmin/activeadmin/) [راهنمای مشارکت خود](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) به مشارکت‌کننده‌ها را اینگونه شروع می‌کند -In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution. +> در ابتدا، از شما ممنون هستم که می‌خواهید با Active Admin مشارکت کنید. افرادی مثل شما هستند که باعث می‌شوند Active Admin عملکرد خوبی داشته باشد. -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. +در ابتدایی‌ترین مرحله‌ی پروژه‌تان، فایل 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/). +در طول زمان، ممکن است اطلاعات و سوالات مکرر زیادی به فایل 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. +برای اینکه بدانید چگونه اطلاعات فایل CONTRIBUTING خود را بنویسید، می‌توانید به مقالات @nayafia’s [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) یا @mozilla’s ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) مراجعه کنید -![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg) +[لینک فایل CONTRIBUTING خود را در فایل README قرار دهید](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) تا افرادی که آن را مطالعه می‌کنند این فایل مشارکت را هم ببینند. اگر فایل CONTRIBUTING خود را در repository (انبار) (مخزن) پروژه‌تان قرار داده باشید، زمانی که یک مشارکت‌کننده طرح مشکل یا گزارش یک باگ یا درخواست ادغام کند، GitHub به صورت خودکار او را به لینک فایل CONTRIBUTING هدایت می‌کند -### Establishing a code of conduct +![راهنماهای مشارکت](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### تعیین آیین نامه‌ی رفتاری (Code of Conduct) -Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer. +بالاخره، آیین نامه‌ی رفتاری به ما کمک می‌کند برای رفتارهای مشارکت‌کننده‌های پروژه‌تان قوائدی تعیین کنید. زمانی که بخواهید یک پروژه‌ی متن بازی را برای انجمن یا یک شرکت منتشر کنید، این قوائد می‌تواند ارزشمند باشد. آیین نامه‌ی رفتاری یا (Code of Conduct) این قدرت را به شما می‌دهد تا رفتارهای سازنده و سالم را در بین جامعه کاربران ترویج کنید که در آینده به عنوان یک مسئول‌نگهداری پروژه احساس استرس کمتری داشته باشید. -For more information, check out our [Code of Conduct guide](../code-of-conduct/). +برای اطلاعات بیشتر می‌توانید به [راهنمای آیین نامه‌ی رفتاری](../code-of-conduct/) مراجعه کنید. -In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs. +علاوه بر اینکه یک آیین نامه‌ی رفتاری رفتارهایی که از شرکت‌کنند‌هایتان انتظار دارید را باید به آن‌ها بگوید، این را هم باید تعریف کنید که اجرای این انتظارات به چه کسانی و در چه زمان‌هایی باید انجام می‌شود. آیین نامه‌ی رفتاری همچنین مشخص می‌کند که درصورت بروز تخلف چه کاری باید انجام شود. -Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. +مشابه استفاده از مجوزهایی که از قبل توسط دیگران تدوین شده استانداردهای نوظهوری برای آیین نامه‌ی رفتاری وجود دارد که لازم نیست خودتان آن را بنویسید. (https://contributor-covenant.org/)[Contributor Covenant] یکی از جاهایی است که آیین نامه‌هایی در همین خصوص ارائه می‌کند و حاصل کار آن در [بیش از 40.000 پروژه‌ی متن باز](https://www.contributor-covenant.org/adopters) مانند Kubernetes، Rails و Swift استفاده می‌شود. مهم نیست متن آیین نامه‌ی رفتاری شما چیست، مهم این است که در صورت لزوم باید از آیین نامه‌ی رفتاری خودتان استفاده کنید -Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README. +متن آیین نامه‌ی رفتاری خود را مستقیما در فایل CODE_OF_CONDUCT در repository (مخزن) گیت هاب خودتان کپی و پیست کنید. فایل را در دایرکتوری روت پروژه‌تان ذخیره کنید تا پیدا کردن و لینک دادن آن به فایل README راحت باشد. -## Naming and branding your project +## نام‌گذاری و برندسازی پروژه -Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message. +برندسازی چیزی فراتر از یک لوگوی پُر زرق وُ برق یا یک نام جذاب برای پروژه‌تان است. برندسازی نحوه‌ی صبحت کردن درباره‌ی پروژه و نحوه رساندن پیام به مخاطب‌تان را نشان می‌دهد. -### Choosing the right name +### انتخاب نام درست -Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example: +برای پروژه‌تان از نامی استفاده کنید که یادآوری آن ساده باشد. به طور ایده آل، می‌توانید بعضی از ایده‌ها را از پروژه‌های زیر مشاهده کنید. به عنوان نمونه: -* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting -* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server +* [Sentry](https://github.com/getsentry/sentry) اپ ها را با هدف گزارش خطاهای رخ داده در آنها پایش می کند +* [Thin](https://github.com/macournoyer/thin) یک وب سرور ساده و سریع روبی است -If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js). +اگر در حال طراحی پروژه‌تان هستید، به کارگیری نام آن‌ها به عنوان پیشوند می‌تواند به شفاف کردن پروژه‌تان کمک کند. به عنوان نمونه، ([node-fetch](https://github.com/bitinn/node-fetch)، Window.fetch را به Node.js می‌آورد). -Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work! +با در نظر گرفتن توصیه بالا. می‌توان عناوین بامزه یا خوب زیادی ساخت، اما این را به یاد داشته باشید که بعضی از بازی با کلمات و جناس‌ها ممکن است در سایر فرهنگ‌ها یا افرادی که تجربه‌های متفاوتی نسبت به شما دارند، مفهوم یا ترجمه‌ی نادرستی داشته باشد. برخی از کاربران بالقوه شما هم ممکن است کارمندان یک شرکت باشند و حتما نمی‌خواهید زمانی که در حال توضیح دادن نحوه‌ی پروژه‌تان در محل کارشان هستند، احساس نامساعدی داشته باشند. -### 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. +اگر پروژه‌ی شما زبان و اکوسیستم یکسانی دارد، می‌توانید نام پروژه‌های مشابه با پروژه‌تان را [بررسی کنید](http://ivantomic.com/projects/ospnc/). اگر نام پروژه‌ی شما با پروژه‌ی دیگری شباهت زیادی داشته باشد، مخاطب شما ممکن است سردرگم شود. -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. +اگر با یک وب‌سایت، توئیتر یا دیگر شبکه‌های اجتماعی می‌خواهید پروژه‌تان را نشان دهید، مطمئن شوید همان نامی را انتخاب کنید که می‌خواهید. به طور ایده آل، حتی اگر هنوز نمی‌‌خواهید از آن نام استفاده کنید و برای اینکه خیال‌تان راحت باشد، آن نام را [وارونه کنید](https://instantdomainsearch.com/) -Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk. +مطمئن شوید نام پروژه‌ی شما هیچ برند تجاری را نقض نمی‌کند. اگر چنین باشد، آن شرکت می‌تواند بعدها از شما درخواست کند پروژه‌تان را کنسل کرده یا حتی به صورت قانونی با شما برخورد کند. بنابراین، ارزش این همه ریسک را ندارد و برای جلوگیری از چنین مشکلاتی حتما از نام مناسبی استفاده کنید. -You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/). +برای بررسی تضاد و منافات برندهای تجاری می‌توانید به پایگاه داده برندهای جهانی [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) مراجعه کنید. اگر شما یک شخص حقوقی هستید و در یک شرکت فعالیت می‌کنید، این یکی از چیزهایی است که [تیم حقوقی‌تان می‌تواند](../legal/) به شما کمک کند -Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see? +در نهایت، نام پروژه‌تان را به سرعت در گوگل جستجو کنید. ببینید که افراد به راحتی می‌توانند پروژه‌تان را پیدا کنند؟ در نتایج جستجوی شما چیزی دیگر پیدا می‌شود که نمی‌خواهید کاربران آن را مشاهده کنند؟ -### How you write (and code) affects your brand, too! +### چگونه نوشتن و کدنویسی شما روی برندتان اثر می‌گذارد! -Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists. +در طول عمر پروژه‌تان، در حال نوشتن چیزهای زیادی خواهید بود که می‌توان به نوشتن فایل‌های README، آموزش‌ها، اسناد انجمن، نوشتن پاسخ به مشکلات، حتی شاید نوشتن و پاسخ دادن به خبرنامه و فهرست پستی، اشاره کرد. -Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey. +سبک نویسندگی شما چه در اسناد رسمی و چه در ایمیل‌های محاوره‌ای بخشی از برند پروژه‌تان است. به این فکر کنید چگونه می‌خواهید با مخاطب‌تان برخورد کنید و ببینید این لحن نوشتاری همان چیزی است که می‌خواهید به مخاطب فرستاده شود یا خیر. -Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers. +زمانی که از یک زبان جامع و گرم استفاده می‌کنید و حتی زمانی که با یک فرد صحبت می‌کنید، به جای کلمه‌ی «تو» کلمه‌ی «شما» را به کار می‌برید، کمک زیادی به شما می‌کند تا مشارکت‌کننده‌های جدید از پروژه‌ی شما استقبال کنند. اگر می‌خواهید به زبان انگلیسی بنویسید، سعی کنید ساده باشد. چون زبان بیشتر خواننده‌های شما بومی نیست. -Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. +جدا از کلماتی که در نوشتن اسناد مختلف استفاده می‌کنید، سبک کدنویسی شما هم ممکن است به بخشی از برند پروژه‌تان تبدیل شود. به عنوان مثال می‌توانیم به دو نمونه پروژه به نام‌های [Angular](https://angular.io/guide/styleguide) و [jQuery](https://contribute.jquery.org/style-guide/js/) اشاره کنیم که راهنما و سبک کدنویسی سختی دارند -It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. +در ابتدای کار لازم نیست از راهنمای سبک نویسندگی استفاده کنید. به هر حال، به مرور از ترکیب سبک متفاوت کدنویسی خود در پروژه‌تان لذت خواهید برد. هرچند، این را باید پیش‌بینی کنید که نحوه‌ی نویسندگی و سبک کدنویسی شما ممکن است انواع مختلف افراد را جذب یا دفع کند. در ابتدای‌ترین مرحله‌ی پروژه‌تان فرصت دارید مقدماتی که می‌خواهید مخاطبان ببنند را ارائه دهید. -## Your pre-launch checklist +## مرور (چک لیست / لیست بررسی) قبل از انتشار پروژه‌ی متن باز -Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back. +خب، آماده هستید تا پروژه‌تان را متن باز کنید؟ چک لیست در این مرحله می‌تواند به شما کمک کند. تمام گزینه‌ها و تیک‌ها را بررسی کرده‌اید؟ به محض آماده شدن، روی انتشار [publish](https://help.github.com/articles/making-a-private-repository-public/) کلیک کنید و به خودتان تبریک بگویید. -**Documentation** +**مستندات**
-**Code** +**کد**
@@ -313,50 +311,51 @@ Ready to open source your project? Here's a checklist to help. Check all the box -**People** +**افراد** -If you're an individual: +اگر شما شخص حقیقی هستید:
-If you're a company or organization: +اگر شخص حقوقی هستید و در یک سازمان یا یک شرکت فعالیت می‌کنید:
+ یک شخص برای مدیریت تعاملات اجتماعی (پاسخ به مشکلات، بررسی و درخواست ادغام) که متعهد باشد حضور دارد. +
-## You did it! +## انجامش دادی! -Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow. +اولین پروژه‌ی متن بازتان را تبریک می‌گوییم. بهتر است بدانید که خروجی آن مهم نیست، فقط با این کار تجربه‌ی کار در فضای جامعه را به دست آوردید. با هر کامیت (Commit)، کامنت (Comment) و پاسخ به درخواست ادغام فرصتی برای رشد و یادگیری خود و دیگران ایجاد می‌کنید. From 92fdd15c23425f7b79c453eb6a38103607af882e Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Thu, 6 May 2021 08:52:32 +0000 Subject: [PATCH 034/770] Bump rexml from 3.2.4 to 3.2.5 Bumps [rexml](https://github.com/ruby/rexml) from 3.2.4 to 3.2.5. - [Release notes](https://github.com/ruby/rexml/releases) - [Changelog](https://github.com/ruby/rexml/blob/master/NEWS.md) - [Commits](https://github.com/ruby/rexml/compare/v3.2.4...v3.2.5) Signed-off-by: dependabot[bot] --- Gemfile.lock | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Gemfile.lock b/Gemfile.lock index 86995d3742f..33561394aab 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -238,7 +238,7 @@ GEM rb-fsevent (0.10.4) rb-inotify (0.10.1) ffi (~> 1.0) - rexml (3.2.4) + rexml (3.2.5) rouge (3.26.0) ruby-enum (0.9.0) i18n From b489b3592cf3a35683bef3e356d18e57ad22d95a Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Fri, 7 May 2021 15:31:34 +0430 Subject: [PATCH 035/770] Initial translation done. --- _articles/fa/building-community.md | 228 ++++++++++++++--------------- 1 file changed, 114 insertions(+), 114 deletions(-) diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md index a86c8b26c55..906428112c8 100644 --- a/_articles/fa/building-community.md +++ b/_articles/fa/building-community.md @@ -1,12 +1,8 @@ --- -lang: en -title: Building Welcoming Communities -description: Building a community that encourages people to use, contribute to, and evangelize your project. +lang: fa +title: ساخت انجمن های پذیرا +description: ساخت یک انجمن که افراد را به استفاده کردن ، به اشتراک گذاری و تبلیغ کردن پروژه تان ترغیب کند. class: building -toc: - setting-your-project-up-for-success: "Setting your project up for success" - growing-your-community: "Growing your community" - resolving-conflicts: "Resolving conflicts" order: 4 image: /assets/images/cards/building.png related: @@ -14,267 +10,271 @@ related: - coc --- -## Setting your project up for success +## پروژه تان را برای موفقیت راه اندازی کنید -You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around? +وقتی شما پروژه خود را راه اندازی کنید، مطالبی را پخش می کنید و افراد در حال بررسی آنها هستند. حالا سوال اینجا است که چطور باید از آنها بخواهید که در انتظار مطالب‌تان باشند؟ -A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back. +یک انجمن پذیرا ، یک نوع سرمایه گذاری برای شهرت و آینده پروژه تان است. اگر پروژه تان در حال آغاز کسب مشارکتهای اولیه اش است، با اعطای یک تجربه مثبت به مشارکت کننده های اولیه شروع کنید، و برای آنها به عقب برگشتن را ساده سازید -### Make people feel welcome -One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): +### کاری کنید تا افراد احساس پذیرفته شدن داشته باشند + +یک راه برای تفکر درباره انجمن پروژه تان از طریق آنچه مایک مک کویید آن را [قیف مشارکت کننده](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) می نامد میسر است. ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) -As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more. +در حین اینکه شما انجمن خود را می سازید، در نظر بگیرید چطور فردی در بالای قیف( یک کاربر بالقوه) می تواند از لحاظ نظری راهش را به ته قیف ( یک نگهدارنده فعال) هموار سازد. هدف شما این است که ناسازگاری در هر مرحله تجربه مشارکت کننده را کاهش دهید. وقتی افراد، بردهای آسانی دارند، آنها انگیزه بیشتری برای ادامه کار دارند. + +با مستندات خود شروع کنید: -Start with your documentation: +* **برای افراد استفاده از پروژه خود را ساده سازید:** یک مثال از آن کد واضح و [README دوستانه](../starting-a-project/#writing-a-readme) است که راه اندازی پروژه تان را برای هر کسی هموارتر می سازد. +* **بطور واضح توضیح دهید که مشارکت چگونه است،** البته این کار با استفاده از [فایل مشارکت](../starting-a-project/#writing-your-contributing-guidelines) و به روز نگه داشتن موضوعات میسر است. -* **Make it easy for someone to use your project.** [A friendly README](../starting-a-project/#writing-a-readme) and clear code examples will make it easier for anyone who lands on your project to get started. -* **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date. -* **Good first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level. +* **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس GitHub، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد. -[GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) showed incomplete or confusing documentation is the biggest problem for open source users. Good documentation invites people to interact with your project. Eventually, someone will open an issue or pull request. Use these interactions as opportunities to move them down the funnel. +{نظرسنجی منبع باز( اوپن سورس) 2017 GitHub][GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) که مستندات ناقص و گیچ کننده ای را نشان می داد، بزرگترین مشکل برای کاربران منبع باز می باشد. مستندات خوب، افراد را دعوت می کند که با پروژه‌تان تعامل کنند. در نهایت افراد یک موضوع یا یک درخواست pull( ادغام یا یکپارچگی) را باز خواهند کرد. از این تعاملات به عنوان فرصتهایی برای سوق دادن آنها به پایین قیف استفاده کنید. -* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back. -* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project. -* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help. -* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it. +* **وقتی شخص جدیدی وارد پروژه شما می شود، از وی از روی علاقه تشکر کنید!** این یک تجربه منفی خواهد بود که از فردی بخواهید که از پروژه تان خارج نشود. +* **پاسخگو باشید:** اگر شما به موضوعاتشان در عرض یک ماه پاسخ نمی دهید، شانس اینکه پروژه تان را فراموش کنند بالا می رود. +* **درباره انواع مشارکت هایی که خواهید پذیرفت ، پذیرای عقاید و افکار جدید باشید.** بسیاری از مشارکت کننده ها با یک گزارش باگ یا ترمیم جزئی آغاز می کنند. راه های زیادی برای مشارکت در یک پروژه وجود دارد. به افراد اجازه دهید تا بازگو کنند [چطور می خواهند مساعدت کنند](../how-to-contribute/#what-it-means-to-contribute). +* **اگر یک مشارکتی وجود دارد که شما با آن مخالف هستید،** از آنها به خاطر بیان ایده تشکر کرده و [توضیح دهید](../best-practices/#learning-to-say-no) چرا آن ایده با محدوده پروژه تان تناسب ندارد، و اگر مستندات خوبی دارید رو کنید. -The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute. +اکثریت مشارکت کنندگان منبع باز، مشارکت کنندگان اتفاقی هستند: افرادی که تنها گهگاه در یک پروژه مشارکت می کنند. یک مشارکت کننده اتفاقی شاید زمان کافی برای همگامی با پروژه تان را نداشته باشد، پس کارتان این است که مشارکت را برای او تا حد ممکن ساده تر سازید. -Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself. +ترغیب کردن مشارکت کنندگان دیگر یک سرمایه گذاری روی خودتان می باشد. وقتی شما بزرگترین طرفدارانتان را توانمند می سازید تا با کاری که آنها با انجامش هیجان زده می شوند همگام شوند، فشار کمی برای انجام کامل کار توسط خودتان اعمال می شود. -### Document everything +### مستند کردن همه چیز -When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public. +وقتی شما یک پروژه جدید را آغاز می کنید، شاید احساس طبیعی تان این باشد که کارتان را باید خصوصی ادامه دهید. اما پروژه های منبع باز هنگامی شما را برمی انگیزند که شما پروسه تان را بطور علنی مستند می سازید. -When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed. +وقتی شما کارها را می نویسید، افراد بیشتری می توانند در هر مرحله از رویه ها مشارکت کنند. شما ممکن است درباره چیزی کمک بخواهید چیزی که حتی در حد لزوم هم آن را نمی دانستید. -Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public. +مکتوب کردن چیزها معنایی بیشتر از مستندسازی فنی صرف دارد. هر زمان شما احساس می کنید که مصر هستید تا کاری را مکتوب کنید یا بطور خصوصی پروژه تان را بحث کنید، از خودتان بپرسید که آیا می توانید آنرا علنی کنید یا نه؟ -Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions. +درباره نقشه مسیر پروژه تان ، انواع مشارکت هایی که شما در پی آنها هستید، اینکه چطور مشارکت ها بررسی می شوند یا اینکه چرا تصمیمات خاصی را اتخاذ می کنید ، شفاف سازی کنید. -If you notice multiple users running into the same problem, document the answers in the README. +اگر شما کاربران متعددی را مطلع سازید تا مسئله مشابهی را بررسی کنند، جوابها را در README مستند سازید. -For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you. +برای جلسات، منتشر کردن یادداشت ها و نقشه های مسیر خود در یک موضوع مرتبط را مدنظر قرار دهید. بازخوردی که از این سطح از شفافیت کسب می کنید شاید شما را شگفت زده کند. -Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on. +مستندسازی همه چیزها با کاری که شما انجام می دهید نیز همگام است. اگر شما در حال کار بر روی آپدیت کردن پروژه تان در حجم زیاد هستید، برای آن یک بخش درخواست pull اعمال کنید و آن را به عنوان کاری که در حال پیشرفت است نمره دهید(WIP). از این طریق، افراد دیگر می توانند در پروسه شما اعمال نظر کنند -### Be responsive +### پاسخگو باشید -As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started. +در حین اینکه شما [پروژه تان را ارتقا می دهید](../finding-users)، افراد شاید بازخوردهایی برای شما داشته باشند. آنها ممکن است درباره اینکه چطور موارد کار می کنند سوالاتی داشته باشند، یا برای شروع نیاز به کمک داشته باشند. -Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating. +سعی کنید که هنگامی که شخصی یک موضوع را پیوست می کند، تحویل می دهد یا درخواستی دارد یا درباره پروژه تان سوالی می پرسد پاسخگو باشید. وقتی شما به سرعت پاسخ دهید، افراد احساس خواهند کرد که آنها بخشی از یک گفتگو هستند و درباره مشارکت با شما مشتاق تر خواهند بود. -Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466): +حتی اگر نمی توانید درخواستشان را فوراً بررسی کنید،حداقل از آنها تشکر کنید تا به افزایش مشارکت کمک کرده باشید. اینجا بیان می شود چطور @tdreyno به یک درخواست pull در سایت [Middleman](https://github.com/middleman/middleman/pull/1466) پاسخ داده است: ![Middleman pull request](/assets/images/building-community/middleman_pr.png) -[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution. +[یک مطالعه موزیلا](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) پی برده است که مشارکت کنندگانی که بررسی های کدگونه را در ظرف 48 ساعت دریافت کرده بودند میزان برگشت و تکرار مشارکت خیلی بیشتری داشتند -Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project. +همچنین مکالمات درباره پروژه تان می تواند در محل های د Oیگری در اینترنت مانند Stackverflow ، توییتر، یا Reddit روی دهد. شما می توانید در برخی از این محل ها نوتیفیکیشن هایی را اجرا کنید و بدین طریق هنگامی که شخصی به پروژه تان اشاره می کند، با خبر شوید. -### Give your community a place to congregate +### به انجمن تان یک محلی برای مشارکت کردن اختصاص دهید -There are two reasons to give your community a place to congregate. +دو دلیل برای اعطای یک محل برای مشارکت در انجمن‌تان وجود دارد. -The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate. +اولین دلیل به خاطر مشارکت کنندگان است. به افراد کمک کنید تا همدیگر را بشناسند. افراد دارای منافع مشترک، بطور اجتناب ناپذیری می خواهند که محلی برای گفتگو درباره آن منافع داشته باشند. و وقتی ارتباطات علنی و قابل دسترس باشد، هر کسی می تواند آرشیوهای گذشته را بخواند تا به مشارکت خود شتاب بخشد. -The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel. +دلیل دوم به خاطر خود شما است. اگر شما به افراد محل عمومی برای صحبت درباره پروژه تان ندهید، آنها احتمالاً با شما مستقیماً تماس خواهند گرفت. در شروع، ظاهراً ساده است که به پیامهای خصوصی با موضوع « فقط اینبار»پاسخ دهید. اما در طول زمان مخصوصاً اگر پروژه تان معروف شود، شما کلافه خواهید شد. در برابر وسوسه ارتباط برقرار کردن با افراد درباره پروژه تان بطور خصوصی مقاومت کنید. در عوض آنها را به یک کانال عمومی معین هدایت کنید. -Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above! +ارتباطات عمومی می تواند در حقیقت هدایت کردن مردم برای باز کردن یک موضوع به جای ایمیل مستقیم یا اظهار نظر کردن روی وبلاگ‌تان باشد. همچنین شما می توانید یک لیست مِیلی داشته باشید، یا یک حساب توییتر، Slack یا کانال IRC برای افراد راه بیاندازید تا درباره پروژه تان گفتگو کنند. یا همه موارد بالا را با هم اعمال کنید! -[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members: +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) هر هفته وقت خود را در ساعات اداری به کمک به اعضای انجمن اختصاص می دهد: -> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features. +> همچنین کاپس هر هفته زمانی را برای پیشنهاد دادن کمک و راهنمایی به انجمن اختصاص می دهد. مالکان کاپس با اختصاص زمان اختصاصی برای کار کردن با تازه واردها، کمک به PRs ، و بحث درباره ویژگی های جدید موافقت کرده اند. -Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address. +استثنائات قابل توجهی در مورد ارتباطات عمومی وجود دارد از قبیلِ: موضوعات امنیتی و نقض کدهای رفتاری حساس. شما باید همیشه راهی پیش پای افراد بگذارید تا این موضوعات را بطور خصوصی گزارش کنند. اگر نمی خواهید که از ایمیل شخصی خود استفاده کنید، یک آدرس ایمیل اختصاصی ایجاد کنید. -## Growing your community +## انجمن‌تان را رشد دهید -Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction. +انجمنها بی نهایت قدرتمند هستند. این قدرت می تواند مفید یا مضر باشد که به این بستگی دارد که چطور آن را اعمال می کنید. در حین اینکه انجمن پروژه تان رشد می کند، راه هایی برای کمک به آن وجود دارد تا به جای نیروی مخرب یک نیروی سازنده باشد. -### Don't tolerate bad actors +### بازیگران بد را تحمل نکنید -Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others. +هر پروژه معروفی ناگزیر افرادی که ضرررسان هستند را نیز جذب خواهد کرد. آنها شاید بحثهای غیرضروری را شروع کنند، درباره ویژگی های جزئی خرده گیری کنند یا برای بقیه قلدری کنند. -Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave. +شما به بهترین نحو تلاش کنید تا یک خطی مشی تحمل-صفر نسبت به این نوع افراد اقتباس کنید. اگر افراد منفی را چک نکنید ، افراد دیگر در جامعه تان را نیز ناراحت خواهند ساخت. آنها حتی شاید پروژه تان را ترک کنند. -Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate. +بحثهای دائمی بر روی جنبه های جزئی پروژه تان، افرا دیگر از جمله خود شما را از تمرکز روی کارهای مهم دیگر بازمی دارد. افراد جدیدی که وارد پروژه تان می شوند شاید این مکالمات را ببینند و در نتیجه مشارکت نکنند. -When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations. +وقتی می بینید رفتار منفی‌ای در پروژه تان رخ می دهد، آن را علنی کنید. با لحن قاطع توضیح دهید که چرا رفتارشان قابل قبول نیست. اگر این مسئله دائماً وجود داشت شاید نیاز داشته باشید که از [آنها بخواهید تا پروژه تان را ترک کنند](../code-of-conduct/#enforcing-your-code-of-conduct). [کد رفتاری‌تان](../code-of-conduct/) می تواند یک رهنمود سازنده برای این مکالمات باشد. -### Meet contributors where they're at +### با مشارکت کنندگان تماس بگیرید و در جریان قرار بگیرید که آنها در کجای کار هستند -Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need. +مستندسازی خوب تنها هنگامی مهمتر می شود که انجمن تان رشد می کند. مشارکت کنندگان اتفاقی که ممکن است با پروژه تان آشنا نباشند ، مستنداتتان را می خوانند تا به سرعت متنی که آنها نیاز دارند را بدست آورند. -In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors. +در فایل Contributing خود، بطور آشکار به مشارکت کنندگان جدید بگویید که چگونه کار خود را شروع کنند. شما شاید حتی بخواهید که یک بخش اختصاصی برای این منظور بسازید. برای مثال [Django](https://github.com/django/django) یک صفحه ویژه برای خوشامدگویی به مشارکت کنندگان جدید دارد ![Django new contributors page](/assets/images/building-community/django_new_contributors.png) -In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started. +در صف موضوعتان ، باگهایی که برای انواع مختلف مشارکت کنندگان مناسب هستند، وجود دارد: برای مثال [_تنها اولین دفعه_](https://kentcdodds.com/blog/first-timers-only) ، « اولین موضوع خوب» یا « مستندات» را برچسب بزنید. این برچسب ها برای فرد جدید، بررسی سریع پروژه و شروع به کار بر روی موضوعاتتان را آسان می سازد -Finally, use your documentation to make people feel welcome at every step of the way. +سرانجام از مستندات‌تان استفاده کنید تا افراد را در هر مرحله از این رویه خرسند سازید. -You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration. +شما هرگز با اکثر افرادی که وارد پروژه تان می شوند تعامل نخواهید کرد. شاید مشارکتهایی وجود داشته باشد که آنها را دریافت نکرده اید چون برخی از افراد نمی دانند از کجا باید مشارکت خود را شروع کنند. حتی کلمات کمی وجود دارند که با آن می توان افراد را از ترک کردن پروژه تان به خاطر اشباع شدن بازداشت. -For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): +برای مثال، در اینجا ما [رهنمودهای مشارکت](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) پروژه [روبینیوس]https://github.com/rubinius/rubinius/) را می آوریم: -> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue. +> ما می خواهیم که کار خود را با قدردانی از شما برای استفاده از روبینیوس شروع کنیم. این پروژه یک کار عاشقانه است و ما از همه کاربرانی که باگها را معرفی می کنند، عملکردها را بهبود می دهند و به مستندسازی کمک می کنند، قدردانی می کنیم. هر مشارکتی مهم است پس از شما برای مشارکت سپاسگزاری می کنیم. اینکه گفته می شود اینجا رهنمودهای کمی وجود دارند که ما از شما بخواهیم تا از آنها پیروی کنید، می تواند باعث موفقیت رسیدگی به موضوعتان شود. -### Share ownership of your project +### مالکیت پروژه تان را به اشتراک گذارید -People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around. +افراد با مشارکت در پروژه هایتان هنگام احساس مالکیت بر آن هیجان زده می شوند. این بدان معنی نیست که شما باید چشم انداز پروژه تان را تغییر دهید یا مشارکتهایی که شما نمی خواهید را بپذیرید. اما هرچه به دیگران اعتبار بیشتری ببخشید، آنها بیشتر انتظار آن را می کشند. -See if you can find ways to share ownership with your community as much as possible. Here are some ideas: +ببینید آیا می توانید تا آنجا که ممکن است راه هایی را برای تسهیم مالکیت با انجمن تان بیابید. در اینجا بعضی ایده ها در این باره ارائه می شوند: + +* **در برابر رفع باگ های ( غیرسرنوشت ساز) ساده مقاومت کنید:** در عوض از آنها به عنوان فرصتهایی برای پذیرش مشارکت کنندگان جدید استفاده کنید، یا شخصی که تمایل به مشارکت دارد، را راهنمایی کنید. شاید در اول غیرطبیعی به نظر برسد، اما سرمایه گذاری‌تان در طول زمان بازدهی‌اش را به تدریج بدست خواهد داد. برای مثال، @michaeljoseph از یک مشارکت کننده خواست تا درخواست Pull خود را درباره موضوع [Cookiecutter](https://github.com/audreyr/cookiecutter) به جای تعمیر آن توسط خودش ارائه دهد. -* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself. ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) -* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does. +* **یک فایل مشارکت کننده یا مولف در پروژه تان را شروع کنید** تا همه افرادی که به پروژه تان کمک می کردند مانند [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) را لیست کنید. -* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples. +* **اگر شما یک انجمن بزرگ دارید، یک خبرنامه منتشر کنید یا یک پست وبلاگی بنویسید** که قدردان مشارکت کنندگان هستید. خبرنامه های [This Week in Rust](https://this-week-in-rust.org/) و [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) هودی دو نمونه خوب از این موارد هستند. -* **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile. +* **به همه مشارکت کنندگان دسترسی Commit کردن بدهید.** @fleixge پی برد که این کار، [افراد را وادار می کند](https://felixge.de/2013/03/11/the-pull-request-hack.html) تا با هیجان بیشتری patch هایشان را اصلاح کنند و حتی باعث می شود اعضای جدید برای پروژه هایی بیابید که روی آنها سرمایه گذاری نکرده بودید. -* If your project is on GitHub, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators. +* اگر پروژه تان روی گیت هاب است، **آن را از حساب شخصی خود به یک [سازمان](https://help.github.com/articles/creating-a-new-organization-account/) انتقال دهید** و حداقل یک ادمین پشتیبان به آن بیافزایید. سازمان ها کار کردن روی پروژه هایی با همکاران خارجی را آسانتر می سازند. -The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help. +واقعیت این است که [اکثر پروژه ها](https://peerj.com/preprints/1233.pdf) تنها دارای یک یا دو عضو هستند کسانی که اکثر کار را انجام می دهند. هرچه پروژه تان بزرگتر باشد، و هرچه انجمن تان بزرگتر باشد، دستیابی به کمک ساده تر خواهد بود. -While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help. +در حالی که شاید همیشه شخصی را برای جواب دادن به تماس ها نیابید، اما فرستادن سیگنالهایی به آنجا شانسی که افراد دیگر در پروژه همکاری بکنند را افزایش خواهد داد. و اینکه هرچه زودتر اقدام کنید، افراد زودتر می توانند به شما کمک کنند. -## Resolving conflicts +## حل و فصل تضادها -In the early stages of your project, making major decisions is easy. When you want to do something, you just do it. +در مراحل اولیۀ پروژه تان، اتخاذ کردن تصمیمات بزرگ ساده است. وقتی می خواهید که کاری را انجام دهید، شما فقط مشغول انجام آن شوید. -As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own. +در حین اینکه پروژه تان معروف تر می شود، مردم بیشتری از تصمیماتی که شما اتخاذ می کنید سود می برند. حتی اگر انجمن بزرگی از مشارکت کنندگان را ندارید، و اگر پروژه تان دارای کاربران زیادی نیست، شما افرادی را خواهید یافت که تصمیمات را می سنجند و موضوعاتی مرتبط با خودشان را مطرح می کنند. -For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address. +برای اکثر بخش ها، اگر شما یک انجمن محترم و صمیمی را پرورش می دهید و پروسه تان را علنی مستندسازی کنید، انجمن تان باید قادر باشد تا راه حل را پیدا کند. اما گاهی اوقات شما موضوعی را مطرح می کنید که پرداختن به آن یک کمی دشوارتر است. -### Set the bar for kindness +### قالبی برای نوع دوستی تعیین کنید -When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you. +وقتی انجمن تان با یک موضوع خاص مواجه است، مجرب ها ممکن است داوطلب شوند. افراد ممکن است عصبی شوند یا اشباع شوند و آن وظیفه را به شما یا دیگری محول کنند. -Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive. +کارتان به عنوان یک نگاهدارنده آن است که از وخیم تر شدن شرایط جلوگیری کنید. حتی اگر شما عقیده قوی‌ای به این موضوع دارید، سعی کنید که جایگاه یک میانجی یا تسهیل کننده را داشته باشید به جای اینکه به نبرد با دیدگاه تان وارد شوید. اگر شخصی در حال بی مهر شدن است یا دارد مکالمات را انحصاری می سازد، [فوراً اقدام کنید](../building-community/#dont-tolerate-bad-actors) تا مباحثات را مدنی و سودمند نگه دارید. -Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly. +افراد دیگر به رهنمودهای شما نگاه می کنند. یک نمونه خوب را تعیین کنید، شما هنوز می توانید ناامیدی، ناراحتی یا نگرانی را اظهار کنید اما آرامش خود را کاملاً حفظ کنید. -Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you. +خونسرد بودن آسان نیست، اما نشان دادن رهبری ، سلامت انجمن تان را بهبود می بخشد. اینترنت از شما تشکر می کند. -### Treat your README as a constitution +### فایل README خود را به عنوان یک قانون اساسی در نظر بگیرید -Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion. +فایل README تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#writing-a-readme)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره README تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی README تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید. -### Focus on the journey, not the destination +### تمرکز روی سفر نه مقصد -Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns. +برخی پروژه ها از یک فرایند رای گیری استفاده می کنند تا تصمیمات بزرگی را اتخاذ کنند. در حالی که در نگاه اول معقول به نظر می رسد، اما رای گیری به جای گوش دادن و پرداختن به نگرانی های همدیگر روی دستیابی به یک جواب تاکید می کند. -Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place. +رای گیری می تواند سیاسی باشد، که در آن اعضای انجمن برای انجام منافع همدیگر یا رای دادن در یک راه خاص احساس تحت فشار قرار داشتن کنند. البته همه رای نمی دهند، چه [اکثریت انجمن تان سکوت پیشه کنند](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) چه کاربران فعلی که از رای آگاهی ندارند در حال جایگزین شدن باشند. -Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus. +گاهی اوقات، رای گیری یک رهگشای ضروری است. هرچه شما بیشتر توانمند باشید به جای خودِ اجماع بیشتر روی « اجماع‌جویی» تاکید می کنید. -Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion. +تحت یک فرایند اجماع جویی ، اعضای انجمن، نگرانی های بزرگ خود را بحث می کنند تا آنها احساس کنند که حرفهایشان شنیده می شود. وقتی تنها نگرانی های کوچک باقی می ماند، انجمن روی به جلو حرکت می کند.« اجماع جویی مهر تاییدی بر این مطلب است که یک انجمن شاید قادر نباشد که به یک جواب جامع دست یابد. در عوض، آن به گوش سپاری و مباحثه اولویت می دهد. -Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions. +حتی اگر شما در عمل به عنوان یک نگهدارنده پروژه یک فرایند اجماع‌جویی را اقتباس کنید، مهم است که بدانید چه افرادی در حال گوش دادن هستند. وادار کنید دیگر افراد احساس کنند که شنیده می شوند و متعهد شوید که نگرانی هایشان را حل می کنید، و راه طولانی انتشار شرایط حساس را طی می کنید. سپس حرفهایتان را با اقداماتتان مقایسه کنید. + +با به خاطر داشتن یک راه حل به یک تصمیم متمایل نشوید. مطمئن شوید که همه افراد احساس شنیده شدن می کنند و اینکه همه اطلاعات قبل از حرکت به سوی راه حل علنی شده اند. -Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution. +### مکالمه را بطور متمرکز روی کار عملی حفظ کرده و پیش ببرید -### Keep the conversation focused on action +مباحثه مهم است اما یک تفاوت بین مکالمات سودمند و غیرمفید وجود دارد. -Discussion is important, but there is a difference between productive and unproductive conversations. +مباحثات مادامی که فعالانه به سوی راه حل سوق می یابند را تشویق کنید. اگر واضح است که مکالمه بی فروغ شده یا به خارج از موضوع هدایت شده، گفتگوها دارد شخصی می شود یا افراد وارد بحثهای جزئی و حاشیه ای می شوند، زمان آن فرا رسیده که به مباحثات خاتمه دهید. -Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down. -Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues. +اجازه دادن به این مکالمات که همچنان ادامه یابد نه تنها برای موضوع تحت بررسی بد است بلکه برای سلامت انجمن تان نیز بد است. این کار پیامی می فرستد مبنی بر اینکه این نوع مکالمات مجاز هستند یا حتی انجام آنها مورد تشویق قرار می گیرد و در نتیجه می تواند روحیه افراد را از مطرح کردن و حل کردن موضوعات آتی تضعیف کند. -With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_ +با ذکر هر نکته توسط دیگران یا خودتان، از خود بپرسید که _«چطور این نکته ما را به راه حل نزدیکتر می کند؟»_ -If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation. +اگر مکالمه به سوی حل شدن سوق یافته است از گروه بپرسید که در مرحله بعد باید _چه گامهایی را انتخاب کنید؟_ تا دوباره روی مکالمه متمرکز شوید. -If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it. +اگر یک مکالمه بطور واضح هیچ روزنه ای به سوی راه حل نیافته یا هیچ اقدام واضحی برای عملیاتی شدن وجود ندارد یا اقدام مناسب قبلا اتخاذ شده، موضوع را ببندید و توضیح دهید چرا شما آن را بسته اید. -### Pick your battles wisely +### نبردهایتان را عاقلانه سازید -Context is important. Consider who is involved in the discussion and how they represent the rest of the community. +متن مهم است، در نظر بگیرید چه کسانی در بحث درگیر می شوند و چطور آنها بقیه انجمن را تحت تاثیر قرار می دهند. -Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices. +آیا همه افراد در انجمن در این باره ناراحت هستند یا حتی درگیر این موضوع هستند؟ یا آیا یک دردسرساز منحصر به فرد وجود دارد؟ فراموش نکنید که فقط صداهای فعال را در نظر نگیرید و اعضای ساکت جامعه تان را نیز لحاظ کنید. -If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread. +اگر موضوع ، نیازهای گسترده تر انجمن تان را متجلی نمی سازد، شما شاید نیاز به تایید نگرانی های افراد کمی از انجمن تان داشته باشید. اگر این یک موضوع تکرار شونده بدون یک راه حل واضح باشد، آنها را به مباحثات قبلی درباره این موضوع ارجاع دهید و موضوع را ببندید. -### Identify a community tiebreaker +### راهگشای انجمن تان را شناسایی کنید -With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker. +با یک نگرش خوب و ارتباطات واضح، اکثر شرایط دشوار قابل حل هستند. البته حتی در مکالمه سودمند، می تواند یک تفاوت در عقیده درباره چگونگی پیشرفت رویه ها وجود داشته باشد. در این موارد، یک فرد یا گروه از افرادی را شناسایی کنید که می توانند به عنوان رهگشا عمل کنند. -A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it. +یک رهگشا می تواند نگه دارنده اولیه پروژه باشد یا می تواند یک گروه کوچک از کسانی باشند که مبتنی بر رای گیری تصمیم می گیرند. بطور ایده آل شما یک رهگشا و یک فرایند مرتبط در یک فایل GOVERNANCE را شناسایی کرده اید قبل از اینکه ملزم باشید که از آن استفاده کنید. -Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible. +رهگشایتان، باید یک تصمیم گیرنده نهایی باشد. موضوعات نفاق انگیز فرصتی برای انجمن تان است تا درس بگیرد و تکامل یابد. در آغوش کشیدن این فرصتها و استفاده از یک فرایند همکارانه برای حرکت به سوی یک راه حل هرجایی شدنی است. -## Community is the ❤️ of open source +## اجتماع ها و انجمن ها ❤️ متن باز هستند -Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience. +انجمنهای سالم اما کوشا هزاران ساعت را برای منبع باز در هر هفته اختصاص می دهند. خیلی از مشارکت کنندگان به افراد دیگر به عنوان دلیلی برای کار کردن یا نکردن روی منبع باز اشاره می کنند. با یادگیری اینکه چطور از قدرت بطور سازنده بهره برداری کنید شما باید به افراد خارج از آنجا کمک کنید تا از یک تجربه منبع باز فراموش نشدنی برخوردار شوند. From faabd571cb77a8557540f150236fed9cbaa4f9a9 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Sat, 8 May 2021 02:20:05 +0430 Subject: [PATCH 036/770] Initial translation done. --- _articles/fa/code-of-conduct.md | 111 ++++++++++++++++---------------- 1 file changed, 54 insertions(+), 57 deletions(-) diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md index 0b21e42d458..563ad07cbd4 100644 --- a/_articles/fa/code-of-conduct.md +++ b/_articles/fa/code-of-conduct.md @@ -1,14 +1,8 @@ --- -lang: en -title: Your Code of Conduct -description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. +lang: fa +title: منشور اخلاقی +description: با تصویب و اجرای منشور اخلاقی، رفتار سالم و سازنده را در انجمن (community) خود تسهیل کنید. 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: @@ -16,105 +10,108 @@ related: - leadership --- -## Why do I need a code of conduct? +## چرا به منشور اخلاقی نیاز داریم؟ -A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community. +منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین می‌کند. تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند. -Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time. +منشور اخلاقی نه تنها از شرکت‌کنندگان پروژه بلکه از شما هم محافظت می‌کند. اگر شما از پروژه‌ای نگهداری می‌کنید، ممکن است متوجه شده باشید که نگرش‌های مخرب از طرف دیگر شرکت‌کنندگان باعث می‌شود در طول کار از کار خود خسته یا ناراضی شوید. -A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with. +منشور اخلاقی این امکان را به شما می‌دهد تا رفتاری سالم و سازنده را در جامعه تسهیل کنید. داشتن نگرشی پیشگیرانه، احتمال اینکه شما یا دیگران از پروژه خسته شوید را کاهش می‌دهد و این امکان را برای شما فراهم می‌سازد تا وقتی کسی کاری را اشتباه انجام داد بتوانید با آن مقابله و جلوی آن را بگیرید. -## Establishing a code of conduct +## ایجاد منشور اخلاقی -Try to establish a code of conduct as early as possible: ideally, when you first create your project. +سعی کنید هر چه زودتر منشور اخلاق را ایجاد کنید: در حالت ایده‌آل، هنگامی که پروژۀ خود را شروع می‌کنید. -In addition to communicating your expectations, a code of conduct describes the following: +علاوه بر ابلاغ انتظاراتی که دارید، منشور اخلاقی موارد زیر را شرح می‌دهد: -* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_ -* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_ -* What happens if someone violates the code of conduct -* How someone can report violations +* منشور اخلاقی در چه جاهایی اعمال می‌شود _(فقط در مورد مشکلات و درخواست‌های pull، یا دیگر فعالیت‌های انجمن مانند رویدادها؟)_ +* منشور اخلاقی برای چه کسانی اعمال می‌شود _(اعضای انجمن و نگه‌دارندگان، در مورد حامیان مالی چطور؟)_ +* اگر کسی منشور اخلاقی را نقض کند چه اتفاقی می‌افتد؟ +* چگونه می‌توان تخلفات را گزارش داد؟ -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. +در هر جا که می‌توانید، از دانش پیشین خود استفاده کنید. [عهدنامۀ مشارکت‌کنندگان](https://contributor-covenant.org/) نوعی منشور اخلاقی جا افتاده و مقبول است که بیش از 40،000 پروژۀ متن باز از جمله «Kubernetes»، « «Rails و «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. +[منشور اخلاقی Django](https://www.djangoproject.com/conduct/) و [منشور اخلاقی Citizen](http://citizencodeofconduct.org/) نیز دو نمونۀ خوب دیگر هستند. -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. +فایل «منشور اخلاقی» را در فهرست اصلی پروژه قرار دهید و با لینک کردن آن با فایل‌های CONTRIBUTING یا README، آن را در دیدگاه انجمن خود قرار دهید. -## Deciding how you'll enforce your code of conduct +## تصمیم‌گیری در مورد نحوۀ پیش بردن منشور اخلاقی -You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so: +شما باید **قبل از وقوع** هر گونه تخلفی ابتدا توضیح دهید که منشور اخلاقی شما چگونه عملیاتی می‌شود. چندین دلیل برای اینکار وجود دارد: -* It demonstrates that you are serious about taking action when it's needed. +* نشان می‌دهد که شما جدی هستید و در صورت لزوم اقدام می‌کنید. -* Your community will feel more reassured that complaints actually get reviewed. +* انجمن‌تان نسبت به بررسی شدن شکایات، اطمینان بیشتری پیدا می‌کند. -* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation. +* به انجمن خود در صورت مرتکب شدن به تخلفی اطمینان خواهید داد که روند بازبینی منصفانه و شفاف خواهد بود. -You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group. +شما باید روشی ویژه‌ای (مانند آدرس ایمیل) برای مردم فراهم آورید تا بتوانند تخلفات ناشی از منشور اخلاقی را گزارش دهند و توضیح دهند که چه کسی مرتکب تخلفات شده است. می‌تواند یک نگهدارنده، گروهی از نگهدارنده‌ها یا یک کارگروه ویژۀ منشور اخلاقی باشد. -Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +فراموش نکنید که ممکن است کسی بخواهد در مورد شخصی که این گزارشات را دریافت می‌کند تخلفی را گزارش دهد. در این صورت، برای آن‌ها گزینه‌ای تعبیه کنید تا بتوانند تخلفات را به شخص دیگری گزارش دهند. به عنوان مثال، @ctb و @mr-c در مورد [پروژۀ خود «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.* +> مواردی از سوءرفتار، آزار و اذیت و رفتارهای غیر‌قابل‌قبول را می توان با ایمیل زدن به **khmer project@idyll.org** گزارش داد که فقط «C. Titus Brown» و Michael R. Crusoe» به آن دسترسی دارند. برای گزارش مسئله‌ای در رابطه با هر کدام از آن‌ها، لطفاً به **Judi Brown Clarke** دکترای مدیریت در مرکز «BEACON» برای مطالعۀ تکامل در عمل، مرکز علوم و فناوری «NSF» ایمیل بزنید. -For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project). +برای ایده گرفتن، به [کتابچۀ راهنمای اجرای](https://www.djangoproject.com/conduct/enforcement-manual/) «Django» مراجعه کنید (اگرچه ممکن است بنا به اندازه پروژۀ خود، نیازی به چنین کتابچۀ جامعی نداشته باشید). -## Enforcing your code of conduct +## عملیاتی کردن منشور اخلاقی -Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up. +گاهی اوقات علی‌رغم تلاشی که می‌کنید، شخصی کاری خلاف منشور اخلاقی انجام می‌دهد. روش‌های مختلفی برای پرداختن و عکس‌العمل نشان دادن به رفتار منفی و مضر در هنگام بروز آن وجود دارد. -### Gather information about the situation +### جمع‌آوری اطلاعات در مورد وضعیت -Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment. +با هر یک از اعضای انجمن خود، رفتاری یکسان داشته باشید. اگر گزارشی منوط بر نقص منشور اخلاقی دریافت کردید، آن را جدی بگیرید و موضوع را بررسی کنید، حتی اگر با آن شخص رابطه‌ای نزدیک دارید. با این کار به انجمن خود نشان می‌دهید که برای دیدگاه آن‌ها ارزش قائل هستید و به قضاوت آن‌ها اعتماد دارید. -The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context. +آن عضو خطاکار انجمن ممکن است اولین بار نباشد که مرتکب به خطایی شده و به طور مداوم دیگران را ناراحت می‌کند، یا ممکن است اولین بار آن‌ها باشد. بسته به خطایی که مرتکب می‌شوند، اقدامات لازمی باید اجرا شود. + +قبل از عکس‌العمل نشان دادن، زمان کافی را برای فهمیدن کامل ماجرا صرف کنید. نظرات و گفتگوهای مربوط به گذشتۀ شخص را بررسی کنید تا آن‌ها را بهتر بشناسید و متوجه شوید چرا ممکن است چنین رفتاری از آن‌ها سر بزند. سعی کنید دیدگاه‌های دیگری را غیر از دیدگاه‌های خودتان دربارۀ این فرد و رفتار او جمع‌آوری کنید. -Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior. -### Take appropriate action +### اقداماتی مناسب به کار ببرید + +پس از جمع آوری و بررسی اطلاعات کافی، باید تصمیم بگیرید که چه کاری انجام دهید. همانطور که به قدم بعدی می‌اندیشید، به یاد داشته باشید که هدف شما به عنوان ناظر، ایجاد محیطی امن، محترم و فضایی مشارکتی است. در نظر داشته باشید که تنها مسئلۀ چگونگی برخورد در آن موقعیت مهم نیست، بلکه چگونگی پاسخ و عکس‌العمل شما در آینده‌ی رفتار و انتظارات افراد حاضر در انجمن شما تأثیر می‌گذارد. + +وقتی کسی گزارشی منوط بر تخلف در منشور اخلاقی می‌دهد، رسیدگی به آن وظیفۀ شماست و نه خود او. گاهی اوقات، فرد گزارش‌دهنده با افشای این اطلاعات، آیندۀ شغلی، اعتبار یا ایمنی خود را ممکن است در معرض خطر بزرگی قرار دهد. وادار کردن آن‌ها به مقابله کردن با فرد مزاحم و خاطی می‌تواند فرد گزارش‌دهنده را در موقعیتی مخاطره‌آمیز قرار دهد. شما باید شخصا ارتباط مستقیم با فرد خاطی مورد نظر را مدیریت کنید، مگر اینکه فرد گزارش‌دهنده صریحاً خلاف آن را درخواست کند. -After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward. -When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise. +چند روش وجود دارد که شما می‌توانید با استفاده از آن‌ها با موارد نقض منشور اخلاقی برخورد کنید: -There are a few ways you might respond to a code of conduct violation: +* **به شخص مورد نظر ترجیحاً به طور مشخص‌ و واضح اخطار عمومی دهید** و توضیح دهید که چگونه رفتار او بر دیگران تأثیر منفی می‌گذارد. اخطار به صورت عمومی به بقیۀ افراد انجمن این پیام را می‌رساند که منشور اخلاقی را جدی می‌گیرید. در مکالمه‌های خود خوش‌برخود باشید ولی جدی بمانید. -* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication. +* **به طور خصوصی با شخص مورد نظر صحبت بکنید** تا توضیح دهید که چگونه رفتار او بر دیگران تأثیر منفی می‌گذارد. اگر موقعیت طوری باشد که اطلاعات حساس شخصی فرد در میان باشد، بهتر است از کانال‌های ارتباطی خصوصی استفاده کنید. اگر با شخص به طور خصوصی صحبت می‌کنید، بهتر است کسانی را که برای اولین بار وضعیت را گزارش کرده‌اند مطلع کنید تا بدانند که اقدام کرده‌اید. قبل از پیگیری کردن گزارش مربوطه، از شخص گزارش‌دهنده رضایت بگیرید. -* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them. +گاهی اوقات، نمی‌توان به نتیجه‌ای قطعی رسید. فرد مورد نظر ممکن است در مواجهه با او پرخاشگر یا خصمانه برخورد کند یا تغییری در رفتار خود ایجاد نکند. در این شرایط، ممکن است بخواهید اقدامات جدی‌تری را در نظر بگیرید. مثلا: -Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example: +* **فرد مورد نظر را از ادامۀ همکاری در پروژه تعلیق کنید**، که از طریق منع موقت یا شرکت در هر جنبه‌ای از پروژه اعمال می‌شود -* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project +* **فرد مورد نظر را به طور دائمی** از ادامۀ همکاری در پروژه تعلیق کنید -* **Permanently ban** the person from the project +منع کردن اعضا نباید امری ساده تلقی شود و باید نشان‌دهندۀ اختلاف دائمی در دیدگاه و آشتی‌ناپذیری تلقی شود. این اقدامات را فقط باید در مواقعی پیش بگیرید که مشخص باشد امکان دستیابی به نتیجه‌ای قطعی وجود ندارد. -Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached. +## وظایف شما به عنوان یک نگهدارنده -## Your responsibilities as a maintainer +منشور اخلاقی آیین‌نامه‌ای نیست که به صورت خودسرانه اجرا شود. شما مجری منشور اخلاقی هستید و مسئولیت پیروی از قوانین تعیین شده به وسیله‌ی منشور اخلاقی از وظایف شماست. -A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes. +شما به عنوان نگهدارنده، دستورالعمل‌هایی را برای انجمن خود تعیین می‌کنید و آن دستورالعمل‌ها را مطابق با قوانین مندرج در منشور اخلاقی اجرا می‌کنید. این به معنای جدی گرفتن هر گونه گزارش مربوطی به نقض منشور اخلاقی است. گزارش فرد گزارش‌دهنده باید کاملا جامع و منصفانه بررسی شود. اگر تشخیص دادید رفتاری که آن‌ها گزارش داده‌اند، نقض منشور اخلاقی نیست، این مسئله را به وضوح با آن‌ها در میان بگذارید و توضیح دهید که چرا در این زمینه اقدامی نمی‌کنید. عکس‌العملی که نشان می‌دهند به خودشان مربوط است: باید رفتاری که آن‌ها با آن روبرو بوده‌اند را تحمل کنند یا مشارکت‌شان در انجمن را متوقف سازند. -As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community. +گزارش رفتاری که در واقع منشور اخلاقی شما را نقض نمی‌کند، همچنان نشان‌دهندۀ مشکلی در انجمن شما است و شما باید این مشکل بالقوه را بررسی کرده و چاره‌ای برای آن پیدا کنید. که این ممکن است شامل بازنگری در منشور اخلاقی برای روشن ساختن رفتار قابل‌قبول یا صحبت با شخصی باشد که رفتار وی گزارش شده است و شما باید به فرد بگویید که اگرچه منشور اخلاقی را نقض نکرده‌اند، اما دارند در لبۀ آنچه که از آن‌ها انتظار می‌رود راه می‌روند و موجب ناراحتی در برخی از شرکت‌کنندگان شده‌اند. -A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable. +موضوع مهم این است که شما به عنوان یک نگهدارنده، باید استانداردهای رفتار قابل‌قبول را تعیین و عملیاتی کنید. شما توانایی شکل دادن به ارزش‌های اجتماعی پروژه را دارید و شرکت‌کنندگان انتظار دارند که شما این ارزش‌ها را به صورت منصفانه و یکسان اجرا کنید. -In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way. -## Encourage the behavior you want to see in the world 🌎 +## ترغیب‌کنندۀ رفتاری باشید که می‌خواهید در دنیا آن را مشاهده کنید 🌎 -When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow. +هنگامی که یک پروژه خصمانه یا ناخوشایند به نظر می‌رسد، حتی اگر فقط یک نفر باشد که رفتار او غیرقابل‌تحمل باشد، ممکن است مشارکت‌کنندگان بیشتری را از دست بدهید که حتی ممکن است بعضی از آن‌ها را هرگز ملاقات نکرده باشید. اتخاذ یا اجرای منشور اخلاقی همیشه ساده نیست، اما ایجاد فضایی دوستانه به رشد انجمن شما کمک می کند. From e6bac70d8a1ff4e68979cacbaa27ca90244a974e Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Sun, 9 May 2021 20:05:55 +0430 Subject: [PATCH 037/770] Initial translation done. --- _articles/fa/metrics.md | 123 +++++++++++++++++++--------------------- 1 file changed, 59 insertions(+), 64 deletions(-) diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md index 080b3eea9d4..d7274ce79b5 100644 --- a/_articles/fa/metrics.md +++ b/_articles/fa/metrics.md @@ -1,14 +1,8 @@ --- lang: en -title: Open Source Metrics -description: Make informed decisions to help your open source project thrive by measuring and tracking its success. +title: سنجه‌های پروژه‌های متن باز +description: آگاهانه تصمیم‌گیری کنید تا با ارزیابی و پیگیری موفقیت، به پیشرفت پروژۀ متن باز خود کمک کنید. class: metrics -toc: - why-measure-anything: "Why measure anything?" - discovery: "Discovery" - usage: "Usage" - retention: "Retention" - maintainer-activity: "Maintainer activity" order: 9 image: /assets/images/cards/metrics.png related: @@ -16,117 +10,118 @@ related: - best-practices --- -## Why measure anything? +## چرا چیزی را ارزیابی کنیم؟ -Data, when used wisely, can help you make better decisions as an open source maintainer. +هنگامی که داده‌ها هوشمندانه استفاده شوند، به شما کمک می‌کنند تا به عنوان یک نگهدارندۀ متن باز تصمیمات بهتری بگیرید. -With more information, you can: +با اطلاعات بیشتر، می‌توانید: -* Understand how users respond to a new feature -* Figure out where new users come from -* Identify, and decide whether to support, an outlier use case or functionality -* Quantify your project's popularity -* Understand how your project is used -* Raise money through sponsorships and grants +* درک بهتری از واکنش کاربران به ویژگی‌های جدید داشته باشید +* بفهمید کاربران جدید از کجا آمده‌اند +* موارد کاربردی برجسته و قابلیت‌ها را شناسایی کنید و تصمیم بگیرید که آیا به پشتیبانی از آن‌ها ادامه می‌دهید یا خیر +* محبوبیت پروژۀ خود را بسنجید +* جنبه‌های کاربردی پروژه را درک کنید +* از طریق اسپانسرها و کمک‌هزینه‌ها، پول جمع‌آوری کنید -For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work: +به عنوان مثال، پروژۀ متن باز [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) دریافت که «Google Analytics» به آن‌ها در اولویت‌بندی کارها کمک می‌کند. -> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew. +> «Homebrew» بصورت رایگان در اختیار کاربران قرار می‌گیرد و توسط داوطلبان در اوقات فراغت‌شان اداره می‌شود. در نتیجه، ما منابع لازم برای انجام مطالعات دقیق دربارۀ کاربران «Homebrew» را نداریم تا در مورد چگونگی بهترین طراحی برای ‌آینده و اولویت‌بندی کارهای فعلی تصمیم بگیریم. تجزیه و تحلیل کلی و ناشناس در رابطه با کاربران به ما امکان می‌دهد اصلاحات و ویژگی‌ها را بر اساس شیوه، مکان و زمان استفادۀ کاربران از «Homebrew» اولویت‌بندی کنیم. -Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you. +محبوبیت، همه چیز نیست. دلایل متفاوت زیادی برای ورود افراد در پروژه‌های متن باز وجود دارد. اگر هدف شما به عنوان نگهدارندۀ متن باز این است که کار خود را در معرض نمایش بگذارید، پس همینطور برخورد کنید یا فقط از آن لذت ببرید؛ معیارها برای شما آنچنان مهم نیستند. -If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity. +اگر _می‌خواهید_ به سطح درک عمیق‌تری دربارۀ پروژۀ خودتان برسید، روش‌های تجزیه و تحلیل فعالیت‌های پروژه خود را بدانید. -## Discovery -Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_ +## کشف و پیدا کردن + +قبل از اینکه کسی بتواند از پروژۀ شما استفاده کند یا در آن مشارکت داشته باشد، باید بداند که همچین پروژه‌ای وجود دارد. از خودتان بپرسید: _آیا مردم می‌توانند این پروژه را پیدا کنند؟_ ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) -If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see: +اگر پروژۀ شما در «GitHub» قرار دارد، [می‌توانید ببینید](https://help.github.com/articles/about-repository-graphs/#traffic) افرادی که در پروژۀ شما هستند از کجا آمده‌اند؟ در صفحه پروژۀ خود، روی «Insights» و سپس «Traffic» کلیک کنید. در این صفحه، این موارد را می‌توانید ببینید: -* **Total page views:** Tells you how many times your project was viewed +* **تعداد بازدیدها از صفحه:** به شما می‌گوید پروژه چند بار دیده شده است -* **Total unique visitors:** Tells you how many people viewed your project +* **تعداد بازدیدکنندگان منحصر به فرد:** به شما می‌گوید چند نفر پروژه را دیده‌اند -* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working. +* **سایت‌های ارجاع دهنده یا معرفی‌کننده:** به شما می‌گوید، بازدیدکنندگان از کجا آمده‌اند. این معیار به شما کمک می‌کند تا بفهمید در کجا می‌توانید به مخاطب خود دسترسی پیدا کنید و آیا تلاش‌های تبلیغاتی شما موثر واقع شده است یا خیر. -* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors. +* **محتوای محبوب:** به شما می‌گوید، بازدیدکنندگان به کدام بخش پروژۀ شما می‌روند و شمار بازدیدهای صفحه و بازدیدکنندگان منحصر به فرد را نشان می‌دهد. -[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work. +قسمت [GitHub stars](https://help.github.com/articles/about-stars/) هم می‌تواند به صورت معیاری برای محبوبیت عمل کند.اگرچه «GitHub stars» لزوماً با تعداد دانلودها و استفاده از محتوا ارتباط مستقیمی ندارد، اما این قسمت می‌تواند به شما بگوید که چه تعدادی از آدم‌ها متوجه پروژۀ شما شده‌اند.. -You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites. +همچنین شاید بخواهید قابلیت کشف شدن (شناخته‌ شدن) را در [بخش‌های مشخصی ردیابی کنید](https://opensource.com/business/16/6/pirate-metrics): به عنوان مثال، «Google PageRank»، ترافیک رجوعی به وب‌سایت پروژۀ شما، یا مراجعات از سایر پروژه‌های متنباز یا سایر وب‌سایت‌ها. -## Usage +## استفاده -People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_ +مردم پروژۀ شما را در این دنیای عجیب‌غریبی که اینترنت می‌نامیم، پیدا می‌کنند. در بهترین حالت، وقتی پروژۀ شما را ببینند، به آن مشتاق می‌شوند و می‌خواهند کاری انجام دهند. دومین سوالی که باید از خود بپرسید این است که: _آیا مردم از این پروژه استفاده می‌کنند؟_ -If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads. +اگر از یک برنامۀ مدیریت پکیج (package manager) مانند «npm» یا «RubyGems.org» برای انتشار پروژۀ خود استفاده می‌کنید، می‌توانید دانلودهای مربوط به پروژه را ردیابی کنید. -Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers. +هر برنامۀ مدیریت پکیجی ممکن است تعریف متفاوتی از دانلود داشته باشد و دانلود لزوماً با نصب یا استفاده ارتباط داشته باشد، اما مبنایی را برای مقایسه فراهم می‌کند. برای پیگیری آمارهای مختلف می‌توانید در میان بسیاری از مدیریت‌های محبوب پیکیج، از [Libraries.io](https://libraries.io/) استفاده کنید. -If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners. +اگر پروژۀ شما در «GitHub» است، دوباره به صفحۀ «Traffic» بروید. می‌توانید از نمودار کلون [clone graph](https://github.com/blog/1873-clone-graphs) استفاده کنید تا ببینید چند بار پروژۀ شما در یک روز مشخص کپی شده است، که این نمودار براساس کل کلون‌ها (کپی‌ها) و کپی‌های منحصر به فرد مشخص شده است. ![Clone graph](/assets/images/metrics/clone_graph.png) -If usage is low compared to the number of people discovering your project, there are two issues to consider. Either: +اگر میزان استفاده در مقایسه با تعداد افرادی که پروژۀ شما را پیدا می‌کنند کم است، دو مسئله وجود دارد که باید در نظر بگیرید: + +* مخاطبان به طور موفقیت‌آمیز با پروژۀ شما ارتباط نمی‌گیرند +* یا مخاطبان اشتباهی را جذب کرده‌اید -* Your project isn't successfully converting your audience, or -* You're attracting the wrong audience +به عنوان مثال، اگر پروژۀ شما در صفحۀ اول «Hacker News» قرار گیرد، احتمالاً جهشی در میزان کشف (ترافیک) اما با نرخ گرایش پایینی را مشاهده خواهید کرد؛ زیرا در Hacker News، افراد زیادی پروژۀ شما را پیدا می‌کنند. اگر پروژۀ «Ruby» شما در یک مجمع «Ruby» ارائه شده باشد، به احتمال زیاد نرخ گرایش بالایی از مخاطبان هدف را شاهد خواهید بود. -For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience. +سعی کنید بفهمید مخاطبان شما از کجا می‌آیند و از نظرات دیگران در مورد صفحۀ پروژۀ خود بهره ببرید تا متوجه شوید با کدام یک از این دو مسئله روبرو هستید. -Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing. +وقتی با مخاطبان و افرادی که از پروژۀ شما استفاده می‌کنند آشنا شدید، بهتر است بفهمید که آن‌ها چه استفاده‌ای از پروژه می‌کنند. آیا آن‌ها با فورک کردن کد شما و افزودن ویژگی‌های مختلف، بر روی آن کار می‌کنند؟ آیا آن‌ها از آن برای مصارف علمی یا تجاری استفاده می‌کنند؟ -Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business? -## Retention +## استمرار و نگهداری -People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_ +مردم پروژۀ شما را پیدا می‌کنند و از آن استفاده می‌کنند. سوالی که باید از خودتان بپرسید این است که: _آیا مردم در آن مشارکت هم می‌کنند یا خیر؟_ -It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand). +هیچ‌وقت برای فکر کردن به مشارکت‌کنندگان دیر نیست. اگر پروژۀ شما محبوب باشد (بسیاری از از آن استفاده کنند) و سایر افراد دست به کار نشوند و از آن _پشتیبانی نکنند_ خود را در موقعیتی ناسالم قرار می‌دهید (به اندازۀ کافی نگهدارنده نداشته باشید). -Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things. +نگهداری، مستلزم [ورود مشارکت‌کنندگان جدید](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) است، زیرا مشارکت‌کنندگان فعال قبلی در نهایت به سراغ کارهای دیگر می‌روند. -Examples of community metrics that you may want to regularly track include: +نمونه‌هایی از معیارهای انجمن که باید مرتباً آن‌ها را بررسی کنید، شامل این موارد می‌شود: -* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository. +* **تعداد کل مشارکت‌کنندگان و تعداد تعهدات هر مشارکت‌کننده:** به شما می‌گوید چه تعداد مشارکت‌کننده دارید و چه کسانی کم و بیش فعال هستند. این بخش را می‌توانید در «GitHub» در قسمت «Insights -> Contributors» مشاهده کنید. در حال حاضر، این نمودار فقط مشارکت‌کنندگانی که متعهد به شاخۀ پیش‌فرض مرکز ذخیره‌سازی شده‌اند را مشخص می‌کند. ![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) -* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant. +* **مشارکت‌کنندگان تازه‌کار، عادی، همیشگی:** کمک می‌کند تا پیگیری کنید که آیا مشارکت‌کنندگان جدیدی دریافت می‌کنید یا خیر. (مشارکت‌کنندگان عادی، مشارکت‌کنندگانی با تعهدات کم هستند که البته تعریف «تعهدات کم» به خود شما بستگی دارد و می‌تواند یک یا پنج یا کمتر باشد) بدون مشارکت‌کنندگان جدید، انجمن پروژه راکد و کم‌رونق می‌شود. -* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews. +* **تعداد مسائل در جریان و درخواست‌های باز pull:** اگر بیش از حد زیاد شوند، ممکن است در اولویت‌بندی مسائل و بررسی کدها به کمک نیاز داشته باشید. -* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project. +* **تعداد مسائل باز شده (open issued) و درخواست های باز شدۀ pull:** مسائل باز شده، یعنی کسی به اندازه کافی به پروژۀ شما اهمیت بدهد تا مسئله‌ای را باز کند. اگر این تعداد با گذشت زمان افزایش یابد، نشان‌دهندۀ این است که مردم به پروژۀ شما علاقه‌مند هستند. -* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue. +* **انواع مشارکت‌ها:** به عنوان مثال، نوع تعهدها، رفع اشتباهات یا اشکالات یا اظهار نظر در مورد یک موضوع. -## Maintainer activity +## فعالیت‌های شخص نگهدارنده -Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_ +نگهدارنده‌هایی که پاسخگو نیستند به نقطۀ ضعف پروژه‌های متن باز تبدیل می‌شوند. اگر کسی مشارکتی از خود به جای بگذارد اما هرگز از یک نگهدارنده پاسخی دریافت نکند، ممکن است احساس دلسردی کرده و آنجا را ترک کند. -Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave. +[تحقیقات که در Mozilla شکل گرفت](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) نشان می‌دهد که پاسخگو بودن نگهدارنده عاملی حیاتی در تشویق به مشارکت‌های بیشتر است. -[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions. +در نظر بگیرید که چه مدت طول می‌کشد تا شما (یا نگهدارنده‌ای دیگر) به مشارکت‌ها پاسخ دهید، خواه مسئله‌ای باشد یا درخواست pull. پاسخگو بودن نیاز به اقدام خاصی ندارد. می‌تواند به این سادگی باشد: _«ممنون از درخواست شما! در عرض یک هفته آن را بررسی می‌کنم.»_ -Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_ +همچنین می‌توانید مدت زمانی که برای تکمیل مراحل مختلف فرآیند مشارکت لازم است را اندازه بگیرید، همچون: -You could also measure the time it takes to move between stages in the contribution process, such as: +* متوسط زمان باز ماندن مسئله +* بسته شدن مسئله توسط روابط عمومی (PR) +* بسته شدن مسائل قدیمی +* متوسط زمان ادغام کردن درخواست‌های pull -* Average time an issue remains open -* Whether issues get closed by PRs -* Whether stale issues get closed -* Average time to merge a pull request -## Use 📊 to learn about people +## از آمار 📊 برای درک مردم استفاده کنید -Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive. +درک معیارها (استانداردها) به شما کمک می‌کند تا پروژۀ متن باز فعال و رو به‌ رشدی داشته باشید. حتی اگر هم تمامی معیارها را پیگیری نمی‌کنید، از چارچوب بالا استفاده کنید تا توجه خود را به نوع رفتاری که به پیشرفت پروژه کمک می‌کند متمرکز کنید. From c9a3449e79b25502be76af0a5d232ed5673188ca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Sun, 9 May 2021 23:54:41 +0000 Subject: [PATCH 038/770] Translate how-to-contribute.md via GitLocalize --- _articles/tr/how-to-contribute.md | 244 +++++++++++++----------------- 1 file changed, 101 insertions(+), 143 deletions(-) diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index 142b1f03e22..0f79a454a87 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -10,22 +10,16 @@ toc: finding-a-project-to-contribute-to: Katkıda bulunacak bir proje bulma how-to-submit-a-contribution: Katkı nasıl gönderilir? what-happens-after-you-submit-a-contribution: Bir katkı gönderdikten sonra ne olur? -order: 1 -image: /assets/images/cards/contribute.png +order: '1' +image: "/assets/images/cards/contribute.png" related: -- beginners -- building + - beginners + - building --- ## Açık kaynağa neden katkıda bulunmalıyım? - + Açık kaynağa katkıda bulunmak, hayal edebileceğiniz herhangi bir konuyu öğrenmek, öğretmek ve deneyim geliştirmek için faydalı bir yol olabilir. @@ -67,79 +61,61 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol ### Kod yazarak katkıda bulunmak zorunda değilsin -Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye _büyük bir_ iyilik yapacaksınız! +Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız! - + Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir. - + ### Etkinlik planlamayı sever misiniz? -* [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin -* Projenin konferansını düzenleyin (eğer varsa) -* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun +- [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin +- Projenin konferansını düzenleyin (eğer varsa) +- Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun ### Tasarlamayı sever misiniz? -* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın -* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın -* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın -* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın +- Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın +- [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın +- Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın +- [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın ### Yazmayı sever misin? -* Proje dokümantasyonunu yazın ve geliştirin -* Projenin nasıl kullanıldığını gösteren örnekler oluşturun -* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın -* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın -* Projenin dokümantasyonu için çeviri yapın +- Proje dokümantasyonunu yazın ve geliştirin +- Projenin nasıl kullanıldığını gösteren örnekler oluşturun +- Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın +- [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın +- Projenin dokümantasyonu için çeviri yapın - + ### Organize etmeyi sever misiniz? -* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin -* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) -* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. +- Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin +- Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) +- Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. ### Kod yazmayı sever misiniz? -* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun -* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun -* Proje kurulumunu otomatikleştirin -* Araçları ve testleri geliştirin +- [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun +- Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun +- Proje kurulumunu otomatikleştirin +- Araçları ve testleri geliştirin ### İnsanlara yardım etmeyi sever misiniz? -* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te -* İnsanlar için açık konulardaki soruları cevaplayın -* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun +- Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te +- İnsanlar için açık konulardaki soruları cevaplayın +- Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun ### Başkalarına kod yazarken yardım etmeyi sever misiniz? -* Diğer kişilerin gönderimlerindeki kodu inceleyin -* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın -* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) +- Diğer kişilerin gönderimlerindeki kodu inceleyin +- Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın +- Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) ### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz! @@ -147,21 +123,15 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d Örneğin: -* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) -* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor -* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) +- @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) +- @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor +- @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır. ## Kendinizi yeni bir projeye yönlendirmek - + Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. @@ -177,34 +147,34 @@ Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapıların Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir: -* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) -* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) -* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) -* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes -* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. +- **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) +- **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) +- **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) +- **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes +- **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın. Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir. -* **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. -* **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. -* **CONTRIBUTING:** README dosyaları projeyi insanların _kullanmalarına_ yardımcı olurken, CONTRIBUTING dökümanları insanların projeye _katkıda_ bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. -* **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. -* **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. +- **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. +- **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. +- **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. +- **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. +- **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir. -* **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. -* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. -* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine _"Nasıl ...?"_ veya _"Ne düşünüyorsunuz ...?" gibi_). Diğerleri, tüm konuşmalar için sorun listesini kullanır. -* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. +- **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. +- **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. +- **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. +- **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. ## Katkıda bulunacak bir proje bulma Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı! -Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, _"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"_ diyen ABD Başkanı John F. Kennedy'yi örnek alın. +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. @@ -222,15 +192,15 @@ Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz: -* [GitHub Explore](https://github.com/explore/) -* [Open Source Friday](https://opensourcefriday.com) -* [First Timers Only](https://www.firsttimersonly.com/) -* [CodeTriage](https://www.codetriage.com/) -* [24 Pull Requests](https://24pullrequests.com/) -* [Up For Grabs](https://up-for-grabs.net/) -* [Contributor-ninja](https://contributor.ninja) -* [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +- [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/) +- [Contributor-ninja](https://contributor.ninja) +- [First Contributions](https://firstcontributions.github.io) +- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi @@ -342,13 +312,7 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac - + ## Nasıl katkı yapılır? @@ -358,45 +322,45 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir. - + Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun. **Bağlam ver.** Başkalarının sizi anlamada hızlanmalarına yardımcı olun. Bir hatayla karşılaşıyorsanız, ne yapmaya çalıştığınızı ve nasıl tekrarlanabileceğini açıklayın. Yeni bir fikir önerecekseniz, neden projeye faydalı olacağını düşündüğünüzü açıklayın (sadece sizin için değil!). -> 😇 _"Y yaptığımda X olmuyor"_ -> X _"X çalışmıyor! Lütfen düzeltin."_ +> 😇 *"Y yaptığımda X olmuyor"* +> +> 😢 *"X çalışmıyor! Lütfen düzeltin."* **Ödevini önceden yap.** Bir şeyleri bilmemek normaldir, ama denediğini göster. Yardım istemeden önce, bir projenin README'sini, belgelerini, sorun listesini (açık veya kapalı), e-posta listesini kontrol ettiğinizden ve bir cevap için interneti aradığınızdan emin olun. Öğrenmeye çalıştığını gösterdiğin zaman insanlar takdir edeceklerdir. -> X _"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'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."* +> +> 😢 "X nasıl yapılır?" **İstekleri kısa ve öz tutun.** Bir e-posta göndermek gibi, ne kadar basit veya yararlı olursa olsun, her katkı başkasının incelemesini gerektirir. Birçok projenin, yardım için uygunların yapabileceklerinden daha fazla gelen talebi olur. Basit olun. Birinin size yardım edebilme şansını artıracaksınız. -> 😇 _"Bir API öğretici belgesi yazmak istiyorum."_ -> 😢 _"Geçen gün otoyoldan aşağı iniyordum ve benzin için durdum ve sonra aklıma yapmamız gereken bir şey için inanılmaz bir fikir geldi, ama bunu açıklamadan önce sana göstereyim ..."_ +> 😇 *"Bir API öğretici belgesi yazmak istiyorum."* +> +> 😢 *"Geçen gün otoyoldan aşağı iniyordum ve benzin için durdum ve sonra aklıma yapmamız gereken bir şey için inanılmaz bir fikir geldi, ama bunu açıklamadan önce sana göstereyim ..."* **Tüm iletişimi herkese açık tutun.** Her ne kadar cazip olsa da, hassas bilgileri (güvenlik sorunu veya ciddi davranış ihlali gibi) paylaşmanız gerekmedikçe, geliştiricilere özel olarak ulaşmayın. Sohbeti herkese açık tuttuğunuzda, daha fazla kişi alış verişinizden öğrenebilir ve bundan faydalanabilir. Tartışmalar da kendi başlarına katkı sayılabilir. -> 😇 _(yorum olarak) "@-maintainer Merhabalar! Bu PR'a nasıl devam edelim?"_ -> 😢 _(bir e-posta olarak) "Hey, e-posta yüzünden sizi rahatsız ettiğim için özür dilerim, ancak PR'mi gözden geçirme şansınız olup olmadığını merak ediyordum"_ +> 😇 *(yorum olarak) "@-maintainer Merhabalar! Bu PR'a nasıl devam edelim?"* +> +> 😢 *(bir e-posta olarak) "Hey, e-posta yüzünden sizi rahatsız ettiğim için özür dilerim, ancak PR'mi gözden geçirme şansınız olup olmadığını merak ediyordum"* **Soru sormak sorun değil (ama sabırlı olun!).** Herkes bir zamanlar projede yeniydi ve deneyimli katılımcıların bile yeni bir projeye bakarken hız kazanmaları gerekiyor. Aynı şekilde, uzun süredir devam edenler bile, projenin her bölümüne aşina değildir. Onlara size göstermelerini istediğiniz sabrı gösterin. -> 😇 _"Bu hatayı incelediğiniz için teşekkür ederiz. Önerilerinizi takip ettim. İşte sonuç."_ -> 😢 _"Neden sorunumu çözemiyorsun? Bu senin projen değil mi?"_ +> 😇 *"Bu hatayı incelediğiniz için teşekkür ederiz. Önerilerinizi takip ettim. İşte sonuç."* +> +> 😢 *"Neden sorunumu çözemiyorsun? Bu senin projen değil mi?"* **Topluluk kararlarına saygı gösterin.** Fikirleriniz, toplumun öncelikleri veya vizyonundan farklı olabilir. Geri bildirim sunabilir veya fikrinizi sürdürmemeye karar verebilirler. Tartışmanız ve uzlaşı aramanız gerekirken, geliştiriciler kararınızla sizden daha uzun yaşamak zorundadır. Düşüncelerine katılmıyorsanız, her zaman kendi çatalınızla çalışabilir veya kendi projenizi başlatabilirsiniz. -> 😇 _"Fikrimi destekleyemediğiniz için hayal kırıklığına uğradım, ancak bunun sadece kullanıcıların küçük bir bölümünü etkilediğini açıkladığınızdan, nedenini anlıyorum. Dinlediğiniz için teşekkürler."_ -> 😢 _"Neden fikrimi desteklemiyorsun? Bu kabul edilemez!"_ +> 😇 *"Fikrimi destekleyemediğiniz için hayal kırıklığına uğradım, ancak bunun sadece kullanıcıların küçük bir bölümünü etkilediğini açıkladığınızdan, nedenini anlıyorum. Dinlediğiniz için teşekkürler."* +> +> 😢 *"Neden fikrimi desteklemiyorsun? Bu kabul edilemez!"* **Her şeyden önce, zarif olun.** Açık kaynak dünyanın her yerinden ortak çalışanlardan oluşur. Bağlam diller, kültürler, coğrafyalar ve zaman dilimleri arasında kaybolur. Ek olarak, yazılı iletişim bir ton veya ruh halini iletmeyi zorlaştırır. Bu konuşmaların niyetlerinin iyi olduğunu düşünün. Bir fikre kibarca geri dönmek, daha fazla içerik istemek veya konumunuzu daha da netleştirmek iyi bir şey. İnterneti bulduğunuzdan daha iyi bir yer bırakmaya çalışın. @@ -406,53 +370,47 @@ Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığ Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız: -* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir -* **PR** bir çözüm üzerinde çalışmaya başlamak içindir -* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. +- **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir +- **PR** bir çözüm üzerinde çalışmaya başlamak içindir +- **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. Bir sorun açmadan veya talepte bulunmadan önce, belirli bir şey eklemeniz gerekip gerekmediğini görmek için projenin katkıda bulunma belgelerini (genellikle CONTRIBUTING veya README dosyaları) kontrol edin. Örneğin, bir şablon izlemenizi istenebilir veya test ortamı kullanmanız gerekebilir. Önemli bir katkı yapmak istiyorsanız, üzerinde çalışmadan önce sormanız gereken bir sorun açın. Projeyi bir süre izlemeniz yararlı olacaktır (GitHub'da, tüm konuşmalar size bildirilmek için ["İzle"yi tıklayabilirsiniz](https://help.github.com/articles/watching-repositories/)) ve kabul edilmeyebilecek bir işe başlamadan önce topluluk üyelerini tanıyın. - + ### Bir istek/sorun açmak Genellikle aşağıdaki durumlarda bir sorun açmalısınız: -* Çözemediğiniz bir hatayı bildirmek için -* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) -* Yeni bir özellik veya başka bir proje fikri önermek için +- Çözemediğiniz bir hatayı bildirmek için +- Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) +- Yeni bir özellik veya başka bir proje fikri önermek için Sorunlar üzerinde iletişim kurmak için ipuçları: -* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. -* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. -* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. +- **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. +- **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. +- **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. ### PR açma Genellikle aşağıdaki durumlarda bir PR açmalısınız: -* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) -* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda +- Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) +- Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz. Proje GitHub'taysa, PR nasıl gönderilir: -* **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) -* Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . -* **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") -* Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. -* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. -* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. +- **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) +- Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . +- **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") +- Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. +- **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. +- **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz. @@ -464,7 +422,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çilebilecek-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 (@). From 1969f16cf07f1a3ac3c7b9bb47e9c11491124399 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Sun, 9 May 2021 23:56:02 +0000 Subject: [PATCH 039/770] Translate code-of-conduct.md via GitLocalize --- _articles/tr/code-of-conduct.md | 46 +++++++++++++-------------------- 1 file changed, 18 insertions(+), 28 deletions(-) diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md index afc8f06f843..9ba8ff26e3b 100644 --- a/_articles/tr/code-of-conduct.md +++ b/_articles/tr/code-of-conduct.md @@ -7,9 +7,9 @@ toc: why-do-i-need-a-code-of-conduct: Neden bir davranış kural listesine ihtiyacım var? establishing-a-code-of-conduct: Davranış kuralları oluşturmak deciding-how-youll-enforce-your-code-of-conduct: Davranış kurallarınızı nasıl uygulayacağınıza karar verme - enforcing-your-code-of-conduct: Davranış kurallarınızı güçlendirmek + enforcing-your-code-of-conduct: Davranış kurallarınızı uygulama your-responsibilities-as-a-maintainer: Bir koruyucu olarak sorumluluklarınız -order: 8 +order: '8' image: "/assets/images/cards/coc.png" related: - building @@ -30,10 +30,10 @@ Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar: -* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_? -* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_? -* Birisi davranış kurallarını ihlal ederse ne olur? -* İhlaller nasıl rapor edilebilir? +- Davranış kuralları nerede yürürlüğe girer *(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)*? +- Davranış kuralları kimin için geçerlidir *(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)*? +- Birisi davranış kurallarını ihlal ederse ne olur? +- İhlaller nasıl rapor edilebilir? Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir. @@ -43,20 +43,15 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN ## Davranış kurallarınızı nasıl uygulayacağınıza karar verme - + -Bir ihlal meydana _gelmeden önce_ davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var: +Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var: -* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. +- İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. -* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. +- Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. -* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. +- Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir. @@ -66,7 +61,7 @@ Birisinin, bu raporları alan bir kişi hakkındaki ihlali bildirmek isteyebilec İlham almak için Django'nun [uygulama kılavuzunu inceleyin](https://www.djangoproject.com/conduct/enforcement-manual/) (ancak projenizin büyüklüğüne bağlı olarak bu kadar kapsamlı bir şeye ihtiyacınız olmayabilir). -## Davranış kural listesini güçlendirmek +## Davranış kurallarınızı güçlendirmek Bazen, en iyi çabalarınıza rağmen, birileri bu kodu ihlal eden bir şey yapabilir. Olay ortaya çıktığında olumsuz ya da zararlı davranışları ele almanın birkaç yolu vardır. @@ -78,12 +73,7 @@ Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesi Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın. - + ### Uygun işlemi yapın @@ -93,15 +83,15 @@ Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır: -* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. +- **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. -* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. +- Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin: -* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** +- Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** -* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** +- Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız. @@ -111,7 +101,7 @@ Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kur Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler. -_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. +*Teknik* olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler. From 49fbda6b00bfbffed71b9465b23e6986373b0953 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Sun, 9 May 2021 23:57:36 +0000 Subject: [PATCH 040/770] Translate finding-users.md via GitLocalize --- _articles/tr/finding-users.md | 79 +++++++---------------------------- 1 file changed, 16 insertions(+), 63 deletions(-) diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md index a3753a58406..914ee05a185 100644 --- a/_articles/tr/finding-users.md +++ b/_articles/tr/finding-users.md @@ -10,7 +10,7 @@ toc: go-where-your-projects-audience-is-online: Projenizin izleyicisinin (çevrimiçi) olduğu yere gidin go-where-your-projects-audience-is-offline: Projenizin kitlesinin (çevrimdışı) olduğu yere gidin build-a-reputation: Bir itibar oluşturun -order: 3 +order: '3' image: "/assets/images/cards/finding.png" related: - beginners @@ -27,7 +27,7 @@ Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığ Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır. -İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. +İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, *kullanıcıların ve katkıda bulunanların* ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır: @@ -37,12 +37,7 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa ## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun - + İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun. @@ -50,17 +45,11 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun. - + **Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin. -Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_. +Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin *"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi*. Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) . @@ -68,31 +57,25 @@ Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHu Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için kolay bir yolu olsun, haydi çıkıp izleyicilerinizle konuşun! -## Projenizin izleyicisinin (çevrimiçi) olduğu yere gidin +## Projenizin hedef kitlesinin olduğu yere gidin (çevrimiçi olarak) Çevrimiçi sosyal yardım, mesajınızı hızla paylaşmanın ve yaymanın harika bir yoludur. Çevrimiçi kanalları kullanarak, çok geniş bir kitleye ulaşma potansiyeline sahip olursunuz. Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun. - + Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın: -* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. -* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. -* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: _"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum_ ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. +- **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. +- **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. +- **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın. İlk duyurularınız hiç kimsesin dikkatini çekmiyorsa veya kimse cevap vermiyorsa, cesaretini kırmayın! Çoğu proje lansmanı aylar veya yıllar alabilen yinelemeli bir süreçtir. İlk kez bir yanıt alamazsanız, farklı bir taktik deneyin veya başkalarının çalışmalarına ilk olarak değer katmanın yollarını arayın. Projenizi tanıtmak ve başlatmak zaman ve özveri gerektirir. -## Projenizin kitlesinin (çevrimdışı) olduğu yere gidin +## Projenizin hedef kitlesinin olduğu yere gidin (çevrimdışı) ![Public speaking](/assets/images/finding-users/public_speaking.jpg) @@ -100,37 +83,19 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları [Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın. - + Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar. Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin. - + Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir. Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz. - + ## Bir itibar oluşturun @@ -138,25 +103,13 @@ Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir. - + İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin. Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir. - + ## Devam et! From a1a39d7ee96ac9136dc68ecce7a28f4cb5e033c4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Mon, 10 May 2021 00:06:28 +0000 Subject: [PATCH 041/770] Translate starting-a-project.md via GitLocalize --- _articles/tr/starting-a-project.md | 184 ++++++++++------------------- 1 file changed, 62 insertions(+), 122 deletions(-) diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index a466eb48bd2..b5d1598305a 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -9,11 +9,11 @@ toc: 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 +order: '2' +image: "/assets/images/cards/beginner.png" related: -- finding -- building + - finding + - building --- ## Açık kaynağın "nedir"i ve "neden"i @@ -26,25 +26,19 @@ Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için pro Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir. -_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. _Free_ ve _Libre_ özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor). +*Özgür yazılım* , *açık kaynak ile* aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. *Free* ve *Libre* özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor). ### İnsanlar neden işlerini açık kaynak olarak sunarlar? - + Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler: -* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. +- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. -* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. +- **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 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. +- **Ş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 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. @@ -68,19 +62,13 @@ Henüz ikna olmadıysanız, hedeflerinizin ne olabileceğini düşünmek için b ### Hedeflerinizi belirlemek -Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, _neden bu projeye kaynak açıyorum?_ +Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, *neden bu projeye kaynak açıyorum?* Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahip farklı projeler için birden fazla hedefiniz olabilir. Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız. - + Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir. @@ -90,13 +78,7 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın. - + ### Diğer projelere katkıda bulunmak @@ -112,24 +94,24 @@ Genel olarak konuşursak, başkalarının işinizi görmesini ve işiniz hakkın Projenizi hangi aşamada açmaya karar verirseniz verin, her proje aşağıdaki belgeleri içermelidir: -* [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) -* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) -* [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) -* [Davranış kuralları](../code-of-conduct/) +- [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +- [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +- [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +- [Davranış kuralları](../code-of-conduct/) Bir geliştirici olarak, bu bileşenler beklentileri iletmenize, katkıları yönetmenize ve herkesin yasal haklarını (kendi haklarınız dahil) korumanıza yardımcı olur. Olumlu bir deneyim yaşama şansınızı önemli ölçüde artırırlar. -Projeniz GitHub'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 -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.** +Projeniz GitHub'taysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak GitHub'ın onları okuyucularınıza tanıtmasına ve otomatik olarak göstermesine yardımcı olacaktır. Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.** -[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ve [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) en popüler açık kaynaklı lisanslardır, ancak seçilebilecek [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 kaynak lisanslarıdır, ancak [aralarından seçim yapabileceğiniz 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. +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ve [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) en popüler açık kaynaklı lisanslardır, ancak seçilebilecek [başka seçenekler](https://choosealicense.com) de vardır. ![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) @@ -137,28 +119,22 @@ Açık kaynak kodlu bir projeyi yönetmenin yasal yönleri hakkında başka soru ### 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'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar. -* Bu proje ne yapıyor? -* Bu proje neden faydalıdır? -* Kullanmaya nasıl başlarım? -* İhtiyacım olursa nereden daha fazla yardım alabilirim? +- Bu proje ne yapıyor? +- Bu proje neden faydalıdır? +- Kullanmaya nasıl başlarım? +- İhtiyacım olursa nereden daha fazla yardım alabilirim? README'nizi, katkıları nasıl ele aldığınız, projenin 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. +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. -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. +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. @@ -166,27 +142,27 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler. -* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) -* Yeni bir özellik nasıl önerilir -* Proje ortamı nasıl kurulur ve testler nasıl yapılır +- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) +- Yeni bir özellik nasıl önerilir +- Proje ortamı nasıl kurulur ve testler nasıl yapılır Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: -* Aradığınız katkı türleri -* Proje için yol haritanız veya vizyonunuz -* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) +- Aradığınız katkı türleri +- Proje için yol haritanız veya vizyonunuz +- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) -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/HEAD/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. -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. +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. -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. +Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsiniz. Bu bilgileri yazmak, daha az kişinin size aynı soruları tekrar soracağı anlamına gelir. CONTRIBUTING dosyanızı yazarken daha fazla yardım için @nayafia'nın [katkıda bulunma rehber şablonuna](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz. @@ -194,23 +170,17 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan ### Davranış kural listesi oluşturmak - + Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. -Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın. +Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. -Katılımcıların _nasıl_ davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir. +Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir. Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız. -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 @@ -220,44 +190,38 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy 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 +- [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). ### Benzersiz isim bulmak +Her şeyden önce netlik düşünün. Püf noktaları eğlencelidir, ancak bazı şakaların diğer kültürlere veya sizden farklı deneyimlere sahip insanlara tercüme edilemeyebileceğini unutmayın. Potansiyel kullanıcılarınızdan bazıları şirket çalışanları olabilir: projenizi işte açıklamak zorunda kaldıklarında onları rahatsız etmek istemezsiniz! + Özellikle aynı dili veya ekosistemi paylaşıyorsanız, [benzer bir adla açık kaynaklı projeleri kontrol edin](http://ivantomic.com/projects/ospnc/). İsminiz popüler bir projeyle örtüşüyorsa, takipçilerinizin kafaları karışabilir. Bir web sitesi, Twitter hesabı veya projenizi temsil eden diğer özellikleri istiyorsanız, istediğiniz adları aldığınızdan emin olun. İdeal olarak, [bu isimleri](https://instantdomainsearch.com/) henüz kullanmak istemediğiniz zamanlarda bile, rahat etmek için şimdiden alın. Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez. -Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez. - [WIPO Global Marka Veritabanını](http://www.wipo.int/branddb/en/) ticari marka çakışmaları için kontrol edebilirsiniz. Eğer bir şirketteyseniz, bu [hukuk ekibinizin size yardımcı olabileceği](../legal/) şeylerden biridir. ### Nasıl yazdığın (ve kodladığın) markanı da etkiler! -Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. +Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. - + Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün. Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin markasının bir parçası olabilir. [Angular](https://angular.io/guide/styleguide) ve [jQuery](https://contribute.jquery.org/style-guide/js/) titiz kodlama stilleri ve yönergeleri olan projelere iki örnektir. -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 @@ -267,53 +231,39 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
- +
- +
- +
- +
**Kod**
- +
- +
- +
**İnsanlar** @@ -322,39 +272,29 @@ Bireyseniz:
- +
Bir şirket veya kuruluşsanız:
- +
- +
- +
- +
## Başardınız! From 20d86932785458cd1c687f0d3cfde1b376107408 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Mon, 10 May 2021 00:10:48 +0000 Subject: [PATCH 042/770] Translate starting-a-project.md via GitLocalize --- _articles/tr/starting-a-project.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index b5d1598305a..c0dd38a4479 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -174,7 +174,7 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. -Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. +Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın. Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir. From 9547d757b56c58232bb3d42dcdfe624a7415263d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Mon, 10 May 2021 00:13:36 +0000 Subject: [PATCH 043/770] Translate starting-a-project.md via GitLocalize --- _articles/tr/starting-a-project.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index c0dd38a4479..7c8076466bc 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -128,7 +128,7 @@ README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını - 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. From f505bc844147675fd9769709c9a376dc083093df Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Mon, 10 May 2021 03:57:26 +0300 Subject: [PATCH 044/770] Fix formating errors created by Gitlocalize --- _articles/tr/code-of-conduct.md | 38 ++-- _articles/tr/finding-users.md | 73 ++++++-- _articles/tr/how-to-contribute.md | 274 +++++++++++++++++++---------- _articles/tr/starting-a-project.md | 134 ++++++++++---- 4 files changed, 360 insertions(+), 159 deletions(-) diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md index 9ba8ff26e3b..886e0c91a85 100644 --- a/_articles/tr/code-of-conduct.md +++ b/_articles/tr/code-of-conduct.md @@ -30,10 +30,10 @@ Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar: -- Davranış kuralları nerede yürürlüğe girer *(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)*? -- Davranış kuralları kimin için geçerlidir *(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)*? -- Birisi davranış kurallarını ihlal ederse ne olur? -- İhlaller nasıl rapor edilebilir? +* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_? +* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_? +* Birisi davranış kurallarını ihlal ederse ne olur? +* İhlaller nasıl rapor edilebilir? Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir. @@ -43,15 +43,20 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN ## Davranış kurallarınızı nasıl uygulayacağınıza karar verme - + Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var: -- İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. +* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. -- Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. +* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. -- Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. +* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir. @@ -73,7 +78,12 @@ Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesi Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın. - + ### Uygun işlemi yapın @@ -83,15 +93,15 @@ Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır: -- **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. +* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. -- Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. +* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin: -- Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** +* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** -- Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** +* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız. @@ -101,7 +111,7 @@ Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kur Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler. -*Teknik* olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. +_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler. diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md index 914ee05a185..20d8e3c976e 100644 --- a/_articles/tr/finding-users.md +++ b/_articles/tr/finding-users.md @@ -27,7 +27,7 @@ Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığ Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır. -İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, *kullanıcıların ve katkıda bulunanların* ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. +İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır: @@ -37,7 +37,12 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa ## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun - + İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun. @@ -45,11 +50,17 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun. - + **Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin. -Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin *"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi*. +Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_. Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) . @@ -63,13 +74,19 @@ Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun. - + Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın: -- **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. -- **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. -- **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. +* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. +* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. +* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın. @@ -83,19 +100,37 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları [Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın. - + Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar. Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin. - + Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir. Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz. - + ## Bir itibar oluşturun @@ -103,13 +138,25 @@ Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir. - + İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin. Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir. - + ## Devam et! diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index 0f79a454a87..487e228f428 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -19,7 +19,13 @@ 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. @@ -63,59 +69,77 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız! - + Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir. - + ### Etkinlik planlamayı sever misiniz? -- [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin -- Projenin konferansını düzenleyin (eğer varsa) -- Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun +* [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin +* Projenin konferansını düzenleyin (eğer varsa) +* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun ### Tasarlamayı sever misiniz? -- Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın -- [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın -- Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın -- [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın +* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın +* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın +* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın +* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın ### Yazmayı sever misin? -- Proje dokümantasyonunu yazın ve geliştirin -- Projenin nasıl kullanıldığını gösteren örnekler oluşturun -- Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın -- [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın -- Projenin dokümantasyonu için çeviri yapın +* Proje dokümantasyonunu yazın ve geliştirin +* Projenin nasıl kullanıldığını gösteren örnekler oluşturun +* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın +* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın +* Projenin dokümantasyonu için çeviri yapın - + ### Organize etmeyi sever misiniz? -- Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin -- Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) -- Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. +* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin +* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) +* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. ### Kod yazmayı sever misiniz? -- [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun -- Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun -- Proje kurulumunu otomatikleştirin -- Araçları ve testleri geliştirin +* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun +* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun +* Proje kurulumunu otomatikleştirin +* Araçları ve testleri geliştirin ### İnsanlara yardım etmeyi sever misiniz? -- Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te -- İnsanlar için açık konulardaki soruları cevaplayın -- Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun +* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te +* İnsanlar için açık konulardaki soruları cevaplayın +* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun ### Başkalarına kod yazarken yardım etmeyi sever misiniz? -- Diğer kişilerin gönderimlerindeki kodu inceleyin -- Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın -- Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) +* Diğer kişilerin gönderimlerindeki kodu inceleyin +* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın +* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) ### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz! @@ -123,15 +147,21 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d Örneğin: -- @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) -- @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor -- @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) +* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) +* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor +* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır. ## Kendinizi yeni bir projeye yönlendirmek - + Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. @@ -147,34 +177,34 @@ Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapıların Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir: -- **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) -- **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) -- **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) -- **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes -- **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. +* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) +* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) +* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) +* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes +* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın. Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir. -- **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. -- **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. -- **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. -- **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. -- **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. +* **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. +* **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. +* **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. +* **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. +* **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir. -- **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. -- **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. -- **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. -- **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. +* **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. +* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. +* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. +* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. ## Katkıda bulunacak bir proje bulma Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı! -Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi örnek alın. +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. @@ -192,15 +222,15 @@ Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz: -- [GitHub Explore](https://github.com/explore/) -- [Open Source Friday](https://opensourcefriday.com) -- [First Timers Only](https://www.firsttimersonly.com/) -- [CodeTriage](https://www.codetriage.com/) -- [24 Pull Requests](https://24pullrequests.com/) -- [Up For Grabs](https://up-for-grabs.net/) -- [Contributor-ninja](https://contributor.ninja) -- [First Contributions](https://firstcontributions.github.io) -- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [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/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi @@ -212,7 +242,9 @@ Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kab
- +
**Proje aktif olarak katkı kabul ediyor** @@ -221,71 +253,97 @@ Ana daldaki geliştirici faaliyetine bakın. GitHub'da, bu bilgiyi bir kütüpha
- +
- +
- +
Ardından, projenin sorun listesine bakın.
- +
- +
- +
- +
- +
Şimdi aynısını projenin PR listesi için yapın.
- +
- +
- +
- +
- +
**Proje katkı bekliyor mu?** @@ -294,25 +352,39 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac
- +
- +
- +
- +
- + ## Nasıl katkı yapılır? @@ -322,7 +394,13 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir. - + Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun. @@ -370,47 +448,53 @@ Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığ Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız: -- **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir -- **PR** bir çözüm üzerinde çalışmaya başlamak içindir -- **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. +* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir +* **PR** bir çözüm üzerinde çalışmaya başlamak içindir +* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. Bir sorun açmadan veya talepte bulunmadan önce, belirli bir şey eklemeniz gerekip gerekmediğini görmek için projenin katkıda bulunma belgelerini (genellikle CONTRIBUTING veya README dosyaları) kontrol edin. Örneğin, bir şablon izlemenizi istenebilir veya test ortamı kullanmanız gerekebilir. Önemli bir katkı yapmak istiyorsanız, üzerinde çalışmadan önce sormanız gereken bir sorun açın. Projeyi bir süre izlemeniz yararlı olacaktır (GitHub'da, tüm konuşmalar size bildirilmek için ["İzle"yi tıklayabilirsiniz](https://help.github.com/articles/watching-repositories/)) ve kabul edilmeyebilecek bir işe başlamadan önce topluluk üyelerini tanıyın. - + ### Bir istek/sorun açmak Genellikle aşağıdaki durumlarda bir sorun açmalısınız: -- Çözemediğiniz bir hatayı bildirmek için -- Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) -- Yeni bir özellik veya başka bir proje fikri önermek için +* Çözemediğiniz bir hatayı bildirmek için +* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) +* Yeni bir özellik veya başka bir proje fikri önermek için Sorunlar üzerinde iletişim kurmak için ipuçları: -- **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. -- **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. -- **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. +* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. +* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. +* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. ### PR açma Genellikle aşağıdaki durumlarda bir PR açmalısınız: -- Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) -- Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda +* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) +* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz. Proje GitHub'taysa, PR nasıl gönderilir: -- **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) -- Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . -- **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") -- Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. -- **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. -- **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. +* **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) +* Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . +* **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") +* Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. +* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. +* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz. diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index 7c8076466bc..e577a4289a3 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -30,15 +30,21 @@ Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek ### İnsanlar neden işlerini açık kaynak olarak sunarlar? - + Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler: -- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. +* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. -- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. +* **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 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. +* **Ş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 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. @@ -68,7 +74,13 @@ Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahi Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız. - + Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir. @@ -78,7 +90,13 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın. - + ### Diğer projelere katkıda bulunmak @@ -94,10 +112,10 @@ Genel olarak konuşursak, başkalarının işinizi görmesini ve işiniz hakkın Projenizi hangi aşamada açmaya karar verirseniz verin, her proje aşağıdaki belgeleri içermelidir: -- [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) -- [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) -- [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) -- [Davranış kuralları](../code-of-conduct/) +* [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Davranış kuralları](../code-of-conduct/) Bir geliştirici olarak, bu bileşenler beklentileri iletmenize, katkıları yönetmenize ve herkesin yasal haklarını (kendi haklarınız dahil) korumanıza yardımcı olur. Olumlu bir deneyim yaşama şansınızı önemli ölçüde artırırlar. @@ -123,14 +141,20 @@ README'ler, projenizi nasıl kullanılacağını açıklamadan fazlasını yapar README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar. -- Bu proje ne yapıyor? -- Bu proje neden faydalıdır? -- Kullanmaya nasıl başlarım? -- İhtiyacım olursa nereden daha fazla yardım alabilirim? +* Bu proje ne yapıyor? +* Bu proje neden faydalıdır? +* Kullanmaya nasıl başlarım? +* İhtiyacım olursa nereden daha fazla yardım alabilirim? README'nizi, katkıları nasıl ele aldığınız, projenin hedeflerinin ne olduğu ve lisanslar ve atıfla ilgili bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkıları kabul etmek istemiyorsanız veya projeniz henüz üretime hazır değilse, bu bilgileri not edin. - + README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin. @@ -142,15 +166,15 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler. -- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) -- Yeni bir özellik nasıl önerilir -- Proje ortamı nasıl kurulur ve testler nasıl yapılır +* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) +* Yeni bir özellik nasıl önerilir +* Proje ortamı nasıl kurulur ve testler nasıl yapılır Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: -- Aradığınız katkı türleri -- Proje için yol haritanız veya vizyonunuz -- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) +* Aradığınız katkı türleri +* Proje için yol haritanız veya vizyonunuz +* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: @@ -170,7 +194,13 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan ### Davranış kural listesi oluşturmak - + Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. @@ -190,8 +220,8 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy 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 +* [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). @@ -215,7 +245,13 @@ Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici b 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. @@ -231,39 +267,53 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
- +
- +
- +
- +
**Kod**
- +
- +
- +
**İnsanlar** @@ -272,29 +322,39 @@ Bireyseniz:
- +
Bir şirket veya kuruluşsanız:
- +
- +
- +
- +
## Başardınız! From 06c7506fdee312aa1816e1d22ca659449fcef07e Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Wed, 12 May 2021 08:07:42 +0000 Subject: [PATCH 045/770] Bump actions/setup-ruby from 1 to 1.1.3 Bumps [actions/setup-ruby](https://github.com/actions/setup-ruby) from 1 to 1.1.3. - [Release notes](https://github.com/actions/setup-ruby/releases) - [Commits](https://github.com/actions/setup-ruby/compare/v1...v1.1.3) Signed-off-by: dependabot[bot] --- .github/workflows/tests.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 27f8a14d6a8..0eb22ebf388 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -11,7 +11,7 @@ jobs: uses: actions/checkout@v2.3.4 - name: Set up Ruby - uses: actions/setup-ruby@v1 + uses: actions/setup-ruby@v1.1.3 - name: Set up Node uses: actions/setup-node@v2.1.5 From 5470c2f44c3d8d8c01c66d9f7c6b019b4baa8b5b Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Fri, 14 May 2021 16:20:21 +0430 Subject: [PATCH 046/770] Initial translation done. --- _articles/fa/legal.md | 152 +++++++++++++++++++++--------------------- 1 file changed, 76 insertions(+), 76 deletions(-) diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md index ed6cf093fd5..fe8c35ec5f4 100644 --- a/_articles/fa/legal.md +++ b/_articles/fa/legal.md @@ -1,16 +1,8 @@ --- -lang: en -title: The Legal Side of Open Source -description: Everything you've ever wondered about the legal side of open source, and a few things you didn't. +lang: fa +title: جنبه‌های حقوقی پروژه‌های متن باز +description: تمامی چیزهایی که در مورد جنبه‌های حقوقی متن باز برای شما سوال شده و چیزهایی که سوال نشده. class: legal -toc: - why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?" - are-public-github-projects-open-source: "Are public GitHub projects open source?" - just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project" - which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?" - what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?" - does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?" - what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?" order: 10 image: /assets/images/cards/legal.png related: @@ -18,149 +10,157 @@ related: - leadership --- -## Understanding the legal implications of open source +## درک پیامدهای حقوقی پروژه‌های منبع آزاد -Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).) +اشتراک گذاشتن کارهای خلاقانه با جهانیان می‌تواند تجربه‌ای هیجان‌انگیز و ارزشمند باشد. همچنین می‌تواند به معنای درگیر شدن با یک سری موارد حقوقی باشد در رابطه با آن‌ها چیزی نمی‌دانید. خوشبختانه، نیازی نیست از ابتدا شروع کنید. ما نیازهای حقوقی شما را برآورده کرده و پوشش داده‌ایم. (قبل از شروع، حتماً متن [سلب مسئولیت](/notices/) ما را بخوانید.) -## Why do people care so much about the legal side of open source? +## چرا مردم اینقدر به جنبه‌های حقوقی متن آزاد اهمیت می‌دهند؟ -Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it. +به طور کلی، به این معنی است که هیچ کس دیگری نمی‌تواند از اثر شما استفاده کند، کپی کند، پخش کند یا اصلاحاتی روی آن انجام دهد؛ بدون اینکه در معرض ریسک دعوی قضایی و پیگیری قرار بگیرد. -In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. +هرچند پروژه‌های متن باز شرایطی غیرمعمول دارند، زیرا خالق اثر انتظار دارد که دیگران از اثر استفاده کنند و آن را اصلاح نمایند و به اشتراک بگذارند. اما از آنجا که پیش‌فرض قانونی همچنان شامل حقق نشر می‌شود، شما به مجوزی نیاز دارید که صریحاً این دسترسی‌ها را میسر سازد. -Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions. +اگر مجوز (لایسنس) مربوط به پروژه‌های متن باز را اعمال نکنید، همه کسانی که در پروژۀ شما مشارکت می‌کنند نیز به عنوان دارندۀ حق نشر برای کارهای منحصر به فرد خود شناخته می‌شوند. این بدان معناست که هیچ کس نمی‌تواند از مشارکت‌های خود استفاده یا کپی کند و آن را توزیع یا اصلاح نماید و این «هیچ کس» شامل شما هم می‌شود. -If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you. +در آخر اینکه ممکن است پروژۀ شما وابستگی‌هایی با ملزومات مجوز داشته باشد که از آن‌ها اطلاع نداشته باشید. انجمن (community) پروژه یا سیاست‌های کارفرمایی شما نیز ممکن است پروژه را ملزم به استفاده از مجوز‌های متن باز خاصی بکند. در زیر دربارۀ آن توضیح می‌دهیم. -Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. -## Are public GitHub projects open source? +## آیا پروژه‌های عمومی «GitHub» متن باز محسوب می‌شوند؟ -When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**. +هنگام ایجاد [پروژه‌ای جدید](https://help.github.com/articles/creating-a-new-repository/) در «GitHub»، این انتخاب را دارید که منبع را **خصوصی** یا **عمومی** مشخص کنید ![Create repository](/assets/images/legal/repo-create-name.png) -**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. +**عمومی کردن پروژه‌تان در «GitHub» به منزلۀ مجوزدار کردن پروژه نیست.** پروژه‌های عمومی‌ای که [تحت شرایط خدمات «GitHub»](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) قرار می‌گیرند این امکان را برای افراد میسر می‌سازد که پروژه شما را مشاهده کنند و آن را فورک (fork) کنند، اما در غیر این افراد همچین اجازه‌ای ندارند. -If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. +اگر می‌خواهید دیگران از پروژۀ شما استفاده کنند، آن را توزیع دهند یا اصلاح نمایند و در آن مشارکت کنند، باید پروانۀ مخصوص پروژه‌های متن باز داشته باشید. به عنوان مثال، کسی قانونا نمی‌تواند از هر بخشی از پروژۀ «GitHub» شما در کد خود استفاده کند، حتی اگر عمومی باشد؛ مگر اینکه صریحاً به او اجازۀ چنین کاری را بدهید. -## Just give me the TL;DR on what I need to protect my project. +## به من توضیحات تکمیلی را در مورد چگونگی مراقبت از پروژه بدهید -You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project. +امروزه کار خیلی ساده‌تر شده است زیرا مجوز‌های پروژه‌های متن باز استاندارد شده و استفاده از آن‌ها آسان است. می‌توانید مجوزهای (پروانه‌های) موجود را مستقیماً در پروژۀ خود کپی کنید. -[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). +[MIT](https://choosealicense.com/licenses/mit/) ، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) و [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) معروف‌ترین مجوزهای متن باز هستند، اما گزینه‌های دیگری نیز برای انتخاب وجود دارد. می‌توانید متن کامل این مجوزها و دستورالعمل‌های مربوط به نحوۀ استفاده از آن‌ها را در سایت [choosealicense.com] پیدا کنید. -When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). +وقتی پروژۀ جدیدی را در «GitHub» ایجاد می‌کنید، [از شما خواسته می‌شود مجوزی را انتخاب کرده و به پروژه اضافه کنید](https://help.github.com/articles/open-source-licensing/). -## Which open source license is appropriate for my project? +## چه مجوز متن بازی برای پروژۀ من مناسب است؟ -If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. +اگر تازه‌کار هستید، [مجوز MIT](https://choosealicense.com/licenses/mit/) به درد شما می‌خورد. کوتاه است، درک آن بسیار آسان می‌باشد و به هر کسی اجازه می‌دهد هر کاری انجام دهد تا زمانی که کپی مجوز، از جمله اخطار حق نشر شما را نگه دارند. در صورت نیاز، می‌توانید پروژه را تحت هر مجوز دیگری انتشار دهید. -Otherwise, picking the right open source license for your project depends on your objectives. +در غیر این صورت، انتخاب مجوز متن باز مناسب برای پروژۀ شما به اهداف‌تان بستگی دارد. -Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. +پروژۀ شما به احتمال زیاد **وابستگی‌ها** و مولفه‌های فراوانی داشته باشد (یا خواهد داشت). به عنوان مثال، اگر در پروژۀ متن باز خود از «Node.js» استفاده می‌کنید، احتمالاً از کتابخانه‌های Node Package Manager (npm) (مدیریت پکیج Node) استفاده خواهید کرد. هر کدام از این کتابخانه‌هایی که به آن‌ها وابسته هستید، مجوز (لایسنس، پروانه) متن باز مخصوص به خود را دارند. اگر هر یک از مجوزهای آن‌ها «اختیاری» باشد (بدون هیچ گونه شرطی برای فعالیت‌های آینده، اجازۀ استفاده، اصلاح، تغییر و اشتراک‌گذاری را به عموم مردم می‌دهد)، می‌توانید از هر مجوزی که می‌خواهید استفاده کنید. مجوزهای اختیاری متداول شامل «MIT»، «Apache 2.0»، «ISC» و «BSD» می‌شوند. -On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. +از طرف دیگر، اگر هر یک از مجوزهای وابستگی شما، «کپی‌لفت قوی» باشند (مشروط به استفاده از همان مجوز در آینده، مجوزهای عمومی مشابهی را می‌دهد)، در این صورت پروژۀ شما باید از همان مجوز استفاده کند. مجوزهای متداول کپی‌لفت ((Copyleft (تعریف: کپی‌لفت نوعی بازی با کلمهٔ کپی‌رایت است. کپی‌لفت عملی را توصیف می‌کند که در آن تضمین می‌شود که اجازهٔ نسخه‌برداری و ویرایش یک اثر برای همگان محفوظ می‌مانَد و هیچ شخصی اجازه ندارد حق ویرایش و نسخه‌برداری را از دیگر افراد سلب کند.) قوی شامل «GPLv2»، «GPLv3» و «AGPLv3» می‌شوند. -You may also want to consider the **communities** you hope will use and contribute to your project: +همچنین ممکن است بخواهید **انجمن‌هایی** را در نظر بگیرید که امیدوار هستید از پروژۀ شما استفاده کنند و در آن مشارکت کنند: -* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). -* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. -* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. +* **آیا می‌خواهید پروژۀ شما به عنوان وابستگی توسط سایر پروژه‌ها مورد استفاده قرار گیرد؟** بهتر است محبوب‌ترین نوع مجوز را در انجمن‌تان استفاده کنید. به عنوان مثال، [MIT](https://choosealicense.com/licenses/mit/) محبوب‌ترین مجوز برای [کتابخانه‌های npm](https://libraries.io/search?platforms=NPM) است. -Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know). +* **آیا می‌خواهید پروژۀ شما مورد توجه کسب و کارهای بزرگ قرار بگیرد؟** کسب‌وکارهای بزرگ احتمالاً سریعا مجوز ثبت اختراع را از تمامی مشارکت‌کنندگان می‌خواهند. در این صورت، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) به درد شما و آن‌ها می‌خورد. -When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). +* **آیا می‌خواهید پروژه شما مورد توجه مشارکت‌کنندگانی قرار بگیرد که نمی‌خواهند مشارکت‌های آن‌ها در نرم‌افزارهای متن بسته مورد استفاده قرار بگیرد؟** [GPLv3] یا (همچنین اگر آن‌ها تمایلی به مشارکت در خدمات متن بسته ندارند) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) به درد خواهد خورد. -## What if I want to change the license of my project? +ممکن است **شرکت** شما در پروژه‌های متن باز، شرایط خاصی برای مجوزها داشته باشد. به عنوان مثال، ممکن است به مجوز اختیاری نیاز داشته باشد تا شرکت بتواند از پروژۀ شما در محصول متن بستۀ خود استفاده کند. یا ممکن است شرکت شما به یک مجوز کپی‌لفت قوی و یک توافق‌نامۀ همکاری اضافی نیاز داشته باشد (به زیر مراجعه کنید) تا فقط منحصرا شرکت شما بتواند از پروژه در نرم‌افزارهای متن بسته استفاده کند. یا ممکن است شرکت شما نیازها و شرایط خاصی در رابطه با استانداردها، مسئولیت‌های اجتماعی یا شفافیت داشته باشد، که هر یک از آن‌ها ممکن است به یک استراتژی خاص دیگری در ارتباط با مجوز نیاز داشته باشد. با [بخش حقوقی شرکت] خود در رابطه با این موارد صحبت کنید. -Most projects never need to change licenses. But occasionally circumstances change. +هنگام ایجاد پروژه جدید در «GitHub»، به شما امکان انتخاب نوع مجوز داده می‌شود. انتخاب یکی از مجوزهایی که در بالا ذکر شد، پروژۀ «GitHub» شما را متن باز می‌کند. اگر مایل به دیدن گزینه‌های دیگه‌ای هستید، [choosealicense.com](https://choosealicense.com) را بررسی کنید تا مجوز مناسب‌تان را پیدا کنید حتی اگر برای [نرم‌افزار](https://choosealicense.com/non-software/) نباشد. -For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license: +## اگر بخواهم مجوز پروژۀ خود را تغییر دهم چه کاری باید بکنم؟ -**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! +اکثر پروژه‌ها به تغییر دادن مجوز خود، نیازی پیدا نمی‌کنند. ولی گاهی اوقات شرایط فرق می‌کند. -**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. +به عنوان مثال، با رشد پروژۀ شما، وابستگی‌ها یا کاربران آن اضافه می‌شود یا شرکت شما استراتژی‌های خود را تغییر می‌دهد که هرکدام از آن‌ها نیاز به مجوز دیگری دارند. همچنین، اگر از ابتدا مجوزی برای پروژۀ خود انتخاب نکردید، افزودن مجوز در واقع تفاوتی با تغییر مجوز ندارد. هنگام افزودن یا تغییر مجوز پروژه، سه نکتۀ اساسی باید در نظر گرفته شود: -**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. +**کاری پیچیده است.** تعیین سازگاری و انطباق مجوز و حق نشر می تواند خیلی زود پیچیده و گیج‌کننده شود. تغییر مجوز به مجوزی جدید و سازگار برای نسخه‌های جدید و مشارکت‌ها با تغییر مجوز تمامی مشارکت‌های موجود، تفاوت‌هایی دارد. در اولین قدم، در صورت تمایل به تغییر مجوزها، تیم حقوقی شما درگیر می‌شود. حتی اگر برای تغییر مجوز از دارندگان حق نشر پروژه خود اجازه دارید یا می‌توانید از آن‌ها اجازه بگیرید، تأثیر این تغییر را بر سایر کاربران و مشارکت‌کنندگان پروژۀ خود در نظر داشته باشید. تغییر مجوز را به صورت یک «رویداد مدیریتی» برای پروژۀ خود تصور کنید که به احتمال زیاد با برقراری ارتباط صریح و مشورت با ذی‌نفعان پروژه، هموارتر پیش خواهد رفت. بنابراین بهتر است از بدو تأسیس، مجوزی مناسب را برای پروژۀ خودتان انتخاب کنید! -Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. +**مجوز موجود و فعلی پروژه‌تان.** در صورتی که مجوز کنونی پروژۀ شما با مجوزی که می‌خواهید به آن تغییر دهید سازگار باشد، می‌توانید از مجوز جدید استفاده کنید. به این دلیل که اگر مجوز A با مجوز B سازگار باشد، در حالی که با شرایط B مطابقت دارید، با شرایط A نیز منطبق خواهید بود (اما لزوما برعکس آن درست نیست). بنابراین اگر در حال حاضر از مجوزی اختیاری استفاده می‌کنید (به عنوان مثال، «MIT»)، می‌توانید به مجوزی با شرایط بیشتری تغییر مجوز دهید، به شرطی که نسخه‌ای از مجوز «MIT» و هرگونه شرط حق نشر دیگۀ مربوط به آن را حفظ کنید (یعنی همچنان با حداقل شرایط مجوز «MIT» سازگار باشید). اما اگر مجوز فعلی شما اختیاری نباشد (به عنوان مثال کپی‌لفت باشد یا مجوزی نداشته باشید) و تنها دارندۀ حق نشر نیستید، نمی‌توانید مجوز پروژۀ خود را به «MIT» تغییر دهید. اساساً، صاحبان حق نشر پروژه با داشتن مجوز اختیاری از قبل اجازۀ تغییر مجوزها را داده‌اند. -## Does my project need an additional contributor agreement? +**صاحبان کنونی حق‌نشر پروژه‌تان.** اگر تنها مشارکت‌کننده در پروژه‌تان هستید، شما یا شرکت شما تنها صاحبان حق‌نشر این پروژه خواهید بود. خودتان یا شرکت می‌توانید، مجوز را تغییر دهید یا مجوز جدیدی اضافه کنید. در غیر این صورت ممکن است باید قبل از تغییر مجوز، با دیگر صاحبان حق‌نشر به توافق برسید. آن‌ها چه کسانی هستند؟ افرادی که در متعهد به پروژه هستند، نفطۀ خوبی برای شروع است. اما در برخی موارد حق‌نشر توسط افراد بالادستی این افراد حفظ می‌شود. در برخی موارد افراد مشارکت کم و حداقلی داشته‌اند، اما هیچ قانون سخت و جدی وجود ندارد که بگوید افرادی که مشارکتی در برخی از خطوط کد داشته‌اند مشمول حق‌نشر نباشد. چه کار باید کرد؟ بستگی دارد. برای پروژه‌ای نسبتاً کوچک و تازه‌شکل گرفته، ممکن است امکان‌پذیر باشد که همۀ مشارکت‌کنندگان موجود با تغییر مجوز در طرح مسئله‌ای یا در درخواست pullی موافقت کنند. برای پروژه‌های بزرگ و قدیمی، ممکن است برای مثلا تغییر مجوز مجبور شوید به جستجوی بسیاری از مشارکت‌کنندگان و حتی ورثه‌های آن‌ها مشغول شوید. موزیلا سال‌ها به طول انجامید (2001 تا 2006) تا مجوز «Firefox»، «Thunderbird» و دیگر نرم‌افزارهای مربوطه را تغییر دهد. -Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). +همچنین می‌توانید موافقت مشارکت‌کنندگان را از قبل جلب کنید (از طریق توافق‌نامه‌های مشارکتی اضافی - به زیر مراجعه کنید) تا بتوانید کارتان را در مورد برخی از تغییرات مجوز تحت شرایط خاصی را فراتر از شرایط مجاز مجوز متن باز موجود پیش ببرید. این موضوع پیچیدگی تغییر مجوزها را کمی تغییر می‌دهد. برای اینکار به کمک وکلای خود بیشتر احتیاج خواهید داشت و هنوز هم باید در هنگام اجرای تغییر مجوز، به طور واضح با ذی‌نفعان پروژۀ خود صحبت کنید. -An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. +## آیا پروژۀ من به توافق‌نامه‌های همکاری (مشارکتی) اضافی نیاز دارد؟ + +به احتمال زیاد نه. برای اکثریت قریب به اتفاق پروژه‌های متن باز، یک مجوز متن آزاد به طور ضمنی به عنوان مجوز درونی (برای مشارکت‌کنندگان) و مجوز خارجی (برای سایر مشارکت‌کنندگان و کاربران) عمل می‌کند. اگر پروژۀ شما در «GitHub» میزبانی می‌شود، شرایط خدمات‌دهی «GitHub»، «مجوزهای درونی و مجوزهای خروجی را [صریحا پیش‌فرض](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license) درنظر می‌گیرد. + +توافق‌نامه‌های همکاری اضافی - که اغلب به آن توافق‌نامه مجوز مشارکت‌کننده (CLA) گفته می‌شود - برای نگهدارندگان پروژه می‌تواند کارهای مدیریتی ایجاد کند. اینکه توافق‌نامه چه مقدار کار اضافه می‌کند به پروژه و نحوۀ اجرای آن بستگی دارد. یک توافق‌نامه‌ی ساده ممکن است نیاز داشته باشد که مشارکت‌کنندگان با یک کلیک تأیید کنند که از حقوق لازم برای مشارکت در مجوز پروژه متن باز برخوردار هستند. یک توافق‌نامه‌ی پیچیده‌تر ممکن است نیاز به بررسی قانونی داشته باشد و مربوط به کارفرمایان مشارکت‌کنندگان شود. + +همچنین، با افزودن «تشریفات اداری» که به عقیدۀ برخی غیرضروری می‌باشد و فهم آن سخت یا ناعادلانه است (وقتی که ذی‌نفعان توافق‌نامه حقوق و مزایای بیشتری از مشارکت‌کنندگان یا عموم مردمی که کارهایی در پروژه‌ی متن باز انجام می‌دهند، به دست می‌آورند)؛ به همین خاطر ممکن است یک توافق‌نامه‌ی همکاری اضافی غیرمنصفانه نسبت به انجمن پروژه تلقی شود. -Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community. -Some situations where you may want to consider an additional contributor agreement for your project include: +برخی از شرایطی که ممکن است بخواهید یک توافق‌نامه‌ی همکاری اضافی را برای پروژۀ خود در نظر بگیرید، شامل این موارد می‌شود: + +* وکلای شما می‌خواهند که تمامی مشارکت‌کنندگان به طور صریح شرایط مشارکت (آنلاین یا آفلاین) را بپذیرند، شاید به این دلیل که فکر می‌کنند مجوز متن باز به خودی خود کافی نیست (با اینکه هست!). اگر این تنها نگرانی است، توافق‌نامه‌ی مشارکت‌کننده که مجوز پروژۀ متن باز را تأیید می‌کند باید کافی باشد. [توافق‌نامۀ مجوز مشارکت‌کنند‌ۀ حقیقی jQuery] نمونۀ خوبی از توافق‌نامۀ همکاری اضافی خفیف است. + +* شما یا وکیل‌هاتان بخواهید توسعه‌دهندگان نشان دهند که هر تعهدی که روی آن کار می‌کنند مجاز است. الزام [گواهی مبدا توسعه‌دهنده](https://developercertificate.org/) برای این است که چه تعداد پروژه به این صورت هستند. به عنوان مثال، انجمن «Node.js» به جای «توافق‌نامۀ مجوز مشارکت‌کننده» قبلی خود از «گواهی مبدا توسعه‌دهنده» استفاده می کند. راهکار ساده برای اجرای خودکار «گواهی مبدا توسعه‌دهنده» در منبع (repository) شما، «ربات گواهی مبدا توسعه‌دهنده» است. -* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. -* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). -* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. -* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. -* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. +* پروژۀ شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache]https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است. -If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. +* پروژۀ شما تحت مجوز کپی‌لفت باشد ، اما شما همچنین باید نسخه‌ای اختصاصی از پروژه را توزیع و پخش کنید. هر مشارکت‌کننده باید به شما حق نشر اختصاص دهد یا به شما (اما نه به عموم) مجوز اختیاری بدهد. [توافق‌نامۀ همکاری MongoDB](https://www.mongodb.com/legal/contributor-agreement) نمونه‌ای از این نوع توافق‌نامه است. -## What does my company's legal team need to know? +* ممکن باشد پروژۀ شما در طول عمر خود مجوزهایش را تغییر بدهد و بخواهید مشارکت‌کنندگان از قبل با چنین تغییراتی موافقت کنند. -If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project. +اگر در پروژۀ خود نیازی به استفاده از توافق‌نامه‌های همکاری اضافی داشته باشید، استفاده از توافق‌نامه‌های یکپارچه‌سازی مانند [توافق‌نامۀ مجوز مشارکت‌کننده](https://github.com/cla-assistant/cla-assistant) را برای به حداقل رساندن حواس‌پرتی مشارکت‌کنندگان در نظر بگیرید. -For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company. +## تیم حقوقی شرکت من چه چیزهایی را باید بداند؟ -**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: +اگر به عنوان کارمند شرکت پروژه‌ای متن باز را منتشر می‌کنید، ابتدا تیم حقوقی باید بداند که شما در حال تهیۀ پروژه‌ای متن باز هستید. -* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. +حتما این موضوع را به آن‌ها بگویید حتی اگر این پروژه‌ای شخصی باشد. شما احتمالاً با شرکت خود «توافق‌نامۀ کارمندی» دارید که به آن‌ها تا حدودی کنترلی بر روی پروژه های شما می‌دهد، به خصوص اگر مربوط به شرکت باشند یا از منابع شرکت برای توسعۀ پروژه استفاده کرده باشید. شرکت شما _باید_ به شما اجازه دهد و ممکن است از قبل از طریق توافق‌نامه‌ی کارمندی یا سایر سیاست‌های شرکت مجوز داشته باشد. در غیر این صورت، می‌توانید مذاکره کنید (به عنوان مثال، توضیح دهید که پروژۀ شما اهداف یادگیری و توسعۀ حرفه‌ای شرکت را دنبال می‌کند)، یا تا زمانی که شرکت بهتری پیدا نکردید از کار بر روی پروژۀ خودتان خودداری کنید.. -* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. +**اگر در جستجوی پروژه‌ای برای شرکت هستید،** قطعاً آن‌ها را در جریان بگذارید. تیم حقوقی شما احتمالاً قبلاً سیاست‌هایی را برای استفاده از مجوزهای متن باز (و شاید توافق‌نامه‌های همکاری اضافی) برای استفاده بر اساس الزامات تجاری و تخصصی شرکت در مورد اطمینان از مطابقت پروژۀ شما با مجوزهای وابستگی شرکت، در نظر گرفته است. اگر نه، به نفع هم شما و هم شرکت است! تیم حقوقی شما باید مشتاق همکاری با شما برای مشخص کردن این موارد باشد. چند مسئلۀ مهم: -* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). +* **نهادهای واسط** آیا پروژه شما وابستگی‌هایی به کار دیگران دارد یا در غیر این صورت کد دیگران را شامل می شود یا از آن‌ها استفاده می‌کند؟ اگر پروژه متن باز باشد، باید پروژۀ شما با مجوزهای متن باز مطابقت داشته باشد. این کار با انتخاب مجوز شروع می‌شود که مربوط به مجوزهای متن باز واسط می‌شود (نگاه کنید به بالا). اگر پروژۀ شما پروژه‌های متن باز واسط دیگر را اصلاح یا توزیع می‌کند، تیم حقوقی شما همچنین می‌خواهد بداند که شما سایر شرایط‌های مجوزهای متن باز واسط مانند حفظ اخطارهای حق نشر را رعایت می‌کنید یا خیر. اگر پروژۀ شما از کدهای دیگران استفاده می‌کند که فاقد مجوز متن باز هستند، احتمالاً باید از نگهدارندگان واسط بخواهید که [مجوز متن باز را اضافه کنند](https://choosealicense.com/no-license/#for-users) و اگر نمی‌توانید مجوز را دریافت کنید، استفاده از کد دیگران را در پروژۀ خوتان متوقف کنید. -* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. +* **اسرار کاری:** به این توجه داشته باشید که آیا چیزی در پروژه وجود دارد که شرکت نخواهد آن را در دسترس عموم قرار دهد. در این صورت، پس از مشخص کردن مطالبی که می‌خواهید خصوصی نگه دارید، می‌توانید بقیۀ پروژۀ خود را با متن باز کنید. -* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. +* **حق ثبت اختراع:** آیا شرکت شما متقاضی ثبت اختراعی است که متن باز آن پروژه در [دسترس عموم](https://en.wikipedia.org/wiki/Public_disclosure) است؟ متأسفانه، ممکن است از شما خواسته شود صبر کنید (یا شاید این شرکت در دیدگاه خود تجدید نظر کند). اگر انتظار دارید که کارمندان شرکت‌های بزرگی که دارای حق ثبت اختراع هستند، به پروژۀ شما کمک کنند و در آن مشارکت داشته باشند، ممکن است تیم حقوقی از شما بخواهد از یک مجوز با امتیاز ثبت اختراع سریع (از جمله Apache 2.0 یا GPLv3) یا توافق‌نامۀ همکاری اضافی استفاده کنید ( به بالا نگاه کنید). -If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). +* **نشان تجاری:** بررسی کنید تا نام پروژۀ شما با [هیچ نشان تجاری موجودی مغایرت نداشته باشد](../starting-a-project/#avoiding-name-conflicts). اگر از نشان‌های تجاری شرکت خود در پروژه استفاده می‌کنید، بررسی کنید تا هیچ مشکلی ایجاد نکند. [FOSSmarks](http://fossmarks.org/) یک راهنمای جامع برای شناخت نشان‌های تجاری در زمینه‌ی پروژه‌های متن باز و رایگان است. -Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: +* **حریم خصوصی:** آیا پروژۀ شما اطلاعات مربوط به کاربران را جمع‌آوری می‌کند؟ سرورهای شرکت، مکالمات را ضبط می‌کند؟ تیم حقوقی می‌تواند به شما در زمینه‌ی پیروی از سیاست‌های شرکت و آیین‌نامه‌های خارجی کمک کند. -* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). +اگر دارید اولین پروژه متن باز شرکت خود را منتشر می‌کنید، رعایت موارد فوق کافی است (اما نگران نباشید، اکثر پروژه‌ها نگرانی‌های اساسی خاصی نباید ایجاد کنند). + +در بلند مدت، تیم حقوقی می‌تواند کمک بیشتری به شرکت کند تا از مشارکت خود در پروژه‌های متن باز بهره‌ی بیشتری ببرد و در امان بماند: + +* سیاست های مربوط به مشارکت کارمندان سیاست‌هایی را تدوین کنید که مشخص سازد کارمندان شما در پروژه‌های متن باز چه نوع مشارکتی داشته باشند. داشتن سیاست‌های مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آن‌ها در مشارکت هرچه بهتر در پروژه‌های متن باز شرکت می‌شود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغت‌شان. یک مثال خوب، [مدل‌های استاندارد و سیاست‌های همکاری در پروژه‌های متن باز](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) «Rackspace» است. -* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts. -* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. +* **چه چیزهایی را منتشر کنیم:** [(تقریبا) همه چیز؟](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/) می‌تواند از بروز مشکلات بی‌جا، تأخیر در محصول و شکایات جلوگیری کند. -* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). -* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project). +* **امتیاز ثبت اختراع:** ممکن است شرکت شما مایل باشد به شبکۀ [Open Invention Network](https://www.openinventionnetwork.com/)، که یک مجموعۀ ثبت اختراع مشترک برای محافظت از اعضا و استفادۀ آن‌ها از از پروژه‌های بزرگ متن باز یا جستجوی سایر [مجوزهای اختراع ثبت جایگزین](https://www.eff.org/document/hacking-patent-system-2016) است، بپیوندد. + +* **نظارت:** مخصوصاً زمانی منطقی است که پروژه‌ای را به یک [شخص حقوقی خارج از شرکت](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project) منتقل کنید. \ No newline at end of file From 6d1e0aa720aa1b876d0836df366826d3df5401f9 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Fri, 14 May 2021 16:41:14 +0430 Subject: [PATCH 047/770] Language abbreviation updated. --- _data/locales/fa.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_data/locales/fa.yml b/_data/locales/fa.yml index dd41c8e0717..9a17d1650ef 100644 --- a/_data/locales/fa.yml +++ b/_data/locales/fa.yml @@ -1,4 +1,4 @@ -en: +fa: locale_name: Farsi nav: about: درباره From ec476224d3874771bf1284f8e48f69a5246c4ebd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Wed, 19 May 2021 02:18:00 +0300 Subject: [PATCH 048/770] Fix formating errors created by Gitlocalize (#35) --- _articles/tr/code-of-conduct.md | 38 ++-- _articles/tr/finding-users.md | 73 ++++++-- _articles/tr/how-to-contribute.md | 274 +++++++++++++++++++---------- _articles/tr/starting-a-project.md | 134 ++++++++++---- 4 files changed, 360 insertions(+), 159 deletions(-) diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md index 9ba8ff26e3b..886e0c91a85 100644 --- a/_articles/tr/code-of-conduct.md +++ b/_articles/tr/code-of-conduct.md @@ -30,10 +30,10 @@ Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar: -- Davranış kuralları nerede yürürlüğe girer *(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)*? -- Davranış kuralları kimin için geçerlidir *(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)*? -- Birisi davranış kurallarını ihlal ederse ne olur? -- İhlaller nasıl rapor edilebilir? +* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_? +* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_? +* Birisi davranış kurallarını ihlal ederse ne olur? +* İhlaller nasıl rapor edilebilir? Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir. @@ -43,15 +43,20 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN ## Davranış kurallarınızı nasıl uygulayacağınıza karar verme - + Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var: -- İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. +* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. -- Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. +* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. -- Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. +* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir. @@ -73,7 +78,12 @@ Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesi Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın. - + ### Uygun işlemi yapın @@ -83,15 +93,15 @@ Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır: -- **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. +* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. -- Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. +* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin: -- Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** +* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** -- Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** +* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız. @@ -101,7 +111,7 @@ Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kur Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler. -*Teknik* olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. +_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler. diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md index 914ee05a185..20d8e3c976e 100644 --- a/_articles/tr/finding-users.md +++ b/_articles/tr/finding-users.md @@ -27,7 +27,7 @@ Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığ Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır. -İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, *kullanıcıların ve katkıda bulunanların* ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. +İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır: @@ -37,7 +37,12 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa ## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun - + İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun. @@ -45,11 +50,17 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun. - + **Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin. -Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin *"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi*. +Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_. Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) . @@ -63,13 +74,19 @@ Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun. - + Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın: -- **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. -- **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. -- **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. +* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. +* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. +* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın. @@ -83,19 +100,37 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları [Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın. - + Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar. Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin. - + Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir. Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz. - + ## Bir itibar oluşturun @@ -103,13 +138,25 @@ Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir. - + İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin. Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir. - + ## Devam et! diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index 0f79a454a87..487e228f428 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -19,7 +19,13 @@ 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. @@ -63,59 +69,77 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız! - + Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir. - + ### Etkinlik planlamayı sever misiniz? -- [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin -- Projenin konferansını düzenleyin (eğer varsa) -- Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun +* [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin +* Projenin konferansını düzenleyin (eğer varsa) +* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun ### Tasarlamayı sever misiniz? -- Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın -- [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın -- Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın -- [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın +* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın +* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın +* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın +* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın ### Yazmayı sever misin? -- Proje dokümantasyonunu yazın ve geliştirin -- Projenin nasıl kullanıldığını gösteren örnekler oluşturun -- Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın -- [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın -- Projenin dokümantasyonu için çeviri yapın +* Proje dokümantasyonunu yazın ve geliştirin +* Projenin nasıl kullanıldığını gösteren örnekler oluşturun +* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın +* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın +* Projenin dokümantasyonu için çeviri yapın - + ### Organize etmeyi sever misiniz? -- Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin -- Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) -- Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. +* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin +* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) +* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. ### Kod yazmayı sever misiniz? -- [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun -- Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun -- Proje kurulumunu otomatikleştirin -- Araçları ve testleri geliştirin +* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun +* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun +* Proje kurulumunu otomatikleştirin +* Araçları ve testleri geliştirin ### İnsanlara yardım etmeyi sever misiniz? -- Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te -- İnsanlar için açık konulardaki soruları cevaplayın -- Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun +* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te +* İnsanlar için açık konulardaki soruları cevaplayın +* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun ### Başkalarına kod yazarken yardım etmeyi sever misiniz? -- Diğer kişilerin gönderimlerindeki kodu inceleyin -- Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın -- Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) +* Diğer kişilerin gönderimlerindeki kodu inceleyin +* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın +* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) ### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz! @@ -123,15 +147,21 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d Örneğin: -- @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) -- @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor -- @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) +* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) +* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor +* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır. ## Kendinizi yeni bir projeye yönlendirmek - + Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. @@ -147,34 +177,34 @@ Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapıların Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir: -- **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) -- **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) -- **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) -- **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes -- **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. +* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) +* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) +* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) +* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes +* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın. Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir. -- **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. -- **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. -- **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. -- **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. -- **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. +* **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. +* **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. +* **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. +* **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. +* **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir. -- **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. -- **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. -- **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. -- **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. +* **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. +* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. +* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. +* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. ## Katkıda bulunacak bir proje bulma Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı! -Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi örnek alın. +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. @@ -192,15 +222,15 @@ Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz: -- [GitHub Explore](https://github.com/explore/) -- [Open Source Friday](https://opensourcefriday.com) -- [First Timers Only](https://www.firsttimersonly.com/) -- [CodeTriage](https://www.codetriage.com/) -- [24 Pull Requests](https://24pullrequests.com/) -- [Up For Grabs](https://up-for-grabs.net/) -- [Contributor-ninja](https://contributor.ninja) -- [First Contributions](https://firstcontributions.github.io) -- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [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/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi @@ -212,7 +242,9 @@ Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kab
- +
**Proje aktif olarak katkı kabul ediyor** @@ -221,71 +253,97 @@ Ana daldaki geliştirici faaliyetine bakın. GitHub'da, bu bilgiyi bir kütüpha
- +
- +
- +
Ardından, projenin sorun listesine bakın.
- +
- +
- +
- +
- +
Şimdi aynısını projenin PR listesi için yapın.
- +
- +
- +
- +
- +
**Proje katkı bekliyor mu?** @@ -294,25 +352,39 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac
- +
- +
- +
- +
- + ## Nasıl katkı yapılır? @@ -322,7 +394,13 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir. - + Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun. @@ -370,47 +448,53 @@ Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığ Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız: -- **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir -- **PR** bir çözüm üzerinde çalışmaya başlamak içindir -- **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. +* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir +* **PR** bir çözüm üzerinde çalışmaya başlamak içindir +* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. Bir sorun açmadan veya talepte bulunmadan önce, belirli bir şey eklemeniz gerekip gerekmediğini görmek için projenin katkıda bulunma belgelerini (genellikle CONTRIBUTING veya README dosyaları) kontrol edin. Örneğin, bir şablon izlemenizi istenebilir veya test ortamı kullanmanız gerekebilir. Önemli bir katkı yapmak istiyorsanız, üzerinde çalışmadan önce sormanız gereken bir sorun açın. Projeyi bir süre izlemeniz yararlı olacaktır (GitHub'da, tüm konuşmalar size bildirilmek için ["İzle"yi tıklayabilirsiniz](https://help.github.com/articles/watching-repositories/)) ve kabul edilmeyebilecek bir işe başlamadan önce topluluk üyelerini tanıyın. - + ### Bir istek/sorun açmak Genellikle aşağıdaki durumlarda bir sorun açmalısınız: -- Çözemediğiniz bir hatayı bildirmek için -- Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) -- Yeni bir özellik veya başka bir proje fikri önermek için +* Çözemediğiniz bir hatayı bildirmek için +* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) +* Yeni bir özellik veya başka bir proje fikri önermek için Sorunlar üzerinde iletişim kurmak için ipuçları: -- **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. -- **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. -- **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. +* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. +* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. +* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. ### PR açma Genellikle aşağıdaki durumlarda bir PR açmalısınız: -- Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) -- Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda +* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) +* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz. Proje GitHub'taysa, PR nasıl gönderilir: -- **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) -- Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . -- **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") -- Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. -- **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. -- **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. +* **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) +* Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . +* **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") +* Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. +* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. +* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz. diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index 7c8076466bc..e577a4289a3 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -30,15 +30,21 @@ Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek ### İnsanlar neden işlerini açık kaynak olarak sunarlar? - + Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler: -- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. +* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. -- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. +* **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 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. +* **Ş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 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. @@ -68,7 +74,13 @@ Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahi Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız. - + Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir. @@ -78,7 +90,13 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın. - + ### Diğer projelere katkıda bulunmak @@ -94,10 +112,10 @@ Genel olarak konuşursak, başkalarının işinizi görmesini ve işiniz hakkın Projenizi hangi aşamada açmaya karar verirseniz verin, her proje aşağıdaki belgeleri içermelidir: -- [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) -- [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) -- [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) -- [Davranış kuralları](../code-of-conduct/) +* [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Davranış kuralları](../code-of-conduct/) Bir geliştirici olarak, bu bileşenler beklentileri iletmenize, katkıları yönetmenize ve herkesin yasal haklarını (kendi haklarınız dahil) korumanıza yardımcı olur. Olumlu bir deneyim yaşama şansınızı önemli ölçüde artırırlar. @@ -123,14 +141,20 @@ README'ler, projenizi nasıl kullanılacağını açıklamadan fazlasını yapar README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar. -- Bu proje ne yapıyor? -- Bu proje neden faydalıdır? -- Kullanmaya nasıl başlarım? -- İhtiyacım olursa nereden daha fazla yardım alabilirim? +* Bu proje ne yapıyor? +* Bu proje neden faydalıdır? +* Kullanmaya nasıl başlarım? +* İhtiyacım olursa nereden daha fazla yardım alabilirim? README'nizi, katkıları nasıl ele aldığınız, projenin hedeflerinin ne olduğu ve lisanslar ve atıfla ilgili bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkıları kabul etmek istemiyorsanız veya projeniz henüz üretime hazır değilse, bu bilgileri not edin. - + README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin. @@ -142,15 +166,15 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler. -- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) -- Yeni bir özellik nasıl önerilir -- Proje ortamı nasıl kurulur ve testler nasıl yapılır +* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) +* Yeni bir özellik nasıl önerilir +* Proje ortamı nasıl kurulur ve testler nasıl yapılır Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: -- Aradığınız katkı türleri -- Proje için yol haritanız veya vizyonunuz -- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) +* Aradığınız katkı türleri +* Proje için yol haritanız veya vizyonunuz +* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: @@ -170,7 +194,13 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan ### Davranış kural listesi oluşturmak - + Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. @@ -190,8 +220,8 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy 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 +* [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). @@ -215,7 +245,13 @@ Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici b 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. @@ -231,39 +267,53 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
- +
- +
- +
- +
**Kod**
- +
- +
- +
**İnsanlar** @@ -272,29 +322,39 @@ Bireyseniz:
- +
Bir şirket veya kuruluşsanız:
- +
- +
- +
- +
## Başardınız! From 95b66da2f678846e87bde4772b0254c555bc8190 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Wed, 19 May 2021 02:26:17 +0300 Subject: [PATCH 049/770] Fetch From Upstream (#36) * Bump actions/setup-ruby from 1 to 1.1.3 Bumps [actions/setup-ruby](https://github.com/actions/setup-ruby) from 1 to 1.1.3. - [Release notes](https://github.com/actions/setup-ruby/releases) - [Commits](https://github.com/actions/setup-ruby/compare/v1...v1.1.3) Signed-off-by: dependabot[bot] * Fix formating errors created by Gitlocalize (#35) Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Blake Williams --- .github/workflows/tests.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 27f8a14d6a8..0eb22ebf388 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -11,7 +11,7 @@ jobs: uses: actions/checkout@v2.3.4 - name: Set up Ruby - uses: actions/setup-ruby@v1 + uses: actions/setup-ruby@v1.1.3 - name: Set up Node uses: actions/setup-node@v2.1.5 From 5fd0351050ac5b3dbe070f5c4e56033b8791db54 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Wed, 19 May 2021 07:26:51 +0000 Subject: [PATCH 050/770] Bump nokogiri from 1.11.3 to 1.11.4 Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.11.3 to 1.11.4. - [Release notes](https://github.com/sparklemotion/nokogiri/releases) - [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md) - [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.11.3...v1.11.4) Signed-off-by: dependabot[bot] --- Gemfile.lock | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Gemfile.lock b/Gemfile.lock index 33561394aab..3029fa9f9cc 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -220,7 +220,7 @@ GEM jekyll-seo-tag (~> 2.1) minitest (5.14.4) multipart-post (2.1.1) - nokogiri (1.11.3) + nokogiri (1.11.4) mini_portile2 (~> 2.5.0) racc (~> 1.4) nokogumbo (2.0.5) From 10a1bdbd7166982df5e2ced14ebddf2b1c4d7d60 Mon Sep 17 00:00:00 2001 From: Bart Date: Thu, 20 May 2021 12:05:44 +0800 Subject: [PATCH 051/770] Modify 2 incorrect words MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Modify 2 incorrect words' translation, function and variable always stand for 函数 and 变量 --- _articles/zh-hans/starting-a-project.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md index 897a26d9232..3a8113891a5 100644 --- a/_articles/zh-hans/starting-a-project.md +++ b/_articles/zh-hans/starting-a-project.md @@ -300,7 +300,7 @@ redirect_from: /zh-cn/starting-a-project/
From a2c53e912d2aa0cfeef243ada78b7d9a7f5e0b3a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=AB=AB=E6=B3=93?= Date: Thu, 27 May 2021 11:46:49 +0800 Subject: [PATCH 052/770] Fix typo in article "how to contribute" --- _articles/zh-hant/how-to-contribute.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md index c6eb5d96d90..c29fd8b182e 100644 --- a/_articles/zh-hant/how-to-contribute.md +++ b/_articles/zh-hant/how-to-contribute.md @@ -57,7 +57,7 @@ redirect_from: /zh-tw/how-to-contribute/ ### **你不一定要會寫程式才能貢獻** -對開源做出貢獻常見的誤解之一就是：要寫程式纔算貢獻。其實專案裡不需編碼的工作也是[經常被忽視](https://github.com/blog/2195-the-shape-of-open-source)的部分。你對專案所做的非程式類貢獻，其實是對專案來說莫大的幫助！ +對開源做出貢獻常見的誤解之一就是：要寫程式才算貢獻。其實專案裡不需編碼的工作也是[經常被忽視](https://github.com/blog/2195-the-shape-of-open-source)的部分。你對專案所做的非程式類貢獻，其實是對專案來說莫大的幫助！