[ { "path": ".devcontainer/devcontainer.json", "content": "{\n \"name\": \"Jekyll website\",\n \"image\": \"mcr.microsoft.com/devcontainers/jekyll:latest\",\n \"features\": {\n \"ghcr.io/devcontainers/features/node:1\": {\n \"version\": \"22\"\n },\n \"ghcr.io/devcontainers/features/ruby:1\": {\n \"version\": \"3.3.5\"\n }\n },\n \"forwardPorts\": [\n // Jekyll server\n 4000,\n // Live reload server\n 35729\n ],\n \"postCreateCommand\": \"bundle exec jekyll serve --incremental\"\n}\n" }, { "path": ".github/PULL_REQUEST_TEMPLATE.md", "content": "- [ ] Have you followed the [contributing guidelines](https://github.com/github/opensource.guide/blob/HEAD/CONTRIBUTING.md)?\n- [ ] Have you explained what your changes do, and why they add value to the Guides?\n\n**Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.**\n\n-----\n" }, { "path": ".github/dependabot.yml", "content": "version: 2\nupdates:\n - package-ecosystem: npm\n directory: \"/\"\n schedule:\n interval: daily\n open-pull-requests-limit: 99\n rebase-strategy: disabled\n commit-message:\n prefix: \"chore(deps)\"\n groups:\n dependencies:\n applies-to: version-updates\n update-types:\n - \"minor\"\n - \"patch\"\n - package-ecosystem: \"github-actions\"\n directory: \"/\"\n schedule: \n interval: daily\n open-pull-requests-limit: 99\n rebase-strategy: disabled\n commit-message:\n prefix: \"chore(deps)\"\n groups:\n dependencies:\n applies-to: version-updates\n update-types:\n - \"minor\"\n - \"patch\"\n - package-ecosystem: bundler\n directory: \"/\"\n schedule:\n interval: daily\n versioning-strategy: increase\n open-pull-requests-limit: 99\n commit-message:\n prefix: \"chore(deps)\"\n groups:\n dependencies:\n applies-to: version-updates\n update-types:\n - \"minor\"\n - \"patch\"\n" }, { "path": ".github/workflows/jekyll-preview.yml", "content": "# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\n\n# Sample workflow for building and deploying a Jekyll site to GitHub Pages\nname: Deploy Jekyll site to Pages preview environment\non:\n # Runs on pull requests targeting the default branch\n pull_request_target:\n branches: [\"main\"]\n# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages\npermissions:\n contents: read\n pages: write\n id-token: write\n# Allow only one concurrent deployment per PR, skipping runs queued between the run in-progress and latest queued.\n# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.\nconcurrency:\n group: \"pages-preview @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}\"\n cancel-in-progress: false\njobs:\n # Build job\n build:\n environment:\n name: \"Pages Preview\"\n # Limit permissions of the GITHUB_TOKEN for untrusted code\n permissions:\n contents: read\n runs-on: ubuntu-latest\n steps:\n - name: Checkout\n uses: actions/checkout@v6.0.2\n with:\n # For PRs make sure to checkout the PR branch\n ref: ${{ github.event.pull_request.head.sha }}\n repository: ${{ github.event.pull_request.head.repo.full_name }}\n - name: Setup Pages\n uses: actions/configure-pages@v5.0.0\n - name: Build with Jekyll\n uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1\n with:\n source: ./\n destination: ./_site\n - name: Upload artifact\n # Automatically uploads an artifact from the './_site' directory by default\n uses: actions/upload-pages-artifact@v4.0.0\n # Deployment job\n deploy:\n environment:\n name: \"Pages Preview\"\n url: ${{ steps.deployment.outputs.page_url }}\n # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages\n permissions:\n contents: read\n pages: write\n id-token: write\n runs-on: ubuntu-latest\n needs: build\n steps:\n - name: Deploy to GitHub Pages\n id: deployment\n uses: actions/deploy-pages@v4.0.5\n with:\n preview: \"true\"\n" }, { "path": ".github/workflows/jekyll.yml", "content": "# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\n\n# Sample workflow for building and deploying a Jekyll site to GitHub Pages\nname: Deploy Jekyll site to Pages\non:\n # Runs on pushes targeting the default branch\n push:\n branches: [\"main\"]\n # Allows you to run this workflow manually from the Actions tab\n workflow_dispatch:\n# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages\npermissions:\n contents: read\n pages: write\n id-token: write\n# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.\n# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.\nconcurrency:\n group: \"pages\"\n cancel-in-progress: false\njobs:\n # Build job\n build:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout\n uses: actions/checkout@v6.0.2\n - name: Setup Pages\n uses: actions/configure-pages@v5.0.0\n - name: Build with Jekyll\n uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1\n with:\n source: ./\n destination: ./_site\n - name: Upload artifact\n # Automatically uploads an artifact from the './_site' directory by default\n uses: actions/upload-pages-artifact@v4.0.0\n # Deployment job\n deploy:\n environment:\n name: github-pages\n url: ${{ steps.deployment.outputs.page_url }}\n runs-on: ubuntu-latest\n needs: build\n steps:\n - name: Deploy to GitHub Pages\n id: deployment\n uses: actions/deploy-pages@v4.0.5\n" }, { "path": ".github/workflows/stale.yml", "content": "name: Mark stale PRs\non:\n workflow_dispatch:\n schedule:\n - cron: \"0 12 * * *\"\npermissions:\n contents: read\n issues: write\n pull-requests: write\njobs:\n stale:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/stale@v10.2.0\n with:\n stale-pr-message: >\n This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.\n\n stale-pr-label: \"stale\"\n exempt-pr-labels: \"pinned,security\"\n days-before-pr-stale: 30\n days-before-pr-close: 7\n ascending: true\n operations-per-run: 100\n" }, { "path": ".github/workflows/tests.yml", "content": "name: GitHub Actions CI\non:\n push:\n branches: master\n pull_request:\n merge_group:\npermissions:\n contents: read\njobs:\n tests:\n runs-on: ubuntu-latest\n steps:\n - name: Set up Git repository\n uses: actions/checkout@v6.0.2\n - name: Set up Ruby\n uses: ruby/setup-ruby@19a43a6a2428d455dbd1b85344698725179c9d8c # v1\n with:\n bundler-cache: true\n - name: Set up Node\n uses: actions/setup-node@v6.3.0\n - name: Bootstrap\n run: script/bootstrap\n env:\n SKIP_BUNDLER: true\n - name: Tests\n run: script/test\n" }, { "path": ".gitignore", "content": ".DS_Store\n.asset-downloads\n.bundle\n.jekyll-metadata\n.ruby-version\n.tool-versions\n.sass-cache/\n/vendor\n_site/\nbin\ncss/main.scss\ntest/node_modules\ntest/package-lock.json\n" }, { "path": ".node-version", "content": "12.14.0\n" }, { "path": "CNAME", "content": "opensource.guide\n" }, { "path": "CODEOWNERS", "content": "* @github/communities-oss-reviewers\narticles/legal.md @github/legal-oss\narticles/leadership-and-governance.md @github/legal-oss\n" }, { "path": "CODE_OF_CONDUCT.md", "content": "# Contributor Covenant Code of Conduct\n\n## Our Pledge\n\nIn the interest of fostering an open and welcoming environment, we as\ncontributors and maintainers pledge to make participation in our project and\nour community a harassment-free experience for everyone, regardless of age, body\nsize, disability, ethnicity, gender identity and expression, level of experience,\nnationality, personal appearance, race, religion, or sexual identity and\norientation.\n\n## Our Standards\n\nExamples of behavior that contributes to creating a positive environment\ninclude:\n\n* Using welcoming and inclusive language\n* Being respectful of differing viewpoints and experiences\n* Gracefully accepting constructive criticism\n* Focusing on what is best for the community\n* Showing empathy towards other community members\n\nExamples of unacceptable behavior by participants include:\n\n* The use of sexualized language or imagery and unwelcome sexual attention or\nadvances\n* Trolling, insulting/derogatory comments, and personal or political attacks\n* Public or private harassment\n* Publishing others' private information, such as a physical or electronic\n address, without explicit permission\n* Other conduct which could reasonably be considered inappropriate in a\n professional setting\n\n## Our Responsibilities\n\nProject maintainers are responsible for clarifying the standards of acceptable\nbehavior and are expected to take appropriate and fair corrective action in\nresponse to any instances of unacceptable behavior.\n\nProject maintainers have the right and responsibility to remove, edit, or\nreject comments, commits, code, wiki edits, issues, and other contributions\nthat are not aligned to this Code of Conduct, or to ban temporarily or\npermanently any contributor for other behaviors that they deem inappropriate,\nthreatening, offensive, or harmful.\n\n## Scope\n\nThis Code of Conduct applies both within project spaces and in public spaces\nwhen an individual is representing the project or its community. Examples of\nrepresenting a project or community include using an official project e-mail\naddress, posting via an official social media account, or acting as an appointed\nrepresentative at an online or offline event. Representation of a project may be\nfurther defined and clarified by project maintainers.\n\n## Enforcement\n\nInstances of abusive, harassing, or otherwise unacceptable behavior may be\nreported by contacting opensource@github.com, which is a shared team inbox. If the incident involves someone who receives that shared inbox, you can contact an individual maintainer (@bkeepers or @nayafia) at ```GitHub username``` + ```@github.com```. All\ncomplaints will be reviewed and investigated and will result in a response that\nis deemed necessary and appropriate to the circumstances. The project team is\nobligated to maintain confidentiality with regard to the reporter of an incident.\nFurther details of specific enforcement policies may be posted separately.\n\nProject maintainers who do not follow or enforce the Code of Conduct in good\nfaith may face temporary or permanent repercussions as determined by other\nmembers of the project's leadership.\n\n## Attribution\n\nThis Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,\navailable at [https://contributor-covenant.org/version/1/4][version]\n\n[homepage]: https://contributor-covenant.org\n[version]: https://contributor-covenant.org/version/1/4/\n" }, { "path": "CONTRIBUTING.md", "content": "---\nlayout: default\n---\n\n# Contributing to Open Source Guides\n\nThanks for checking out the Open Source Guides! We're excited to hear and learn from you. Your experiences will benefit others who read and use these guides.\n\nWe've put together the following guidelines to help you figure out where you can best be helpful.\n\n## Table of Contents\n\n0. [Types of contributions we're looking for](#types-of-contributions-were-looking-for)\n0. [Ground rules & expectations](#ground-rules--expectations)\n0. [How to contribute](#how-to-contribute)\n0. [Style guide](#style-guide)\n0. [Setting up your environment](#setting-up-your-environment)\n0. [Community](#community)\n\n## Types of contributions we're looking for\n\nThere are many ways you can directly contribute to the guides (in descending order of need):\n\n* Fix editorial inconsistencies or inaccuracies\n* [Translate guides into other languages](docs/translations.md)\n\nInterested in contributing to this Open Source Guide? Read on!\n\n## Ground rules & expectations\n\nBefore we get started, here are a few things we expect from you (and that you should expect from others):\n\n* Be kind and thoughtful in your conversations around this project. We all come from different backgrounds and projects, which means we likely have different perspectives on \"how open source is done.\" Try to listen to others rather than convince them that your way is correct.\n* Open Source Guides are released with a [Contributor Code of Conduct](./CODE_OF_CONDUCT.md). By participating in this project, you agree to abide by its terms.\n* Please ensure that your contribution passes all tests if you open a pull request. If there are test failures, you will need to address them before we can merge your contribution.\n* When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created, as others will do so if they appreciate it.\n\n## How to contribute\n\nIf you'd like to contribute, start by searching through the [pull requests](https://github.com/github/opensource.guide/pulls) to see whether someone else has raised a similar idea or question.\n\nIf you don't see your idea listed, and you think it fits into the goals of this guide, open a pull request.\n\n## 💡 Quick Tip for Beginners\n\n1. Always create a new branch for your changes.\n2. Write clear commit messages.\n3. Test your changes locally before submitting a PR.\n4. Follow the style guide.\n5. Be patient during reviews.\n\n## Style guide\n\nIf you're writing content, see the [style guide](./docs/styleguide.md) to help your prose match the rest of the guides.\n\n## Setting up your environment\n\nThis site is powered by [Jekyll](https://jekyllrb.com/). Running it on your local machine requires a working [Ruby](https://www.ruby-lang.org/en/) installation with [Bundler](https://bundler.io/) along with [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm).\n\nOnce you have that set up:\n\n1. Grant execution permissions to the scripts:\n\n```bash\nchmod +x script/bootstrap\nchmod +x script/server\n```\n\n2. Execute the scripts:\n\n```bash\n./script/bootstrap\n./script/server\n```\n\n…and open in your web browser.\n\n## Community\n\nDiscussions about the Open Source Guides take place on this repository's [Pull Requests](https://github.com/github/opensource.guide/pulls) section. Anybody is welcome to join these conversations.\n\nWherever 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.\n" }, { "path": "Gemfile", "content": "source \"https://rubygems.org\"\n\ngem \"github-pages\", \"~> 232\", group: :jekyll_plugins\ngem \"nokogiri\", \">= 1.18.3\"\n\ngroup :test do\n gem \"html-proofer\"\n gem \"rake\"\nend\n" }, { "path": "LICENSE", "content": "Attribution 4.0 International\n\n=======================================================================\n\nCreative Commons Corporation (\"Creative Commons\") is not a law firm and\ndoes not provide legal services or legal advice. Distribution of\nCreative Commons public licenses does not create a lawyer-client or\nother relationship. Creative Commons makes its licenses and related\ninformation available on an \"as-is\" basis. Creative Commons gives no\nwarranties regarding its licenses, any material licensed under their\nterms and conditions, or any related information. Creative Commons\ndisclaims all liability for damages resulting from their use to the\nfullest extent possible.\n\nUsing Creative Commons Public Licenses\n\nCreative Commons public licenses provide a standard set of terms and\nconditions that creators and other rights holders may use to share\noriginal works of authorship and other material subject to copyright\nand certain other rights specified in the public license below. The\nfollowing considerations are for informational purposes only, are not\nexhaustive, and do not form part of our licenses.\n\n Considerations for licensors: Our public licenses are\n intended for use by those authorized to give the public\n permission to use material in ways otherwise restricted by\n copyright and certain other rights. Our licenses are\n irrevocable. Licensors should read and understand the terms\n and conditions of the license they choose before applying it.\n Licensors should also secure all rights necessary before\n applying our licenses so that the public can reuse the\n material as expected. Licensors should clearly mark any\n material not subject to the license. This includes other CC-\n licensed material, or material used under an exception or\n limitation to copyright. More considerations for licensors:\n\twiki.creativecommons.org/Considerations_for_licensors\n\n Considerations for the public: By using one of our public\n licenses, a licensor grants the public permission to use the\n licensed material under specified terms and conditions. If\n the licensor's permission is not necessary for any reason--for\n example, because of any applicable exception or limitation to\n copyright--then that use is not regulated by the license. Our\n licenses grant only permissions under copyright and certain\n other rights that a licensor has authority to grant. Use of\n the licensed material may still be restricted for other\n reasons, including because others have copyright or other\n rights in the material. A licensor may make special requests,\n such as asking that all changes be marked or described.\n Although not required by our licenses, you are encouraged to\n respect those requests where reasonable. More_considerations\n for the public:\n\twiki.creativecommons.org/Considerations_for_licensees\n\n=======================================================================\n\nCreative Commons Attribution 4.0 International Public License\n\nBy exercising the Licensed Rights (defined below), You accept and agree\nto be bound by the terms and conditions of this Creative Commons\nAttribution 4.0 International Public License (\"Public License\"). To the\nextent this Public License may be interpreted as a contract, You are\ngranted the Licensed Rights in consideration of Your acceptance of\nthese terms and conditions, and the Licensor grants You such rights in\nconsideration of benefits the Licensor receives from making the\nLicensed Material available under these terms and conditions.\n\n\nSection 1 -- Definitions.\n\n a. Adapted Material means material subject to Copyright and Similar\n Rights that is derived from or based upon the Licensed Material\n and in which the Licensed Material is translated, altered,\n arranged, transformed, or otherwise modified in a manner requiring\n permission under the Copyright and Similar Rights held by the\n Licensor. For purposes of this Public License, where the Licensed\n Material is a musical work, performance, or sound recording,\n Adapted Material is always produced where the Licensed Material is\n synched in timed relation with a moving image.\n\n b. Adapter's License means the license You apply to Your Copyright\n and Similar Rights in Your contributions to Adapted Material in\n accordance with the terms and conditions of this Public License.\n\n c. Copyright and Similar Rights means copyright and/or similar rights\n closely related to copyright including, without limitation,\n performance, broadcast, sound recording, and Sui Generis Database\n Rights, without regard to how the rights are labeled or\n categorized. For purposes of this Public License, the rights\n specified in Section 2(b)(1)-(2) are not Copyright and Similar\n Rights.\n\n d. Effective Technological Measures means those measures that, in the\n absence of proper authority, may not be circumvented under laws\n fulfilling obligations under Article 11 of the WIPO Copyright\n Treaty adopted on December 20, 1996, and/or similar international\n agreements.\n\n e. Exceptions and Limitations means fair use, fair dealing, and/or\n any other exception or limitation to Copyright and Similar Rights\n that applies to Your use of the Licensed Material.\n\n f. Licensed Material means the artistic or literary work, database,\n or other material to which the Licensor applied this Public\n License.\n\n g. Licensed Rights means the rights granted to You subject to the\n terms and conditions of this Public License, which are limited to\n all Copyright and Similar Rights that apply to Your use of the\n Licensed Material and that the Licensor has authority to license.\n\n h. Licensor means the individual(s) or entity(ies) granting rights\n under this Public License.\n\n i. Share means to provide material to the public by any means or\n process that requires permission under the Licensed Rights, such\n as reproduction, public display, public performance, distribution,\n dissemination, communication, or importation, and to make material\n available to the public including in ways that members of the\n public may access the material from a place and at a time\n individually chosen by them.\n\n j. Sui Generis Database Rights means rights other than copyright\n resulting from Directive 96/9/EC of the European Parliament and of\n the Council of 11 March 1996 on the legal protection of databases,\n as amended and/or succeeded, as well as other essentially\n equivalent rights anywhere in the world.\n\n k. You means the individual or entity exercising the Licensed Rights\n under this Public License. Your has a corresponding meaning.\n\n\nSection 2 -- Scope.\n\n a. License grant.\n\n 1. Subject to the terms and conditions of this Public License,\n the Licensor hereby grants You a worldwide, royalty-free,\n non-sublicensable, non-exclusive, irrevocable license to\n exercise the Licensed Rights in the Licensed Material to:\n\n a. reproduce and Share the Licensed Material, in whole or\n in part; and\n\n b. produce, reproduce, and Share Adapted Material.\n\n 2. Exceptions and Limitations. For the avoidance of doubt, where\n Exceptions and Limitations apply to Your use, this Public\n License does not apply, and You do not need to comply with\n its terms and conditions.\n\n 3. Term. The term of this Public License is specified in Section\n 6(a).\n\n 4. Media and formats; technical modifications allowed. The\n Licensor authorizes You to exercise the Licensed Rights in\n all media and formats whether now known or hereafter created,\n and to make technical modifications necessary to do so. The\n Licensor waives and/or agrees not to assert any right or\n authority to forbid You from making technical modifications\n necessary to exercise the Licensed Rights, including\n technical modifications necessary to circumvent Effective\n Technological Measures. For purposes of this Public License,\n simply making modifications authorized by this Section 2(a)\n (4) never produces Adapted Material.\n\n 5. Downstream recipients.\n\n a. Offer from the Licensor -- Licensed Material. Every\n recipient of the Licensed Material automatically\n receives an offer from the Licensor to exercise the\n Licensed Rights under the terms and conditions of this\n Public License.\n\n b. No downstream restrictions. You may not offer or impose\n any additional or different terms or conditions on, or\n apply any Effective Technological Measures to, the\n Licensed Material if doing so restricts exercise of the\n Licensed Rights by any recipient of the Licensed\n Material.\n\n 6. No endorsement. Nothing in this Public License constitutes or\n may be construed as permission to assert or imply that You\n are, or that Your use of the Licensed Material is, connected\n with, or sponsored, endorsed, or granted official status by,\n the Licensor or others designated to receive attribution as\n provided in Section 3(a)(1)(A)(i).\n\n b. Other rights.\n\n 1. Moral rights, such as the right of integrity, are not\n licensed under this Public License, nor are publicity,\n privacy, and/or other similar personality rights; however, to\n the extent possible, the Licensor waives and/or agrees not to\n assert any such rights held by the Licensor to the limited\n extent necessary to allow You to exercise the Licensed\n Rights, but not otherwise.\n\n 2. Patent and trademark rights are not licensed under this\n Public License.\n\n 3. To the extent possible, the Licensor waives any right to\n collect royalties from You for the exercise of the Licensed\n Rights, whether directly or through a collecting society\n under any voluntary or waivable statutory or compulsory\n licensing scheme. In all other cases the Licensor expressly\n reserves any right to collect such royalties.\n\n\nSection 3 -- License Conditions.\n\nYour exercise of the Licensed Rights is expressly made subject to the\nfollowing conditions.\n\n a. Attribution.\n\n 1. If You Share the Licensed Material (including in modified\n form), You must:\n\n a. retain the following if it is supplied by the Licensor\n with the Licensed Material:\n\n i. identification of the creator(s) of the Licensed\n Material and any others designated to receive\n attribution, in any reasonable manner requested by\n the Licensor (including by pseudonym if\n designated);\n\n ii. a copyright notice;\n\n iii. a notice that refers to this Public License;\n\n iv. a notice that refers to the disclaimer of\n warranties;\n\n v. a URI or hyperlink to the Licensed Material to the\n extent reasonably practicable;\n\n b. indicate if You modified the Licensed Material and\n retain an indication of any previous modifications; and\n\n c. indicate the Licensed Material is licensed under this\n Public License, and include the text of, or the URI or\n hyperlink to, this Public License.\n\n 2. You may satisfy the conditions in Section 3(a)(1) in any\n reasonable manner based on the medium, means, and context in\n which You Share the Licensed Material. For example, it may be\n reasonable to satisfy the conditions by providing a URI or\n hyperlink to a resource that includes the required\n information.\n\n 3. If requested by the Licensor, You must remove any of the\n information required by Section 3(a)(1)(A) to the extent\n reasonably practicable.\n\n 4. If You Share Adapted Material You produce, the Adapter's\n License You apply must not prevent recipients of the Adapted\n Material from complying with this Public License.\n\n\nSection 4 -- Sui Generis Database Rights.\n\nWhere the Licensed Rights include Sui Generis Database Rights that\napply to Your use of the Licensed Material:\n\n a. for the avoidance of doubt, Section 2(a)(1) grants You the right\n to extract, reuse, reproduce, and Share all or a substantial\n portion of the contents of the database;\n\n b. if You include all or a substantial portion of the database\n contents in a database in which You have Sui Generis Database\n Rights, then the database in which You have Sui Generis Database\n Rights (but not its individual contents) is Adapted Material; and\n\n c. You must comply with the conditions in Section 3(a) if You Share\n all or a substantial portion of the contents of the database.\n\nFor the avoidance of doubt, this Section 4 supplements and does not\nreplace Your obligations under this Public License where the Licensed\nRights include other Copyright and Similar Rights.\n\n\nSection 5 -- Disclaimer of Warranties and Limitation of Liability.\n\n a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE\n EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS\n AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF\n ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,\n IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,\n WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR\n PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,\n ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT\n KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT\n ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.\n\n b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE\n TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,\n NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,\n INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,\n COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR\n USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN\n ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR\n DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR\n IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.\n\n c. The disclaimer of warranties and limitation of liability provided\n above shall be interpreted in a manner that, to the extent\n possible, most closely approximates an absolute disclaimer and\n waiver of all liability.\n\n\nSection 6 -- Term and Termination.\n\n a. This Public License applies for the term of the Copyright and\n Similar Rights licensed here. However, if You fail to comply with\n this Public License, then Your rights under this Public License\n terminate automatically.\n\n b. Where Your right to use the Licensed Material has terminated under\n Section 6(a), it reinstates:\n\n 1. automatically as of the date the violation is cured, provided\n it is cured within 30 days of Your discovery of the\n violation; or\n\n 2. upon express reinstatement by the Licensor.\n\n For the avoidance of doubt, this Section 6(b) does not affect any\n right the Licensor may have to seek remedies for Your violations\n of this Public License.\n\n c. For the avoidance of doubt, the Licensor may also offer the\n Licensed Material under separate terms or conditions or stop\n distributing the Licensed Material at any time; however, doing so\n will not terminate this Public License.\n\n d. Sections 1, 5, 6, 7, and 8 survive termination of this Public\n License.\n\n\nSection 7 -- Other Terms and Conditions.\n\n a. The Licensor shall not be bound by any additional or different\n terms or conditions communicated by You unless expressly agreed.\n\n b. Any arrangements, understandings, or agreements regarding the\n Licensed Material not stated herein are separate from and\n independent of the terms and conditions of this Public License.\n\n\nSection 8 -- Interpretation.\n\n a. For the avoidance of doubt, this Public License does not, and\n shall not be interpreted to, reduce, limit, restrict, or impose\n conditions on any use of the Licensed Material that could lawfully\n be made without permission under this Public License.\n\n b. To the extent possible, if any provision of this Public License is\n deemed unenforceable, it shall be automatically reformed to the\n minimum extent necessary to make it enforceable. If the provision\n cannot be reformed, it shall be severed from this Public License\n without affecting the enforceability of the remaining terms and\n conditions.\n\n c. No term or condition of this Public License will be waived and no\n failure to comply consented to unless expressly agreed to by the\n Licensor.\n\n d. Nothing in this Public License constitutes or may be interpreted\n as a limitation upon, or waiver of, any privileges and immunities\n that apply to the Licensor or You, including from the legal\n processes of any jurisdiction or authority.\n\n\n=======================================================================\n\nCreative Commons is not a party to its public\nlicenses. Notwithstanding, Creative Commons may elect to apply one of\nits public licenses to material it publishes and in those instances\nwill be considered the \"Licensor.\" The text of the Creative Commons\npublic licenses is dedicated to the public domain under the CC0 Public\nDomain Dedication. Except for the limited purpose of indicating that\nmaterial is shared under a Creative Commons public license or as\notherwise permitted by the Creative Commons policies published at\ncreativecommons.org/policies, Creative Commons does not authorize the\nuse of the trademark \"Creative Commons\" or any other trademark or logo\nof Creative Commons without its prior written consent including,\nwithout limitation, in connection with any unauthorized modifications\nto any of its public licenses or any other arrangements,\nunderstandings, or agreements concerning use of licensed material. For\nthe avoidance of doubt, this paragraph does not form part of the\npublic licenses.\n\nCreative Commons may be contacted at creativecommons.org.\n" }, { "path": "README.md", "content": "# Open Source Guides\n[![Build Status](https://github.com/github/opensource.guide/workflows/GitHub%20Actions%20CI/badge.svg)](https://github.com/github/opensource.guide/actions)\n\nOpen Source Guides (https://opensource.guide/) are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open-source project.\n\n## Background\nOpen Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is that we felt that there weren't enough resources for people creating open-source projects.\n\nOur 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.\n\n## Contributing\n\nThis site is powered by [Jekyll](https://jekyllrb.com/). Check out our [contributing guidelines](/CONTRIBUTING.md) for ways to offer feedback and contribute.\n\n## Licenses\n\nContent is released under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/). See [notices](notices.md) for complete details, including attribution guidelines, contribution terms, and software and third-party licenses and permissions.\n\n## Acknowledgments\n\nThe initial release of these guides was authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**.\n\nThanks to **[@aitchabee][5], [@benbalter][6], [@brettcannon][7], [@caabernathy][8], [@coralineada][9], [@dmleong][10], [@ericholscher][11], [@gr2m][12], [@janl][13], [@jessfraz][14], [@bluesomewhere][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides.\n\n## Disclaimer\nWhile we've got advice about running an open source project, we're not lawyers. Be sure to read our [disclaimer](notices.md#legal-disclaimer) before diving in.\n\n[1]:https://github.com/nayafia\n[2]:https://github.com/bkeepers\n[3]:https://github.com/stephbwills\n[4]:https://github.com/mlinksva\n[5]:https://github.com/aitchabee\n[6]:https://github.com/benbalter\n[7]:https://github.com/brettcannon\n[8]:https://github.com/caabernathy\n[9]:https://github.com/CoralineAda\n[10]:https://github.com/dmleong\n[11]:https://github.com/ericholscher\n[12]:https://github.com/gr2m\n[13]:https://github.com/janl\n[14]:https://github.com/jessfraz\n[15]:https://github.com/bluesomewhere\n[16]:https://github.com/kfogel\n[17]:https://github.com/kytrinyx\n[18]:https://github.com/lee-dohm\n[19]:https://github.com/mikeal\n[20]:https://github.com/MikeMcQuaid\n[21]:https://github.com/nathansobo\n[22]:https://github.com/nruff\n[23]:https://github.com/nsqe\n[24]:https://github.com/orta\n[25]:https://github.com/parkr\n[26]:https://github.com/shazow\n[27]:https://github.com/steveklabnik\n[28]:https://github.com/wooorm\n[29]:https://github.com/sophshep\n[30]:https://github.com/jeejkang\n" }, { "path": "Rakefile", "content": "require \"rake/testtask\"\nRake::TestTask.new do |t|\n t.libs << \"test\"\n t.test_files = FileList[\"test/*_test.rb\"]\n t.warning = false\n t.verbose = false\nend\n\ntask default: :test\n" }, { "path": "_articles/ar/best-practices.md", "content": "---\nlang: ar\ntitle: أفضل الممارسات للمشرفين\ndescription: تسهيل حياتك كمشرف على مشروع مفتوح المصدر، من توثيق العمليات إلى الاستفادة من مجتمعك\nclass: best-practices\norder: 5\nimage: /assets/images/cards/best-practices.png\nrelated:\n - metrics\n - leadership\n---\n\n
\n\n## ما معنى أن تكون مسؤول عن مشروع؟\n\nإذا كنت مسؤولًا عن مشروع open source يستخدمه عدد كبير من الناس، فمن المؤكد أنك لاحظت أنك أصبحت تقوم بـ coding أقل، وتقضي وقتًا أكثر في الرد على issues المشاكل والبلاغات .\n\nفي بدايات المشروع، تكون لا تزال تجرب أفكارًا جديدة وتتخذ قرارات بناءً على ما ترغب فيه. ومع نمو المشروع وزيادة شعبيته، ستجد نفسك تعمل أكثر مع users و contributors\n\nصيانة مشروع تتطلب أكثر من مجرد كتابة الكود. غالبًا ما تكون هذه المهام غير متوقعة، لكنها مهمة بنفس قدر أهمية المشروع قيد التطور. جمعنا بعض الطرق لتسهيل حياتك، من توثيق العمليات إلى الاستفادة من مجتمعك.\n\n## وثّق الإجراءات الخاصة بك\n\nإن تدوين الأمور يعد واحدًا من أهم الأشياء التي يمكنك القيام بها كـ maintainer.\n\nالـ Documentation ليس فقط لتوضيح أفكارك لنفسك، بل يساعد أيضًا الآخرين على فهم ما تحتاجه أو تتوقعه منهم، حتى قبل أن يسألوا.\n\nعندما تكون الأمور مكتوبة، يصبح من الأسهل عليك قول \"لا\" عندما لا تناسب مسألة معينة الـ scope الخاص بك. وفي الوقت نفسه، يصبح من الأسهل على الآخرين الدخول والمساعدة. فأنت لا تعرف من قد يقرأ أو يستخدم مشروعك.\n\nحتى لو لم تكتب فقرات كاملة، فإن تدوينها كنقاط سريعة bullet points أفضل من عدم كتابة أي شيء على الإطلاق.\n\nوتذكّر دائمًا أن تحافظ على الـ documentation محدثًا up-to-date. وإذا لم تتمكن من القيام بذلك دائمًا، فاحذف التوثيق القديم أو وضح أنه قديم outdated، حتى يعرف الـ contributors أن التحديثات مرحّب بها.\n\n### اكتب رؤية مشروعك\n\nابدأ بكتابة أهداف مشروعك. أضفها في ملف الـ README، أو أنشئ ملفًا منفصلًا وسمّه VISION. إذا كانت هناك أي عناصر أخرى قد تساعد، مثل \"خارطة طريق\" للمشروع project roadmap، اجعلها public أيضًا.\n\nعندما تمتلك رؤية واضحة ومكتوبة، فإن ذلك يجعلك مركّزًا ويساعدك على تجنّب ما يُعرف بـ \"scope creep\" الزحف بالنطاق الذي يحدث نتيجة مساهمات الآخرين.\n\nكمثال، اكتشف @lord أن وجود رؤية للمشروع ساعده على تحديد أي الطلبات تستحق أن يقضي وقتَه عليها. وكـ maintainer جديد، ندم على عدم التزامه بـ scope مشروعه عندما تعامل مع أول feature request لمشروع [Slate](https://github.com/lord/slate).\n\n\n\n### وضّح توقعاتك\n\nكتابة القوانين Rules أمر مرهق أحيانًا. قد تشعر أحيانًا وكأنك \"شرطي\" يراقب تصرفات الآخرين أو أنك تفسد الجو المرح.\n\nلكن الحقيقة أن القوانين الجيدة، عندما تُكتب وتُطبق بعدل، تمنح الـ maintainers القوة. فهي تمنعك من الانجرار للقيام بأمور لا ترغب فيها.\n\nأغلب الأشخاص الذين يشاهدون مشروعك لا يعرفون عنك شيئًا أو عن ظروفك. قد يفترضون أنك تتقاضى أجرًا للعمل عليه، خصوصًا إذا كانوا يستخدمونه بشكل دائم ويعتمدون عليه. ربما كنت في السابق تخصص وقتًا كبيرًا لمشروعك، لكن الآن قد تكون مشغولًا بعمل آخر أو لديك التزامات عائلية.\n\nكل هذا طبيعي وعادي جدًا، لكن المهم أن تتأكد أن الآخرين على علم بهذه الظروف.\n\nإذا كانت إدارتك للمشروع part-time أو مجرد تطوع كامل volunteered، كن صريحًا بشأن مقدار الوقت المتاح لديك. هذا لا يعني الوقت الذي تعتقد أن المشروع يحتاجه، ولا الوقت الذي يريدك الآخرون أن تقضيه فيه.\n\nإليك بعض القوانين التي يستحق كتابتها:\n\n* كيفية مراجعة المساهمات contribution وقبولها:( هل تحتاج إلى tests ؟ هل يجب تعبئة issue template نموذج بلاغ ؟ )\n* أنواع المساهمات التي تقبلها:( هل تريد المساعدة في جزء معين من كود المشروع فقط؟ )\n* متى يكون من المقبول متابعتك أو تذكيرك:( مثلًا، \"يمكن توقع رد من مسؤول المشروع خلال 7 أيام. إذا لم تسمع شيئًا بعد هذا الوقت، من المقبول تمامًا إرسال ping في النقاش.\" )\n* مقدار الوقت الذي تخصصه للمشروع:( مثلًا، \"نخصص حوالي 5 ساعات في الأسبوع لهذا المشروع.\" )\n\nومن الأمثلة للمشاريع التي لها قواعد أساسية للمحافظين والمساهمين :[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) ,[Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md)\n\n### اجعل التواصل عامًّا\n\nلا تنسَ أن تعمل document لتفاعلاتك أيضًا. قدر ما تستطيع، اجعل التواصل الذي يخص مشروعك public. إذا حاول أحدهم التواصل معك على الخاص لمناقشة feature request أو احتاج support، فبكل أدب وجّهه إلى قناة تواصل علنية، مثل mailing list (قائمة بريدية) أو issue tracker (متتبّع البلاغات).\n\nإذا جلست مع maintainers آخرين، أو اتخذتم قرارًا كبيرًا على الخاص، فقُم بتوثيق هذه النقاشات بشكل public، حتى ولو فقط بنشر notes الخاصة بك.\n\nبهذه الطريقة، أي شخص جديد ينضم إلى الـ community الخاص بك سيحصل على نفس المعلومات التي يمتلكها الشخص الموجود منذ سنوات.\n\n## تعلم قول لا {#تعلم-قول-لا}\n\nلقد دونت الأمور مكتوبة. من الناحية المثالية، يجب أن يقرأ الجميع التوثيق الخاص بك، لكن في الواقع، ستضطر إلى تذكير الآخرين بوجود هذه المعرفة.\n\nوجود كل شيء مكتوبًا يساعد على جعل المواقف أقل شخصية عندما تحتاج إلى تطبيق قواعدك.\n\nقول لا ليس ممتعًا، لكن عبارة _\"مساهمتك لا تتوافق مع معايير هذا المشروع\"_ تبدو أقل شخصية من _\"لا أحب مساهمتك\"_.\n\nقول لا ينطبق على العديد من المواقف التي ستواجهها كمحافظ على المشروع: طلبات ميزات لا تتناسب مع نطاق المشروع، شخص يشتت النقاش، القيام بأعمال غير ضرورية للآخرين.\n\n### حافظ على ودية النقاش\n\nأحد أهم الأماكن التي ستتدرب فيها على قول لا هو قائمة القضايا issue وطلبات السحب pull request. كمحافظ على المشروع، ستتلقى حتماً اقتراحات قد لا ترغب في قبولها.\n\nربما تغير المساهمة نطاق مشروعك أو لا تتوافق مع رؤيتك. ربما الفكرة جيدة، لكن التنفيذ ضعيف.\n\nبغض النظر عن السبب، من الممكن التعامل بلباقة مع المساهمات التي لا تفي بمعايير مشروعك.\n\nإذا تلقيت مساهمة لا ترغب في قبولها، قد تكون ردة فعلك الأولى هي تجاهلها أو التظاهر بعدم رؤيتها. القيام بذلك قد يجرح مشاعر الشخص الآخر، وربما يثبط أيضًا الآخرين المحتملين للمساهمة في مجتمعك.\n\n\n\nلا تترك مساهمة لا ترغب بها مفتوحة فقط لأنك تشعر بالذنب أو بدافع اللطف. مع مرور الوقت، تراكم issues و PRs غير المردود عليها سيجعل العمل على مشروعك أكثر توترًا ويخلق شعورًا بالرهبة.\n\nمن الأفضل أن تقوم بإغلاق المساهمات التي تعلم مسبقًا أنك لن تقبلها، وبشكل فوري. وإذا كان مشروعك يعاني بالفعل من backlog كبير، فإن @steveklabnik يقدّم نصائح ممتازة حول [كيفية إجراء triage للـ issues بطريقة فعّالة](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).\n\nأيضًا، تجاهل المساهمات يرسل إشارة سلبية إلى الـ community. المشاركة في مشروع مفتوح المصدر قد تكون خطوة مخيفة، خصوصًا إذا كانت هذه أول تجربة للشخص. حتى إن لم تقبل المساهمة، فمن المهم الاعتراف بجهد صاحبها وشكره على اهتمامه، فمجرد مشاركته هو بمثابة مجاملة كبيرة للمشروع!\n\nإذا لم تكن ترغب في قبول مساهمة معينة:\n\n* **اشكرهم** على مساهمتهم.\n* **اشرح لهم سبب عدم توافقها** مع نطاق المشروع **scope**، وقدّم اقتراحات واضحة للتحسين إن أمكن. كن لطيفًا، لكن حازمًا.\n* **ضع رابطًا إلى التوثيق** المناسب **documentation** إن كان متوفرًا. إذا لاحظت وصول طلبات متكررة لأمور لا ترغب في قبولها، أضفها إلى التوثيق لتجنّب تكرار الشرح.\n* **قم بإغلاق الطلب**.\n\nلا تحتاج إلى أكثر من جملة أو جملتين للرد. على سبيل المثال، عندما أبلغ أحد مستخدمي [celery](https://github.com/celery/celery/) عن خطأ متعلق بـ Windows، قام **@berkerpeksag** بالرد بطريقة واضحة:\n\n![Celery screenshot](/assets/images/best-practices/celery.png)\n\nإذا كانت فكرة قول \"لا\" ترعبك، فأنت لست وحدك. كما قالت @jessfraz [هنا](https://blog.jessfraz.com/post/the-art-of-closing/):\n\n> لقد تحدثت مع القائمين بالصيانة في عدة مشاريع مفتوحة المصدر مختلفة، مثل Mesos وKubernetes وChromium، وجميعهم يتفقون على أن أحد أصعب الأمور في كونك صيانياً هو قول \"لا\" للتحديثات (patches) التي لا ترغب بها.\n\nلا تشعر بالذنب لعدم رغبتك في قبول مساهمة شخص ما، فالقاعدة الأولى في المصدر المفتوح وفقًا لما ذكره @shykes [هنا](https://twitter.com/solomonstre/status/715277134978113536) هي _\"لا مؤقت، نعم دائم\"_، ورفض المساهمة لا يعني رفض الشخص نفسه وراءها.\n\nفي النهاية، إذا لم تكن المساهمة جيدة بما يكفي، فلا يُلزمك قبولها. كن لطيفًا ومتجاوبًا عندما يساهم الناس في مشروعك، لكن اقبل فقط التغييرات التي تؤمن حقًا أنها ستحسن مشروعك. كلما مارست قول \"لا\" أكثر، أصبح الأمر أسهل. وعد.\n\n### كُن مبادرًا\n\nلتقليل كمية المساهمات غير المرغوب فيها من البداية، قم بشرح process مشروعك لتقديم وقبول المساهمات في ملف contributing guide دليل المساهمة.\n\nإذا لاحظت وصول مساهمات low-quality بشكل متكرر، اجعل من الضروري أن يقوم contributors ببعض الخطوات المسبقة، مثل:\n\n* تعبئة template للـ issue أو الـ PR، أو استخدام قائمة تدقيق.\n* فتح issue قبل تقديم PR.\n\nإذا لم يلتزموا بالقواعد، قم بإغلاق الـ issue فورًا ووجّههم إلى الـ documentation الخاص بك.\n\nرغم أن هذه الطريقة قد تبدو unkind في البداية، إلا أن كونك proactive مفيد للطرفين. فهو يقلل من احتمال أن يضع شخص ما ساعات طويلة من العمل الضائع على pull request لن يتم قبوله، ويسهّل إدارة ضغط العمل الخاص بك.\n\n\n\nأحيانًا، عندما تقول \"لا\"، قد يغضب المساهم المحتمل أو ينتقد قرارك. إذا أصبح سلوكه عدائيًا، [اتخذ خطوات لتهدئة الوضع](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) أو حتى قم بإزالته من الـcommunity الخاص بك، إذا لم يكن راغبًا في التعاون بشكل بنّاء.\n\n### تبنَّ نهج الإشراف والتوجيه\n\nقد يقوم أحد الأعضاء في الـ community بتقديم contributions متكررة لا تتماشى مع standards المشروع. هذا قد يكون محبطًا للطرفين بسبب تكرار حالات الرفض.\n\nإذا لاحظت أن هذا الشخص متحمّس للمشروع ولكنه يحتاج إلى مزيد من polish، فتحلَّ بالصبر. اشرح له بوضوح في كل مرة سبب عدم توافق مساهمته مع expectations المشروع. حاول توجيهه نحو task أسهل أو أقل غموضًا، مثل issue تحمل وسم \"good first issue\" ليبدأ بالتدرّج. وإن كان لديك وقت، فكّر في منحه mentoring خلال أول مساهمة له، أو اطلب من أحد أعضاء الـ community مساعدته في ذلك.\n\n## استفد من قوة الـمجتمع\n\nلست مضطرًا للقيام بكل شيء بنفسك. وُجدت الـ community من أجل دعم المشروع! حتى لو لم يكن لديك مساهمون نشطون بعد، لكن لديك عدد كبير من users، فيمكن توجيههم للمساعدة.\n\n### قسّم عبء العمل\n\nإذا كنت تبحث عن من يساهم معك، ابدأ بطلب الدعم ممن حولك.\n\nإحدى الطرق لجذب contributors جدد هي تحديد issues بسيطة مناسبة للمبتدئين عبر وضع label واضح عليها. عندها سيقوم GitHub بإبراز هذه issues في أماكن مختلفة، مما يزيد من visibility لها.\n\nعندما تلاحظ contributors جدد يقدمون مساهمات متكررة، قدّر جهودهم من خلال منحهم responsibility أكبر. ولا تنسَ توثيق كيفية التطور داخل المشروع والوصول إلى leadership roles لمن يرغب بذلك.\n\nتشجيع الآخرين على مشاركة ownership في المشروع يمكن أن يقلّل من workload عنك بشكل كبير، كما حدث مع المشروع p5.js الخاص بـ @lmccart.\n\n\n\nإذا احتجت إلى الابتعاد عن مشروعك أو اضطررت إلى step away عن مشروعك، سواء لفترة hiatus مؤقتة أو بشكل permanently دائم، فلا يوجد أي شعور بالـ shame في أن تطلب من شخص آخر أن take over تولّي المسؤولية بدلاً منك.\n\nإذا كان هناك من هو متحمّس لـ direction المشروع، يمكنك منحه commit access أو تسليم الـ control الإداري رسميًا لشخص آخر. وإذا قام أحدهم بعمل fork للمشروع ويقوم بـ maintaining نشط له في مكان آخر، فمن الجيد أن تضع link لهذا الـ fork من مشروعك الأصلي. من الرائع أن هناك أشخاصًا يريدون لمشروعك أن يبقى live on!\n\n@progrium اكتشف أن توثيق الـ vision لمشروعه Dokku ساعد في استمرار تحقيق الأهداف حتى بعد ابتعاده عن المشروع:\n\n> \"كتبت صفحة wiki أوضّح فيها ما أريد ولماذا. ولدهشتي، بدأ الـ maintainers بتحريك المشروع في هذا الاتجاه! هل حدث تمامًا كما كنت سأفعله؟ ليس دائمًا. لكنه قرّب المشروع أكثر نحو الرؤية التي وضعتها.\"\n\n### دع الآخرين يبنون الحلول التي يحتاجونها\n\nإذا كان لدى مساهم محتمل رأي مختلف حول ما ينبغي أن يقوم به مشروعك، يمكنك \"encourage\" تشجيعه بلطف للعمل على fork خاص به.\n\nالـ Forking ليس أمرًا سيئًا. القدرة على copy وmodify المشاريع هي واحدة من أقوى مزايا open source. تشجيع أعضاء الـ community على العمل في fork خاص بهم يمكن أن يوفر لهم creative outlet يحتاجونه، دون أن يتعارض مع vision مشروعك.\n\n\n\nنفس الشيء ينطبق على المستخدم الذي يريد حلًا لا تمتلك الوقت لبنائه. تقديم واجهات برمجة التطبيقات وخيارات التخصيص يساعد الآخرين على تلبية احتياجاتهم دون تعديل المصدر مباشرة. [@orta وجد أن تشجيع الإضافات في CocoaPods أدى إلى \"بعض من أكثر الأفكار إثارة للاهتمام\"](https://artsy.github.io/blog/2016/07/03/handling-big-projects/).\n\n> من الطبيعي تقريبًا أنه عندما يكبر المشروع، يجب على المسؤولين أن يكونوا أكثر حذرًا عند إضافة كود جديد. تصبح ماهرًا في قول \"لا\"، لكن الكثير من الناس لديهم احتياجات مشروعة. لذلك، ينتهي بك الأمر بتحويل أداتك إلى منصة.\n\n## الاستعانة بالروبوتات\n\nكما توجد مهام يمكن للآخرين مساعدتك فيها، هناك مهام أخرى لا ينبغي لأي إنسان القيام بها. الروبوتات صديقك، استخدمها لتسهيل حياتك كمشرف على المشروع.\n\n### اطلب اختبارات وفحوصات أخرى لتحسين جودة الكود\n\nإحدى أهم طرق أتمتة مشروعك هي إضافة tests.\n\nتساعد tests المساهمين على الشعور بالثقة بعدم كسر أي شيء، كما تسهل عليك مراجعة وقبول المساهمات بسرعة. كلما كنت أكثر استجابة، كان مجتمعك أكثر تفاعلًا.\n\nقم بإعداد automatic tests لتعمل على جميع المساهمات الواردة، وتأكد من أنه يمكن تشغيلها محليًا بسهولة من قبل المساهمين. اجعل كل مساهمة تمر عبر tests قبل تقديمها، لتضع معيارًا أدنى للجودة. تساعد required status checks على GitHub في ضمان عدم دمج أي تغيير دون اجتياز tests.\n\nإذا أضفت tests، تأكد من شرح كيفية عملها في ملف CONTRIBUTING.\n\n\n\n### استخدام الأدوات لأتمتة مهام الصيانة الأساسية\n\nالأمر الجيد في إدارة مشروع مشهور هو أن مسؤولين آخرين ربما واجهوا مشاكل مشابهة ووجدوا لها حلولًا.\n\nهناك [variety of tools](https://github.com/showcases/tools-for-open-source) متاحة لمساعدتك على أتمتة بعض جوانب عمل الصيانة. بعض الأمثلة:\n\n* [semantic-release](https://github.com/semantic-release/semantic-release) لأتمتة الإصدارات\n* [mention-bot](https://github.com/facebook/mention-bot) لذكر المراجعين المحتملين في pull requests\n* [Danger](https://github.com/danger/danger) يساعد في أتمتة مراجعة الكود\n* [no-response](https://github.com/probot/no-response) يغلق القضايا التي لم يرد فيها المؤلف على طلب معلومات إضافية\n* [dependabot](https://github.com/dependabot) يتحقق يوميًا من ملفات الاعتماديات ويفتح pull requests لأي تحديثات قديمة\n\nبالنسبة لتقارير الأخطاء والمساهمات الشائعة، لدى GitHub [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates) يمكنك إعدادها لتسهيل التواصل معك. @TalAter أنشأ [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) لمساعدتك في كتابة هذه القوالب.\n\nلإدارة إشعارات البريد الإلكتروني، يمكنك إعداد [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) لتنظيمها حسب الأولوية.\n\nإذا أردت التقدم أكثر، يمكن لدلائل الأسلوب و linters توحيد مساهمات المشروع وجعل مراجعتها وقبولها أسهل.\n\nلكن إذا كانت معاييرك معقدة جدًا، فقد تزيد من صعوبة المساهمة. تأكد من إضافة القواعد الضرورية فقط لتسهيل الأمور على الجميع.\n\nإذا لم تكن متأكدًا من الأدوات المناسبة، انظر إلى ما يفعله المشاريع الشهيرة الأخرى، خصوصًا في نفس النظام البيئي الخاص بك. على سبيل المثال، كيف تبدو عملية المساهمة في وحدات Node الأخرى؟ استخدام أدوات مماثلة سيجعل عملية المساهمة أكثر ألفة للمساهمين المستهدفين.\n\n## من المقبول أخذ استراحة\n\nربما كان العمل في open source مصدرًا للمتعة بالنسبة لك. ربما بدأ الآن يثير شعورًا بالتجنب أو الذنب.\n\nقد تشعر بالإرهاق أو بالخوف عند التفكير في مشاريعك، وفي الوقت نفسه تتراكم القضايا وpull requests.\n\nالإرهاق burnout قضية حقيقية وشائعة في العمل المفتوح المصدر، خاصة بين المسؤولين. كمحافظ على المشروع، سعادتك شرط أساسي لاستمرار أي مشروع open source.\n\nوبالرغم من أن هذا بديهي، خذ استراحة! لا تنتظر حتى تشعر بالإرهاق لتأخذ عطلة. @brettcannon، مطور أساسي في Python، قرر أخذ [month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) بعد 14 سنة من العمل التطوعي فيOSS.\n\nمثل أي عمل آخر، ستبقيك الاستراحات المنتظمة متجدد النشاط، سعيدًا، ومتحمسًا لمواصلة عملك.\n\n\n\nأحيانًا يكون من الصعب أخذ استراحة من العمل في open source عندما تشعر أن الجميع يحتاج إليك. قد يحاول البعض حتى جعلك تشعر بالذنب إذا ابتعدت قليلًا.\n\nابذل جهدك لإيجاد الدعم لمستخدميك ولمجتمعك أثناء ابتعادك عن المشروع. وإذا لم تتمكن من العثور على الدعم الذي تحتاجه، خذ استراحة على أي حال. تأكد من إعلام الآخرين بعدم تواجدك، حتى لا يشعروا بالارتباك بسبب قلة استجابتك.\n\nأخذ الاستراحات لا يقتصر على الإجازات فقط. إذا كنت لا ترغب في العمل على open source في عطلات نهاية الأسبوع أو خلال ساعات عملك، ضع هذه التوقعات بوضوح للآخرين حتى يعرفوا عدم إزعاجك.\n\n## اهتم بنفسك أولًا!\n\nإدارة مشروع مشهور تتطلب مهارات مختلفة عن مراحل النمو الأولى، لكنها ليست أقل مكافأة. كمحافظ على المشروع، ستكتسب خبرة في القيادة والمهارات الشخصية على مستوى نادر أن يحصل عليه معظم الناس. ورغم أن الأمر قد يكون صعبًا أحيانًا، فإن وضع حدود واضحة وأخذ فقط ما تستطيع تحمله سيساعدك على البقاء سعيدًا، متجدد النشاط، ومنتجًا.\n\n
\n" }, { "path": "_articles/ar/building-community.md", "content": "---\nlang: ar\ntitle: بناء مُجتمعات مُرحِّبة\ndescription: إنشاء مجتمع يدعم مشاركة الناس في مشروعك، ويحفّزهم على استخدامه والمساهمة فيه والترويج له\nclass: building\norder: 4\nimage: /assets/images/cards/building.png\nrelated:\n - best-practices\n - coc\n---\n\n
\n\n## تجهيز مشروعك للنجاح\n\nلقد أطلقت مشروعك، وبدأت في نشره، والناس بدأوا يتعرفون عليه. رائع! لكن، كيف تجعلهم يبقون ويستمرون في المشاركة؟\n\nوجود مجتمع مرحب يُعد استثمارًا في مستقبل مشروعك وسمعته. إذا كان مشروعك قد بدأ لِتوّه في استقبال أولى المساهمات، ابدأ بتوفير تجربة إيجابية للمساهمين الأوائل، واجعل من السهل عليهم العودة والمشاركة مرة أخرى.\n\n### اجعل الناس يشعرون بالترحيب\n\nإحدى الطرق لفهم مجتمع مشروعك هي ما يسميه @MikeMcQuaid بـ [قُمع المساهمين](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):\n\n![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)\n\nأثناء بناء مجتمعك، ضع في اعتبارك كيف يمكن لشخص في أعلى القُمع (مستخدم محتمل) أن يتقدم تدريجيًا ليصبح في أسفل القُمع (مشرف نشط). هدفك هو تقليل العقبات في كل مرحلة من تجربة المساهم. عندما يحقق الناس إنجازات سهلة، سيشعرون بالحافز للقيام بالمزيد.\n\nابدأ بالـ documentation الخاصة بمشروعك\n\n* **سهّل على أي شخص استخدام المشروع .** [ملف README سهل الاستخدام](../starting-a-project/#كتابة-ملف-README) وأمثلة كود واضحة تجعل من السهل على أي شخص يزور مشروعك أن يبدأ بسرعة.\n* **اشرح بوضوح كيفية المساهمة،** استخدم [ملف CONTRIBUTING الخاص بك](../starting-a-project/#كتابة-ارشادات-المساهمة-الخاصة-بك) وحافظ على تحديث الـ issues باستمرار.\n* **مهام أولية سهلة للمساهمين الجدد**: لمساعدة المساهمين الجدد على البدء، ضع تسميات واضحة على الـ issues التي يمكن للمبتدئين التعامل معها بسهولة ([وضع labels على الـ issues التي تكون بسيطة بما يكفي ليستطيع المبتدئون التعامل معها.](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels)). سيعرض GitHub هذه الـ issues في أماكن مختلفة على المنصة، مما يزيد المساهمات المفيدة ويقلل من friction عند التعامل مع مشاكل صعبة جدًا لمستوى المستخدم.\n\n[استطلاع GitHub 2017 عن الـ Open Source](http://opensourcesurvey.org/2017/) أظهر أن الوثائق غير المكتملة أو المربكة هي أكبر مشكلة تواجه مستخدمي الـ open source. توثيق جيد يدعو الناس للتفاعل مع مشروعك. في النهاية، سيقوم شخص ما بفتح issue أو pull request. استخدم هذه التفاعلات كفرص لتحريكهم إلى أسفل القمع (funnel).\n\n* **عندما يزور مشروعك شخص جديد، اشكره على اهتمامه!** تجربة سلبية واحدة فقط قد تجعل الشخص لا يريد العودة.\n* **كن سريع الاستجابة (responsive).** إذا لم ترد على issue لمدة شهر، فالأرجح أنهم قد نسوا مشروعك بالفعل.\n* **كن منفتحًا على أنواع المساهمات التي ستقبلها.** كثير من المساهمين يبدأون بتقرير عن bug أو تعديل صغير. هناك [طرق عديدة للمساهمة (contribute) في المشروع](../how-to-contribute/#ما-معنى-المساهمة) في المشروع. دع الناس يساعدون بالطريقة التي يريدونها.\n* **إذا كانت هناك مساهمة لا توافق عليها،** اشكر صاحبها على الفكرة و[اشرح السبب](../best-practices/#تعلم-قول-لا) لعدم ملاءمتها لمجال المشروع، واربطها بالوثائق ذات الصلة إذا كانت موجودة.\n\n\n\nالغالبية العظمى من المساهمين في الـ open source هم **\"المساهمون غير المنتظمين\"**: أشخاص يساهمون في المشروع بشكل متقطع فقط. قد لا يكون لدى المساهم العادي الوقت ليصبح على دراية كاملة بمشروعك، لذلك مهمتك هي جعل المساهمة سهلة بالنسبة لهم.\n\nتشجيع المساهمين الآخرين هو استثمار في نفسك أيضًا. عندما تمكّن أكبر المعجبين بمشروعك من متابعة العمل الذي يحمسون له، يقل الضغط عليك للقيام بكل شيء بنفسك.\n\n### وثّق كل شيء\n\n\n\nعندما تبدأ مشروعًا جديدًا، قد تشعر أن من الطبيعي الاحتفاظ بعملك خاصًا. لكن مشاريع الـ open source تزدهر عندما تقوم بتوثيق عمليتك بشكل علني.\n\nعندما تكتب الأمور، يمكن لعدد أكبر من الناس المشاركة في كل خطوة. قد تحصل على مساعدة في شيء لم تكن تعرف حتى أنك بحاجة إليه.\n\nالكتابة لا تعني مجرد التوثيق التقني . في أي وقت تشعر بالرغبة في كتابة شيء أو مناقشة مشروعك بشكل خاص، اسأل نفسك هل يمكنك جعله public؟\n\nكن شفافًا بشأن roadmap مشروعك، وأنواع المساهمات (contributions) التي تبحث عنها، وكيفية مراجعتها، ولماذا اتخذت قرارات معينة.\n\nإذا لاحظت أن عدة مستخدمين يواجهون نفس المشكلة، قم بتوثيق الإجابات في الـ README.\n\nبالنسبة للاجتماعات، فكر في نشر ملاحظاتك أو الاستنتاجات في issue مناسب. التغذية الراجعة التي ستحصل عليها من هذا المستوى من الشفافية قد تفاجئك.\n\nتوثيق كل شيء يشمل أيضًا عملك الحالي. إذا كنت تعمل على تحديث كبير لمشروعك، ضعه في pull request وعلم أنه مشروع قيد التنفيذ (WIP). بهذه الطريقة، يمكن للآخرين المشاركة في العملية منذ البداية.\n\n### كن سريع الاستجابة\n\nعندما تقوم بـ [الترويج لمشروعك](../finding-users)، سيكون لدى الناس ملاحظات لك. قد يكون لديهم أسئلة حول كيفية عمل الأشياء، أو يحتاجون للمساعدة في البدء.\n\nحاول أن تكون responsive عندما يقدم شخص ما issue، أو pull request، أو يسأل سؤالًا عن مشروعك. عندما ترد بسرعة، سيشعر الناس أنهم جزء من حوار، وسيكونون أكثر حماسًا للمشاركة.\n\nحتى إذا لم تتمكن من مراجعة الطلب فورًا، فإن الاعتراف المبكر به يزيد من التفاعل. هذا مثال على كيفية استجابة @tdreyno لطلب pull request على [Middleman](https://github.com/middleman/middleman/pull/1466):\n\n![طلب pull لمشروع Middleman](/assets/images/building-community/middleman_pr.png)\n\n[وجدت دراسة من Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) أن المساهمين الذين تلقوا code reviews خلال 48 ساعة لديهم معدل عودة ومساهمات متكررة أعلى بكثير.\n\nقد تتم المناقشات حول مشروعك أيضًا في أماكن أخرى على الإنترنت، مثل Stack Overflow، Twitter، أو Reddit. يمكنك إعداد notifications في بعض هذه الأماكن ليتم تنبيهك عندما يذكر أحد مشروعك.\n\n### امنح مجتمعك مكانًا للتجمع\n\nهناك سببين لإعطاء مجتمعك مكانًا للتجمّع.\n\nالسبب الأول هو لهم. ساعد الناس على التعرف على بعضهم البعض. الأشخاص الذين لديهم اهتمامات مشتركة سيرغبون حتمًا في مكان للتحدث عنها. وعندما تكون الاتصالات public ومتاحة، يمكن لأي شخص قراءة الأرشيفات السابقة ليصبح على دراية ويشارك.\n\nالسبب الثاني هو لك. إذا لم توفر للناس مكانًا عامًّا للتحدث عن مشروعك، فغالبًا ما سيتواصلون معك مباشرة. في البداية، قد يبدو من السهل الرد على الرسائل الخاصة \"هذه المرة فقط\". لكن مع الوقت، خاصة إذا أصبح مشروعك مشهورًا، ستشعر بالإرهاق. قاوم الرغبة في التواصل مع الناس حول مشروعك بشكل خاص، وبدلاً من ذلك وجههم إلى قناة عامة designated.\n\nيمكن أن تكون الاتصالات العامة بسيطة مثل توجيه الناس لفتح issue بدلاً من مراسلتك مباشرة أو التعليق على مدونتك. يمكنك أيضًا إنشاء mailing list، أو حساب Twitter، أو قناة Slack أو IRC ليتمكن الناس من التحدث عن مشروعك. أو جرب كل ما سبق!\n\n[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) يخصص office hours كل أسبوعين لمساعدة أعضاء المجتمع:\n\n> يخصص Kops وقتًا كل أسبوعين لتقديم المساعدة والإرشاد للمجتمع. وقد اتفق المسؤولون عن Kops على تخصيص هذا الوقت بشكل خاص للعمل مع المساهمين الجدد، ومساعدة في PRs، ومناقشة الميزات الجديدة.\n\nاستثناءات ملحوظة للاتصالات العامة هي: 1) مسائل الأمان (security issues) و 2) انتهاكات حساسة لمدونة السلوك (code of conduct). يجب أن يكون لديك دائمًا طريقة للإبلاغ عن هذه القضايا بشكل private. إذا لم ترغب في استخدام بريدك الشخصي، أنشئ عنوان بريد إلكتروني مخصص.\n\n## نمو مجتمعك\n\nالمجتمعات قوية جدًا. هذه القوة يمكن أن تكون نعمة أو نقمة، اعتمادًا على كيفية إدارتك لها. مع نمو مجتمع مشروعك، هناك طرق لمساعدته على أن يصبح قوة بناء وليس هدم.\n\n### لا تتسامح مع الأشخاص السلبيين {#لا-تتسامح-مع-الأشخاص-السلبيين}\n\nأي مشروع مشهور سيجذب بلا شك أشخاصًا يضرون بالمجتمع بدلًا من مساعدته. قد يبدؤون مناقشات غير ضرورية، أو يجادلون حول ميزات تافهة، أو يسيئون للآخرين.\n\nابذل قصارى جهدك لتطبيق سياسة zero-tolerance تجاه هذا النوع من الأشخاص. إذا تُركوا دون رقابة، سيجعل الأشخاص السلبيون الآخرين في مجتمعك غير مرتاحين، وقد يغادرون حتى. أعلى بكثير.\n\n\n\nالنقاشات المستمرة حول جوانب تافهة من مشروعك تشتت انتباه الآخرين، بما فيهم أنت، عن التركيز على المهام المهمة. الأشخاص الجدد الذين يصلون إلى مشروعك قد يرون هذه المحادثات ولا يرغبون في المشاركة.\n\nعندما تلاحظ سلوكًا سلبيًا يحدث في مشروعك، قم بالإشارة إليه بشكل علني. اشرح، بنبرة لطيفة ولكن حازمة، لماذا سلوكهم غير مقبول. إذا استمر المشكلة، قد تحتاج إلى [طلب مغادرتهم](../code-of-conduct/#تطبيق-مدونة-السلوك-الخاصة-بك). يمكن أن يكون [مدونة السلوك الخاصة بك](../code-of-conduct/) دليلًا بناءً لهذه المحادثات.\n\n### قابل المساهمين حيث هم\n\nالتوثيق الجيد يصبح أكثر أهمية مع نمو مجتمعك. المساهمون الغير منتظمين (Casual contributors) ، الذين قد لا يكونون على دراية بمشروعك، يقرأون توثيقك للحصول بسرعة على السياق الذي يحتاجونه.\n\nفي ملف CONTRIBUTING الخاص بك، وضح بشكل صريح للمساهمين الجدد كيفية البدء. قد ترغب حتى في تخصيص قسم خاص لهذا الغرض. على سبيل المثال، [Django](https://github.com/django/django) لديه صفحة استقبال خاصة لاستقبال المساهمين الجدد.\n\n![صفحة المساهمين الجدد في Django](/assets/images/building-community/django_new_contributors.png)\n\nفي قائمة الـ issues، قم بوضع labels للأخطاء التي تناسب أنواعًا مختلفة من المساهمين: على سبيل المثال، [_\"للمبتدئين فقط\"_](https://kentcdodds.com/blog/first-timers-only)، _\"good first issue\"_، أو _\"documentation\"_. هذه [labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) تجعل من السهل على المساهم الجديد مسح الـ issues بسرعة والبدء بالمساهمة.\n\nأخيرًا، استخدم توثيقك لجعل الناس يشعرون بالترحيب في كل خطوة.\n\nلن تتفاعل أبدًا مع معظم الأشخاص الذين يصلون إلى مشروعك. قد يكون هناك مساهمات لم تتلقاها لأن شخصًا ما شعر بالخوف أو لم يعرف من أين يبدأ. حتى بضع كلمات لطيفة يمكن أن تمنع شخصًا من ترك مشروعك بالإحباط.\n\nعلى سبيل المثال، إليك كيف يبدأ [Rubinius](https://github.com/rubinius/rubinius/) [دليل المساهمة الخاص به](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):\n\n> نود أن نبدأ بشكركم على استخدام Rubinius. هذا المشروع هو عمل حب، ونحن نقدر جميع المستخدمين الذين يكتشفون الأخطاء، ويعملون على تحسين الأداء، ويساعدون في التوثيق. كل مساهمة لها قيمة، لذلك شكرًا لمشاركتكم. ومع ذلك، إليكم بعض الإرشادات التي نطلب منكم اتباعها لكي نتمكن من معالجة مشكلتكم بنجاح.\n\n### شارك ملكية مشروعك {#شارك-ملكية-مشروعك}\n\n\n\nيشعر الناس بالحماس للمساهمة في المشاريع عندما يشعرون بملكية فيها. هذا لا يعني أنه يجب عليك التخلي عن رؤية مشروعك أو قبول مساهمات لا تريدها. لكن كلما منحت الآخرين المزيد من التقدير ، زاد احتمال بقائهم ومشاركتهم.\n\nحاول أن تجد طرقًا لمشاركة ملكية مشروعك (ownership) مع مجتمعك قدر الإمكان. إليك بعض الأفكار:\n\n* **قاوم إصلاح الأخطاء السهلة (غير الحرجة).** بدلًا من ذلك، استخدمها كفرص لتجنيد مساهمين جدد، أو لتوجيه شخص يرغب في المساهمة. قد يبدو هذا غير طبيعي في البداية، لكن استثمارك سيؤتي ثماره مع الوقت. على سبيل المثال، طلب @michaeljoseph من أحد المساهمين تقديم pull request على issue في [Cookiecutter](https://github.com/audreyr/cookiecutter) بدلًا من إصلاحه بنفسه.\n\n![Issue في Cookiecutter](/assets/images/building-community/cookiecutter_submit_pr.png)\n\n* **ابدأ بملف CONTRIBUTORS أو AUTHORS في مشروعك** يسرد جميع من ساهم في مشروعك، كما يفعل [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).\n\n* إذا كان لديك مجتمع كبير، **أرسل newsletter أو اكتب مدونة** لشكر المساهمين. أمثلة جيدة على ذلك: Rust's [This Week in Rust](https://this-week-in-rust.org/) و Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html).\n\n* **امنح كل مساهم صلاحية commit.** وجد @felixge أن هذا جعل الناس [أكثر حماسًا لتحسين التعديلات الخاصة بهم](https://felixge.de/2013/03/11/the-pull-request-hack.html)، وحتى وجد مساهمين جدد لمشاريع لم يعمل عليها منذ فترة.\n\n* إذا كان مشروعك على GitHub، **انقل مشروعك من حسابك الشخصي إلى [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** وأضف على الأقل مشرفًا احتياطيًا واحدًا. الـ Organizations تسهل العمل على المشاريع مع مساهمين خارجيين.\n\nالواقع هو أن [معظم المشاريع](https://peerj.com/preprints/1233/) لديها مشرف أو مشرفان يقومان بمعظم العمل. كلما كان مشروعك ومجتمعك أكبر، كان العثور على المساعدة أسهل.\n\nحتى لو لم تجد دائمًا من يلبّي الدعوة، فإن إرسال إشارة يزيد من فرص مشاركة الآخرين. وكلما بدأت مبكرًا، كلما تمكن الناس من المساعدة مبكرًا.\n\n\n\n## حل النزاعات\n\nفي المراحل الأولى من مشروعك، اتخاذ القرارات الكبرى يكون سهلًا. عندما تريد فعل شيء، ببساطة تقوم به.\n\nمع زيادة شعبية مشروعك، سيهتم المزيد من الأشخاص بالقرارات التي تتخذها. حتى لو لم يكن لديك مجتمع كبير من المساهمين، إذا كان لمشروعك العديد من المستخدمين، ستجد أشخاصًا يشاركون برأيهم أو يرفعون issues خاصة بهم.\n\nغالبًا، إذا كنت قد بنيت مجتمعًا ودودًا ومحترمًا ووثّقت عملياتك بشكل مفتوح، يجب أن يكون مجتمعك قادرًا على إيجاد حلول. لكن أحيانًا تواجه مسألة أصعب قليلاً للتعامل معها.\n\n### ضع معيارًا للود\n\nعندما يواجه مجتمعك قضية صعبة، قد ترتفع درجات التوتر. قد يشعر الناس بالغضب أو الإحباط ويصرفونه على بعضهم البعض أو عليك.\n\nدورك ك maintainer هو منع تصعيد هذه المواقف. حتى لو كان لديك رأي قوي في الموضوع، حاول أن تتخذ موقفًا كمُنسق أو ميسر، بدلًا من الدخول في النزاع ودفع آرائك. إذا كان شخص ما غير لطيف أو يحتكر المحادثة، [تصرف فورًا](../building-community/#لا-تتسامح-مع-الأشخاص-السلبيين) للحفاظ على المناقشات مدنية ومنتجة.\n\n\n\nالآخرون ينظرون إليك للحصول على التوجيه. ضع مثالًا جيدًا. يمكنك التعبير عن خيبة أملك، أو عدم رضاك، أو قلقك، لكن افعل ذلك بهدوء.\n\nالحفاظ على هدوئك ليس سهلاً، لكن إظهار القيادة يحسن صحة مجتمعك. الإنترنت يشكرك.\n\n### عامل README الخاص بك كدستور\n\nملف README الخاص بك هو [أكثر من مجرد مجموعة تعليمات](../starting-a-project/#كتابة-ملف-README). إنه أيضًا مكان للحديث عن أهدافك، ورؤية المنتج، وخارطة الطريق. إذا كان الناس يركزون كثيرًا على جدال حول جدوى ميزة معينة، قد يساعد إعادة النظر في README للحديث عن الرؤية الأكبر لمشروعك. التركيز على README يجعل النقاش أقل شخصية، وبالتالي يمكنك إجراء مناقشة بناءة.\n\n### ركز على الرحلة، لا على الوجهة\n\nبعض المشاريع تستخدم عملية تصويت لاتخاذ قرارات كبيرة. وعلى الرغم من أن ذلك يبدو منطقيًا للوهلة الأولى، فإن التصويت يركز على الوصول إلى \"إجابة\"، بدلًا من الاستماع ومعالجة مخاوف الآخرين.\n\nيمكن أن يصبح التصويت سياسيًا، حيث يشعر أعضاء المجتمع بالضغط لمساعدة بعضهم البعض أو التصويت بطريقة معينة. وليس الجميع يصوت، سواء كانت [الأغلبية الصامتة](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) في مجتمعك، أو المستخدمون الحاليون الذين لم يعلموا بأن هناك تصويتًا جاريًا.\n\nأحيانًا، يكون التصويت كسرًا للتعادل ضروريًا. ومع ذلك، حاول قدر الإمكان التركيز على [\"السعي للوصول إلى توافق\"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) بدلًا من الوصول إلى إجماع كامل.\n\nفي عملية consensus seeking، يناقش أعضاء المجتمع المخاوف الكبرى حتى يشعروا بأنهم قد تم الاستماع إليهم بشكل كافٍ. وعندما تبقى المخاوف طفيفة فقط، يمضي المجتمع قدمًا. \"عملية consensus seeking أوالسعي للوصول إلى توافق\" يعترف بأن المجتمع قد لا يتمكن من الوصول إلى إجابة مثالية، بل يعطي أولوية للاستماع والنقاش.\n\n\n\nحتى لو لم تعتمد فعليًا عملية consensus seeking، كمُشرف على المشروع ، من المهم أن يعلم الناس أنك تستمع إليهم. جعل الآخرين يشعرون بأنهم مسموعون والالتزام بحل مخاوفهم يساعد كثيرًا في تهدئة المواقف الحساسة. ثم تابع كلماتك بأفعال.\n\nلا تتسرع في اتخاذ قرار لمجرد الوصول إلى حل. تأكد من أن الجميع قد تم الاستماع إليهم وأن جميع المعلومات متاحة قبل المضي قدمًا نحو الحل.\n\n### حافظ على تركيز النقاش على العمل\n\nالنقاش مهم، لكن هناك فرق بين المحادثات المنتجة وغير المنتجة.\n\nشجع النقاش طالما أنه يتجه بنشاط نحو الحل. إذا كان واضحًا أن النقاش يتوقف أو يخرج عن الموضوع، أو أصبحت الملاحظات شخصية، أو يتجادل الناس حول تفاصيل صغيرة، فقد حان الوقت لإنهائه.\n\nاستمرار هذه المحادثات ليس ضارًا فقط بالمسألة المطروحة، بل بصحة مجتمعك أيضًا. فهي ترسل رسالة بأن هذا النوع من النقاشات مسموح أو حتى مشجع، وقد تثبط الناس عن طرح أو حل مسائل مستقبلية.\n\nمع كل نقطة تُطرح من قبلك أو من قبل الآخرين، اسأل نفسك: _\"كيف يقربنا هذا من الحل؟\"_\n\nإذا بدأ النقاش في التفكك، اسأل المجموعة: _\"ما الخطوات التالية التي يجب اتخاذها؟\"_ لإعادة تركيز النقاش.\n\nإذا كان واضحًا أن النقاش لا يؤدي إلى أي مكان، أو لا توجد خطوات واضحة للقيام بها، أو تم اتخاذ الإجراء المناسب بالفعل، أغلق الـ issue واشرح سبب إغلاقه.\n\n\n\n### اختر معاركك بحكمة\n\nالسياق مهم. فكر في من يشارك في النقاش وكيف يمثل بقية المجتمع.\n\nهل الجميع في المجتمع منزعج من هذه المسألة، أو حتى مشارك فيها؟ أم أنه مجرد شخص مشاغب وحيد؟ لا تنسَ النظر إلى أعضاء مجتمعك الصامتين، وليس فقط الأصوات النشطة.\n\nإذا كانت المسألة لا تمثل احتياجات المجتمع بشكل أوسع، قد تحتاج فقط إلى الاعتراف بمخاوف بعض الأشخاص. وإذا كانت هذه مشكلة متكررة دون حل واضح، وجههم إلى النقاشات السابقة حول الموضوع وأغلق الـ thread.\n\n### تحديد جهة لحسم القرارات في المجتمع\n\nمع موقف إيجابي وتواصل واضح، يمكن حل معظم المواقف الصعبة. ومع ذلك، حتى في نقاش منتج، قد يحدث اختلاف في الرأي حول كيفية المضي قدمًا. في هذه الحالات، حدد شخصًا أو مجموعة يمكنها أن تكون tiebreaker.\n\nيمكن أن يكون الـ tiebreaker هو maintainer الرئيسي للمشروع، أو مجموعة صغيرة تتخذ القرار بناءً على التصويت. من الأفضل أن تحدد الـ tiebreaker والعملية المرتبطة به في ملف GOVERNANCE قبل الحاجة لاستخدامه فعليًا.\n\nينبغي أن يكون الـ tiebreaker خيارًا أخيرًا. القضايا المثيرة للانقسام فرصة لنمو المجتمع وتعلمه. استغل هذه الفرص واستخدم عملية تعاونية للوصول إلى حل كلما أمكن.\n\n## المجتمع هو ❤️ البرمجيات المفتوحة المصدر\n\nالمجتمعات الصحية والمزدهرة هي مصدر الطاقة للآلاف من الساعات التي تُستثمر في open source كل أسبوع. كثير من المساهمين يشيرون إلى أشخاص آخرين كسبب للعمل - أو عدم العمل - على open source. من خلال تعلم كيفية الاستفادة من هذه القوة بشكل بناء، ستساعد شخصًا ما على تجربة open source لا تُنسى.\n\n
\n" }, { "path": "_articles/ar/code-of-conduct.md", "content": "---\nlang: ar\ntitle: مُدوّنة السلوك الخاصة بمشروعك\ndescription: عزِّز السلوك الإيجابي والبنّاء في مجتمعك من خلال اعتماد وتطبيق مدونة سلوك\nclass: coc\norder: 8\nimage: /assets/images/cards/coc.png\nrelated:\n - building\n - leadership\n---\n\n
\n\n## لماذا تحتاج إلى مُدوّنة سلوك (Code of Conduct)؟\n\nتُعدّ مدونة السلوك وثيقة تُحدّد التوقعات والمعايير السلوكية للمشاركين في مشروعك. إن اعتماد مدونة سلوك وتطبيقها يُسهم في خلق بيئة اجتماعية إيجابية داخل مجتمع المشروع.\n\nتساعد مدونات السلوك في حماية جميع المشاركين — وليس المشاركين فقط، بل أيضًا أنت كمشرف أو مطوّر للمشروع. فبمرور الوقت، قد تؤدي المواقف غير البنّاءة من بعض الأعضاء إلى شعورك بالإرهاق أو فقدان الحافز تجاه العمل.\n\nتمنحك مدونة السلوك القدرة على تعزيز سلوك مجتمعي صحي وبنّاء، كما أن اتخاذ مواقف استباقية يقلل من احتمال شعورك أنت أو غيرك بالإجهاد من المشروع، ويساعدك على اتخاذ الإجراء المناسب عندما يتصرف أحد الأعضاء بطريقة غير لائقة أو غير متوافقة مع قيم المشروع.\n\n## وضع مدونة سلوك\n\nمن الأفضل أن تقوم بوضع مدونة سلوك في أقرب وقت ممكن، ويفضل أن يكون ذلك عند إنشاء مشروعك لأول مرة.\n\nإلى جانب توضيح التوقعات الخاصة بك، تساعد مدونة السلوك على تحديد الأمور التالية:\n\n* نطاق تطبيق مدونة السلوك _( هل تنطبق فقط على القضايا والطلبات، أم تشمل الأنشطة المجتمعية مثل الفعاليات ؟)_\n* الأشخاص الذين ينطبق عليهم السلوك _( أعضاء المجتمع والمشرفون ، وماذا عن الرعاة ؟)_\n* الإجراءات المتخذة في حال خرق أحدهم مدونة السلوك\n* الطريقة التي يمكن من خلالها الإبلاغ عن الانتهاكات\n\nكلما أمكن، اعتمد على نماذج موجودة مسبقًا بدل أن تصنع كل شيء من الصفر. على سبيل المثال، [اتفاقية المساهمين](https://contributor-covenant.org/) هي مدونة سلوك جاهزة يمكن دمجها مباشرة في مشروعك، وقد تبناها آلاف المشاريع المفتوحة المصدر مثل Kubernetes وRails وSwift.\n\n[مدونة سلوك Django](https://www.djangoproject.com/conduct/) و [مدونة السلوك للمواطنين](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) كما تعتبر هاتان المدونتان مثالين جيدين على مدونات السلوك يمكن الاعتماد عليهما.\n\nضع ملف CODE_OF_CONDUCT في المجلد الرئيسي لمشروعك، واجعله مرئيًا لمجتمعك عن طريق ربطه من ملف CONTRIBUTING أو README\n\n## تحديد كيفية تطبيق مدونة السلوك الخاصة بك\n\n\n\nينبغي أن توضح كيف سيتم تطبيق مدونة السلوك الخاصة بك، بحيث يعرف الجميع الإجراءات المتخذة عند حدوث أي انتهاك وكيفية التعامل معه عند حدوث أي انتهاك. هناك عدة أسباب تجعل من المهم توضيح ذلك:\n\n* يُظهر هذا أنك تتعامل بجدية مع أي تجاوزات تحدث عند الحاجة،\n\n* كما يمنح أفراد مجتمعك شعورًا بالثقة بأن أي شكوى يتم أخذها بعين الاعتبار فعلًا.\n\n* ويُطمئن الجميع بأن عملية المراجعة تتم بشفافية وعدالة، في حال تم التحقيق مع أحدهم بسبب مخالفة محتملة.\n\nيجب أن توفّر وسيلة خاصة للأشخاص للإبلاغ عن أي انتهاك لمدونة السلوك، مثل بريد إلكتروني مخصص، وتوضح من يستقبل هذا الإبلاغ. يمكن أن يكون شخصًا مشرفًا، أو مجموعة من المشرفين، أو فريق خاص بإدارة مدونة السلوك.\n\nتذكر أن هناك احتمال أن يرغب شخص بالإبلاغ عن انتهاك يرتبط بشخص يستقبل هذه التقارير. في هذه الحالة، يجب أن توفّر لهم خيارًا للإبلاغ إلى شخص آخر. على سبيل المثال، يمكن تحديد مشرفين بديلين مثل @ctb و @mr-c. [اشرح ذلك في مشروعهم](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):\n\n> يمكن الإبلاغ عن أي سلوك مسيء أو تحرشي أو غير مقبول عبر إرسال بريد إلكتروني إلى: **khmer-project@idyll.org** والذي يذهب فقط إلى C. Titus Brown وMichael R. Crusoe. للإبلاغ عن أي مشكلة تتعلق بأحدهما، يرجى إرسال البريد الإلكتروني إلى: **Judi Brown Clarke, Ph.D.** إلى مدير التنوع في مركز BEACON لدراسة التطور في الفعل، وهو مركز تابع للصندوق الوطني للعلوم (NSF) للعلوم والتكنولوجيا.\n\nللحصول على مصدر إلهام، يمكنك الاطلاع على مدونة سلوك Django. [دليل تطبيق القواعد](https://www.djangoproject.com/conduct/enforcement-manual/) (قد لا يكون من الضروري أن يكون لديك دليل شامل بهذا الشكل، فهذا يعتمد على حجم مشروعك)\n\n## تطبيق مدونة السلوك الخاصة بك {#تطبيق-مدونة-السلوك-الخاصة-بك}\n\nفي بعض الأحيان، رغم كل جهودك، قد يقوم شخص ما بفعل يخالف مدونة السلوك. هناك عدة طرق للتعامل مع السلوك السلبي أو الضار عند حدوثه.\n\n### اجمع المعلومات المتعلقة بالموقف\n\nعامل كل عضو في المجتمع كما لو كانت صوته مهم بقدر صوتك. إذا وصلتك بلاغات عن شخص انتهك مدونة السلوك، خذ الأمر بجدية وحقق فيه، حتى لو لم تتوافق مع تجربتك الشخصية معه. هذا يُظهر لأعضاء المجتمع أنك تقدر وجهات نظرهم وتثق في حكمهم.\n\nقد يكون العضو المعني متكرّر الانتهاك ويجعل الآخرين يشعرون بعدم الارتياح بشكل مستمر، أو قد يكون تصرف مرة واحدة فقط. في كلتا الحالتين، يمكن أن يكون هناك سبب لاتخاذ إجراء، حسب السياق.\n\nقبل أن ترد، امنح نفسك وقتًا لفهم ما حدث. راجع تعليقات الشخص ومحادثاته السابقة لتفهم شخصيته وأسباب تصرفه بهذه الطريقة. حاول أيضًا جمع آراء غير رأيك الشخصي حول هذا الشخص وسلوكه.\n\n\n\n### اتخذ الإجراء المناسب\n\nبعد أن تجمع وتعالج معلومات كافية، ستحتاج لتقرير ما هو الإجراء المناسب. أثناء تفكيرك في خطواتك التالية، تذكّر أن هدفك كمسؤول أو مشرف هو خلق بيئة آمنة، محترمة، ومتعاونة. ركّز ليس فقط على كيفية التعامل مع الموقف نفسه، بل أيضًا على كيف سيؤثر ردك على سلوك المجتمع وتوقعاته في المستقبل.\n\nعندما يبلغ أحدهم عن انتهاك لمدونة السلوك، فإن مسؤوليتك أنت، لا هم، في التعامل مع الأمر. أحيانًا يكون المبلغ يشارك معلومات معرّضة مخاطر كبيرة على مسيرته المهنية، سمعته، أو سلامته الشخصية. إجباره على مواجهة من أساء له قد يضعه في موقف صعب. لذلك، يجب أن تتولى أنت التواصل المباشر مع الشخص المعني، إلا إذا طلب المبلغ خلاف ذلك صراحة.\n\nهناك عدة طرق يمكن من خلالها الرد على انتهاك مدونة السلوك:\n\n* **وجّه تحذيرًا علنيًا للشخص المعني** واشرح كيف أثّر سلوكهم سلبًا على الآخرين، ويفضّل أن يكون ذلك في القناة التي وقع فيها السلوك. التواصل العلني، حينما يكون ممكنًا، يُظهر لبقية المجتمع أنك تأخذ مدونة السلوك على محمل الجد. كن لطيفًا في حديثك، لكن حازمًا في موقفك.\n\n* **تواصل مع الشخص المعني بشكل خاص** لتوضيح كيف أثّر سلوكهم سلبًا على الآخرين. قد ترغب في استخدام وسيلة تواصل خاصة إذا كان الموقف يتضمن معلومات شخصية حساسة. إذا تواصلت مع الشخص على انفراد، فمن الجيد إشراك (CC) من أبلغوا عن الموقف أولًا، ليعرفوا أنك اتخذت إجراءً. استأذن المبلغ قبل إضافته في الـ CC.\n\nأحيانًا، لا يمكن التوصل إلى حل. قد يصبح الشخص المعني عدائيًا أو عدوانيًا عند مواجهته، أو قد لا يغيّر سلوكه. في هذه الحالة، قد تحتاج إلى التفكير في اتخاذ إجراءات أشد. على سبيل المثال:\n\n* **أوقف الشخص عن المشاركة مؤقتًا** من المشروع، ويتم تطبيق ذلك عبر حظر مؤقت يمنعهم من المشاركة في أي جزء من أنشطة المشروع.\n\n* **منع الشخص نهائيًا من المشاركة** في المشروع.\n\nحظر الأعضاء ليس أمرًا يُتخذ باستخفاف، فهو يمثل اختلافًا دائمًا ولا يمكن التوفيق بين وجهات النظر فيه. يجب اتخاذ مثل هذه الإجراءات فقط عندما يكون واضحًا أن الحل لا يمكن الوصول إليه.\n\n## مسؤولياتك كصاحب المشروع أو المشرف\n\nمدونة السلوك ليست قانونًا يُطبق بشكل تعسفي. أنت المسؤول عن تطبيق مدونة السلوك، ومن مسؤوليتك الالتزام بالقواعد التي تحددها المدونة.\n\nكصاحب المشروع أو المشرف، أنت من يضع الإرشادات لمجتمعك ويطبّقها وفق القواعد الواردة في مدونة السلوك. هذا يعني أن أي تقرير عن انتهاك يجب أخذه على محمل الجد. المبلغ عن الانتهاك يستحق مراجعة عادلة وشاملة لشكواه. إذا وجدت أن السلوك المبلغ عنه لا يشكل انتهاكًا، فاخبره بذلك بوضوح واشرح سبب عدم اتخاذ أي إجراء. وما يفعله بعد ذلك يعود له: سواء تقبل السلوك أو قرر التوقف عن المشاركة في المجتمع.\n\nحتى التقرير عن سلوك لا يُعتبر تقنيًا انتهاكًا، قد يشير إلى وجود مشكلة ضمن مجتمعك، ويجب عليك التحقيق في هذه المشكلة المحتملة واتخاذ الإجراء المناسب. قد يشمل ذلك تعديل مدونة السلوك لتوضيح السلوك المقبول، أو التحدث مع الشخص المعني وإخباره أنه لم ينتهك المدونة، لكنه يقترب من حدود ما هو متوقع ويجعل بعض المشاركين يشعرون بعدم الارتياح.\n\nفي النهاية، بصفتك المشرف أو صاحب المشروع، أنت من يحدد ويطبّق المعايير للسلوك المقبول. لديك القدرة على تشكيل قيم المجتمع الخاص بالمشروع، ويتوقع المشاركون منك تطبيق هذه القيم بطريقة عادلة ومتوازنة.\n\n## شجّع السلوك الذي ترغب في رؤيته في مجتمعك 🌎\n\nعندما يبدو المشروع عدائيًا أو غير مرحب، حتى لو كان هناك شخص واحد فقط يُسمح له بسلوك سيء، فإنك تخاطر بخسارة العديد من المساهمين الآخرين، قد يكون بعضهم لم تلتقِ بهم من قبل. قد لا يكون من السهل دائمًا تبني أو تطبيق مدونة السلوك، لكن خلق بيئة مرحبة سيساعد مجتمعك على النمو والتطور.\n\n
\n" }, { "path": "_articles/ar/finding-users.md", "content": "---\nlang: ar\ntitle: العثور على مستخدمين لمشروعك\ndescription: ساعد مشروعك مفتوح المصدر على النمو من خلال إتاحته للمستخدمين السعداء\nclass: finding\norder: 3\nimage: /assets/images/cards/finding.png\nrelated:\n - beginners\n - building\n---\n\n
\n\n## نشر الخبر\n\nلا توجد قاعدة تنص على أنه يجب عليك الترويج لمشروع مفتوح المصدر عند إطلاقه. هناك العديد من الأسباب المرضية للعمل في مجال البرمجيات مفتوحة المصدر والتي لا علاقة لها بالشهرة. بدلاً من الأمل في أن يجد الآخرون مشروعك مفتوح المصدر ويستخدموه، عليك أن تنشر أخبار عملك الجاد!\n\n## حدد رسالتك\n\nقبل أن تبدأ العمل الفعلي في الترويج لمشروعك، يجب أن تكون قادرًا على شرح ما يفعله المشروع وأهميته.\n\nما الذي يجعل مشروعك مختلفًا أو مثيرًا للاهتمام؟ لماذا قمت بإنشائه؟ إن الإجابة على هذه الأسئلة بنفسك سوف تساعدك على توصيل أهمية مشروعك.\n\nتذكر أن الأشخاص ينخرطون كمستخدمين، ويصبحون في النهاية مساهمين، لأن مشروعك يحل مشكلة لهم. عندما تفكر في رسالة مشروعك وقيمته، حاول أن تنظر إليهما من منظور ما قد يرغب فيه المستخدمون والمساهمون.\n\nعلى سبيل المثال، يستخدم @robb أمثلة التعليمات البرمجية لتوصيل سبب فائدة مشروعه, [Cartography](https://github.com/robb/Cartography), بوضوح:\n\n![Cartography README](/assets/images/finding-users/cartography.jpg)\n\nللتعمق أكثر في الرسائل، راجع تمرين Mozilla [\"الشخصيات والمسارات\"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) لتطوير شخصيات المستخدمين.\n\n## ساعد الأشخاص في العثور على مشروعك ومتابعته\n\n\n\nساعد الأشخاص في العثور على مشروعك وتذكره من خلال توجيههم إلى مساحة اسم واحدة.\n\n**امتلك حساب واضح للترويج لعملك.** يعد حساب Twitter أو عنوان GitHub URL أو قناة IRC طريقة سهلة لتوجيه الأشخاص إلى مشروعك. توفر هذه المنافذ أيضًا مكانًا لتجمع المجتمع المتنامي لمشروعك.\n\nإذا كنت لا ترغب في إنشاء منافذ لمشروعك حتى الآن، فقم بالترويج لحسابك الخاص على Twitter أو GitHub في كل ما تفعله. إن الترويج لحسابك على Twitter أو GitHub سيسمح للأشخاص بمعرفة كيفية الاتصال بك أو متابعة عملك. إذا كنت تتحدث في اجتماع أو حدث، فتأكد من تضمين معلومات الاتصال الخاصة بك في سيرتك الذاتية أو شرائحك.\n\n\n\n**فكر في إنشاء موقع إلكتروني لمشروعك.** يجعل موقع الويب مشروعك أكثر سهولة ويسرًا في التصفح، خاصةً عندما يقترن بوثائق وبرامج تعليمية واضحة. كما أن وجود موقع ويب يشير إلى أن مشروعك نشط، مما يجعل جمهورك يشعر براحة أكبر عند استخدامه. قدم أمثلة لتزويد الأشخاص بأفكار حول كيفية استخدام مشروعك.\n\n[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), قال أحد مؤسسي Django، إن إنشاء موقع ويب كان _\"أفضل شيء فعلناه مع Django في الأيام الأولى\"_.\n\nإذا كان مشروعك مستضافًا على GitHub، فيمكنك استخدام [GitHub Pages](https://pages.github.com/) لإنشاء موقع ويب بسهولة. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), و [Middleman](https://middlemanapp.com/) هي [بعض الأمثلة](https://github.com/showcases/github-pages-examples) على مواقع ويب ممتازة وشاملة.\n\n![الصفحة الرئيسية لـ Vagrant](/assets/images/finding-users/vagrant_homepage.png)\n\nالآن بعد أن أصبحت لديك رسالة لمشروعك، وطريقة سهلة ليتمكن الأشخاص من العثور على مشروعك، فلنخرج ونتحدث إلى جمهورك!\n\n## اذهب إلى حيث يتواجد جمهور مشروعك (عبر الإنترنت)\n\nالتواصل عبر الإنترنت هو وسيلة رائعة لمشاركة المعلومات ونشرها بسرعة. باستخدام القنوات الإلكترونية، يمكنك الوصول إلى جمهور واسع جدًا.\n\nاستفد من المجتمعات والمنصات الموجودة على الإنترنت للوصول إلى جمهورك. إذا كان مشروعك مفتوح المصدر مشروعًا برمجيًا، فمن المحتمل أن تجد جمهورك على [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), أو [Quora](https://www.quora.com/). ابحث عن القنوات التي تعتقد أن الأشخاص سيستفيدون منها أكثر أو سيكونون متحمسين لعملك.\n\n\n\nانظر إذا كان بإمكانك العثور على طرق لمشاركة مشروعك بالطرق :\n\n* **تعرف على المشاريع والمجتمعات مفتوحة المصدر ذات الصلة.** في بعض الأحيان، لا يتعين عليك الترويج لمشروعك بشكل مباشر. إذا كان مشروعك مثاليًا لعلماء البيانات الذين يستخدمونPython، فتعرف على مجتمع علوم بيانات Python. عندما يتعرف الناس عليك، ستنشأ فرص طبيعية للحديث عن عملك ومشاركته.\n* **ابحث عن الأشخاص الذين يعانون من المشكلة التي يحلها مشروعك.** ابحث في المنتديات ذات الصلة عن الأشخاص الذين يندرجون ضمن الجمهور المستهدف لمشروعك. أجب عن سؤالهم وابحث عن طريقة لبقة، عندما يكون ذلك مناسبًا، لاقتراح مشروعك كحل.\n* **اطلب التعليقات.** قدم نفسك وعملك لجمهور قد يجده مهماً ومثيراً للاهتمام. كن محدداً بشأن من تعتقد أنه سيستفيد من مشروعك. حاول إكمال الجملة التالية: \"أعتقد أن مشروعي سيساعد حقاً X، الذين يحاولون القيام بـ Y\". استمع إلى تعليقات الآخرين ورد عليها، بدلاً من مجرد الترويج لعملك.\n\nبشكل عام، ركز على مساعدة الآخرين قبل أن تطلب منهم شيئًا في المقابل. نظرًا لأن أي شخص يمكنه بسهولة الترويج لمشروع ما عبر الإنترنت، فسيكون هناك الكثير من الضوضاء. لكي تبرز من بين الحشود، قدم للأشخاص سياقًا عن هويتك وليس فقط عما تريده.\n\nإذا لم يهتم أحد أو يرد على اتصالك الأولي، فلا تشعر بالإحباط! معظم عمليات إطلاق المشاريع هي عملية تكرارية يمكن أن تستغرق شهورًا أو سنوات. إذا لم تحصل على رد في المرة الأولى، فجرب تكتيك مختلف، أو ابحث عن طرق لإضافة قيمة إلى عمل الآخرين أولاً. يستغرق الترويج لمشروعك وإطلاقه وقتًا وتفانيًا.\n\n## اذهب إلى حيث يتواجد جمهور مشروعك (خارج الإنترنت)\n\n![الخطابة](/assets/images/finding-users/public_speaking.jpg)\n\nتعد الفعاليات غير المتصلة بالإنترنت طريقة شائعة للترويج للمشاريع الجديدة للجمهور. فهي طريقة رائعة للوصول إلى جمهور متفاعل وبناء علاقات إنسانية أعمق، خاصة إذا كنت مهتمًا بالوصول إلى المطورين.\n\nإذا كنت [جديد في مجال الخطابة](https://speaking.io/), ابدأ بالبحث عن لقاء محلي يتعلق بلغة أو نظام مشروعك.\n\n\n\nإذا لم يسبق لك التحدث في أي مناسبة من قبل، فمن الطبيعي أن تشعر بالتوتر! تذكر أن جمهورك موجود هناك لأنه يرغب حقًا في الاستماع إلى ما ستقوله عن عملك.\n\nعند كتابة خطابك، ركز على ما سيجده جمهورك مثيرًا للاهتمام وذا قيمة. استخدم لغة ودية وميسّرة. ابتسم، تنفس، واستمتع.\n\n\n\nعندما تشعر أنك مستعد، فكر في التحدث في مؤتمر لترويج مشروعك. يمكن أن تساعدك المؤتمرات في الوصول إلى المزيد من الأشخاص، وأحيانًا من جميع أنحاء العالم.\n\nابحث عن المؤتمرات التي تخص لغتك أو نظامك البيئي. قبل أن ترسل محاضرتك، ابحث عن المؤتمر لتكييف محاضرتك مع الحضور وزيادة فرص قبولك للتحدث في المؤتمر. غالبًا ما يمكنك التعرف على جمهورك من خلال الاطلاع على المتحدثين في المؤتمر.\n\n\n\n## بناء سمعة\n\nبالإضافة إلى الاستراتيجيات الموضحة أعلاه، فإن أفضل طريقة لدعوة الأشخاص للمشاركة والمساهمة في مشروعك هي المشاركة والمساهمة في مشاريعهم.\n\nإن مساعدة المبتدئين ومشاركة الموارد وتقديم مساهمات مدروسة لمشاريع الآخرين سيساعدك على بناء سمعة إيجابية. كونك عضوًا نشطًا في مجتمع المصادر المفتوحة سيساعد الناس على فهم سياق عملك ويجعلهم أكثر اهتمامًا بمشروعك ومشاركته. يمكن أن يؤدي تطوير العلاقات مع مشاريع المصادر المفتوحة الأخرى إلى شراكات رسمية.\n\n\n\nليس من المبكر أو المتأخر أبدًا أن تبدأ في بناء سمعتك. حتى لو كنت قد أطلقت مشروعك الخاص بالفعل، فاستمر في البحث عن طرق لمساعدة الآخرين.\n\nلا توجد حلول سريعة لبناء جمهور. اكتساب ثقة واحترام الآخرين يستغرق وقتًا، وبناء سمعتك لا ينتهي أبدًا.\n\n## استمر في ذلك!\n\nقد يستغرق الأمر وقتًا طويلاً قبل أن يلاحظ الناس مشروعك مفتوح المصدر. لا بأس بذلك! فقد استغرقت بعض المشاريع الأكثر شهرة اليوم سنوات عديدة حتى وصلت إلى مستويات عالية من النشاط. ركز على بناء العلاقات بدلاً من الأمل في أن يكتسب مشروعك شعبية تلقائيًا. كن صبورًا، واستمر في مشاركة عملك مع أولئك الذين يقدرونه.\n\n
\n" }, { "path": "_articles/ar/getting-paid.md", "content": "---\nlang: ar\ntitle: الحصول على أجر مقابل العمل في المشاريع مفتوحة المصدر\ndescription: استمر على عملك في المصدر المفتوح من خلال الحصول على الدعم المالي مقابل وقتك أو مشروعك\nclass: getting-paid\norder: 7\nimage: /assets/images/cards/getting-paid.png\nrelated:\n - best-practices\n - leadership\n---\n\n
\n\n## لماذا يسعى بعض الأشخاص للحصول على الدعم المالي\n\nمعظم الأعمال مفتوحة المصدر هي أعمال تطوعية. على سبيل المثال، قد يصادف شخص ما خطأً في مشروع يستخدمه ويقدم حلاً سريعاً له، أو قد يستمتع بالتلاعب بمشروع مفتوح المصدر في أوقات فراغه.\n\n\n\nهناك العديد من الأسباب التي تجعل الشخص لا يرغب في الحصول على أجر مقابل عمله في مجال مفتوح المصدر.\n\n* **ربما يكون لديهم بالفعل وظيفة بدوام كامل يحبونها،** مما يتيح لهم المساهمة في المصادر المفتوحة في أوقات فراغهم.\n* **يستمتعون بالتفكير في المصادر المفتوحة كهواية** أو الهروب الإبداعي ولا يريدون أن يشعروا بالالتزام المالي للعمل على مشاريعهم.\n* **يحصلون على مزايا أخرى من المساهمة في المصادر المفتوحة،** مثل بناء سمعتهم أو ملف أعمالهم، أو تعلم مهارة جديدة، أو الشعور بالقرب من مجتمع ما.\n\n\n\nبالنسبة للآخرين، خاصةً عندما تكون المساهمات مستمرة أو تتطلب وقتًا طويلاً، فإن الحصول على أجر مقابل المساهمة في المصادر المفتوحة هو الطريقة الوحيدة التي يمكنهم من خلالها المشاركة، إما لأن المشروع يتطلب ذلك، أو لأسباب شخصية.\n\nيمكن أن يكون الحفاظ على المشاريع الشهيرة مسؤولية كبيرة، حيث يستغرق 10 أو 20 ساعة في الأسبوع بدلاً من بضع ساعات في الشهر.\n\n\n\nكما أن العمل المدفوع الأجر يمكّن الأشخاص من مختلف مناحي الحياة من تقديم مساهمات ذات مغزى. لا يستطيع بعض الأشخاص تخصيص وقت غير مدفوع الأجر لمشاريع مفتوحة المصدر، بسبب وضعهم المالي الحالي أو ديونهم أو التزاماتهم العائلية أو غيرها من الالتزامات. وهذا يعني أن العالم لا يرى أبدًا مساهمات الأشخاص الموهوبين الذين لا يستطيعون تخصيص وقتهم للتطوع. وهذا له آثار أخلاقية، كما @ashedryden [وصف](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), نظرًا لأن العمل المنجز يميل لصالح أولئك الذين يتمتعون بالفعل بمزايا في الحياة، والذين يكتسبون مزايا إضافية بناءً على مساهماتهم التطوعية، في حين أن الآخرين غير القادرين على التطوع لا يحصلون على فرص لاحقًا، مما يعزز النقص الحالي في التنوع في مجتمع المصادر المفتوحة.\n\n\n\nإذا كنت تبحث عن دعم مالي، فهناك طريقان يمكنك اتباعهما. يمكنك تمويل وقتك الخاص كمساهم، أو يمكنك البحث عن تمويل مؤسسي للمشروع.\n\n## تمويل وقتك الخاص\n\nاليوم، يتقاضى الكثير من الناس رواتب مقابل العمل بدوام جزئي أو كامل في مجال المصادر المفتوحة. الطريقة الأكثر شيوعًا للحصول على أجر مقابل وقتك هي التحدث إلى صاحب العمل.\n\nمن الأسهل الدفاع عن العمل مفتوح المصدر إذا كان صاحب العمل يستخدم المشروع بالفعل، ولكن كن مبدعًا في عرضك. ربما لا يستخدم صاحب العمل المشروع، ولكنه يستخدم Python، وتساعد صيانة مشروع Python شهير في جذب مطوري Python جدد. ربما يجعل ذلك صاحب العمل يبدو أكثر ملاءمة للمطورين بشكل عام.\n\nإذا لم يكن لديك مشروع مفتوح المصدر حاليًا ترغب في العمل عليه، ولكنك تفضل أن يكون إنتاجك الحالي مفتوح المصدر، فقدم حجة مقنعة لصاحب العمل لكي يفتح المصدر لبعض برامجه الداخلية.\n\nتقوم العديد من الشركات بتطوير برامج مفتوحة المصدر لبناء علامتها التجارية وتوظيف مواهب متميزة.\n\n@hueniverse, على سبيل المثال، وجد أن هناك أسبابًا مالية تبرر [استثمار Walmart في البرمجيات مفتوحة المصدر](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). و @jamesgpearce وجدت أن برنامج المصدر المفتوح ل Facebook [أحدث فرقًا](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) في التوظيف:\n\n> إنه يتوافق بشكل وثيق مع ثقافة القراصنة لدينا، وكيف كان يُنظر إلى مؤسستنا. سألنا موظفينا: ”هل كنتم على علم ببرنامج البرمجيات مفتوحة المصدر في Facebook؟“. أجاب ثلثاهم بـ”نعم“. وقال نصفهم إن البرنامج ساهم بشكل إيجابي في قرارهم العمل لدينا. هذه أرقام ليست هامشية، وآمل أن يستمر هذا الاتجاه.\n\nإذا سلكت شركتك هذا الطريق، فمن المهم الحفاظ على الحدود بين نشاط المجتمع ونشاط الشركة واضحة. في النهاية، يستمر المصدر المفتوح في البقاء من خلال مساهمات الناس من جميع أنحاء العالم، وهذا أكبر من أي شركة أو موقع.\n\n\n\nإذا لم تتمكن من إقناع صاحب العمل الحالي بإعطاء الأولوية للعمل في مجال المصادر المفتوحة، ففكر في البحث عن صاحب عمل جديد يشجع مساهمات الموظفين في مجال المصادر المفتوحة. ابحث عن الشركات التي تعلن صراحة عن التزامها بالعمل في مجال المصادر المفتوحة. على سبيل المثال:\n\n* بعض الشركات، مثل [Netflix](https://netflix.github.io/), لديهم مواقع ويب تسلط الضوء على مشاركتهم في المصادر المفتوحة\n\nالمشاريع التي نشأت في شركة كبيرة، مثل [Go](https://github.com/golang) أو [React](https://github.com/facebook/react), من المرجح أيضًا أن توظف أشخاصًا للعمل على المصادر المفتوحة.\n\nاعتمادًا على ظروفك الشخصية، يمكنك محاولة جمع الأموال بشكل مستقل لتمويل عملك في مجال المصادر المفتوحة. على سبيل المثال:\n\n* @Homebrew (و [العديد من المُشرفين والمنظمات الأخرى](https://github.com/sponsors/community)) تمويل عملهم من خلال [GitHub Sponsors](https://github.com/sponsors)\n* @gaearon مول عمله في [Redux](https://github.com/reactjs/redux) من خلال [حملة التمويل الجماعي على Patreon](https://redux.js.org/)\n* @andrewgodwin تمويل العمل على ترحيل مخطط Django [من خلال حملة Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)\n\nأخيرًا، في بعض الأحيان تضع مشاريع المصادر المفتوحة مكافآت على المشكلات التي قد تفكر في المساعدة في حلها.\n\n* @ConnorChristie تمكن من الحصول على أجر مقابل [مساعدة](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol العمل على مكتبة JavaScript الخاصة بهم [من خلال مكافأة على gitcoin](https://gitcoin.co/).\n* @mamiM قامت بترجمة @MetaMask إلى اللغة اليابانية بعد [تم تمويل هذه المشكلة على شبكة Bounties Network](https://explorer.bounties.network/bounty/134).\n\n## العثور على تمويل لمشروعك\n\nبالإضافة إلى الترتيبات الخاصة بالمساهمين الأفراد، تقوم المشاريع أحيانًا بجمع الأموال من الشركات والأفراد وغيرهم لتمويل الأعمال الجارية.\n\nقد يوجه التمويل التنظيمي إلى دفع رواتب المساهمين الحاليين، أو تغطية تكاليف تشغيل المشروع (مثل رسوم الاستضافة)، أو الاستثمار في ميزات أو أفكار جديدة.\n\nمع تزايد شهرة المصادر المفتوحة، لا يزال العثور على تمويل للمشاريع أمراً تجريبياً، ولكن هناك بعض الخيارات الشائعة المتاحة.\n\n### جمع الأموال لعملك من خلال حملات التمويل الجماعي أو الرعاية\n\nيكون البحث عن رعاة ناجحًا إذا كان لديك جمهور كبير أو سمعة طيبة بالفعل، أو إذا كان مشروعك يحظى بشهرة كبيرة.\nومن أمثلة المشاريع التي تم تمويلها ما يلي:\n\n* **[webpack](https://github.com/webpack)** يجمع الأموال من الشركات والأفراد [من خلال OpenCollective](https://opencollective.com/webpack)\n* **[Ruby Together](https://rubytogether.org/),** منظمة غير ربحية تدفع مقابل العمل على [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), وغيرها من مشاريع البنية التحتية ل Ruby\n\n### إنشاء مصدر للإيرادات\n\nاعتمادًا على مشروعك، قد تتمكن من تحصيل رسوم مقابل الدعم التجاري أو الخيارات المستضافة أو الميزات الإضافية. وتشمل بعض الأمثلة ما يلي:\n\n* **[Sidekiq](https://github.com/mperham/sidekiq)** يقدم إصدارات مدفوعة للحصول على دعم إضافي\n* **[Travis CI](https://github.com/travis-ci)** تقدم إصدارات مدفوعة من منتجها\n* **[Ghost](https://github.com/TryGhost/Ghost)** هي منظمة غير ربحية تقدم خدمة مُدارة مدفوعة الأجر\n\nبعض المشاريع الشهيرة، مثل [npm](https://github.com/npm/cli) و [Docker](https://github.com/docker/docker), جمعوا رأس مال استثماري لدعم نمو أعمالهم.\n\n### تقدم بطلب للحصول على منحة تمويلية\n\nتقدم بعض مؤسسات البرمجيات والشركات منحًا للأعمال المفتوحة المصدر. في بعض الأحيان، يمكن دفع المنح للأفراد دون إنشاء كيان قانوني للمشروع.\n\n* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** حصل على منحة من [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)\n* **[OpenMRS](https://github.com/openmrs)** تم تمويل العمل من قبل [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)\n* **[Libraries.io](https://github.com/librariesio)** حصل على منحة من [مؤسسة Sloan](https://sloan.org/programs/digital-technology)\n* **[مؤسسة برمجيات Python](https://www.python.org/psf/grants/)** تقدم منحًا للأعمال المتعلقة بلغة Python\n\nللحصول على خيارات أكثر تفصيلاً ودراسات حالة، @nayafia [كتبت دليلاً](https://github.com/nayafia/lemonade-stand) للحصول على أجر مقابل العمل في مجال المصادر المفتوحة. تتطلب أنواع التمويل المختلفة مهارات مختلفة، لذا فكر في نقاط قوتك لتحديد الخيار الأنسب لك.\n\n## بناء حجة للحصول على الدعم المالي\n\nسواء كان مشروعك فكرة جديدة أو قائمًا منذ سنوات، يجب أن تتوقع أن تبذل جهدًا كبيرًا في تحديد الممول المستهدف وتقديم حجة مقنعة.\n\nسواء كنت تريد أن تدفع مقابل وقتك الخاص أو تجمع التبرعات لمشروع ما، يجب أن تكون قادرًا على الإجابة عن الأسئلة التالية.\n\n### التأثير\n\nلماذا يعتبر هذا المشروع مفيدًا؟ لماذا يحبه المستخدمون الحاليون أو المحتملون إلى هذا الحد؟ أين سيكون بعد خمس سنوات؟\n\n### الجاذبية\n\nحاول جمع أدلة تثبت أهمية مشروعك، سواء كانت مقاييس أو حكايات أو شهادات. هل هناك أي شركات أو أشخاص بارزون يستخدمون مشروعك في الوقت الحالي؟ إذا لم يكن الأمر كذلك، فهل أيده شخص بارز؟\n\n### القيمة بالنسبة للجهة الممولة\n\nغالبًا ما تتاح للممولين، سواء كانوا أصحاب العمل أو مؤسسات مانحة، فرص عديدة. لماذا يجب أن يدعموا مشروعك دون غيره؟ ما الفائدة التي سيجنونها شخصيًا؟\n\n### استخدام الأموال\n\nما الذي ستحققه بالضبط من التمويل المقترح؟ ركز على معالم المشروع أو نتائجه بدلاً من دفع الرواتب.\n\n### كيف ستتلقى الأموال\n\nهل لدى الممول أي متطلبات بشأن الصرف؟ على سبيل المثال، قد تحتاج إلى أن تكون منظمة غير ربحية أو أن يكون لديك راعٍ مالي غير ربحي. أو ربما يجب أن تُمنح الأموال لمقاول فردي بدلاً من منظمة. تختلف هذه المتطلبات بين الممولين، لذا تأكد من إجراء بحثك مسبقًا.\n\n\n\n## جرب ولا تستسلم\n\nجمع الأموال ليس بالأمر السهل، سواء كنت تعمل في مشروع مفتوح المصدر أو منظمة غير ربحية أو شركة ناشئة في مجال البرمجيات، وفي معظم الحالات يتطلب منك أن تكون مبدعًا. إن تحديد الطريقة التي تريد أن تحصل بها على أموالك، وإجراء البحوث اللازمة، ووضع نفسك في مكان ممولك سيساعدك على بناء حجة مقنعة للحصول على التمويل.\n\n
\n" }, { "path": "_articles/ar/how-to-contribute.md", "content": "---\nlang: ar\ntitle: كيف تساهم في مشروع مفتوح المصدر ؟\ndescription: هل تريد أن تساهم في مشاريع مفتوحة المصدر؟ دليل للمبتدئين والمحترفين حول كيفية المساهمة فيها\nclass: contribute\norder: 1\nimage: /assets/images/cards/contribute.png\nrelated:\n - beginners\n - building\n---\n\n
\n\n## لماذا تساهم في مشروع مفتوح المصدر؟\n\n\n\nالمساهمة في مشاريع مفتوحة المصدر يمكن أن تكون تجربة مُجزية للتعلّم، والتعليم، واكتساب الخبرة في أيّ مهارة تقريبًا.\n\nلماذا يساهم الناس في مشاريع مفتوحة المصدر؟ هناك الكثير من الأسباب.\n\n### تحسين البرمجيات التي تعتمد عليها\n\nيبدأ العديد من المساهمين كمستخدمين للبرامج التي يشاركون فيها. عندما تكتشف خطأً في برنامج مفتوح المصدر تستخدمه، قد ترغب في الاطّلاع على المصدر لترى إذا كان بإمكانك إصلاحه بنفسك. إذا كان هذا هو الحال، فإن تقديم التصحيح للمشروع هو أفضل وسيلة لضمان استفادة أصدقائك (وأنت نفسك عند التحديث إلى الإصدار التالي) من هذا الإصلاح.\n\n### تطوير المهارات الحالية\n\nسواء كان الأمر يتعلق بالبرمجة، أو تصميم واجهة المستخدم، أو التصميم الجرافيكي، أو الكتابة، أو التنظيم — إذا كنت تبحث عن فرصة للتدريب، فهناك مهمة بانتظارك في أحد المشاريع مفتوحة المصدر.\n\n### التعرف على أشخاص مهتمين في أشياء متشابهة\n\nالمشاريع مفتوحة المصدر التي تمتلك مجتمعات لطيفة ومرّحبة تجذب الناس للاستمرار لسنوات. كثير من الأشخاص كوّنوا صداقات قويّة من خلال مشاركتهم في هذه المشاريع، سواء بلقائهم في المؤتمرات أو عبر محادثاتهم الليلية على الإنترنت.\n\n### إيجاد مرشدين وتعليم الآخرين\n\nالعمل مع الآخرين على مشروع مشترك، يعني أنك ستحتاج إلى شرح طريقة عملك، كما ستحتاج إلى طلب المساعدة من الآخرين. فإن عمليتَي التعلّم والتعليم يمكن أن تشكّلا نشاطًا مُرضيًا لجميع الأطراف.\n\n### بناء أعمال عامة تساعدك على بناء سمعتك ومسارك المهني\n\nكل مساهماتك في المشاريع مفتوحة المصدر تكون عامة ومتاحة للجميع، مما يمنحك أمثلة عملية مجانية يمكنك استخدامها في أي مكان كدليل ملموس على مهاراتك وقدراتك.\n\n### تعلُّم مهارات التعامل مع الآخرين\n\nتُقدّم المشاريع مفتوحة المصدر فرصاً ثمينة لممارسة مهارات القيادة والإدارة، مثل حل التعارضات، وتنظيم فرق العمل، وتحديد أولويات المهام.\n\n### الشعور بالقدرة على إجراء تغييرات، حتى لو صغيرة، يعطيك إحساس بالقوة\n\nلا حاجة لأن تصبح مساهمًا مدى الحياة حتى تستمتع بالمشاركة في عالم المشاريع مفتوحة المصدر. هل سبق أن رأيت خطأً مطبعيًّا على موقع إلكتروني، وتمنيت لو أن أحدًا ما سيصححه؟ في مشروع مفتوح المصدر يمكنك أنت القيام بذلك.\n\nتساعد المشاريع مفتوحة المصدر الناس على الشعور بأن لديهم قدرة على التأثير في حياتهم وكيفية تجربتهم للعالم، وهذا بحد ذاته مُجزٍ.\n\n## ما معنى المساهمة {#ما-معنى-المساهمة}\n\nإذا كنت مساهمًا جديدًا في المشاريع مفتوحة المصدر، فقد تكون العملية مخيفة بعض الشيء. كيف تجد المشروع المناسب؟ ماذا لو كنت لا تعرف البرمجة؟ ماذا لو حدث خطأ ما؟\n\nلا تقلق! هناك العديد من الطرق للمشاركة في مشروع مفتوح المصدر، وبعض النصائح البسيطة ستساعدك على تحقيق أقصى استفادة من تجربتك.\n\n### لا تحتاج إلى المساهمة بالبرمجة\n\nمن المفاهيم الخاطئة الشائعة حول المساهمة في المشاريع مفتوحة المصدر هو أنك بحاجة إلى المساهمة بالكود. في الواقع، غالبًا ما تكون الأجزاء الأخرى من المشروع هي [الأكثر إهمالًا أو تجاهلًا](https://github.com/blog/2195-the-shape-of-open-source). ستقدّم خدمة كبيرة للمشروع إذا عرضت المساعدة في هذا النوع من المساهمات!\n\n\n\nحتى لو كنت تحب كتابة الكود، فأنواع المساهمات الأخرى تُعد طريقة ممتازة للمشاركة في المشروع والتعرف على أعضاء المجتمع الآخرين. بناء هذه العلاقات سيفتح أمامك فرصًا للعمل على أجزاء أخرى من المشروع.\n\n### هل تحب تنظيم الأحداث (events)؟\n\n* نظّم ورش عمل، أو لقاءات حول المشروع , [@fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)\n* نظّم مؤتمر المشروع (إذا كان لديهم واحد)\n* ساعد أعضاء المجتمع في العثور على المؤتمرات المناسبة وتقديم مقترحات للحديث فيها\n\n### هل تحب التصميم؟\n\n* أعِد هيكلة التصاميم لتحسين قابلية استخدام المشروع\n* نفّذ أبحاث تجربة المستخدم (user research) لإعادة تصميم هيكل التنقّل(navigation structure) والقوائم، [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)\n* أنشئ Style Guide لمساعدة المشروع على الحفاظ على تصميم بصري متّسق\n* صمّم رسومات للt-shirts أو شعارًا جديدًا للمشروع، [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)\n\n### هل تحب الكتابة؟\n\n* اكتُب وطوّر توثيق المشروع, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)\n* نظّم مجلدًا يحتوي على أمثلة توضح كيفية استخدام المشروع\n* أطلِق نشرة إخبارية للمشروع، أو نظّم أبرز المحتويات من قائمة البريد الإلكتروني, [like @opensauced did for their product](https://news.opensauced.pizza/about/)\n* اكتب شروحات (Tutorials) للمشروع, [like PyPA's contributors did](https://packaging.python.org/)\n* اكتب ترجمة لتوثيق المشروع, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)\n\n\n\n### هل تحب التنظيم؟\n\n* اربط المشاكل المكررة واقترح تسميات جديدة للمشاكل (Issue Labels)، للحفاظ على تنظيم المشروع\n* راجع المشاكل المفتوحة (Open Issues)، واقترح إغلاق المشاكل القديمة, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)\n* اطرح أسئلة توضيحية على المشاكل التي فُتحت مؤخرًا لدفع النقاش قدمًا.\n\n### هل تحب البرمجة؟\n\n* ابحث عن مشكلة مفتوحة لتعمل عليها, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)\n* اسأل إذا كان بإمكانك المساعدة في كتابة ميزة جديدة\n* أتمتة إعداد المشروع(Project Setup)\n* تحسين الأدوات أو الاختبارات (Tooling and Testing)\n\n### هل تحب مساعدة الآخرين؟\n\n* أجب عن الأسئلة المتعلقة بالمشروع، على سبيل المثال: Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) أوReddit\n* أجب على أسئلة الأشخاص المتعلقة بالمشاكل المفتوحة\n* ساعد في إدارة ومراقبة قنوات التواصل والمجتمعات التقنية\n\n### هل تحب مساعدة الآخرين في البرمجة؟\n\n* اجع الكود في مساهمات الآخرين\n* اكتب شروحات حول كيفية استخدام المشروع\n* اعرض الإشراف أو التوجيه على مساهم آخر, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)\n\n### لست مضطرًا للعمل على مشاريع برمجية فقط!\n\nرغم أن مصطلح (Open Source) غالبًا ما يشير إلى البرمجيات، إلا أنه يمكنك المساهمة في أي شيء تقريبًا. هناك كتب، وصفات، قوائم، ودروس يتم تطويرها كمشاريع مفتوحة المصدر.\n\nعلى سبيل المثال:\n\n* @sindresorhus curates a [list of \"awesome\" lists](https://github.com/sindresorhus/awesome)\n* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates\n* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)\n\nحتى لو كنت مطور برمجيات، العمل على مشروع توثيق يمكن أن يساعدك على البدء في عالم المشاريع مفتوحة المصدر. غالبًا ما يكون العمل على المشاريع التي لا تتضمن كود أقل رعبًا، وعملية التعاون ستزيد من ثقتك وخبرتك.\n\n## التعرف على مشروع جديد\n\n\n\nبالنسبة لأي مساهمة تتعدى مجرد تصحيح خطأ مطبعي، فإن المساهمة في المشاريع مفتوحة المصدر تشبه الاقتراب من مجموعة غرباء في حفلة. إذا بدأت بالحديث عن حيوان اللاما بينما هم منغمسون في مناقشة حول أسماك الزينة، فغالبًا سينظرون إليك بنظرة محيرة بعض الشيء.\n\nقبل أن تندفع بتقديم اقتراحاتك بشكل عشوائي، ابدأ أولاً بتعلّم \"قراءة الجو العام\" للمناقشة. فعل ذلك يزيد من فرص أن تُلاحَظ أفكارك ويُصغَى لها.\n\n### مكونات المشروع مفتوح المصدر\n\nكل مجتمع مفتوح المصدر ينطلق من رؤيته الخاصة.\n\nقضاء سنوات في مشروع مفتوح المصدر واحد يعني أنك لم تتعرّف سوى على مشروع واحد فقط. لكن إن انتقلت إلى مشروع آخر، فقد تكتشف أن المصطلحات والعادات وأساليب التواصل مختلفة تمامًا.\n\nومع ذلك، فإن العديد من المشاريع مفتوحة المصدر تتبع هيكلًا تنظيميًا متشابهًا.\nفهم الأدوار المختلفة داخل المجتمع وطريقة العمل سيساعدك على التأقلم بسرعة مع أي مشروع جديد.\n\nعادةً ما يحتوي المشروع مفتوح المصدر على الأنواع التالية من الأدوار:\n\n* **المؤلف:** الشخص أو الأشخاص، أو الجهة التي أنشأت المشروع\n* **المالك:** الشخص أو الأشخاص، الذين يملكون صلاحيات الإدارة على المنظمة أو المستودع (وليسوا دائمًا نفس مؤلف المشروع الأصلي)\n* **المشرفون:** المساهمون المسؤولون عن توجيه رؤية المشروع وإدارة الجوانب التنظيمية له (وقد يكونون أيضًا من مؤلفي المشروع أو مالكيه)\n* **المساهمون:** كل من قدّم مساهمة ما للمشروع\n* **أعضاء المجتمع:** الأشخاص الذين يستخدمون المشروع، وقد يشاركون في النقاشات أو يعبّرون عن آرائهم حول مسار المشروع.\n\nقد تحتوي المشاريع الأكبر أيضًا على لجان فرعية أو مجموعات عمل تركز على مهام مختلفة، مثل أدوات التطوير، وفرز المشكلات، وإدارة المجتمع، وتنظيم الفعاليات. ابحث في موقع المشروع عن صفحة الفريق (Team)\nأو في المستودع عن وثائق إدارة المشروع(governance documentation) لمعرفة هذه المعلومات.\n\nيحتوي المشروع أيضًا على وثائق.\nتكون هذه الملفات عادةً موجودة في المستوى الأعلى من المستودع (أي في المجلد الرئيسي).\n\n* **LICENSE:** الترخيص؛ كل مشروع مفتوح المصدر يجب أن يكون له [ترخيص مفتوح المصدر](https://choosealicense.com).إذا لم يكن للمشروع ترخيص، فهو ليس مفتوح المصدر.\n* **README:** ملف الترحيب؛ هو دليل التعليمات الذي يرحب بأعضاء المجتمع الجدد ويشرح لماذا المشروع مفيد وكيفية البدء به.\n* **CONTRIBUTING:** دليل المساهمة؛ بينما تساعد ملفات الREADME الناس على استخدام المشروع، فإن ملفات الCONTRIBUTING تساعد الناس على المساهمة في المشروع. يشرح أنواع المساهمات المطلوبة وكيفية سير العملية. وجود هذا الملف يشير إلى أن المشروع مُرحّب بالمساهمين الجدد. مثال جيد لدليل المساهمة الفعّال الموجود في [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).\n* **CODE_OF_CONDUCT:** قواعد السلوك؛ تحدد قواعد السلوك الأساسية لسلوك المشاركين وتساعد على خلق بيئة ودية. على الرغم من أن ليس كل مشروع يحتوي على هذا الملف، إلا أن وجوده يشير إلى أن المشروع مُرحّب بالمساهمين الجدد.\n* **Other documentation:** قد تكون هناك وثائق إضافية، مثل الدروس التعليمية، الشروحات خطوة بخطوة، أو سياسات إدارة المشروع، خصوصًا في المشاريع الكبيرة مثل: [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).\n\nأخيرًا، تستخدم المشاريع مفتوحة المصدر الأدوات التالية لتنظيم النقاشات.\nقراءة الأرشيفات ستمنحك فكرة جيدة عن كيفية تفكير المجتمع وطريقة عمله.\n\n* **Issue tracker:** المكان الذي يناقش فيه الناس المشاكل المتعلقة بالمشروع.\n* **Pull/Merge requests:** المكان الذي يناقش فيه الناس التغييرات الجاري العمل عليها ويستعرضونها، سواء كان ذلك لتحسين سطر كود لمساهم، أو استخدام القواعد اللغوية، أو الصور، وغيرها. بعض المشاريع، مثل [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml)، تستخدم بعض GitHub Action لتسريع وأتمتة مراجعات الكود.\n* **Discussion forums or mailing lists:** قد تستخدم بعض المشاريع هذه القنوات للمواضيع الحوارية (على سبيل المثال، _\"كيف أفعل...\"_ أو _\"ما رأيك في...\"_ بدلاً من تقارير الأخطاء أو طلبات المزايا). بينما يستخدم البعض الآخر الـ Issue tracker لجميع المحادثات. مثال جيد على ذلك هو [CHAOSS' weekly Newsletter](https://chaoss.community/news/).\n* **Synchronous chat channel:** تستخدم بعض المشاريع قنوات الدردشة (مثل Slack أو IRC) للمحادثات غير الرسمية، والتعاون، والتبادل السريع للأفكار. مثال جيد على ذلك هو [EddieHub's Discord community](http://discord.eddiehub.org/).\n\n## إيجاد مشروع للمساهمة فيه\n\nالآن بعد أن فهمت كيف تعمل المشاريع مفتوحة المصدر، حان الوقت للعثور على مشروع للمساهمة فيه!\n\nإذا لم تكن قد ساهمت في المشاريع مفتوحة المصدر من قبل، خذ بعض النصائح من الرئيس الأمريكي جون إف. كينيدي، الذي قال مرة: _\"لا تسأل ماذا يمكن لبلدك أن يفعل لك، بل اسأل ماذا يمكنك أن تفعل لبلدك.\"_\n\n\n\nتحدث المساهمة في المصادر المفتوحة على جميع المستويات وفي مختلف المشاريع. لا تحتاج إلى التفكير كثيرًا فيما ستكون عليه مساهمتك الأولى بالضبط، أو كيف ستبدو.\n\nبدلاً من ذلك، ابدأ بالتفكير في المشاريع التي تستخدمها بالفعل، أو ترغب في استخدامها. المشاريع التي ستساهم فيها بنشاط هي تلك التي تجد نفسك تعود إليها باستمرار.\n\nضمن تلك المشاريع، كلما شعرت أن شيئًا ما يمكن أن يكون أفضل أو مختلفًا، تصرف بناءً على حدسك.\n\nالمشاريع مفتوحة المصدر ليست ناديًا حصريًا؛ فهي مصنوعة من أشخاص مثلك تمامًا. مصطلح \"المشاريع مفتوحة المصدر\" هو مجرد تعبير أنيق للتعامل مع مشاكل العالم على أنها قابلة للحل.\n\nقد تتصفح ملف README وتجد رابطًا معطلًا أو خطأً مطبعيًا. أو ربما تكون مستخدمًا جديدًا ولاحظت شيئًا لا يعمل، أو مشكلة تعتقد أنها يجب أن تكون موثقة. بدلًا من تجاهلها والمضي قدمًا، أو طلب مساعدة شخص آخر لإصلاحها، تحقق مما إذا كان بإمكانك المساهمة بالمساعدة. هذا هو جوهر مشاريع البرمجيات مفتوحة المصدر!\n\n> وفقًا لدراسة أجراها Igor Steinmacher وباحثون آخرون في علوم الحاسوب، فإن [28٪ من المساهمات الصغيرة](https://www.igor.pro.br/publica/papers/saner2016.pdf) في مشاريع البرمجيات مفتوحة المصدر تتعلق بالتوثيق، مثل تصحيح الأخطاء المطبعية، إعادة التنسيق، أو كتابة ترجمة.\n\nإذا كنت تبحث عن المشاكل الموجودة التي يمكنك إصلاحها، فإن كل مشروع من مشاريع البرمجيات مفتوحة المصدر يحتوي على صفحة `/contribute` التي تبرز الـ beginner-friendly issues التي يمكنك البدء بها. انتقل إلى الصفحة الرئيسية للمستودع على GitHub، وأضف `/contribute` في نهاية الـ URL (على سبيل المثال [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).\n\nيمكنك أيضًا استخدام أحد المصادر التالية لمساعدتك في اكتشاف مشاريع جديدة والمساهمة فيها:\n\n* [GitHub Explore](https://github.com/explore/)\n* [جمعة المصادر المفتوحة](https://opensourcefriday.com)\n* [First Timers Only](https://www.firsttimersonly.com/)\n* [CodeTriage](https://www.codetriage.com/)\n* [24 Pull Requests](https://24pullrequests.com/)\n* [Up For Grabs](https://up-for-grabs.net/)\n* [First Contributions](https://firstcontributions.github.io)\n* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)\n* [OpenSauced](https://opensauced.pizza/)\n* [GitLab Explore](https://gitlab.com/explore/projects/starred)\n\n### قائمة تحقّق قبل أن تساهم {#قائمة-تحقّق-قبل-أن-تساهم}\n\nعندما تجد مشروعًا ترغب في المساهمة فيه، قم بمراجعة سريعة للتأكد من أن المشروع مناسب لقبول المساهمات. وإلا، فقد لا يحصل عملك الجاد على أي رد.\n\nإليك قائمة مرجعية مفيدة لتقييم ما إذا كان المشروع مناسبًا للمساهمين الجدد.\n\n**يتوافق مع تعريف المشاريع مفتوحة المصدر**\n\n
\n \n \n
\n\n**المشروع يقبل المساهمات بشكل فعّال**\n\nاطلع على نشاط الـ commit على الفرع الرئيسي. على GitHub، يمكنك رؤية هذه المعلومات في تبويب Insights على الصفحة الرئيسية للمستودع، مثل [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\nبعد ذلك، اطلع على الـ issues الخاصة بالمشروع.\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\nالآن افعل الشيء نفسه بالنسبة للـ pull requests الخاصة بالمشروع.\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n**المشروع مرحّب بالمساهمين**\n\nالمشروع الذي يكون ودودًا ومرحّبًا يشير إلى أنه سيكون متقبلًا للمساهمين الجدد.\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n\n\n## كيف ترسل المساهمة؟\n\nلقد وجدت مشروعًا يعجبك، وأنت جاهز لتقديم مساهمة. أخيرًا! إليك كيفية تقديم مساهمتك بالطريقة الصحيحة.\n\n### التواصل بفعالية\n\nسواء كنت مساهمًا لمرة واحدة أو تحاول الانضمام إلى مجتمع، فإن العمل مع الآخرين هو من أهم المهارات التي ستطورها في المشاريع مفتوحة المصدر.\n\n\n\nقبل أن تفتح (issue) أو (pull request)، أو تطرح سؤالًا في المحادثة، ضع هذه النقاط في اعتبارك لمساعدتك على توصيل أفكارك بفعالية.\n\n**ساعد الآخرين على فهم الموقف**؛ إذا واجهت خطأً فاشرح ما الذي تحاول فعله وكيف يمكن إعادة إنتاج المشكلة، أما إذا كنت تقترح فكرة جديدة فاشرح لماذا تعتقد أنها ستكون مفيدة للمشروع (وليس لك فقط!).\n\n> 😇 _\"لا يحدث X عندما أقوم بـ Y\"_\n>\n> 😢 _\"X لا يعمل! من فضلك أصلحه.\"_\n\n**قُم بواجبك مُسبقًا.** لا بأس ألا تعرف كل شيء، لكن أظهر أنك حاولت. قبل أن تطلب المساعدة، تأكد من مراجعة (README)، و(issues) \"المشاكل المفتوحة أو المغلقة\"، والقائمة البريدية، وابحث في الإنترنت عن إجابة. سيقدّر الناس ذلك عندما تُظهر أنك تحاول التعلم.\n\n> 😇 _\"لست متأكدًا من كيفية تنفيذ X. راجعت مستندات المساعدة ولم أجد أي ذكر لها.\"_\n>\n> 😢 _\"كيف أفعل X؟\"_\n\n**اجعل طلباتك قصيرة ومباشرة.** تمامًا مثل إرسال بريد إلكتروني، كل مساهمة، مهما كانت بسيطة أو مفيدة، تحتاج إلى مراجعة من شخص آخر. العديد من المشاريع لديها طلبات أكثر من عدد الأشخاص المتاحين للمساعدة. كن موجزًا، فهذا سيزيد من فرص أن يتمكن شخص ما من مساعدتك.\n\n> 😇 _\"أود أن أكتب درسًا تعليميًا حول **كيفية إنشاء API**.\"_\n>\n> 😢 _\"كنت أقود على الطريق السريع في اليوم الآخر وتوقفت لتعبئة الوقود، ثم خطرت لي فكرة رائعة حول شيء يجب أن نفعله. لكن قبل أن أشرح ذلك، دعني أريك...\"_\n\n**اجعل كل تواصلك علنيًا.** مع أن الرغبة قد تدفعك، لا تتوجه إلى القائمين على المشروع بشكل خاص إلا إذا كنت بحاجة لمشاركة معلومات حساسة (مثل مشكلة أمنية أو انتهاك خطير للسلوك). عندما تبقي النقاش علنيًا، يمكن للمزيد من الأشخاص التعلم والاستفادة من تبادلك. النقاشات بحد ذاتها يمكن أن تكون مساهمات.\n\n> 😇 _(as a comment) \"@-maintainer أهلاً! كيف يجب أن نتابع في هذا PR؟\"_\n>\n> 😢 _(as an email) \"أهلاً، آسف للإزعاج عبر البريد الإلكتروني، لكني كنت أتساءل إذا كانت لديك فرصة لمراجعة الـ PR الخاص بي\"_\n\n**لا بأس في طرح الأسئلة (ولكن كن صبورًا!).** كان الجميع جديدين على المشروع في وقت ما، وحتى المساهمين ذوي الخبرة يحتاجون إلى الوقت لاستيعاب المشروع الجديد. وبالمثل، حتى القائمون على المشروع منذ فترة طويلة ليسوا دائمًا على دراية بكل جزء منه. اظهر لهم نفس الصبر الذي تريدهم أن يظهروه لك.\n\n> 😇 _\"شكراً للنظر في هذا الخطأ. لقد اتبعت اقتراحاتك. إليك الناتج:\"_\n>\n> 😢 _\"لماذا لا يمكنك إصلاح مشكلتي؟ أليس هذا مشروعك؟\"_\n\n**احترم قرارات المجتمع.** قد تختلف أفكارك عن أولويات المجتمع أو رؤيته. قد يقدمون ملاحظات أو يقررون عدم متابعة فكرتك. بينما يجب عليك النقاش ومحاولة الوصول إلى حل وسط، يجب على القائمين بالصيانة (maintainers) التعايش مع قرارك لفترة أطول منك. إذا لم تتفق مع اتجاههم، يمكنك دائمًا العمل على نسخة Fork خاصة بك أو بدء مشروعك الخاص.\n\n> 😇 _\"أنا مستاء لأنكم لا تستطيعون دعم فكرتي، لكن كما أوضحتم، فهي تؤثر فقط على جزء صغير من المستخدمين، لذلك أفهم السبب. شكرًا لاستماعكم.\"_\n>\n> 😢 _\"لماذا لن تدعموا فكرتي؟ هذا أمر غير مقبول!\"_\n\n**قبل كل شيء، حافظ على الاحترام.** يتكون مجتمع المشاريع مفتوحة المصدر من متعاونين من جميع أنحاء العالم. يُفقد السياق عبر اللغات والثقافات والجغرافيا والمناطق الزمنية. بالإضافة إلى ذلك، يجعل التواصل الكتابي من الصعب نقل النبرة أو المزاج. افترض النوايا الحسنة في هذه المحادثات. لا بأس في الاعتراض بأدب على فكرة، أو طلب المزيد من السياق، أو توضيح موقفك. فقط حاول أن تترك الإنترنت مكانًا أفضل مما وجدته عليه.\n\n### جمع المعلومات\n\nقبل القيام بأي شيء، قم بإجراء فحص سريع للتأكد من أن فكرتك لم تُناقش في مكان آخر. تصفح README المشروع، و**issues** (المفتوحة والمغلقة)، وقوائم البريد، وStack Overflow. لا تحتاج لقضاء ساعات في مراجعة كل شيء، لكن البحث السريع عن بعض الكلمات المفتاحية يكون ذا فائدة كبيرة.\n\nإذا لم تتمكن من إيجاد فكرتك في مكان آخر، فأنت جاهز لاتخاذ خطوة. إذا كان المشروع على GitHub، فمن المرجح أن تتواصل عن طريق القيام بما يلي:\n\n* **Raising an Issue:** هذه مثل بدء محادثة أو نقاش\n* **Pull requests:** مخصصة لبدء العمل على حل\n* **Communication Channels:** إذا كان للمشروع قناة مخصصة على Discord، IRC، أو Slack، فكر في بدء محادثة أو طلب توضيح حول مساهمتك.\n\nقبل أن تفتح issue أو pull request، تحقق من مستندات المساهمة في المشروع (عادةً ملف يسمى CONTRIBUTING، أو في README)، لتعرف ما إذا كنت بحاجة لتضمين أي شيء محدد. على سبيل المثال، قد يطلبون منك اتباع قالب معين، أو يشترطون أن تستخدم الاختبارات.\n\nإذا كنت تريد تقديم مساهمة كبيرة، افتح issue للسؤال قبل البدء بالعمل عليها. من المفيد متابعة المشروع لفترة (على GitHub، [يمكنك الضغط على \"Watch\"](https://help.github.com/articles/watching-repositories/) لتصلك إشعارات بكل النقاشات)، والتعرف على أعضاء المجتمع، قبل القيام بعمل قد لا يتم قبوله.\n\n\n\n### الإبلاغ عن مشكلة (issue)\n\nعادةً ما يجب عليك فتح **issue** (مشكلة والإبلاغ عنها) في الحالات التالية:\n\n* الإبلاغ عن خطأ لا تستطيع حله بنفسك\n* مناقشة موضوع أو فكرة على مستوى عالٍ (على سبيل المثال: المجتمع، الرؤية، أو السياسات)\n* اقتراح ميزة جديدة أو فكرة مشروع أخرى\n\nنصائح للتواصل حول **issues**:\n\n* **إذا رأيت issue مفتوحة تريد التعامل معها،** قم بالتعليق على الـ issue لإعلام الآخرين بأنك تعمل عليها. بهذه الطريقة، تقل احتمالية تكرار عملك من قبل الآخرين.\n* **إذا كانت issue مفتوحة منذ فترة،** فمن الممكن أن يتم التعامل معها في مكان آخر أو أنها حُلّت بالفعل، لذا قم بالتعليق لطلب التأكيد قبل البدء بالعمل.\n* **إذا فتحت issue بنفسك، ثم اكتشفت الحل لاحقًا بنفسك،** قم بالتعليق على الـ issue لإعلام الآخرين، ثم أغلق الـ issue. حتى توثيق هذه النتيجة يُعد مساهمة في المشروع.\n\n### فتح طلب دمج (pull request)\n\nعادةً ما يُفضّل فتح (pull request) في الحالات التالية:\n\n* إرسال إصلاحات بسيطة مثل الأخطاء الإملائية، أو الروابط المعطلة، أو الأخطاء الواضحة.\n* البدء بالعمل على مساهمة تم طلبها مسبقًا، أو تم مناقشتها بالفعل في إحدى المشاكل (issues).\n\nليش شرطًا أن يُمثّل طلب (Pull Request) عملًا منتهيًا بالكامل. في العادة من الأفضل فتح (Pull Request) في وقتٍ مبكر، حتى يتمكن الآخرون من متابعة تقدمك أو تقديم ملاحظاتهم حوله. يمكنك فتحه كـ **\"مسودة (Draft)\"** أو وضع علامة **\"WIP\" (عمل قيد التنفيذ)** في عنوان الطلب أو في قسم **\"Notes to Reviewers\"** إن وُجد (أو يمكنك إنشاء قسمك الخاص مثل: **## Notes to Reviewer**).ويمكنك دائمًا إضافة المزيد من التعديلات (commits) لاحقًا.\n\nإذا كان المشروع موجودًا على GitHub، فإليك كيفية تقديم (Pull Request):\n\n* **[قم بعمل Fork للمستودع](https://guides.github.com/activities/forking/)** ونسخه إلى جهازك محليًا (clone). اربط نسختك المحلية بالمستودع الأصلي \"upstream\" عن طريق إضافته كـ remote. قم بسحب التحديثات من \"upstream\" بشكل دوري لتبقى محدثًا، حتى تقل احتمالية حدوث تعارضات (merge conflicts) عند تقديم طلب السحب (pull request). (راجع التعليمات التفصيلية [هنا](https://help.github.com/articles/syncing-a-fork/).)\n* **[قم بإنشاء فرع (branch)](https://guides.github.com/introduction/flow/)** لإجراء تعديلاتك.\n* **قم بالإشارة إلى أي Issues** ذات صلة أو مستندات داعمة في طلب (PR) الخاص بك (على سبيل المثال: \"Closes #37.\").\n* **أضف لقطات شاشة قبل وبعد** إذا كانت تغييراتك تتضمن فروقات في HTML/CSS. اسحب الصور وأفلتها داخل محتوى طلب (pull request) الخاص بك.\n* **اختبر تغييراتك!** شغّل تغييراتك مقابل أي اختبارات موجودة مسبقًا إذا كانت موجودة، وأنشئ اختبارات جديدة عند الحاجة. من المهم التأكد أن تغييراتك لا تؤدي إلى كسر المشروع الحالي.\n* **ساهم بأسلوب المشروع** قدر استطاعتك. قد يعني هذا استخدام المسافات البادئة (indents)، الفواصل المنقوطة (semi-colons) أو التعليقات (comments) بشكل مختلف عما اعتدت عليه في مستودعك الخاص، لكن هذا يسهل على المسؤول عن المشروع الدمج، وعلى الآخرين فهم الكود وصيانته في المستقبل.\n\nإذا كان هذا أول pull request لك، اطلع على [Make a Pull Request](http://makeapullrequest.com/)، الذي أنشأه @kentcdodds كدليل فيديو تعليمي. يمكنك أيضًا التدريب على عمل **pull request** في مستودع [First Contributions](https://github.com/Roshanjossey/first-contributions) الذي أنشأه @Roshanjossey.\n\n## ماذا يحدث بعد تقديم مساهمتك؟\n\nقبل أن نبدأ بالاحتفال، سيحدث أحد الأمور التالية بعد تقديم مساهمتك:\n\n### 😭 لم تتلقَّ أيَّ ردّ\n\nنأمل أن تكون قد [تحققت من نشاط المشروع](#قائمة-تحقّق-قبل-أن-تساهم) قبل تقديم مساهمتك. ومع ذلك، حتى في المشاريع النشطة، من الممكن ألا تتلقى مساهمتك أي رد.\n\nإذا لم تتلقَ ردًا خلال أكثر من أسبوع، من المقبول أن ترد بأدب في نفس threads، طالبًا مراجعة من شخص ما. إذا كنت تعرف اسم الشخص المناسب لمراجعة مساهمتك، يمكنك الإشارة إليه باستخدام @ في تلك threads.\n\n**لا تتواصل مع ذلك الشخص بشكل خاص**؛ تذكر أن التواصل العام مهم جدًا في المشاريع مفتوحة المصدر.\n\nإذا أعطيت تذكيرًا مهذبًا وما زلت لم تتلقَ ردًا، فمن الممكن ألا يرد أحد أبدًا. قد لا يكون شعورًا رائعًا، لكن لا تدع ذلك يثنيك عن المشاركة! 😄 هناك العديد من الأسباب المحتملة لعدم حصولك على رد، بما في ذلك الظروف الشخصية التي قد تكون خارجة عن إرادتك. حاول إيجاد مشروع آخر أو طريقة أخرى للمساهمة. على الأقل، هذا سبب جيد لعدم استثمار الكثير من الوقت في تقديم مساهمة قبل أن يكون أعضاء المجتمع الآخرون منخرطين ومستجيبين.\n\n### 🚧 أحدهم يطلب إجراء تعديلات على مساهمتك\n\nمن الشائع أن يُطلب منك إجراء تعديلات على مساهمتك، سواء كان ذلك ملاحظات حول نطاق فكرتك، أو تغييرات في الكود الذي كتبته.\n\nعندما يطلب منك أحد إجراء تغييرات، كن مستجيبًا. لقد أخذوا وقتهم لمراجعة مساهمتك. فتح **Pull Request** ثم الابتعاد عنه يُعد سلوكًا سيئًا. إذا لم تكن تعرف كيفية إجراء التغييرات، قم بالبحث عن المشكلة، ثم اطلب المساعدة إذا احتجت.\nمثال جيد على ذلك هو [التعليقات التي قدمها أحد المساهمين لـ @a-m-lamb على Pull Request الخاص بهم في مستندات Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).\n\nإذا لم يعد لديك وقت للعمل على المشكلة لعدة أسباب مثل استمرار النقاش لأشهر، أو تغيُّر ظروفك، أو عدم قدرتك على إيجاد حل، فأخبر المسؤول عن المشروع حتى يتمكن من فتح المشكلة لشخص آخر.\nمثل ما فعلت [@RitaDee مع مشكلة في مستودع تطبيق OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).\n\n### 👎 لم تُقبَل مساهمَتَك\n\nمساهمتك قد تُقبل في النهاية أو قد لا تُقبل. نأمل أنك لم تبذل جهدًا كبيرًا فيها بالفعل. إذا كنت غير متأكد من سبب عدم قبولها، فمن المعقول تمامًا أن تطلب توضيحًا وتغذية راجعة من المشرف. في النهاية، عليك أن تحترم أن هذا قرارهم. لا تجادل أو تتصرف بعدائية. أنت مرحب بك دائمًا في إنشاء نسخة مستقلة والعمل على إصدارك الخاص إذا كنت لا توافق!\n\n### 🎉 قُبِلت مساهمَتَك\n\nرائع! لقد قمت بإجراء مساهمة ناجحة في مشروع مفتوح المصدر!\n\n## لقد فَعَلتها 🎉\n\nسواء كنت قد قدّمت مساهمتك الأولى في مشروع مفتوح المصدر، أو كنت تبحث عن طرق جديدة للمساهمة، نأمل أن تكون متحمسًا لاتخاذ خطوة. حتى لو لم تُقبل مساهمتك، لا تنسَ أن تشكر المشرفين الذين بذلوا جهدًا لمساعدتك. المشاريع مفتوحة المصدر يطورها أشخاص مثلك: مشكلة (One Issue)، pull request، تعليق، أو تشجيع بسيط في كل مرة.\n\n
\n" }, { "path": "_articles/ar/index.html", "content": "---\nlayout: index\nlang: ar\ntitle: إرشادات المشاريع مفتوحة المصدر\npermalink: /ar/\n---\n" }, { "path": "_articles/ar/leadership-and-governance.md", "content": "---\nlang: ar\ntitle: القيادة والحوكمة\ndescription: المشاريع مفتوحة المصدر التي تتوسع مع الوقت قد تستفيد كثيرًا من وجود قواعد واضحة ومنظمة تساعدها في اتخاذ القرارات\nclass: leadership\norder: 6\nimage: /assets/images/cards/leadership.png\nrelated:\n - best-practices\n - metrics\n---\n\n
\n\n## فهم آلية الحوكمة في مشروعك المتنامي\n\nمشروعك بدأ يكبر، والمشاركون فيه صاروا أكثر تفاعلًا، وأنت مصمم على استمراره وتطوره، في هذه المرحلة قد تتساءل كيف يمكن دمج المساهمين الدائمين في سير عمل المشروع — سواء من خلال منحهم صلاحية التعديل المباشر على الكود، أو إيجاد طريقة لحل الخلافات والنقاشات داخل المجتمع، وإذا كانت لديك تساؤلات حول ذلك فستجد هنا الإجابات التي تحتاجها\n\n## ما هي أمثلة الأدوار الرسمية في المشاريع مفتوحة المصدر؟\n\nكثير من المشاريع تتبع هيكلًا متشابهًا في تحديد أدوار المساهمين وطريقة تقديرهم.\n\nلكن المعنى الحقيقي لكل دور يعتمد بالكامل على ما تراه مناسبًا لمشروعك. وفيما يلي بعض أنواع الأدوار التي قد تكون مألوفة لك:\n\n* **المشرف (القائم على المشروع)**\n* **المساهم**\n* **المصرّح له بالتحديث**\n\n**في بعض المشاريع**, يكون **\"المشرفون\"** هم الأشخاص الوحيدون الذين يملكون صلاحية التعديل المباشر على الكود، أما في مشاريع أخرى، فقد يُذكر اسمهم فقط في ملف الـ README على أنهم المشرفون.\n\nولا يشترط أن يكون المشرف شخصًا يكتب الكود بنفسه، قد يكون شخصًا ساهم في نشر المشروع والتعريف به، أو كتب توثيقًا جعل استخدامه أسهل للآخرين، وبغض النظر عن طبيعة عمله اليومية، فالمشرف عادة هو شخص يشعر بالمسؤولية تجاه اتجاه المشروع، ومخلص في تطويره وتحسينه باستمرار.\n\n**\"المساهم\" يمكن أن يكون أي شخص** يعلق على مشكلة أو طلب دمج، أو أي شخص يضيف قيمة للمشروع (سواء من خلال فرز المشكلات، كتابة الأكواد، أو تنظيم الفعاليات)، أو أي شخص تم دمج طلبه للدمج (ربما أضيق تعريف للمساهم).\n\n\n\n**مصطلح \"المصرّح له بالتحديث\"** قد يُستخدم للتمييز بين الأشخاص الذين يمتلكون صلاحية تعديل الكود مباشرة — وهي مسؤولية محددة — وبين المساهمين الآخرين الذين يقدّمون دعمًا أو مساهمات بطرق مختلفة.\n\nرغم أنه بإمكانك تحديد أدوار المشروع بالطريقة التي تناسبك, [فكر في استخدام تعريفات أوسع للأدوار أو المسؤوليات](../how-to-contribute/#ما-معنى-المساهمة) لتشجيع المزيد من أشكال المساهمة. كما يمكنك استخدام أدوار القيادة للاعتراف رسميًا بالأشخاص الذين قدموا مساهمات بارزة في مشروعك، بغض النظر عن مهاراتهم التقنية.\n\n\n\n## كيف يمكنني جعل هذه الأدوار القيادية رسمية؟\n\nإضفاء الطابع الرسمي على أدوار القيادة يساعد المشاركين على الشعور بالمسؤولية والانتماء، ويُوضح لأعضاء المجتمع الآخرين من يمكنهم اللجوء إليه للحصول على المساعدة.\n\nفي المشاريع الصغيرة، قد يكون تحديد القادة أمرًا بسيطًا مثل إضافة أسمائهم إلى ملف README أو إلى ملف CONTRIBUTORS.\n\nفي المشاريع الأكبر، إذا كان لديك موقع إلكتروني، يمكنك إنشاء صفحة للفريق أو إدراج أسماء قادة المشروع هناك. على سبيل المثال:, [Postgres](https://github.com/postgres/postgres/) لديها [صفحة فريق شاملة](https://www.postgresql.org/community/contributors/) مع ملفات تعريف مختصرة لكل مساهم\n\nإذا كان مشروعك يضم مجتمع مساهمين نشط جدًا، يمكنك تشكيل \"فريق أساسي\" من المشرفين، أو حتى لجان فرعية لأشخاص يتحملون مسؤولية مجالات مختلفة من المشروع (مثل الأمن، فرز المشكلات، أو سلوك المجتمع)، اترك المجال للأشخاص لتنظيم أنفسهم والتطوع للأدوار التي يشعرون بالحماس تجاهها، بدلًا من تعيينها لهم مباشرة .\n\n\n\nد ترغب فرق القيادة في إنشاء قناة مخصصة (مثل IRC) أو عقد اجتماعات منتظمة لمناقشة المشروع (مثل Gitter أو Google Hangout). يمكنك حتى جعل هذه الاجتماعات عامة ليستمع إليها الآخرون. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), على سبيل المثال, [يستضيف ساعات مكتبية أسبوعية](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).\n\nبمجرد أن تحدد أدوار القيادة، لا تنسَ توثيق كيفية الوصول إليها! ضع عملية واضحة لكيفية أن يصبح الشخص مشرفًا (maintainer) أو ينضم إلى لجنة فرعية (subcommittee) في مشروعك، واكتب ذلك في ملف GOVERNANCE.md.\n\nأدوات مثل [Vossibility](https://github.com/icecrime/vossibility-stack) يمكن أن تساعدك في تتبع من يساهم أو لا يساهم في المشروع بشكل عام. توثيق هذه المعلومات يمنع انطباع المجتمع بأن المشرفين هم مجموعة مغلقة تتخذ قراراتها بشكل خاص.\n\nأخيرًا، إذا كان مشروعك موجودًا على GitHub، فكر في نقل المشروع من حسابك الشخصي إلى منظمة (Organization) وإضافة على الأقل مشرف احتياطي واحد. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) تجعل إدارة الصلاحيات والمستودعات المتعددة أسهل، وتحمي إرث مشروعك من خلال [الملكية المشتركة](../building-community/#شارك-ملكية-مشروعك).\n\n## متى يجب أن أمنح شخصًا صلاحية التعديل؟\n\nيعتقد بعض الأشخاص أنه يجب منح صلاحية التعديل لكل من يقدم مساهمة. القيام بذلك قد يشجع المزيد من الناس على الشعور بالانتماء لمسؤولية المشروع.\n\nمن ناحية أخرى، وخاصة في المشاريع الكبيرة والمعقدة، قد ترغب في منح صلاحية التعديل فقط للأشخاص الذين أثبتوا التزامهم بالمشروع، لا توجد طريقة صحيحة واحدة لذلك – افعل ما يجعلك أكثر راحة وثقة\n\nإذا كان مشروعك موجودًا على GitHub، يمكنك استخدام [الفروع المحمية](https://help.github.com/articles/about-protected-branches/) لإدارة من يمكنه رفع التعديلات إلى فرع معين، وتحديد الظروف التي يُسمح فيها بذلك.\n\n\n\n## ما هي بعض الهياكل الحوكمة الشائعة للمشاريع مفتوحة المصدر؟\n\nهناك ثلاث هياكل حوكمة شائعة مرتبطة بالمشاريع مفتوحة المصدر.\n\n* **BDFL:** BDFL اختصار لعبارة \"المستبد الخيّر مدى الحياة\". في هذا الهيكل، يكون لشخص واحد (عادة مؤلف المشروع الأصلي) الكلمة الأخيرة في جميع القرارات الكبرى للمشروع. [بايثون](https://github.com/python) يُعد مثال Python كلاسيكيًا على هذا الهيكل، غالبًا ما تكون المشاريع الصغيرة BDFL بشكل افتراضي، نظرًا لوجود مشرف واحد أو مشرفين فقط، كما أن المشروع الذي نشأ داخل شركة قد يندرج أيضًا تحت فئة BDFL.\n\n* **الحوكمة على أساس الجدارة:** **(ملاحظة: مصطلح \"meritocracy\" يحمل دلالات سلبية لدى بعض المجتمعات وله [تاريخ اجتماعي وسياسي معقد](http://geekfeminism.wikia.com/wiki/Meritocracy).)** في هيكل الحوكمة على أساس الجدارة (Meritocracy)، يُمنح المساهمون النشطون في المشروع (أي الذين يظهرون \"جدارتهم\") دورًا رسميًا في اتخاذ القرارات، عادةً ما تُتخذ القرارات بناءً على إجماع التصويت البحت، تم تطوير مفهوم الحوكمة على أساس الجدارة بواسطة [مؤسسة Apache](https://www.apache.org/); [جميع مشاريع Apache](https://www.apache.org/index.html#projects-list) تتبع نموذج الحوكمة على أساس الجدارة، ويمكن تقديم المساهمات فقط من قبل أفراد يمثلون أنفسهم، وليس من قبل أي شركة.\n\n* **Liberal contribution:** في نموذج Liberal contribution، يُعترف بالأشخاص الذين يقومون بأكبر قدر من العمل على أنهم الأكثر تأثيرًا، لكن هذا الاعتراف يعتمد على العمل الحالي وليس على المساهمات التاريخية، تُتخذ القرارات الكبرى في المشروع بناءً على عملية البحث عن التوافق (مناقشة القضايا الكبرى) بدلاً من التصويت البحت، مع السعي لإشراك أكبر عدد ممكن من وجهات نظر المجتمع، من الأمثلة الشهيرة على المشاريع التي تستخدم نموذج Liberal contribution: [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/).\n\nأي نموذج يجب أن تستخدمه؟ القرار يعود إليك! كل نموذج له مميزاته وتحدياته، وعلى الرغم من أن هذه النماذج قد تبدو مختلفة تمامًا في البداية، إلا أن كلها تشترك في كثير من النقاط أكثر مما يبدو، إذا كنت مهتمًا بتبني أحد هذه النماذج، يمكنك الاطلاع على هذه القوالب.\n\n* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)\n* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)\n* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)\n\n## هل أحتاج إلى مستندات حوكمة عند إطلاق مشروعي؟\n\nلا يوجد وقت محدد صحيح لتوثيق حوكمة مشروعك، لكن سيكون من الأسهل كثيرًا تحديدها بعد أن ترى ديناميكيات المجتمع الخاص بك تتبلور، أفضل جزء (وأصعبه) في حوكمة المشاريع مفتوحة المصدر هو أنها تتشكل بواسطة المجتمع نفسه!\n\nمع ذلك، فإن أي توثيق مبكر سيساهم حتمًا في حوكمة مشروعك، لذا ابدأ بكتابة ما يمكنك كتابته. على سبيل المثال، يمكنك وضع توقعات واضحة للسلوك، أو توضيح كيفية عمل عملية المساهمة، حتى عند إطلاق المشروع.\n\nإذا كنت جزءًا من شركة تطلق مشروعًا مفتوح المصدر، فمن المفيد إجراء نقاش داخلي قبل الإطلاق حول كيفية توقع الشركة لإدارة المشروع واتخاذ القرارات المتعلقة به مستقبلًا، قد ترغب أيضًا في توضيح أي أمور خاصة بكيفية مشاركة الشركة (أو عدم مشاركتها!) مع المشروع بشكل عام للجمهور.\n\n\n\n## ماذا يحدث إذا بدأ موظفو الشركات بتقديم مساهمات؟\n\nالمشاريع مفتوحة المصدر الناجحة يتم استخدامها من قبل الكثير من الأشخاص والشركات، وبعض الشركات قد ترتبط إيراداتها مستقبلًا بالمشروع. على سبيل المثال، قد تستخدم شركة ما كود المشروع كجزء من خدمة تجارية تقدمها.\n\nمع ازدياد استخدام المشروع، يصبح الأشخاص الذين لديهم خبرة فيه أكثر طلبًا – وربما تكون واحدًا منهم! – وأحيانًا يتم دفع أجر لهم مقابل العمل الذي يقومون به في المشروع.\n\nمن المهم التعامل مع النشاط التجاري باعتباره أمرًا طبيعيًا ومجرد مصدر إضافي للطاقة التطويرية. بالطبع، لا ينبغي إعطاء المطورين المدفوع لهم معاملة خاصة مقارنة بالمطورين غير المدفوعين؛ يجب تقييم كل مساهمة على أساس قيمتها التقنية. ومع ذلك، يجب أن يشعر الناس بالراحة عند الانخراط في النشاط التجاري، وأن يكونوا قادرين على توضيح حالات استخدامهم عند الدفاع عن تحسين أو ميزة معينة.\n\nمصطلح \"تجاري\" متوافق تمامًا مع \"مفتوح المصدر\". \"تجاري\" يعني ببساطة أن هناك مالًا متورطًا في مكان ما – أي أن البرنامج يُستخدم في التجارة، وهذا يصبح أكثر احتمالًا مع زيادة اعتماد المشروع. (وعندما يُستخدم برنامج مفتوح المصدر كجزء من منتج غير مفتوح المصدر، يظل المنتج الكلي برنامجًا مملوكًا، ولكنه، مثل البرمجيات مفتوحة المصدر، قد يُستخدم لأغراض تجارية أو غير تجارية).\n\nمثل أي شخص آخر، يكسب المطورون الذين لديهم دوافع تجارية تأثيرًا في المشروع من خلال جودة وكمية مساهماتهم. من الواضح أن المطور الذي يتلقى أجرًا عن وقته قد يكون قادرًا على القيام بالمزيد مقارنة بشخص لا يتلقى أجرًا، لكن هذا طبيعي: الأجر هو مجرد أحد العوامل العديدة التي قد تؤثر على حجم مساهمة الشخص. ركّز مناقشات مشروعك على المساهمات نفسها، وليس على العوامل الخارجية التي تمكّن الأشخاص من تقديم هذه المساهمات.\n\n## هل أحتاج إلى كيان قانوني لدعم مشروعي؟ {#هل-أحتاج-إلى-كيان-قانوني-لدعم-مشروعي}\n\nلا تحتاج إلى إنشاء كيان قانوني لدعم مشروعك مفتوح المصدر، إلا إذا كنت تتعامل مع أموال.\n\nعلى سبيل المثال، إذا كنت تريد إنشاء عمل تجاري، فستحتاج إلى إنشاء C Corp أو LLC (إذا كنت مقيمًا في الولايات المتحدة). إذا كنت تقوم فقط بعمل تعاقدي متعلق بمشروعك مفتوح المصدر، يمكنك قبول الأموال كمالك فردي، أو إنشاء LLC (إذا كنت مقيمًا في الولايات المتحدة)\n\nإذا كنت تريد قبول التبرعات لمشروعك مفتوح المصدر، يمكنك إعداد زر تبرع (باستخدام PayPal أو Stripe على سبيل المثال)، لكن الأموال لن تكون قابلة للخصم الضريبي إلا إذا كنت منظمة غير ربحية مؤهلة (501c3 إذا كنت في الولايات المتحدة)\n\nكثير من المشاريع لا ترغب في عناء إنشاء منظمة غير ربحية، لذلك تجد راعٍ مالي غير ربحي بدلاً من ذلك، حيث يقبل الراعي المالي التبرعات نيابة عنك عادةً مقابل نسبة من التبرع. [Software Freedom Conservancy](https://sfconservancy.org/)، [Apache Foundation](https://www.apache.org/)، [Eclipse Foundation](https://www.eclipse.org/org/)، [Linux Foundation](https://www.linuxfoundation.org/projects) و[Open Collective](https://opencollective.com/opensource) أمثلة على المنظمات التي تعمل كراعٍ مالي للمشاريع مفتوحة المصدر.\n\n\n\nإذا كان مشروعك مرتبطًا ارتباطًا وثيقًا بلغة أو بيئة معينة، فقد يكون هناك أيضًا مؤسسة برمجيات ذات صلة يمكنك العمل معها. على سبيل المثال، [Python Software Foundation](https://www.python.org/psf/) تدعم [PyPI](https://pypi.org/)، مدير حزم بايثون، و[Node.js Foundation](https://foundation.nodejs.org/) تدعم [Express.js](https://expressjs.com/)، إطار عمل مبني على Node.\n\n
\n" }, { "path": "_articles/ar/legal.md", "content": "---\nlang: ar\ntitle: الجانب القانوني للبرمجيات مفتوحة المصدر\ndescription: كل ما تريد معرفته عن الجانب القانوني في المشاريع مفتوحة المصدر، و بعض الأمور التي لم تكن تعرف أنك بحاجة لمعرفتها\nclass: legal\norder: 10\nimage: /assets/images/cards/legal.png\nrelated:\n - contribute\n - leadership\n---\n\n
\n\n## فهم الآثار القانونية للبرمجيات مفتوحة المصدر\n\nمشاركة عملك الإبداعي مع العالم يمكن أن تكون تجربة مثيرة ومُجزية، كما قد تعني مجموعة من الأمور القانونية التي لم تكن تعلم أنك بحاجة للقلق بشأنها. لحسن الحظ، مع هذا الدليل، ليس عليك البدء من الصفر. (قبل أن تبدأ، تأكد من قراءة [إخلاء المسؤولية](/notices/).)\n\n## لماذا يهتم الناس كثيراً حول الجانب القانوني للبرمجيات مفتوحة المصدر ؟\n\nسعيدٌ لسؤالك ! عندما تنشئ عمل إبداعي ( كالكتابة، الرسومات أو البرمجيات ) ، يكون هذا العمل محمياً بحقوق النشر الحصرية تلقائياً. أي أن القانون يفترض لك، بصفتك مؤلف ..العمل، الحق في تحديد ما يمكن للآخرين فعله به.\n\nبشكل عام، هذا يعني أنه لا يمكن لأي شخص آخر استخدام ، نسخ ، توزيع ، أو التعديل على عملك دون أن يكون معرضاً لخطر الإزالة أو الابتزاز أو التقاضي .\n\nومع ذلك، فإن البرمجيات مفتوحة المصدر تمثل حالة غير معتادة، لأن المؤلف يتوقع أن يستخدم الآخرون العمل و يعدلوه ويشاركوه. ولكن نظراً لأن الوضع القانوني الافتراضي هو حقوق النشر الحصرية، يجب عليك أن تمنح هذه الأذونات صراحةً من خلال ترخيص.\n\nتنطبق هذه القواعد أيضاً عندما يساهم شخص ما في مشروعك. بدون ترخيص أو اتفاقية أخرى، تكون أي مساهمات مملوكة حصرياً لمؤلفيها. وهذا يعني أنه لا أحد - حتى أنت - يمكنه نسخ، توزيع، أو تعديل مساهماتهم.\n\nأخيراً، قد يحتوي مشروعك على تبعيات لها متطلبات ترخيص لم تكن على علم بها . و قد يتطلب مجتمع مشروعك ، أو سياسات صاحب العمل أيضاً أن يستخدم مشروعك تراخيص محددة للبرمجيات مفتوحة المصدر. سنغطي هذه الحالات أدناه.\n\n## هل مشاريع GitHub العامة مفتوحة المصدر؟\n\nعند [إنشاء مشروع جديد](https://help.github.com/articles/creating-a-new-repository/) على GitHub، لديك الخيار لجعل المستودع **خاص** أو **عام**.\n\n![إنشاء مستودع](/assets/images/legal/repo-create-name.png)\n\n**جعل مشروعك على GitHub عاماً لا يعني ترخيص مشروعك .** المشاريع العامة تخضع ل [شروط الخدمة](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)، و التي تسمح للآخرين بعرض مشروعك و نسخه(fork) . لكن عملك لا يمنح أي أذونات أخرى بشكل افتراضي .\n\nإذا كنت تريد من الآخرين استخدام ، توزيع، تعديل، أو المساهمة في مشروعك، عليك تضمين رخصة مفتوحة المصدر. على سبيل المثال، لا يمكن لأي شخص قانونياً استخدام أي جزء من مشروعك على GitHub في كوده الخاص، حتى لو كان عاماً. ما لم تمنحه الحق بذلك صراحةً.\n\n## فقط أعطني ملخصاً سريعاً عن ما أحتاجه لحماية مشروعي\n\nأنت محظوظ، لأن تراخيص البرمجيات مفتوحة المصدر اليوم موحدة و سهلة الاستخدام. يمكنك نسخ و لصق ترخيص موجود مباشرة في مشروعك.\n\n[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، و [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) هي [رخص مفتوحة المصدر شائعة](https://innovationgraph.github.com/global-metrics/licenses)، لكن هناك خيارات أخرى يمكن الاختيار منها. يمكنك العثور على النص الكامل لهذه الرخص، والتعليمات حول كيفية استخدامها، على [choosealicense.com](https://choosealicense.com/).\n\nعند إنشاء مشروع جديد على GitHub، سيُطلب منك [إضافة ترخيص](https://help.github.com/articles/open-source-licensing/).\n\n \n\n## أي ترخيص مفتوح المصدر مناسب لمشروعي؟ {#اي-ترخيص-مفتوح-المصدر-مناسب-لمشروعي}\n\nمن الصعب أن تخطئ عند استخدام [MIT License](https://choosealicense.com/licenses/mit/) إذا كنت تبدأ من الصفر. فهي قصيرة، سهلة الفهم، وتسمح لأي شخص بفعل أي شيء طالما احتفظ بنسخة من الترخيص، بما في ذلك إشعار حقوق الطبع والنشر الخاص بك. ستكون قادرًا على إصدار المشروع تحت ترخيص مختلف إذا احتجت لذلك لاحقًا.\n\nأما إذا لا، فإن اختيار الترخيص المناسب لمشروعك مفتوح المصدر يعتمد على أهدافك.\n\nمن المرجح أن يحتوي مشروعك (أو سيحتوي) على **dependencies**، كل منها سيكون له ترخيص مفتوح المصدر خاص به مع شروط عليك احترامها. على سبيل المثال، إذا كنت تفتح مصدر مشروع Node.js، فربما ستستخدم مكتبات من **Node Package Manager (npm)**.\n\nتسمح **dependencies** ذات **permissive licenses** مثل [MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، [ISC](https://choosealicense.com/licenses/isc)، و [BSD](https://choosealicense.com/licenses/bsd-3-clause) لك بترخيص مشروعك بالطريقة التي تريدها.\n\nتتطلب dependencies ذات copyleft licenses اهتمامًا أكبر. تضمين أي مكتبة ذات ترخيص strong copyleft مثل [GPLv2](https://choosealicense.com/licenses/gpl-2.0)، [GPLv3](https://choosealicense.com/licenses/gpl-3.0)، أو [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) يتطلب منك اختيار ترخيص مطابق أو [متوافق](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) لمشروعك. أما المكتبات ذات الترخيص limited أو weak copyleft مثل [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) و [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) فيمكن تضمينها في مشاريع بأي ترخيص، بشرط الالتزام بـ [القواعد الإضافية](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) التي تحددها.\n\nتتضمن dependencies ذات **source-available licenses**، مثل Business Source License [BSL](https://spdx.org/licenses/BUSL-1.1.html) أو Server Side Public License [SSPL](https://en.wikipedia.org/wiki/Server_Side_Public_License)، قيودًا على الاستخدام ونموذج العمل قد تجعلها تبدو كأنها تحت تراخيص مفتوحة المصدر، لكنها قد تمنع مشروعك من أن يُعتبر Open Source كما تحدده [Open Source Initiative (OSI)](https://opensource.org/).\n\nتعتمد المشاريع غالبًا على **محتوى غير برمجي** مثل الصور أو الأيقونات أو مقاطع الفيديو أو الخطوط أو ملفات البيانات أو مواد أخرى، والتي تخضع لتراخيصها الخاصة. وكما هو الحال مع تبعيات البرمجيات التقليدية، تتراوح تراخيص هذه المواد من تجارية إلى مرنة إلى كوبيلفت. أنشأت منظمة [Creative Commons](https://creativecommons.org/share-your-work/cclicenses/)، وهي منظمة غير ربحية، سلسلة من التراخيص الشائعة للمحتوى غير البرمجي تتدرج من [CC0](https://creativecommons.org/publicdomain/zero/1.0/deed.en) إلى [CC-BY](https://creativecommons.org/licenses/by/4.0/deed.en) إلى [CC-SA](https://creativecommons.org/licenses/by-sa/2.0/deed.en)، ويمكنها أحيانًا تقييد الاستخدام التجاري بإضافة خيار (NC) إلى هذه التراخيص.\nقد ترغبين أيضًا في أخذ **communities** التي تأملين أن تستخدم مشروعك وتساهم فيه بعين الاعتبار.\n\n* **هل تريد أن يُستخدم مشروعك كـ dependency من قبل مشاريع أخرى؟** من الأفضل على الأرجح استخدام الترخيص الأكثر شيوعًا في المجتمع ذي الصلة. على سبيل المثال، [MIT](https://choosealicense.com/licenses/mit/) هو الترخيص الأكثر شيوعًا لمكتبات [npm](https://libraries.io/search?platforms=NPM).\n* **هل تريد أن يجذب مشروعك الشركات الكبيرة؟** قد تشعر الشركة الكبيرة بالراحة عند وجود ترخيص براءة اختراع صريح من جميع المساهمين. في هذه الحالة، يغطيك [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (ويغطيهم أيضًا).\n* **هل تريد أن يجذب مشروعك المساهمين الذين لا يرغبون في أن تُستخدم مساهماتهم في برامج مغلقة المصدر؟** سيكون [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) أو (إذا لم يرغبوا أيضًا في المساهمة في خدمات مغلقة المصدر) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) مناسبًا لهم.\n\nقد يكون لشركتك **company** سياسات بشأن تراخيص المشاريع مفتوحة المصدر. بعض الشركات تتطلب أن تحمل مشاريعك ترخيصًا permissive للسماح بالتكامل مع منتجات الشركة المملوكة، بينما تفرض سياسات أخرى ترخيصًا strong copyleft واتفاقية مساهم إضافية ([انظري أدناه](#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية)) بحيث يمكن لشركتك فقط استخدام المشروع في برامج مغلقة المصدر. قد يكون لدى المؤسسات أيضًا معايير معينة، أو أهداف مسؤولية اجتماعية، أو احتياجات للشفافية تتطلب استراتيجية ترخيص محددة. استشيري [القسم القانوني لشركتك](#ماذا-يحتاج-فريق-الشؤون-القانونية-في-شركتي-لمعرفته) للحصول على التوجيه.\n\nعند إنشاء مشروع جديد على GitHub، يُعطى لك خيار اختيار ترخيص. تضمين أحد التراخيص المذكورة أعلاه سيجعل مشروعك على GitHub مفتوح المصدر. إذا رغبت في الاطلاع على خيارات أخرى، تفقد [choosealicense.com](https://choosealicense.com) للعثور على الترخيص المناسب لمشروعك، حتى لو [لم يكن برنامجًا](https://choosealicense.com/non-software/).\n\n## ماذا لو أردت تغيير ترخيص مشروعي؟\n\nمعظم المشاريع لا تحتاج أبداً إلى تغيير التراخيص. لكن في بعض الأحيان تتغير الظروف\n\nعلى سبيل المثال، مع نمو مشروعك، قد تضيف اعتمادات أو مستخدمين، أو قد تغير شركتك استراتيجياتها، وكل ذلك قد يتطلب أو يرغب في ترخيص مختلف. أيضًا، إذا أهملت ترخيص مشروعك منذ البداية، فإن إضافة ترخيص جديد تُعادل فعليًا تغيير التراخيص. هناك ثلاث أمور أساسية يجب مراعاتها عند إضافة أو تغيير ترخيص مشروعك.\n\n**الأمر معقد**، تحديد مدى توافق التراخيص والامتثال لها ومعرفة من يحمل حقوق الطبع والنشر يمكن أن يصبح معقدًا ومركبًا بسرعة. الانتقال إلى ترخيص جديد لكن متوافق للإصدارات والمساهمات الجديدة يختلف عن إعادة ترخيص جميع المساهمات الحالية. شارك فريقك القانوني بمجرد ظهور أي رغبة في تغيير التراخيص، حتى لو كان لديك أو يمكنك الحصول على موافقة من أصحاب حقوق الطبع والنشر لمشروعك لتغيير التراخيص، فكر في تأثير هذا التغيير على المستخدمين والمساهمين الآخرين في مشروعك. اعتبر تغيير التراخيص كـ \"حدث حوكمة\" لمشروعك، ومن المرجح أن يسير بسلاسة مع تواصل واضح واستشارة أصحاب المصلحة. كل هذه أسباب إضافية لاختيار واستخدام ترخيص مناسب لمشروعك منذ البداية!\n\n**الترخيص الحالي لمشروعك.** إذا كان الترخيص الحالي لمشروعك متوافقًا مع الترخيص الذي تريد التغيير إليه، فيمكنك ببساطة البدء في استخدام الترخيص الجديد. ذلك لأنه إذا كان الترخيص \"أ\" متوافقًا مع الترخيص \"ب\"، فستكون متوافقًا مع شروط \"أ\" أثناء امتثالك لشروط \"ب\" (ولكن ليس بالضرورة العكس). لذا، إذا كنت تستخدم حاليًا ترخيصًا و أي إشعارات حقوق طبع ونشر مرتبطة به MIT، فيمكنك التغيير إلى ترخيص به شروط أكثر، طالما احتفظت بنسخة من ترخيص (MIT)، ولم تكن أنت المالك الوحيد لحقوق الطبع والنشر (أو ليس لديك ترخيص copyleft)، ولكن إذا كان ترخيصك الحالي غير متساهل مثل MIT، أي استمر في الوفاء بالشروط الدنيا للترخيص. أساسًا، مع الترخيص المتساهل، يكون أصحاب حقوق الطبع والنشر للمشروع قد منحوا الإذن مسبقًا بتغيير التراخيص، فلن تتمكن من تغيير ترخيص مشروعك إلى MIT.\n\n**حاملو حقوق الطبع والنشر الحاليون لمشروعك.** إذا كنت المساهم الوحيد في مشروعك، فإما أنت أو شركتك هو المالك الوحيد لحقوق الطبع والنشر للمشروع، ويمكنك إضافة أو تغيير الترخيص كما تشاء أنت أو شركتك. أما إذا كان هناك أصحاب حقوق نشر آخرون، فستحتاج إلى موافقتهم لتغيير الترخيص. من هم؟ [الأشخاص الذين لديهم مساهمات (commits) في مشروعك](https://github.com/thehale/git-authorship) مكان جيد للبدء، ولكن في بعض الحالات تكون حقوق النشر مملوكة لأصحاب عمل هؤلاء الأشخاص. في حالات أخرى، قد تكون مساهماتهم بسيطة، لكن لا توجد قاعدة صارمة تنص على أن المساهمات الصغيرة لا تخضع لحقوق الطبع والنشر. ماذا تفعل؟ يعتمد ذلك على حجم المشروع وعمره؛ فبالنسبة للمشاريع الصغيرة والحديثة نسبيًا، يمكن الحصول على موافقة جميع المساهمين الحاليين على تغيير الترخيص عبر issue أو pull request، أما المشاريع الكبيرة والمستمرة منذ فترة طويلة، فقد تحتاج إلى التواصل مع العديد من المساهمين وحتى ورثتهم. استغرقت موزيلا سنوات (2001-2006) لإعادة ترخيص فايرفوكس وثندربرد والبرمجيات ذات الصلة.\n\nبدلاً من ذلك، يمكنك أن يوافق المساهمون مسبقًا على تغييرات معينة في الترخيص عبر اتفاقية مساهم إضافية ([انظر أدناه](#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية))، مما يقلل بعض الشيء من تعقيد تغيير التراخيص؛ ستحتاج لمزيد من المساعدة من محاميك في البداية، وستظل بحاجة للتواصل بوضوح مع أصحاب المصلحة في مشروعك عند تنفيذ تغيير الترخيص.\n\n## هل يحتاج مشروعي إلى اتفاقية مساهم إضافية؟ {#هل-يحتاج-مشروعي-الى-اتفاقية-مساهم-اضافية}\n\nعلى الأرجح لا. بالنسبة لغالبية مشاريع المصدر المفتوح، فإن الترخيص مفتوح المصدر يُعد ضمنيًا بمثابة ترخيص **inbound** (من المساهمين) و **outbound** (إلى المساهمين والمستخدمين الآخرين). إذا كان مشروعك على GitHub، فإن شروط خدمة GitHub تجعل \"inbound=outbound\" [افتراضيًا وصريحًا](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).\n\nعملاً إداريًا على القائمين على صيانة المشروع، يمكن أن تخلق اتفاقية المساهم الإضافية (CLA) مقدار العمل الإضافي الذي تضيفه الاتفاقية حسب المشروع وطريقة التنفيذ. قد تتطلب الاتفاقية البسيطة من المساهمين فقط تأكيدًا، بنقرة واحدة، على أن لديهم الحقوق اللازمة للمساهمة بموجب ترخيص المصادر المفتوحة للمشروع، أما الاتفاقية الأكثر تعقيدًا فقد تتطلب مراجعة قانونية وموافقة رسمية من أصحاب عمل المساهمين.\n\nأيضاً من خلال إضافة \"أعمال ورقية\" يعتقد البعض أنها غير ضرورية أو يصعب فهمها أو غير عادلة(عندما يحصل متلقي الاتفاقية على حقوق أكثر من المساهمين أو الجمهور عبر ترخيص المصادر المفتوحة للمشروع)، قد يُنظر إلى اتفاقية المساهم الإضافية على أنها غير ودية تجاه مجتمع المشروع .\n\n\n\nبعض الحالات التي قد ترغب فيها في النظر في اتفاقية مساهم إضافية لمشروعك تشمل :\n\n* يريد محاموك من جميع المساهمين قبول شروط المساهمة صراحةً (_sign_، عبر الإنترنت أو خارجه)، ربما لأنهم يشعرون أن الترخيص مفتوح المصدر نفسه لا يكفي (حتى وإن كان يكفي!). إذا كان هذا هو القلق الوحيد، فستكون اتفاقية المساهم التي تؤكد على ترخيص المشروع مفتوح المصدر كافية. اتفاقية [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) هي مثال جيد على اتفاقية مساهم إضافية خفيفة الوزن.\n* أنت أو محاموك تريدون من المطورين التصريح بأن كل commit يقومون به مُصرح به. مطلب [Developer Certificate of Origin](https://developercertificate.org/) هو الطريقة التي تحقق بها العديد من المشاريع ذلك. على سبيل المثال، مجتمع Node.js [يستخدم](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) الـ DCO [بدلاً](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) من اتفاقية CLA السابقة. خيار بسيط لأتمتة فرض الـ DCO على مستودعك هو [DCO Probot](https://github.com/probot/dco).\n* مشروعك يستخدم ترخيصًا مفتوح المصدر لا يتضمن منح براءة اختراع صريح (مثل MIT)، وتحتاج إلى منح براءة اختراع من جميع المساهمين، بعضهم قد يعمل في شركات لديها محافظ براءات اختراع كبيرة يمكن استخدامها لاستهدافك أو استهداف مساهمي ومستخدمي المشروع الآخرين. اتفاقية [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) هي اتفاقية مساهم إضافية شائعة الاستخدام تحتوي على منح براءة اختراع مماثل للذي يوجد في Apache License 2.0.\n* مشروعك تحت ترخيص copyleft، ولكنك تحتاج أيضًا لتوزيع نسخة مملوكة من المشروع. ستحتاج إلى أن يقوم كل مساهم بتخصيص حقوق الطبع والنشر لك أو منحك (وليس للجمهور) ترخيصًا permissive. اتفاقية [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) هي مثال على هذا النوع من الاتفاقيات.\n* تعتقد أن مشروعك قد يحتاج إلى تغيير التراخيص خلال عمره وتريد من المساهمين الموافقة مسبقًا على مثل هذه التغييرات لتقليل تشتت انتباه المساهمين.\n\nإذا كنت بحاجة إلى استخدام اتفاقية مساهم إضافية مع مشروعك، فكر في استخدام تكامل مثل [CLA assistant](https://github.com/cla-assistant/cla-assistant) لتقليل تشتت المساهمين.\n\n## ماذا يحتاج فريق الشؤون القانونية في شركتي لمعرفته؟ {#ماذا-يحتاج-فريق-الشؤون-القانونية-في-شركتي-لمعرفته}\n\nإذا كنت تطرح مشروعاً مفتوح المصدر كموظف في الشركة، يجب أولاً أن يعرف فريق الشؤون القانونية أنك تطرح مشروعاً مفتوح المصدر.\n\nللخير أو للشر، فكر في إعلامهم حتى لو كان مشروعك شخصيًا. من المحتمل أن يكون لديك \"اتفاقية حقوق ملكية فكرية للموظف\" مع شركتك تمنحهم بعض السيطرة على مشاريعك، خاصة إذا كانت مرتبطة بأعمال الشركة أو استخدمت أي موارد للشركة لتطوير المشروع. يجب أن تمنحك شركتك الإذن بسهولة، وربما تكون قد فعلت ذلك بالفعل عبر اتفاقية حقوق ملكية فكرية صديقة للموظف أو سياسة للشركة. إذا لم يكن الأمر كذلك، يمكنك التفاوض (على سبيل المثال، شرح أن مشروعك يخدم أهداف التعلم والتطوير المهني للشركة بالنسبة لك)، أو تجنب العمل على مشروعك حتى تجد شركة أفضل.\n\n**إذا كنت تحول مشروعًا مفتوح المصدر لشركتك،** فبالتأكيد أخبرهم. من المحتمل أن يكون لفريقك القانوني سياسات بالفعل حول الترخيص مفتوح المصدر الذي يجب استخدامه (وربما اتفاقية مساهم إضافية) استنادًا إلى متطلبات أعمال الشركة وخبرتها في ضمان امتثال مشروعك لتراخيص اعتماداتها. إذا لم يكن الأمر كذلك، فأنت وفريقك محظوظون! يجب أن يكون فريقك القانوني متحمسًا للعمل معك لفهم هذه الأمور. بعض الأشياء للتفكير بها:\n\n* **المواد التابعة لطرف ثالث:** هل يحتوي مشروعك على اعتمادات أنشأها آخرون أو يستخدم كودًا لآخرين؟ إذا كانت هذه الاعتمادات مفتوحة المصدر، فستحتاج إلى الامتثال لتراخيصها. يبدأ ذلك باختيار ترخيص يتوافق مع تراخيص الطرف الثالث مفتوح المصدر ([انظر أعلاه](#اي-ترخيص-مفتوح-المصدر-مناسب-لمشروعي)). إذا كان مشروعك يعدل أو يوزع مواد طرف ثالث مفتوح المصدر، فسيرغب فريقك القانوني أيضًا في التأكد من التزامك بالشروط الأخرى لتراخيص الطرف الثالث، مثل الاحتفاظ بإشعارات حقوق الطبع والنشر. إذا كان مشروعك يستخدم كودًا لآخرين لا يحتوي على ترخيص مفتوح المصدر، فربما تحتاج إلى طلب من القائمين على هذا الكود [إضافة ترخيص مفتوح المصدر](https://choosealicense.com/no-license/#for-users)، وإذا لم تتمكن من الحصول عليه، توقف عن استخدام كودهم في مشروعك.\n\n* **الأسرار التجارية:** فكر فيما إذا كان هناك أي شيء في المشروع لا ترغب الشركة في جعله متاحًا للجمهور. إذا كان الأمر كذلك، يمكنك جعل بقية مشروعك مفتوح المصدر بعد استخراج المواد التي تريد الاحتفاظ بها خاصة.\n\n* **براءات الاختراع:** هل تتقدم شركتك للحصول على براءة اختراع، بحيث أن تحويل مشروعك إلى مفتوح المصدر يشكل [إفصاحًا عامًا](https://en.wikipedia.org/wiki/Public_disclosure)؟ للأسف، قد يُطلب منك الانتظار (أو ربما تعيد الشركة النظر في جدوى تقديم الطلب). إذا كنت تتوقع مساهمات في مشروعك من موظفين في شركات لديها محافظ براءات اختراع كبيرة، فقد يرغب فريقك القانوني في أن تستخدم ترخيصًا يتضمن منح براءة اختراع صريح من المساهمين (مثل Apache 2.0 أو GPLv3)، أو اتفاقية مساهم إضافية ([انظر أعلاه](#اي-ترخيص-مفتوح-المصدر-مناسب-لمشروعي)).\n\n* **العلامات التجارية:** تحقق مرتين من أن اسم مشروعك [لا يتعارض مع أي علامات تجارية موجودة](../starting-a-project/#تجنب-تعارضات-الاسماء). إذا استخدمت علاماتك التجارية الخاصة بالشركة في المشروع، تحقق من أنها لا تسبب أي تعارض. [FOSSmarks](http://fossmarks.org/) هو دليل عملي لفهم العلامات التجارية في سياق المشاريع الحرة ومفتوحة المصدر.\n\n* **الخصوصية:** هل يجمع مشروعك بيانات عن المستخدمين؟ هل يقوم \"بالاتصال بخوادم الشركة\"؟ يمكن لفريقك القانوني مساعدتك في الامتثال لسياسات الشركة واللوائح الخارجية.\n\n* **الذكاء الاصطناعي (AI):** مع تكامل نماذج ووظائف الذكاء الاصطناعي في البرمجيات، من الضروري فهم اتفاقيات الترخيص والتشريعات ذات الصلة التي تتحكم في استخدامها. حتى عندما يدعي نموذج أو خدمة أنها تحت ترخيص مفتوح المصدر قياسي، قد تفرض الشروط الإضافية قيودًا، مثل منع الإساءة أو الاحتيال. التشريعات الجديدة تضع أيضًا قيودًا على أنواع الأنظمة أو الإجراءات التي يمكن تنفيذها بواسطة البرمجيات المعتمدة على الذكاء الاصطناعي.\n* **قائمة مكونات البرمجيات (Software Bill of Materials - SBOM):** قائمة مكونات البرمجيات هي قائمة شاملة بالاعتمادات التابعة لطرف ثالث، الإصدارات، التراخيص المرتبطة، وبيانات وصفية أخرى. تُفرض SBOMs قانونيًا في بعض الدول أو الصناعات أو بسبب الالتزامات التعاقدية. غالبًا ما يبدأ طلب SBOM رحلة الامتثال للتراخيص لمنظمة ما.\n\nإذا كنت تطلق أول مشروع مفتوح المصدر لشركتك، فإن ما سبق أكثر من كافٍ للمرور به (لكن لا تقلق، فمعظم المشاريع لا ينبغي أن تثير أي مخاوف كبيرة).\n\nعلى المدى الطويل، يمكن لفريقك القانوني أن يقوم بالمزيد لمساعدة الشركة على الاستفادة أكثر من مشاركتها في المصدر المفتوح، والبقاء آمنة.\n\n* **سياسات مساهمة الموظفين:** فكر في تطوير سياسة شركية تحدد كيف يساهم موظفوك في مشاريع مفتوحة المصدر. ستقلل سياسة واضحة من الالتباس بين الموظفين وتساعدهم على المساهمة في مشاريع مفتوحة المصدر بما يخدم مصلحة الشركة، سواء كجزء من وظائفهم أو في أوقات فراغهم. مثال جيد هو [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) لشركة Rackspace.\n\n\n\n* **ما الذي يجب إصداره:** [(تقريبًا) كل شيء؟](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) إذا كان فريقك القانوني يفهم ويشارك في استراتيجية شركتك للمصدر المفتوح، فسيكون أفضل من يساعدك بدلاً من عرقلة جهودك.\n* **الامتثال:** حتى إذا لم تصدر شركتك أي مشاريع مفتوحة المصدر، فهي تستخدم برمجيات مفتوحة المصدر للآخرين. يمكن أن تمنع [الوعي والعمليات](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) الصداع، وتأخير المنتجات، والدعاوى القضائية.\n\n\n\n* **براءات الاختراع:** قد ترغب شركتك في الانضمام إلى [Open Invention Network](https://www.openinventionnetwork.com/)، وهي تجمع دفاعي مشترك للبراءات لحماية استخدام الأعضاء للمشاريع مفتوحة المصدر الكبرى، أو استكشاف خيارات [ترخيص براءات اختراع بديلة](https://www.eff.org/document/hacking-patent-system-2016).\n* **الحوكمة:** خاصة إذا ومتى كان من المنطقي نقل مشروع إلى [كيان قانوني خارج الشركة](../leadership-and-governance/#هل-أحتاج-إلى-كيان-قانوني-لدعم-مشروعي).\n\n
\n" }, { "path": "_articles/ar/maintaining-balance-for-open-source-maintainers.md", "content": "---\nlang: ar\ntitle: الحفاظ على التوازن لمشرفي المشاريع مفتوحة المصدر\ndescription: نصائح للعناية الذاتية وتجنب الإرهاق كمشرف\nclass: balance\norder: 0\nimage: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png\n---\n\n
\n\nمع تزايد شعبية المشروع مفتوح المصدر، يصبح من الضروري وضع حدود واضحة لمساعدتك في الحفاظ على التوازن، لتبقى متجددًا ومنتجًا على المدى الطويل.\n\nللحصول على فهم أعمق لتجارب المشرفين واستراتيجياتهم في إيجاد التوازن، أجرينا ورشة عمل بمشاركة 40 عضوًا من مجتمع المشرفين, مما أتاح لنا التعلّم من تجاربهم المباشرة مع الإرهاق في مشاريع المصادر المفتوحة، والممارسات التي ساعدتهم على الحفاظ في التوازن في عملهم. وهنا يأتي دور مفهوم البيئة الشخصية (Personal Ecology).\n\nإذًا, ما هي البيئة الشخصية (Personal Ecology) كما ورد في وصف معهد Rockwood للقيادة, يتضمن الأمر \"الحفاظ على التوازن، والسرعة، والكفاءة للحفاظ على طاقتنا على مدى الحياة.\" لقد أطّر هذا الأمر محادثاتنا، وساعد المشرفين في إدراك أن أفعالهم ومساهماتهم هي أجزاء من نظام بيئي أكبر يتطور مع مرور الوقت. الإرهاق، وهو متلازمة ناتجة عن الإجهاد المزمن في مكان العمل [كما عرّفتها منظمة الصحة العالمية (WHO)](https://icd.who.int/browse/2025-01/foundation/en#129180281), ليس أمرًا نادر الحدوث بين المشرفين. وغالبًا ما يؤدي هذا إلى فقدان الدافع، وعدم القدرة على التركيز، ونقص التعاطف مع المساهمين والمجتمع الذي تعمل معه.\n\n\n\nمن خلال تبنّي مفهوم البيئة الشخصية (Personal Ecology)، يمكن للمُشرفين أن يتجنبوا الإرهاق (burnout)، وإعطاء الأولوية للعناية بالنفس، والحفاظ على إحساسٍ بالتوازن يمكّنهم من أداء عملهم بأفضل صورة ممكنة.\n\n## نصائح للعناية الذاتية وتجنب الإرهاق بصفتك مُشرفًا:\n\n### حدّد دوافعك للعمل في المشاريع مفتوحة المصدر\n\nخذ وقتًا للتفكير في جوانب صيانة المشاريع مفتوحة المصدر التي تمنحك الطاقة والحماس . إن فهم دوافعك يمكن أن يساعدك على ترتيب أولويات عملك بطريقة تُبقيك متحمّسًا ومستعدًا لمواجهة التحديات الجديدة. سواء كان ذلك التعليقات الإيجابية من المستخدمين، أو متعة التعاون والتفاعل مع المجتمع، أو الإحساس بالرضا عند التعمق في الكود — فإن إدراكك لما يُحفّزك يمكن أن يوجّه تركيزك بشكل أفضل.\n\n### فكِّر فيما يجعلك تفقد توازنك وتشعر بالتوتر\n\nمن المهم أن نفهم ما الذي يسبب لنا الإرهاق. فيما يلي بعض النقاط المشتركة التي لاحظناها بين مُشرفي المشاريع مفتوحة المصدر:\n\n* **نقص التعليقات الإيجابية:** المستخدمون غالبًا ما يتواصلون فقط عندما تكون لديهم شكوى. أما إذا كان كل شيء يعمل بشكل جيد، فإنهم يميلون إلى الصمت. قد يكون الأمر محبطًا أن رؤية قائمة متزايدة من المشكلات دون أن تتلقى ملاحظات إيجابية تُظهر كيف أن مساهماتك تُحدث فرقًا فعليًا.\n\n\n\n* **عدم قول \"لا\":** قد يكون من السهل أن تتحمّل مسؤوليات أكثر مما ينبغي في مشروع مفتوح المصدر. سواء كانت الطلبات من المستخدمين أو المساهمين أو حتى المشرفين الآخرين على المشروع — لا يمكننا دائمًا تلبية جميع التوقعات.\n\n\n\n* **العمل بمفردك:** قد يكون عمل المُشرف شديد العزلة. حتى لو كنت تعمل مع مجموعة من المُشرفين، فقد كانت السنوات القليلة الماضية صعبة فيما يخص جمع الفرق الموزعة والعمل سويًا بشكل مباشر (وجهاً لوجه).\n\n\n\n* **عدم توفر وقت أو موارد كافية:** ينطبق هذا بشكلٍ خاص على المشرفين على المشاريع التطوعية، الذين يضطرون إلى التضحية بوقت فراغهم للعمل على المشروع.\n\n\n\n* **المطالب المتعارضة:** مشاريع المصدر المفتوح مليئة بمجموعات ذات دوافع مختلفة، قد يكون من الصعب التوفيق بينها. وإذا كنت تتقاضى أجرًا مقابل عملك في المصدر المفتوح، فقد تتعارض أحيانًا مصالح جهة عملك مع المجتمع.\n\n\n\n### احذر من علامات الإرهاق\n\nهل يمكنك الحفاظ على وتيرتك لمدة 10 أسابيع؟ 10 أشهر؟ 10 سنوات؟\n\nتوجد أدوات مثل قائمة التحقق من الإرهاق [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) من [@shaunagm](https://github.com/shaunagm) التي يمكن أن تساعدك على التأمل في وتيرتك الحالية ومعرفة ما إذا كان بإمكانك إجراء أي تعديلات. يستخدم بعض المشرفين أيضًا الأجهزة القابلة للارتداء (wearable technology) لتتبع مقاييس مثل جودة النوم وتقلّب معدل ضربات القلب (كلاهما مرتبط بالتوتر).\n\n\n\n### ما الذي تحتاجه للاستمرار في دعم نفسك ومجتمعك؟\n\nسيختلف ذلك من مشرف لآخر، وسيتغير حسب مراحل حياتك والعوامل الخارجية، ولكن إليك بعض المواضيع التي سمعناها:\n\n* **الاعتماد على المجتمع:** التفويض وإيجاد مساهمين يمكن أن يخفف من عبء العمل. وجود عدة نقاط اتصال للمشروع يساعدك على أخذ استراحة دون قلق. تواصل مع مشرفين آخرين والمجتمع الأوسع – في مجموعات مثل مجتمع المشرفين [Maintainer Community](http://maintainers.github.com/). يمكن أن تكون هذه المجتمعات مصدرًا رائعًا للدعم والتعلّم المتبادل.\n\n يمكنك أيضًا البحث عن طرق للتفاعل مع مجتمع المستخدمين، لتسمع الملاحظات بانتظام وتفهم تأثير عملك في مشاريع مفتوحة المصدر.\n\n* **استكشاف التمويل:** سواء كنت تبحث عن بعض المال لشراء \"بيتزا\" 🍕، أو تحاول الانتقال إلى المشاريع مفتوحة المصدر بدوام كامل، فهناك العديد من الموارد للمساعدة! كخطوة أولى، فكر في تفعيل [GitHub Sponsors](https://github.com/sponsors) للسماح للآخرين برعاية عملك. إذا كنت تفكر في الانتقال إلى العمل بدوام كامل، قدّم طلبًا للانضمام إلى [GitHub Accelerator](http://accelerator.github.com/).\n\n\n\n* **استخدام الأدوات:** استكشف أدوات مثل [GitHub Copilot](https://github.com/features/copilot/) و [GitHub Actions](https://github.com/features/actions) لأتمتة المهام الروتينية وتحرير وقتك للمساهمات الأكثر أهمية.\n\n\n\n* **الراحة وإعادة الشحن:** خصص وقتًا لهواياتك واهتماماتك خارج المشاريع مفتوحة المصدر. خذ عطلات نهاية الأسبوع للاسترخاء وتجديد النشاط، واضبط حالتك على [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) لتعكس مدى توفرك! النوم الجيد لليلة واحدة يمكن أن يحدث فرقًا كبيرًا في قدرتك على الاستمرار على المدى الطويل.\n\n إذا وجدت أن جوانب معينة من مشروعك ممتعة بشكل خاص، فحاول هيكلة عملك بحيث يمكنك تجربتها على مدار يومك.\n\n\n\n* **وضع الحدود:** لا يمكنك قول \"نعم\" لكل طلب. يمكن أن يكون ذلك ببساطة بقولك: \"لا أستطيع القيام بذلك الآن، وليس لدي خطط لذلك في المستقبل.\" أو سرد ما تهتم بفعله وما لا تهتم بفعله في ملف README. على سبيل المثال، يمكنك أن تقول: \"أنا أدمج فقط طلبات (PRs) التي تشرح بوضوح سبب إنشائها\" أو \"أنا أراجع المشكلات فقط في أيام الخميس البديلة من الساعة 6 إلى 7 مساءً.”هذا يحدد التوقعات للآخرين، ويمنحك شيئًا للإشارة إليه في الأوقات الأخرى للمساعدة في تخفيف المطالب التي يفرضها المساهمون أو المستخدمون على وقتك.\n\n\n\nتعلم أن تكون حازمًا في إيقاف السلوك السام والتفاعلات السلبية. لا بأس ألا تمنح طاقتك للأشياء التي لا تهتم بها.\n\n\n\n\n\nتذكر، أن البيئة الشخصية (personal ecology) هي ممارسة مستمرة ستتطور مع تقدمك في رحلة المشاريع مفتوحة المصدر. من خلال إعطاء الأولوية للرعاية الذاتية والحفاظ على الشعور بالتوازن، يمكنك المساهمة في مجتمع open sources بفعالية واستدامة، مما يضمن رفاهيتك ونجاح مشاريعك على المدى الطويل.\n\n## مصادر إضافية\n\n* [مجتمع المشرفين](http://maintainers.github.com/)\n* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon\n* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg\n* [كيفية التعامل مع الأشخاص السامين](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge\n* [SustainOSS](https://sustainoss.org/)\n* [فن القيادة من روكوود](https://rockwoodleadership.org/art-of-leadership/)\n* [قول لا](https://mikemcquaid.com/saying-no/)\n* تم إعداد جدول الورشة بالاستناد إلى سلسلة [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/)\n\n## المساهمون\n\nجزيل الشكر لجميع المشرفين الذين شاركوا تجاربهم ونصائحهم معنا في هذا الدليل!\n\nكتب هذا الدليل بواسطة @abbycabs بمساهمات من:\n\n[@agnostic-apollo](https://github.com/agnostic-apollo)\n[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)\n[@antfu](https://github.com/antfu)\n[@anthonyronda](https://github.com/anthonyronda)\n[@CBID2](https://github.com/CBID2)\n[@Cli4d](https://github.com/Cli4d)\n[@confused-Techie](https://github.com/confused-Techie)\n[@danielroe](https://github.com/danielroe)\n[@Dexters-Hub](https://github.com/Dexters-Hub)\n[@eddiejaoude](https://github.com/eddiejaoude)\n[@Eugeny](https://github.com/Eugeny)\n[@ferki](https://github.com/ferki)\n[@gabek](https://github.com/gabek)\n[@geromegrignon](https://github.com/geromegrignon)\n[@hynek](https://github.com/hynek)\n[@IvanSanchez](https://github.com/IvanSanchez)\n[@karasowles](https://github.com/karasowles)\n[@KoolTheba](https://github.com/KoolTheba)\n[@leereilly](https://github.com/leereilly)\n[@ljharb](https://github.com/ljharb)\n[@nightlark](https://github.com/nightlark)\n[@plarson3427](https://github.com/plarson3427)\n[@Pradumnasaraf](https://github.com/Pradumnasaraf)\n[@RichardLitt](https://github.com/RichardLitt)\n[@rrousselGit](https://github.com/rrousselGit)\n[@sansyrox](https://github.com/sansyrox)\n[@schlessera](https://github.com/schlessera)\n[@shyim](https://github.com/shyim)\n[@smashah](https://github.com/smashah)\n[@ssalbdivad](https://github.com/ssalbdivad)\n[@The-Compiler](https://github.com/The-Compiler)\n[@thehale](https://github.com/thehale)\n[@thisisnic](https://github.com/thisisnic)\n[@tudoramariei](https://github.com/tudoramariei)\n[@UlisesGascon](https://github.com/UlisesGascon)\n[@waldyrious](https://github.com/waldyrious) + وغيرهم الكثير!\n\n
\n" }, { "path": "_articles/ar/metrics.md", "content": "---\nlang: ar\ntitle: مقاييس المشاريع مفتوحة المصدر\ndescription: اتخذ قرارات مستنيرة لمساعدة مشروعك مفتوح المصدر على الازدهار من خلال قياس وتتبع نجاحه\nclass: metrics\norder: 9\nimage: /assets/images/cards/metrics.png\nrelated:\n - finding\n - best-practices\n---\n\n
\n\n## لماذا نقيس أي شيء؟\n\nيمكن أن تساعدك البيانات، عند استخدامها بحكمة، على اتخاذ قرارات أفضل بصفتك مسؤول مصدر مفتوح.\n\nمع مزيد من المعلومات، يمكنك:\n\n* فهم كيفية استجابة المستخدمين لميزة جديدة\n* معرفة مصدر المستخدمين الجدد\n* تحديد حالات الاستخدام أو الوظائف الشاذة واتخاذ قرار بشأن دعمها\n* قياس شهرة مشروعك\n* فهم كيفية استخدام مشروعك\n* جمع الأموال من خلال الرعاية والمنح\n\nعلى سبيل المثال, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) يجدون أن Google Analytics يساعدهم في تحديد أولويات العمل:\n\n> يتم توفير Homebrew مجانًا ويتم تشغيله بالكامل من قبل متطوعين في أوقات فراغهم. ونتيجة لذلك، لا تتوفر لدينا الموارد اللازمة لإجراء دراسات مفصلة عن مستخدمي Homebrew لتحديد أفضل طريقة لتصميم الميزات المستقبلية وتحديد أولويات العمل الحالي. تسمح لنا تحليلات المستخدمين المجمعة المجهولة الهوية بتحديد أولويات الإصلاحات والميزات بناءً على كيفية ومكان وزمان استخدام الأشخاص لـ Homebrew.\n\nالشهرة ليست كل شيء. كل شخص ينضم إلى مجتمع المصادر المفتوحة لأسباب مختلفة. إذا كان هدفك كمسؤول عن المصادر المفتوحة هو التباهي بعملك، أو أن تكون شفافًا بشأن الكود الخاص بك، أو مجرد الاستمتاع، فقد لا تكون المقاييس مهمة بالنسبة لك.\n\nإذا كنت مهتمًا بفهم مشروعك على مستوى أعمق، فتابع القراءة لتتعرف على طرق تحليل نشاط مشروعك.\n\n## الاكتشاف\n\nقبل أن يتمكن أي شخص من استخدام مشروعك أو المساهمة فيه، يجب أن يعرف بوجوده. اسأل نفسك: _هل يجد الناس هذا المشروع؟_\n\n![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)\n\nإذا كان مشروعك مستضافًا على GitHub, [يمكنك مشاهدة](https://help.github.com/articles/about-repository-graphs/#traffic) عدد الأشخاص الذين يزورون مشروعك ومن أين يأتون. من صفحة مشروعك، انقر على \"Insights\"، ثم \"Traffic\". في هذه الصفحة، يمكنك رؤية:\n\n* **إجمالي عدد مشاهدات الصفحة:** يخبرك بعدد مرات مشاهدة مشروعك\n\n* **إجمالي عدد الزوار الفريدين:** يخبرك بعدد الأشخاص الذين شاهدوا مشروعك\n\n* **المواقع المرجعية:** يخبرك من أين جاء الزوار. يمكن أن تساعدك هذه المقياس في معرفة أين يمكنك الوصول إلى جمهورك وما إذا كانت جهودك الترويجية تؤتي ثمارها.\n\n* **المحتوى الشائع:** يخبرك أين يذهب الزوار في مشروعك، موزعًا حسب عدد مرات مشاهدة الصفحة والزوار الفريدين.\n\n[نجوم GitHub](https://help.github.com/articles/about-stars/) يمكن أن تساعد أيضًا في توفير مقياس أساسي للشهرة. على الرغم من أن نجوم GitHub لا ترتبط بالضرورة بالتنزيلات والاستخدام، إلا أنها يمكن أن تخبرك بعدد الأشخاص الذين ينتبهون إلى عملك.\n\nقد ترغب أيضًا في [تتبع إمكانية الاكتشاف في أماكن محددة](https://opensource.com/business/16/6/pirate-metrics): على سبيل المثال، Google PageRank، أو حركة المرور المرجعية من موقع الويب الخاص بمشروعك، أو الإحالات من مشاريع أو مواقع ويب أخرى مفتوحة المصدر.\n\n## الاستخدام\n\nيجد الناس مشروعك على هذا الشيء الجامح والمجنون الذي نسميه الإنترنت. في الحالة المثالية، عندما يرون مشروعك، سيشعرون برغبة ملحة في القيام بشيء ما. السؤال الثاني الذي سترغب في طرحه هو: _هل يستخدم الناس هذا المشروع؟_\n\nإذا كنت تستخدم مدير حزم، مثل npm أو RubyGems.org، لتوزيع مشروعك، فقد تتمكن من تتبع تنزيلات مشروعك.\n\nقد يستخدم كل مدير حزم تعريفًا مختلفًا قليلاً لمصطلح \"تنزيل\"، ولا يرتبط التنزيل بالضرورة بالتثبيت أو الاستخدام، ولكنه يوفر أساسًا للمقارنة. جرب استخدام [Libraries.io](https://libraries.io/) لتتبع إحصائيات الاستخدام عبر العديد من برامج إدارة الحزم الشائعة.\n\nإذا كان مشروعك موجودًا على GitHub، فانتقل مرة أخرى إلى صفحة \"Traffic\". يمكنك استخدام [clone graph](https://github.com/blog/1873-clone-graphs) لمعرفة عدد المرات التي تم فيها نسخ مشروعك في يوم معين، مقسمة حسب إجمالي النسخ والمستنسخين الفريدين.\n\n![Clone graph](/assets/images/metrics/clone_graph.png)\n\nإذا كان الاستخدام منخفضًا مقارنة بعدد الأشخاص الذين يكتشفون مشروعك، فهناك مسألتان يجب أخذهما في الاعتبار. إما:\n\n* مشروعك لا ينجح في تحويل جمهورك، أو\n* أنت تجذب الجمهور الخطأ\n\nعلى سبيل المثال، إذا ظهر مشروعك على الصفحة الأولى من Hacker News، فمن المحتمل أن تشهد ارتفاعًا في الاكتشاف (traffic)، ولكن معدل تحويل أقل، لأنك تصل إلى جميع مستخدمي Hacker News. ولكن إذا تم عرض مشروع Ruby الخاص بك في مؤتمر Ruby، فمن المرجح أن تشهد معدل تحويل مرتفعًا من الجمهور المستهدف.\n\nحاول معرفة من أين يأتي جمهورك واطلب من الآخرين إبداء آرائهم حول صفحة مشروعك لمعرفة أي من هاتين المشكلتين تواجهها.\n\nبمجرد أن تعرف أن الناس يستخدمون مشروعك، قد ترغب في محاولة معرفة ما يفعلون به. هل يبنون عليه عن طريق تفرع الكود الخاص بك وإضافة ميزات؟ هل يستخدمونه في مجال العلوم أو الأعمال؟\n\n## الاحتفاظ\n\nالناس يجدون مشروعك ويستخدمونه. السؤال التالي الذي ستطرحه على نفسك هو: _هل يساهم الناس في هذا المشروع؟_\n\nليس من المبكر أبدًا البدء في التفكير في المساهمين. بدون مساهمة الآخرين، فإنك تخاطر بوضع نفسك في موقف غير صحي حيث يكون مشروعك _شائعًا_ (يستخدمه الكثير من الناس) ولكنه غير _مدعوم_ (لا يوجد وقت كافٍ للمسؤولين عن الصيانة لتلبية الطلب).\n\nالاحتفاظ يتطلب أيضًا [تدفق مساهمين جدد](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), لأن المساهمين النشطين سابقًا سينتقلون في النهاية إلى أمور أخرى.\n\nمن الأمثلة على المقاييس المجتمعية التي قد ترغب في تتبعها بانتظام ما يلي:\n\n* **إجمالي عدد المساهمين وعدد الالتزامات لكل مساهم:** يخبرك بعدد المساهمين لديك، ومن منهم أكثر أو أقل نشاطًا. على GitHub، يمكنك عرض ذلك تحت \"Insights\" -> \"Contributors\". في الوقت الحالي، لا يحسب هذا المخطط سوى المساهمين الذين التزموا بالفرع الافتراضي للمستودع.\n\n![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)\n\n* **المساهمون الجدد والعرضيون والمتكررون:** يساعدك على تتبع ما إذا كنت تحصل على مساهمين جدد، وما إذا كانوا يعودون. (المساهمون العرضيون هم المساهمون الذين لديهم عدد قليل من الالتزامات. سواء كان ذلك التزامًا واحدًا، أو أقل من خمسة التزامات، أو أي شيء آخر، فهذا الأمر متروك لك). بدون مساهمين جدد، يمكن أن يصبح مجتمع مشروعك راكدًا.\n\n* **عدد المشكلات المفتوحة وطلبات السحب المفتوحة:** إذا ارتفعت هذه الأرقام بشكل كبير، فقد تحتاج إلى مساعدة في فرز المشكلات ومراجعة الأكواد.\n\n* **عدد المشكلات _المفتوحة_ وطلبات السحب _المفتوحة_:** المشكلات المفتوحة تعني أن هناك من يهتم بمشروعك لدرجة أنه فتح مشكلة. إذا زاد هذا العدد بمرور الوقت، فهذا يشير إلى أن الناس مهتمون بمشروعك.\n\n* **أنواع المساهمات:** على سبيل المثال، الالتزامات، إصلاح الأخطاء المطبعية أو الأخطاء البرمجية، أو التعليق على مشكلة ما.\n\n\n\n## نشاط المسؤول\n\nأخيرًا، سترغب في إغلاق الحلقة بالتأكد من أن القائمين على صيانة مشروعك قادرون على التعامل مع حجم المساهمات الواردة. السؤال الأخير الذي سترغب في طرحه على نفسك هو: _هل أنا (أو نحن) نستجيب لمجتمعنا؟_\n\nيصبح المسؤولون غير المستجيبون عقبة أمام مشاريع المصادر المفتوحة. إذا قدم شخص ما مساهمة ولكنه لم يتلق أي رد من المسؤول، فقد يشعر بالإحباط ويغادر.\n\n[بحث من Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) يشير إلى أن استجابة المسؤولين عامل حاسم في تشجيع تكرار المساهمات.\n\nضع في اعتبارك [تتبع المدة التي تستغرقها أنت (أو أي مسؤول آخر) للرد على المساهمات](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), سواء كانت مشكلة أو طلب سحب. لا يتطلب الرد اتخاذ أي إجراء. يمكن أن يكون الأمر بسيطًا مثل: _\"شكرًا على إرسالك! سأراجعه خلال الأسبوع المقبل.\"_\n\nيمكنك أيضًا قياس الوقت الذي يستغرقه الانتقال بين مراحل عملية المساهمة، مثل:\n\n* متوسط الوقت الذي تظل فيه المشكلة مفتوحة\n* ما إذا كانت المشكلات يتم إغلاقها بواسطة PRs\n* ما إذا كانت المشكلات القديمة يتم إغلاقها\n* متوسط الوقت اللازم لدمج طلب السحب\n\n## استخدم 📊 للتعرف على الأشخاص\n\nسيساعدك فهم المقاييس على بناء مشروع مفتوح المصدر نشط ومتنامي. حتى إذا لم تقم بتتبع كل مقياس على لوحة المعلومات، استخدم الإطار أعلاه لتركيز انتباهك على نوع السلوك الذي سيساعد مشروعك على الازدهار.\n\n[CHAOSS](https://chaoss.community/) هي مجتمع مفتوح المصدر ومرحب يركز على التحليلات والمقاييس والبرمجيات الخاصة بصحة المجتمع.\n\n
\n" }, { "path": "_articles/ar/security-best-practices-for-your-project.md", "content": "---\nlang: ar\ntitle: أفضل ممارسات الأمان لمشروعك\ndescription: عزز مستقبل مشروعك من خلال بناء الثقة من خلال الممارسات الأمان الأساسية — من MFA و مسح الكود الى الادارة الأمنة للتبعيات وإعداد تقارير الثغرات الأمنية الخاصة\nclass: security-best-practices\norder: -1\nimage: /assets/images/cards/security-best-practices.png\n---\n\n
\n\nبغض النظر عن الأخطاء والميزات الجديدة، فإن طول عمر المشروع لا يتوقف فقط على فائدته ولكن أيضًا على الثقة التي يكتسبها من مستخدميه.من الضروري جدا اتخاذ تدابير أمنية قوية للحفاظ على هذه الثقة حية. فيما يلي بعض الإجراءات المهمة التي يمكنك اتخاذها لتحسين أمان مشروعك بشكل كبير.\n\n## تأكد من أن جميع المساهمين أصحاب الامتيازات قد قاموا بتمكين المصادقة متعددة العوامل (MFA)\n\n### ممثل خبيث يتمكن من انتحال شخصية مساهم ذو امتيازات في مشروعك، سوف يتسبب في أضرار كارثية.\n\nبمجرد حصوله على حق الوصول المميز، يمكن لهذا الفاعل تعديل الكود الخاص بك لجعله يقوم بإجراءات غير مرغوب فيها (على سبيل المثال، تعدين العملة المشفرة),أو يمكنه نشر البرامج الضارة على البنية التحتية لمستخدميك،أو يمكنه الوصول إلى ملفات الكود علىGithub لاستخراج الملكية الفكرية والبيانات الحساسة، بما في ذلك مفاتيح الوصول إلى خدمات أخرى. \n\nMFA توفر طبقة اضافية من الأمان ضد سؤقة الحساب. عندما تفعل يجب أن تسجل الدخول باسم مستخدمك وكلمة المرور بالاضافة الى شكل أخر من المصادقة أنت فقط تعرفه أو تستطيع الوصول إليه.\n\n## قم بتأمين الكود الخاص بك كجزء من سير عمل التطوير الخاص بك\n\n### يعد إصلاح الثغرات الأمنية في كودك أرخص عند اكتشافها في وقت مبكر من العملية مقارنةً بوقت لاحق، عند استخدامها في production.\n\nاستخدم أداة اختبار أمان التطبيق الثابت (SAST) للكشف عن الثغرات الأمنية في الكود الخاص بك. تعمل هذه الأدوات على مستوى الكود ولا تحتاج إلى بيئة تنفيذ، وبالتالي يمكن تنفيذها في وقت مبكر من العملية، ويمكن دمجها بسلاسة في سير عمل التطوير المعتاد لديك، أثناء البناء أو أثناء مراحل مراجعة الكود.\n\nإنه مثل قيام خبير ماهر بإلقاء نظرة على ملف كودك ، مما يساعد في العثور على الثغرات الأمنية الشائعة التي قد تكون مختبئة على مرأى من الجميع أثناء البرمجة.\n\nكيف تختار أداة SAST\nتأكد من التعليمات: بعض الأدوات مجانية للمشاريع مفتوحة المصدر. على سبيل المثال Github CodeQl, SemGrep.\nتأكد من تغطيتها للغاتك البرمجة.\n\n* اختر واحدا يتكامل بسهولة مع الأدوات التي تستخدمها بالفعل, ومع عمليتك الحالية. على سبيل المثال , من ألأفضل أن تكون التنبيهات متاحة كجزء من عملية وأداة مراحعة كودك الحالي بدلا من الانتقال الى أداة أحرى لرؤيتها.\n* احذر من الإيجابيات الكاذبة! أنت لا تريد أن تبطئك الأداة دون سبب!\n* تحقّق من المزايا: بعض الأدوات قوية جدًا ويمكنها تنفيذ taint tracking (مثل GitHub CodeQL)، وبعضها يقترح AI-generated fix suggestions، وأخرى تسهّل كتابة custom queries (مثل SemGrep).\n\n## لا تشارك أسرارك\n\n### بيانات حساسة مثل API keys,tokens, passwords قد تذهب بالخطأ في بعض الأحيان إلى Github repository.\n\nتخيّل هذا السيناريو: أنت الـ maintainer لمشروع مفتوح المصدر مشهور يشارك فيه مطورون من جميع أنحاء العالم، وفي أحد الأيام يقوم مساهم عن غير قصد بعمل commit يحتوي على بعض مفاتيح الـ API الخاصة بخدمة خارجية، وبعد أيام يجد أحدهم هذه المفاتيح ويستخدمها للوصول إلى الخدمة دون إذن، فتتعرض الخدمة للاختراق، ويواجه مستخدمو مشروعك فترة توقف، وتتضرر سمعة مشروعك، والآن بصفتك الـ maintainer عليك التعامل مع مهام مرهقة مثل إلغاء المفاتيح المخترقة، والتحقيق في الأفعال الضارة التي قد نفذها المهاجم باستخدامها، وإبلاغ المستخدمين المتأثرين، وتنفيذ الإصلاحات اللازمة.\n\nلمنع حوادث كهذه، حلول \"secret scanning\" موجودة لتساعد للكشف المبكر لأسرار كهذه في كودك. بعض الأدات ك Github Secret Scanning و Trufflehog تتستطيع أن تمنعك من وضع هذه الأشياء على remote branches في المقام الأول, وبعض الأدوات ستزيل هذه الأسرار بشكل تلقائي لك.\n\n## تحقّق من التبعيات الخاصة بك وقم بتحديثها\n\n### Dependencies في مشروعك ممكن أن تحتوي على ثغرات قد تخترقه. القيام بتحديث الDependencies يدويا باليد ستكون مهمة مستهلكة للوقت.\n\nتخيل هذا: مشروع مبني على أساس قوي لمكتبة مستخدمة على نطاق واسع , لاحقا المكتبة تواجه مشكلة أمنية كبيرة.لكن الناس الذين بنوا المشروع باستخدامها لا يعرفون عن هذه المشكلة. تُترك بيانات المستخدم الحساسة مكشوفة عندما يستغل المهاجم هذا الضعف، فينقض عليها للاستيلاء عليها. هذا ليس مثالا نظريا انما ما حدث تماما في في 2017.لقد فشلوا في تحديث Apache Struts dependeny الخاص بهم بعد اشعارهم عن وجود ثغرة في الخادم.لقد تم استغلال هذه الثغرة، وأثرت عملية الاختراق الشهيرة لشركة Equifax على بيانات 144 مليون مستخدم. \n\nلمنع سيناريوهات كهذه, أدوات تحليل تكوين البرمجيات (SCA) مثل Dependabot,Renvate تتحقق بشكل تلقائي من Dependencies الخاصة بك لأكثر الثغرات انتشارا في قواعد البيانات العامة مثل NVD,the Github Advisory Database ثم تنشأ pull requests لتحديثهم لأخر نسخ. مواكبة أخر التحديثات لل Dependencies الخاصة بمشروعك تحميه وتمنعه من المخاطر المحتملة.\n\n## تجنّب التغيّرات غير المرغوبة باستخدام الفروع المحمية\n\n### يمكن أن يؤدي الوصول غير المقيد لmain branch إلى تغييرات عرضية التي قد تنتج ثغرات أمنية وتعطل استقرار مشروعك\n\n مساهم جديد يحصل على حق التعديل على main branch وعرضا يقوم برفع تعديلات جديدة لم تختبر بعد. ثم يتم الكشف عن خلل أمني خطير بسبب التغييرات الأخيرة. لمنع مشاكل كهذه, قواعد حماية ال branch تضمن عدم رفع أو دمج تغييرات للmain branches دون الخضوع أولاً للمراجعات واجتياز فحوصات الحالة المحددة.أنت أكثر أمانًا وأفضل مع تطبيق هذا الإجراء الإضافي، مما يضمن جودة عالية في كل مرة.\n\n## إنشاء آلية استقبال للإبلاغ عن نقاط الضعف\n\n### من الجيد أن تتيح لمستخدميك الإبلاغ عن الأخطاء بسهولة، لكن السؤال الأهم هو: عندما يكون لهذا الخطأ تأثير أمني، كيف يمكنهم الإبلاغ عنه بأمان دون أن يجعلوك هدفًا محتملاً للمتسللين الخبيثين؟\n\nتخيّل هذا: يكتشف باحث أمني ثغرة في مشروعك لكنه لا يجد طريقة واضحة أو آمنة للإبلاغ عنها، وبدون وجود عملية محددة، قد ينشئ issue عام أو يناقشها علنًا على وسائل التواصل الاجتماعي. حتى لو كانت نيته حسنة وقدّم إصلاحًا، إذا فعل ذلك من خلال public pull request، سيراه الآخرون قبل دمجه! هذا الكشف العلني سيعرّض الثغرة للمهاجمين قبل أن تتمكن من معالجتها، مما قد يؤدي إلى zero-day exploit يهاجم مشروعك ومستخدميه.\n\n### سياسة الأمان\n\nلتجنب ذلك، قم بنشر سياسة أمان. تُعرّف سياسة الأمان في ملف `SECURITY.md`، وتوضح الخطوات اللازمة للإبلاغ عن المخاوف الأمنية، وتُنشئ عملية واضحة للكشف المنظم، وتحدد مسؤوليات فريق المشروع في معالجة القضايا المُبلّغ عنها. يمكن أن تكون سياسة الأمان بسيطة مثل: \"يرجى عدم نشر التفاصيل في issue أو public pull request، أرسلوا لنا بريدًا إلكترونيًا خاصًا علىsecurity@example.com\"، لكنها يمكن أن تتضمن أيضًا تفاصيل أخرى مثل متى يمكنهم توقع الحصول على رد منكم. أي شيء يمكن أن يُسهم في تعزيز فعالية وكفاءة عملية الكشف.\n\n### الإبلاغ عن الثغرات بشكل خاص\n\nعلى بعض المنصات، يمكنك تبسيط وتعزيز عملية إدارة الثغرات الأمنية لديك، من الاستلام إلى النشر، باستخدام private issues. على GitLab يمكن فعل ذلك باستخدام private issues، أما على GitHub فهذه العملية تُسمى private vulnerability reporting (PVR). تتيح PVR للـ maintainers استقبال ومعالجة تقارير الثغرات كلها ضمن منصة GitHub، حيث يقوم GitHub تلقائيًا بإنشاء private fork لكتابة الإصلاحات، وdraft security advisory. كل هذا يبقى سريًا حتى تقرر الكشف عن الثغرات وإصدار الإصلاحات. لإغلاق الحلقة، سيتم نشر security advisories لإبلاغ وحماية جميع مستخدميك عبر أداة SCA الخاصة بهم.\n\n## الخلاصة: خطوات قليلة منك، لكنها تُحدث فرقًا كبيرًا لمستخدميك.\n\nقد تبدو هذه الخطوات بسيطة أو عادية بالنسبة لك، لكنها تُحدث فرقًا كبيرًا في جعل مشروعك أكثر أمانًا لمستخدميه، لأنها تُوفر حماية فعّالة ضد أكثر المشكلات شيوعًا.\n\n## المساهمون\n\n### جزيل الشكر لجميع المشرفين الذين شاركوا تجاربهم ونصائحهم معنا في إعداد هذا الدليل!\n\nتم كتابة هذا الدليل بواسطة [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) بمشاركة مساهمي من:\n\n[@JLLeitschuh](https://github.com/JLLeitschuh)\n[@intrigus-lgtm](https://github.com/intrigus-lgtm) + آخرون \n\n
\n" }, { "path": "_articles/ar/starting-a-project.md", "content": "---\nlang: ar\ntitle: البدء بمشروع مفتوح المصدر\ndescription: تعلّم المزيد عن عالم المصادر المفتوحة واستعد لإطلاق مشروعك الخاص\nclass: beginners\norder: 2\nimage: /assets/images/cards/beginner.png\nrelated:\n - finding\n - building\n---\n\n
\n\n## الـ\"ماذا\" و\"لماذا\" في المشاريع مفتوحة المصدر\n\nإذًا، أنت تفكر في البدء بالمصادر المفتوحة؟ تهانينا! العالم يقدّر مساهمتك. دعنا نتحدث عن ماهية المصادر المفتوحة ولماذا يفعل الناس ذلك.\n\n### ماذا يعني \"مفتوح المصدر\"؟\n\nعندما يكون المشروع مفتوح المصدر، فهذا يعني **أن أي شخص حر في استخدام مشروعك ودراسته وتعديله وتوزيعه لأي غرض.** يتم فرض هذه الأذونات من خلال [ترخيص مفتوح المصدر](https://opensource.org/licenses).\n\nالمصدر المفتوح قوي لأنه يخفض حواجز التبني والتعاون، مما يسمح للناس بنشر المشاريع وتحسينها بسرعة. كما أنه يمنح المستخدمين إمكانية التحكم في حوسبتهم الخاصة، مقارنةً بالمصادر المغلقة. على سبيل المثال، الشركة التي تستخدم برامج مفتوحة المصدر لديها خيار توظيف شخص ما لإجراء تحسينات مخصصة على البرنامج، بدلاً من الاعتماد حصريًا على قرارات منتج بائع vendor المصادر المغلقة.\n\nيشير Free software إلى نفس مجموعة المشاريع مثل open source. أحيانًا ستجد هذين المصطلحين مجتمعين في عبارة \"free and open source software (FOSS)\" أو \"free, libre, and open source software (FLOSS)\". كلمتا Free و Libre هنا تدلان على الحرية وليس السعر.\n\n### لماذا يفتح الناس مصدر أعمالهم؟\n\n\n\n[هناك العديد من الأسباب](https://ben.balter.com/2015/11/23/why-open-source/) التي قد تجعل شخصًا أو منظمة يرغب في فتح مصدر مشروع. بعض الأمثلة تشمل:\n\n* **التعاون:** يمكن لمشاريع المصادر المفتوحة قبول التغييرات من أي شخص في العالم. [Exercism](https://github.com/exercism/)، على سبيل المثال، هي منصة تمارين برمجية تضم أكثر من 350 مساهمًا.\n\n* **التبني والاقتباس:** يمكن لأي شخص استخدام مشاريع المصادر المفتوحة لأي غرض تقريبًا. يمكن للناس حتى استخدامها لبناء أشياء أخرى. [WordPress](https://github.com/WordPress)، على سبيل المثال، بدأ كـ fork لمشروع موجود يسمى [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).\n\n* **الشفافية:** يمكن لأي شخص فحص مشروع مفتوح المصدر بحثًا عن أخطاء أو تناقضات. الشفافية مهمة للحكومات مثل [بلغاريا](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) أو [الولايات المتحدة](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/)، والصناعات المنظمة مثل البنوك أو الرعاية الصحية، وبرامج الأمان مثل [Let's Encrypt](https://github.com/letsencrypt).\n\nالمصادر المفتوحة ليست للبرمجيات فقط. يمكنك فتح مصدر كل شيء من مجموعات البيانات إلى الكتب. راجع [GitHub Explore](https://github.com/explore) للأفكار حول ما يمكنك فتح مصدره.\n\n### هل مفتوح المصدر يعني \"مجاني\"؟\n\nأحد أكبر عوامل الجذب للمصادر المفتوحة هو أنها لا تكلف مالاً. ومع ذلك، فإن \"المجانية\" هي مجرد نتيجة ثانوية للقيمة الإجمالية للمصادر المفتوحة.\n\nنظرًا لأن [ترخيص المصدر المفتوح يتطلب](https://opensource.org/definition-annotated/) أن يتمكن أي شخص من استخدام مشروعك وتعديله ومشاركته لأي غرض تقريبًا، فإن المشاريع نفسها تميل إلى أن تكون مجانية. إذا كان المشروع يكلف مالاً لاستخدامه، يمكن لأي شخص قانونيًا عمل نسخة واستخدام النسخة المجانية بدلاً من ذلك.\n\nونتيجة لذلك، فإن معظم مشاريع المصادر المفتوحة مجانية، لكن \"المجانية\" ليست جزءًا من تعريف المصدر المفتوح. هناك طرق لفرض رسوم على مشاريع المصادر المفتوحة بشكل غير مباشر من خلال الترخيص المزدوج dual licensing أو الميزات المحدودة limited features، مع الالتزام بالتعريف الرسمي للمصادر المفتوحة.\n\n## هل يجب أن أطلق مشروعي مفتوح المصدر الخاص؟\n\nالإجابة القصيرة هي نعم، لأنه بغض النظر عن النتيجة، فإن إطلاق مشروعك الخاص هو طريقة رائعة لتعلم كيفية عمل المصادر المفتوحة.\n\nإذا لم تفتح مصدر مشروع من قبل، فقد تكون متوترًا بشأن ما سيقوله الناس، أو ما إذا كان أي شخص سيلاحظ على الإطلاق. إذا كان هذا يبدو مثلك، فأنت لست وحدك!\n\nعمل المصادر المفتوحة يشبه أي نشاط إبداعي آخر، سواء كان الكتابة أو الرسم. قد يبدو من المخيف مشاركة عملك مع العالم، لكن الطريقة الوحيدة لتحسين مهاراتك هي الممارسة - حتى لو لم يكن لديك جمهور.\n\nإذا لم تكن مقتنعًا بعد، خذ لحظة للتفكير في ما قد تكون أهدافك.\n\n### تحديد أهدافك\n\nيمكن أن تساعدك الأهداف في معرفة ما يجب العمل عليه، وما يجب قول \"لا\" له، وأين تحتاج إلى مساعدة من الآخرين. ابدأ بسؤال نفسك، _لماذا أفتح مصدر هذا المشروع؟_\n\nلا توجد إجابة صحيحة واحدة على هذا السؤال. قد يكون لديك أهداف متعددة لمشروع واحد، أو مشاريع مختلفة بأهداف مختلفة.\n\nإذا كان هدفك الوحيد هو إظهار عملك، فقد لا تريد حتى مساهمات، بل وحتى تقول ذلك في ملف README الخاص بك. من ناحية أخرى، إذا كنت تريد مساهمين، فستستثمر الوقت في توثيق واضح وجعل الوافدين الجدد يشعرون بالترحيب.\n\n\n\nمع نمو مشروعك، قد يحتاج مجتمعك إلى أكثر من مجرد كود منك. الرد على issues، ومراجعة الكود، والترويج لمشروعك كلها مهام مهمة في مشروع مفتوح المصدر.\n\nبينما تعتمد كمية الوقت الذي تقضيه في المهام غير البرمجية على حجم مشروعك ونطاقه، يجب أن تكون مستعدًا كمسؤول للتعامل معها بنفسك أو العثور على شخص لمساعدتك.\n\n**إذا كنت جزءًا من شركة تفتح مصدر مشروع،** تأكد من أن مشروعك لديه الموارد الداخلية التي يحتاجها للازدهار. ستحتاج إلى تحديد من المسؤول عن صيانة المشروع بعد الإطلاق، وكيف ستشارك هذه المهام مع مجتمعك.\n\nإذا كنت بحاجة إلى ميزانية مخصصة أو موظفين للترويج والعمليات وصيانة المشروع، ابدأ تلك المحادثات مبكرًا.\n\n\n\n### المساهمة في مشاريع أخرى\n\nإذا كان هدفك هو تعلم كيفية التعاون مع الآخرين أو فهم كيفية عمل المصادر المفتوحة، ففكر في المساهمة في مشروع موجود. ابدأ بمشروع تستخدمه وتحبه بالفعل. يمكن أن تكون المساهمة في مشروع بسيطة مثل إصلاح الأخطاء الإملائية أو تحديث التوثيق.\n\nإذا لم تكن متأكدًا من كيفية البدء كمساهم، تحقق من [دليل كيفية المساهمة في المشاريع مفتوحة المصدر](../how-to-contribute/).\n\n## إطلاق مشروعك مفتوح المصدر الخاص\n\nلا يوجد وقت مثالي لفتح مصدر عملك. يمكنك فتح مصدر فكرة، أو عمل قيد التقدم، أو بعد سنوات من كونه مصدرًا مغلقًا.\n\nبشكل عام، يجب عليك فتح مصدر مشروعك عندما تشعر بالراحة في أن يشاهد الآخرون عملك ويقدمون ملاحظات عليه.\n\nبغض النظر عن المرحلة التي تقرر فيها فتح مصدر مشروعك، يجب أن يتضمن كل مشروع التوثيق التالي:\n\n* [ترخيص المصدر المفتوح](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)\n* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)\n* [إرشادات المساهمة](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)\n* [قواعد السلوك](../code-of-conduct/)\n\nكمسؤول، ستساعدك هذه المكونات في توصيل التوقعات، وإدارة المساهمات، وحماية الحقوق القانونية للجميع (بما في ذلك حقوقك). تزيد بشكل كبير من فرص حصولك على تجربة إيجابية.\n\nإذا كان مشروعك على GitHub، فإن وضع هذه الملفات في دليلك الجذري بأسماء الملفات الموصى بها سيساعد GitHub على التعرف عليها وإظهارها تلقائيًا لقرائك.\n\n### اختيار ترخيص\n\nيضمن ترخيص المصدر المفتوح أن يتمكن الآخرون من استخدام مشروعك ونسخه وتعديله والمساهمة فيه دون عواقب. كما يحميك من المواقف القانونية اللزجة. **يجب عليك تضمين ترخيص عند إطلاق مشروع مفتوح المصدر.**\n\nالعمل القانوني ليس ممتعًا. الخبر السار هو أنه يمكنك نسخ ولصق ترخيص موجود في مستودعك. سيستغرق الأمر دقيقة واحدة فقط لحماية عملك الشاق.\n\n[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، و[GPLv3](https://choosealicense.com/licenses/gpl-3.0/) هي تراخيص المصادر المفتوحة الأكثر شعبية، لكن [هناك خيارات أخرى](https://choosealicense.com) للاختيار من بينها.\n\nعند إنشاء مشروع جديد على GitHub، يتم منحك خيار تحديد ترخيص. سيجعل تضمين ترخيص مفتوح المصدر مشروعك على GitHub مفتوح المصدر.\n\n![اختر ترخيصًا](/assets/images/starting-a-project/repository-license-picker.png)\n\nإذا كانت لديك أسئلة أو مخاوف أخرى حول الجوانب القانونية لإدارة مشروع مفتوح المصدر، [فنحن نغطيك](../legal/).\n\n### كتابة ملف README {#كتابة-ملف-README}\n\nتفعل ملفات README أكثر من مجرد شرح كيفية استخدام مشروعك. كما أنها تشرح لماذا مشروعك مهم، وماذا يمكن لمستخدميك فعله به.\n\nفي README الخاص بك، حاول الإجابة على الأسئلة التالية:\n\n* ماذا يفعل هذا المشروع؟\n* لماذا هذا المشروع مفيد؟\n* كيف أبدأ؟\n* أين يمكنني الحصول على مزيد من المساعدة، إذا كنت بحاجة إليها؟\n\nيمكنك استخدام README الخاص بك للإجابة على أسئلة أخرى، مثل كيفية التعامل مع المساهمات، وما هي أهداف المشروع، ومعلومات حول التراخيص والإسناد. إذا كنت لا تريد قبول المساهمات، أو أن مشروعك ليس جاهزًا بعد للإنتاج، اكتب هذه المعلومات.\n\n\n\nفي بعض الأحيان، يتجنب الناس كتابة README لأنهم يشعرون أن المشروع غير مكتمل، أو أنهم لا يريدون مساهمات. هذه كلها أسباب وجيهة جدًا لكتابة واحد.\n\nللمزيد من الإلهام، جرب استخدام دليل @dguo [\"اصنع README\"](https://www.makeareadme.com/) أو قالب @PurpleBooth [لملف README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) لكتابة README كامل.\n\nعند تضمين ملف README في الدليل الجذري، سيعرضه GitHub تلقائيًا على الصفحة الرئيسية للمستودع.\n\n### كتابة إرشادات المساهمة الخاصة بك {#كتابة-ارشادات-المساهمة-الخاصة-بك}\n\nيخبر ملف CONTRIBUTING جمهورك بكيفية المشاركة في مشروعك. على سبيل المثال، قد تتضمن معلومات حول:\n\n* كيفية تقديم تقرير عن خطأ (حاول استخدام [قوالب issue وpull request](https://github.com/blog/2111-issue-and-pull-request-templates))\n* كيفية اقتراح ميزة جديدة\n* كيفية إعداد بيئتك وتشغيل الاختبارات\n\nبالإضافة إلى التفاصيل التقنية، يُعد ملف CONTRIBUTING فرصة لتوصيل توقعاتك للمساهمات، مثل:\n\n* أنواع المساهمات التي تبحث عنها\n* خارطة طريقك أو رؤيتك للمشروع\n* كيف يجب (أو لا يجب) على المساهمين التواصل معك\n\nاستخدام نبرة دافئة وودية وتقديم اقتراحات محددة للمساهمات (مثل كتابة التوثيق، أو إنشاء موقع ويب) يمكن أن يقطع شوطًا طويلاً في جعل الوافدين الجدد يشعرون بالترحيب والحماس للمشاركة.\n\nعلى سبيل المثال، يبدأ [Active Admin](https://github.com/activeadmin/activeadmin/) [دليل المساهمة الخاص به](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) بـ:\n\n> أولاً، شكرًا لك على التفكير في المساهمة في Active Admin. إنه أشخاص مثلك الذين يجعلون Active Admin أداة رائعة.\n\nفي المراحل الأولى من مشروعك، يمكن أن يكون ملف CONTRIBUTING بسيطًا. يجب عليك دائمًا شرح كيفية الإبلاغ عن الأخطاء أو تقديم issues، وأي متطلبات تقنية (مثل الاختبارات) لتقديم مساهمة.\n\nمع مرور الوقت، قد تضيف أسئلة أخرى يتم طرحها بشكل متكرر إلى ملف CONTRIBUTING الخاص بك. كتابة هذه المعلومات يعني أن عددًا أقل من الناس سيسألك نفس الأسئلة مرارًا وتكرارًا.\n\nللمزيد من المساعدة في كتابة ملف CONTRIBUTING الخاص بك، راجع قالب دليل المساهمة لـ @nayafia [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) أو [\"كيفية بناء CONTRIBUTING.md\"](https://mozillascience.github.io/working-open-workshop/contributing/) لـ @mozilla.\n\nاربط ملف CONTRIBUTING الخاص بك من README، حتى يراه المزيد من الناس. إذا [وضعت ملف CONTRIBUTING في مستودع مشروعك](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)، فسيربط GitHub تلقائيًا إلى ملفك عندما ينشئ مساهم issue أو يفتح pull request.\n\n![إرشادات المساهمة](/assets/images/starting-a-project/Contributing-guidelines.jpg)\n\n### إنشاء قواعد السلوك\n\n\n\nأخيرًا، تساعد قواعد السلوك في وضع قواعد أساسية للسلوك لمشاركي مشروعك. هذا ذو قيمة خاصة إذا كنت تطلق مشروع مفتوح المصدر لمجتمع أو شركة. تمكّنك قواعد السلوك من تسهيل سلوك المجتمع الصحي والبنّاء، مما سيقلل من توترك كمسؤول.\n\nلمزيد من المعلومات، راجع [دليل قواعد السلوك](../code-of-conduct/).\n\nبالإضافة إلى توصيل _كيف_ تتوقع من المشاركين أن يتصرفوا، تميل قواعد السلوك أيضًا إلى وصف من تنطبق عليه هذه التوقعات، ومتى تنطبق، وماذا تفعل إذا حدث انتهاك.\n\nمثل تراخيص المصادر المفتوحة، هناك أيضًا معايير ناشئة لقواعد السلوك، لذلك لا داعي لكتابة قواعدك الخاصة. [Contributor Covenant](https://contributor-covenant.org/) هي قواعد سلوك جاهزة للاستخدام يستخدمها [أكثر من 40,000 مشروع مفتوح المصدر](https://www.contributor-covenant.org/adopters)، بما في ذلك Kubernetes وRails Swift. بغض النظر عن النص الذي تستخدمه، يجب أن تكون مستعدًا لفرض قواعد السلوك الخاصة بك عند الضرورة.\n\nالصق النص مباشرة في ملف CODE_OF_CONDUCT في مستودعك. احتفظ بالملف في الدليل الجذري لمشروعك حتى يسهل العثور عليه، واربطه من README الخاص بك.\n\n## تسمية مشروعك ووضع علامة تجارية عليه\n\nالعلامة التجارية هي أكثر من مجرد شعار لامع أو اسم مشروع جذاب. إنها تتعلق بكيفية حديثك عن مشروعك، ومن تصل إليه برسالتك.\n\n### اختيار الاسم الصحيح\n\nاختر اسمًا يسهل تذكره، ومن الناحية المثالية، يعطي فكرة عما يفعله المشروع. على سبيل المثال:\n\n* [Sentry](https://github.com/getsentry/sentry) يراقب التطبيقات للإبلاغ عن الأعطال\n* [Thin](https://github.com/macournoyer/thin) هو خادم ويب Ruby سريع وبسيط\n\nإذا كنت تبني على مشروع موجود، فإن استخدام اسمهم كبادئة يمكن أن يساعد في توضيح ما يفعله مشروعك (على سبيل المثال، [node-fetch](https://github.com/bitinn/node-fetch) يجلب `window.fetch` إلى Node.js).\n\nضع الوضوح قبل كل شيء. التورية ممتعة، لكن تذكر أن بعض النكات قد لا تُترجم إلى ثقافات أخرى أو أشخاص ذوي تجارب مختلفة عنك. قد يكون بعض مستخدميك المحتملين موظفين في الشركة: لا تريد أن تجعلهم غير مرتاحين عندما يضطرون إلى شرح مشروعك في العمل!\n\n### تجنب تعارضات الأسماء {#تجنب-تعارضات-الاسماء}\n\n[تحقق من مشاريع المصادر المفتوحة ذات الأسماء المشابهة](https://namechecker.vercel.app/)، خاصة إذا كنت تشارك نفس اللغة أو النظام البيئي. إذا كان اسمك يتداخل مع مشروع شائع موجود، فقد تربك جمهورك.\n\nإذا كنت تريد موقع ويب، أو مقبض Twitter، أو خصائص أخرى لتمثيل مشروعك، فتأكد من أنه يمكنك الحصول على الأسماء التي تريدها. من الناحية المثالية، [احجز هذه الأسماء الآن](https://instantdomainsearch.com/) لراحة البال، حتى لو لم تكن تنوي استخدامها بعد.\n\nتأكد من أن اسم مشروعك لا ينتهك أي علامات تجارية. قد تطلب منك شركة ما إزالة مشروعك لاحقًا، أو حتى اتخاذ إجراء قانوني ضدك. الأمر لا يستحق المخاطرة.\n\nيمكنك التحقق من [قاعدة بيانات العلامات التجارية العالمية لـ WIPO](http://www.wipo.int/branddb/en/) لتعارضات العلامات التجارية. إذا كنت في شركة، فهذا أحد الأشياء التي يمكن لـ [فريقك القانوني مساعدتك فيها](../legal/).\n\nأخيرًا، قم بإجراء بحث سريع على Google عن اسم مشروعك. هل سيتمكن الناس من العثور على مشروعك بسهولة؟ هل يظهر شيء آخر في نتائج البحث لا تريد منهم رؤيته?\n\n### كيفية كتابتك (وكتابة الكود) تؤثر على علامتك التجارية أيضًا!\n\nطوال حياة مشروعك، ستقوم بالكثير من الكتابة: ملفات README، والبرامج التعليمية، ووثائق المجتمع، والرد على issues، وربما حتى النشرات الإخبارية وقوائم البريد.\n\nسواء كانت وثائق رسمية أو بريدًا إلكترونيًا عاديًا، فإن أسلوب كتابتك هو جزء من علامة مشروعك التجارية. ضع في اعتبارك كيف قد تبدو لجمهورك وما إذا كانت هذه هي النبرة التي ترغب في نقلها.\n\n\n\nاستخدام لغة دافئة وشاملة (مثل \"هم\"، حتى عند الإشارة إلى شخص واحد) يمكن أن يقطع شوطًا طويلاً في جعل مشروعك يبدو ترحيبيًا للمساهمين الجدد. التزم باللغة البسيطة، حيث قد لا يكون العديد من قرائك متحدثين أصليين للغة الإنجليزية.\n\nبالإضافة إلى كيفية كتابة الكلمات، قد يصبح أسلوب البرمجة الخاص بك أيضًا جزءًا من علامة مشروعك التجارية. [Angular](https://angular.io/guide/styleguide) و[jQuery](https://contribute.jquery.org/style-guide/js/) مثالان من المشاريع ذات أساليب البرمجة والإرشادات الصارمة.\n\nليس من الضروري كتابة دليل أسلوب لمشروعك عندما تبدأ للتو، وقد تجد أنك تستمتع بدمج أساليب برمجة مختلفة في مشروعك على أي حال. لكن يجب أن تتوقع كيف يمكن لأسلوب كتابتك وبرمجتك أن يجذب أو يثني أنواعًا مختلفة من الناس. المراحل الأولى من مشروعك هي فرصتك لتحديد السابقة التي ترغب في رؤيتها.\n\n## قائمة التحقق قبل الإطلاق\n\nهل أنت مستعد لفتح مصدر مشروعك؟ إليك قائمة تحقق للمساعدة. ضع علامة على جميع المربعات؟ أنت مستعد للانطلاق! [انقر على \"نشر\"](https://help.github.com/articles/making-a-private-repository-public/) وربت على ظهرك.\n\n**التوثيق**\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n**الكود**\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n**الأشخاص**\n\nإذا كنت فردًا:\n\n
\n \n \n
\n\nإذا كنت شركة أو منظمة:\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n## لقد فَعَلتَها!\n\nتهانينا على فتح مصدر مشروعك الأول. بغض النظر عن النتيجة، فإن العمل بشكل علني هو هدية للمجتمع. مع كل commit وتعليق وpull request، أنت تخلق فرصًا لنفسك وللآخرين للتعلم والنمو.\n\n
\n" }, { "path": "_articles/best-practices.md", "content": "---\nlang: en\ntitle: Best Practices for Maintainers\ndescription: Making your life easier as an open source maintainer, from documenting processes to leveraging your community.\nclass: best-practices\norder: 5\nimage: /assets/images/cards/best-practices.png\nrelated:\n - metrics\n - leadership\n---\n\n## What does it mean to be a maintainer?\n\nIf you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more.\n\nIn the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more.\n\nMaintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community.\n\n## Documenting your processes\n\nWriting things down is one of the most important things you can do as a maintainer.\n\nDocumentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask.\n\nWriting things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project.\n\nEven if you don't use full paragraphs, jotting down bullet points is better than not writing at all.\n\nRemember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome.\n\n### Write down your project's vision\n\nStart by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well.\n\nHaving a clear, documented vision keeps you focused and helps you avoid \"scope creep\" from others' contributions.\n\nFor example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate).\n\n\n\n### Communicate your expectations\n\nRules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun.\n\nWritten and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do.\n\nMost people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member.\n\nAll of this is perfectly okay! Just make sure other people know about it.\n\nIf maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend.\n\nHere are a few rules that are worth writing down:\n\n* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_)\n* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_)\n* When it's appropriate to follow up (_for example, \"You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread.\"_)\n* How much time you spend on the project (_for example, \"We only spend about 5 hours per week on this project\"_)\n\n[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors.\n\n### Keep communication public\n\nDon't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker.\n\nIf you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes.\n\nThat way, anybody who joins your community will have access to the same information as someone who's been there for years.\n\n## Learning to say no\n\nYou've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists.\n\nHaving everything written down, however, helps depersonalize situations when you do need to enforce your rules.\n\nSaying no isn't fun, but _\"Your contribution doesn't match this project's criteria\"_ feels less personal than _\"I don't like your contribution\"_.\n\nSaying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others.\n\n### Keep the conversation friendly\n\nOne of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept.\n\nMaybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor.\n\nRegardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards.\n\nIf you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community.\n\n\n\nDon't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.\n\nIt's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).\n\nSecondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment!\n\nIf you don't want to accept a contribution:\n\n* **Thank them** for their contribution\n* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm.\n* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself.\n* **Close the request**\n\nYou shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):\n\n![Celery screenshot](/assets/images/best-practices/celery.png)\n\nIf the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):\n\n> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying \"No\" to patches you don't want.\n\nDon't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _\"No is temporary, yes is forever.\"_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it.\n\nUltimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise.\n\n### Be proactive\n\nTo reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide.\n\nIf you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example:\n\n* Fill out an issue or PR template/checklist\n* Open an issue before submitting a PR\n\nIf they don't follow your rules, close the issue immediately and point to your documentation.\n\nWhile this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.\n\n\n\nSometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively.\n\n### Embrace mentorship\n\nMaybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections.\n\nIf you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _\"good first issue,\"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them.\n\n## Leverage your community\n\nYou don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work.\n\n### Share the workload\n\nIf you're looking for others to pitch in, start by asking around.\n\nOne way to gain new contributors is to explicitly [label issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing their visibility.\n\nWhen you see new contributors making repeated contributions, recognize their work by offering more responsibility. Document how others can grow into leadership roles if they wish.\n\nEncouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js).\n\n\n\nIf you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you.\n\nIf other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on!\n\n@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project:\n\n> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down.\n\n### Let others build the solutions they need\n\nIf a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork.\n\nForking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision.\n\n\n\nThe same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to \"some of the most interesting ideas\":\n\n> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying \"no\", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform.\n\n## Bring in the robots\n\nJust as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier.\n\n### Require tests and other checks to improve the quality of your code\n\nOne of the most important ways you can automate your project is by adding tests.\n\nTests help contributors feel confident that they won't break anything. They also make it easier for you to review and accept contributions quickly. The more responsive you are, the more engaged your community can be.\n\nSet up automatic tests that will run on all incoming contributions, and ensure that your tests can easily be run locally by contributors. Require that all code contributions pass your tests before they can be submitted. You'll help set a minimum standard of quality for all submissions. [Required status checks](https://help.github.com/articles/about-required-status-checks/) on GitHub can help ensure no change gets merged without your tests passing.\n\nIf you add tests, make sure to explain how they work in your CONTRIBUTING file.\n\n\n\n### Use tools to automate basic maintenance tasks\n\nThe good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.\n\nThere are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:\n\n* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases\n* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests\n* [Danger](https://github.com/danger/danger) helps automate code review\n* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information\n* [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds\n\nFor bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates.\n\nTo manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority.\n\nIf you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept.\n\nHowever, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier.\n\nIf you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors.\n\n## It's okay to hit pause\n\nOpen source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty.\n\nPerhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up.\n\nBurnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project.\n\nAlthough it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) after 14 years of volunteer OSS work.\n\nJust like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work.\n\n\n\nSometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away.\n\nDo your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness.\n\nTaking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you.\n\n## Take care of yourself first!\n\nMaintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive.\n" }, { "path": "_articles/bg/best-practices.md", "content": "---\nlang: bg\ntitle: Добри практики за поддържащи кода.\ndescription: Улесняване на живота ви като поддържащ отворен код, от процеса на документиране до извличане на максимума от общността.\nclass: best-practices\norder: 5\nimage: /assets/images/cards/best-practices.png\nrelated:\n - metrics\n - leadership\n---\n\n## Какво означава да си поддържащ код?\n\nАко вашата работа е да поддържате проект с отворен код, който много хора използват, вероятно сте забелязали, че прекарвате повече време в отговаряне на въпроси, отколкото в програмиране.\n\nВ ранните етапи на проекта прекарвате време в експериментиране с нови идеи и вземане на решения въз основа на това, което харесвате. С нарастването на популярността на проекта ви ще се окажете в ситуация, в която ще работите с вашите потребители и сътрудници все повече и повече.\n\nПоддържането на проект изисква повече от просто код. Тези задачи обикновено не се вземат предвид, но са също толкова важни за разрастващ се проект. Събрахме няколко идеи, които ще улеснят живота ви, от процеса на документиране до извличането на максимума от общността.\n\n## Документиране на вашите процеси\n\nОтбелязването на процедурите е една от най-добрите практики, които можете да направите като поддържащ код.\n\nДокументирането не само изяснява вашето мислене, но също така помага на другите да разберат от какво се нуждаете или очаквате, без дори да се налага да питате.\n\nКато вземете под внимание процесите, ви е по-лесно да кажете \"не\", когато нечие предложение не отговаря на вашия контекст. Така Освен това улеснява други хора да се присъединят и да помогнат. Никога не знаете кой може да чете или използва вашия проект.\n\nДори и да не сте от хората, които пишат цели параграфи, записването на ключови моменти е по-добро от никакви.\n\n### Изясняване на визията на вашия проект\n\nЗапочнете, като напишете целите на вашия проект. Добавете ги към вашия файл README или създайте отделен файл, наречен VISION. Ако има други артефакти, които могат да помогнат, като например карта на проект, направете и тях публични.\n\nНаличието на ясна документирана визия ви държи фокусирани и помага да избегнете неразбиране на обхвата от други сътрудници.\n\nНапример:\n@lord откри фактът, че наличието на визия за проект му помогна да разбере кои заявки да даде приоритет. Като начинаещ поддържащ код, той се оплака че не е бил верен на обхвата на проекта, когато е получил първата ви заявка за функционалност [Slate](https://github.com/lord/slate).\n\n\n\n### Съобщете вашите очаквания\n\nПонякога може да е трудно да се формулират правилата, така че други хора да могат да допринесат. Може да почувствате, че се държите като ченге или разваляте забавлението на другите.\n\nВъпреки това, написани и приложени справедливо, добрите правила дават възможност на поддържащите кода. Те ви предпазват от това да бъдете въвлечени в неща, които не искате да правите.\n\nПовечето хора, които срещат вашия проект, не знаят нищо за вас или вашите обстоятелства. Те може да приемат, че ви е платено да работите по него, особено ако това е нещо, което те използват и от което зависят редовно. Може би някога сте отделяли много време за проекта си, но сега сте заети с нова работа или член на семейството.\n\nВсичко е наред! Просто се уверете, че хората знаят.\n\nНезависимо дали поддържането на вашия проект е на непълно работно време или просто доброволно, бъдете честни за това колко време имате. Това не е същото като колко време мислите, че ще отнеме проектът или колко време другите искат да отделите.\n\nЕто някои правила, които си струва да имате предвид:\n\n* Как се преглежда и приема принос (_Трябва ли да направите някои тестове? Някакви шаблони, които да използвате за проблеми?_)\n* Типовете приноси, които ще приемете (_Искате ли помощ само за част от кода?_)\n* Кога е уместно да се проследи (_напр. \"Можете да очаквате отговор от поддържащия код в рамките на следващите 7 дни. Ако не сте чули нищо дотогава, не се колебайте да изпратите ping на нишката.\"_)\n*Колко време посвещавате на проекта (_напр. \"Ние инвестираме само около 5 часа на седмица в този проект\"_)\n\n[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), и [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) това са някои примери за проекти с ясни правила за поддържащи и сътрудници.\n\n### Поддържайте публична комуникация\n\nНе забравяйте да документирате и вашите взаимодействия. Където можете, поддържайте публична комуникация относно вашия проект. Ако някой се опита да се свърже с вас лично, за да обсъдите заявка за функция или нужда от поддръжка, учтиво го насочете към обществен канал за комуникация, като списък с имейли или инструмент за проследяване на проблеми.\n\nАко се срещнете с други поддържащи или вземете важни решения насаме, документирайте тези разговори публично, дори ако просто публикувате бележките си.\n\nПо този начин всеки, който се присъедини към вашата общност, ще има достъп до същата информация като някой, който е бил там. От години.\n\n## Научете се да казвате не\n\nНаписахте нещата. В идеалния случай всеки ще прочете вашата документация, но в действителност ще трябва да напомняте на другите, че това знание съществува.\n\nНаличието на всичко написано обаче помага да се обезличат ситуациите, в които е необходимо да се налагат правилата.\n\nДа кажете \"не\" не е забавно, но _\"Вашият принос не отговаря на критериите за този проект\"_ изглежда по-малко лично от _\"Не харесвам приноса ви\"_.\n\nКазването \"не\" се отнася за много ситуации, които ще срещнете като поддържащ код: заявки за функции, които са извън обхвата, някой дерайлира дискусия, върши ненужна работа за други.\n\n### Поддържайте разговора приятелски\n\nЕдно от най-важните места, където ще практикувате да казвате \"не\", е в опашката за издаване и изтегляне на заявки. Като ръководител на проекти вие неизбежно ще получите предложения, които не искате да приемете.\n\nМоже би приносът променя обхвата на вашия проект или не отговаря на вашата визия. Може би идеята е добра, но изпълнението е ужасно.\n\nНезависимо от причината, можете тактично да се справите с приноси, които не отговарят на стандартите на проекта.\n\nАко получите изпращане, което не искате да приемете, първата ви реакция може да бъде да го игнорирате или да се престорите, че не сте го видели. Това може да нарани чувствата на другия човек и дори да обезкуражи други потенциални сътрудници във вашата общност.\n\n\n\nНе оставяйте отворен нежелан принос, защото се чувствате виновни или искате да сте мили. С течение на времето вашите въпроси без отговор и PR ще станат излишни. Това ще направи работата по вашия проект много по-стресираща и смущаваща.\n\nНай-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [как да избирате ефективно въпроси](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).\n\nВторо, игнорирането на приносите изпраща отрицателен сигнал към вашата общност. Приносът към проект може да бъде смущаващ, особено ако на някого е за първи път. Дори и да не приемете техния принос, поздравете човека зад него и му благодарете за проявения интерес. Това е страхотен комплимент!\n\nАко не желаете да приемете дарение:\n\n* **Благодаря им** за техния принос.\n* **Обясни защо не отговаря** на обхвата на проекта и предлага ясни предложения за подобрение, ако е възможно. Знам мил, но твърд.\n* **Споделете подходяща информация**, ако я имате. Ако забележите повтарящи се искания за неща, които не искате да приемете, добавете ги към документацията си, за да избегнете винаги да обяснявате едно и също нещо.\n* **Затворете заявката**\n\nНе трябва да имате повече от 1-2 изречения, за да отговорите. Например, когато потребител [celery](https://github.com/celery/celery/) съобщи за грешка, свързана с Windows, @berkerpeksag [той отговори с](https://github.com/celery/celery/issues/3383):\n\n[celery screenshot](/assets/images/best-practices/celery.png)\n\nАко идеята да кажете \"не\" ви ужасява, не се чувствайте сами. Както @jessfraz [казва](https://blog.jessfraz.com/post/the-art-of-closing/):\n\n> Говорил съм с поддържащи кодове от множество различни проекти с отворен код, Mesos, Kubernetes, Chromium, и всички те са съгласни, че една от най-трудните части да си поддържащ код е: да кажеш \"Не\" на пачове, които не искаш да използваш.\n\nНе се чувствайте виновни, че не искате да приемете нечий принос. Първото правило на отворения код, [в съответствие със](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _\"Не, е временно; да, това е завинаги.\"_ Докато мъченичеството на ентусиазма на друг човек е добро нещо, отхвърлянето на принос не е същото като отхвърлянето на човека зад него.\n\nВ крайна сметка, ако даден принос не е достатъчно добър, не сте длъжни да го приемете. Знам Бъдете мили и отзивчиви, когато хората допринасят за вашия проект, но приемайте само промени, които наистина вярвате, че ще направят проекта ви по-добър. Колкото по-често се упражнявате да казвате \"не\", толкова по-лесно става. Това е обещание.\n\n### Бъди проактивен\n\nЗа да намалите първо обема на нежеланите приноси, обяснете процеса на вашия проект за подаване и приемане на приноси в ръководството за приноси.\n\nАко получите твърде много подавания с ниско качество, помолете сътрудниците да свършат малко работа предварително, например:\n\n* Попълнете шаблон или контролен списък за проблеми или PR\n*Отворете проблем, преди да изпратите PR\n\nАко не спазват вашите правила, незабавно затворете проблема и ги насочете към вашата документация.\n\nВъпреки че този подход може да изглежда неприятен в началото, проактивността всъщност е добра и за двете страни. Намалете шанса някой да инвестира много часове пропиляна работа върху заявка за изтегляне, която не приемате. И опростява управлението на натоварването.\n\n\n\nПонякога, когато кажете \"не\", вашият потенциален сътрудник може да се ядоса или да критикува решението ви. Ако поведението ви стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори ги отстранете от вашата общност, ако не желаят да си сътрудничат конструктивно.\n\n### Прегърнете наставничеството\n\nМоже би някой във вашата общност редовно изпраща приноси, които не отговарят на стандартите на вашия проект. Може да бъде разочароващо и за двете страни многократното преминаване през процеса на отхвърляне.\n\nАко видите, че някой е Ако сте развълнувани от проекта си, но той се нуждае от малко практика, бъдете търпеливи. Обяснете ясно във всяка ситуация защо. техният принос не отговаря на очакванията на проекта. Опитайте да им дадете по-лесна или по-малко двусмислена задача, като например проблем, означен с _\"добър първи проблем,\"_, за да ги загреете. Ако имате време, помислете за менторство чрез първия си принос или намерете някой друг във вашата общност, който се интересува. готови да ги наставляват.\n\n##Използване на общността\n\nНе е нужно да правите всичко сами. Вашата проектна общност съществува с причина! Дори ако все още нямате активна общност от сътрудници, ако имате много потребители, оставете ги да работят.\n\n### Споделете натоварването\n\nАко търсите други да се присъединят, започнете, като разпитате наоколо.\n\nКогато видите нови сътрудници да правят повторни приноси, трябва да признаете работата им, като им предложите повече отговорности. Документирайте как другите могат да постигнат лидерски роли, ако желаят.\n\nНасърчаването на други да [споделят собствеността върху проекта](../building-community/#споделете-собствеността-върху-вашия-проект) може значително да намали работното ви натоварване, както установи @lmccart във вашия проект, [p5.js](https://github.com/processing/p5.js).\n\n\n\nАко трябва да се оттеглите от проекта си, независимо дали временно или за постоянно, не е срамно да помолите някой друг да поеме вместо вас.\n\nАко други хора са ентусиазирани относно посоката на проекта, дайте им разрешение да се ангажират или официално предайте контрола на някой друг. Ако някой направи разклонение на вашия проект и това е активно поддържане някъде другаде, помислете за свързване на разклонението от вашия оригинален проект. Страхотно е, че толкова много хора искат вашият проект да се развива!\n\n@progrium [установи, че](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) документирайки визията на вашия проект, [Dokku](https://github.com/dokku/dokku), помогне тези цели да продължават, включително и след това, което е останало на проекта:\n\n> Написах wiki страница, описваща какво искам и защо го искам. По някаква причина бях изненадан от това! Нека поддържащите започнат да движат проекта в тази посока! Случи се? Как точно бихте го направили? Не винаги. Но както и да се приближи, аз реализирах проекта, както исках.\n\n### Позволете на другите да създават решенията, от които се нуждаят\n\nАко потенциален сътрудник има различно мнение за това какво трябва да направи вашият проект, може да се наложи внимателно да го насърчите да работи върху собствената си вилка.\n\nРазклоняването на проект не е задължително да е лошо нещо. Да можеш да копираш и модифицираш проекти е едно от най-добрите неща на отворения код. Насърчаването на членовете на вашата общност да работят върху своя собствена вилица може да осигури творческия изход, от който се нуждаят, без да противоречи на визията на вашия проект.\n\n\n\nСъщото важи и за потребител, който наистина иска решение, което вие просто нямате възможност да създадете. Предлагането на адаптивни API и кукички може да помогне на другите да посрещнат собствените си нужди, без да се налага директно да променят източника.\n@orta [намери че](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) окуражаващи плъгини за CocoaPods към \"някои от по-интересните идеи\":\n\n> Почти неизбежно е след като проектът стане голям, поддържащите трябва да бъдат много по-консервативни по отношение на това как въвеждат нов код. Умеете да казвате \"не\", но много хора имат законни нужди. Следователно в крайна сметка превръщате инструмента си в платформа.\n\n## Доведете роботите\n\nТака Точно както има задачи, с които други хора могат да ви помогнат, има и задачи, които никое човешко същество не трябва да изпълнява. Роботите са ваши приятели. Използвайте ги, за да улесните живота си като поддържащ код.\n\n### Изисквайте тестване и други проверки, за да подобрите качеството на вашия код\n\nЕдин от най-важните начини за автоматизиране на вашия проект е чрез тестване.\n\nТестването помага на сътрудниците да се чувстват уверени, че няма да нарушат нищо. Те също така улесняват прегледа и бързото приемане на приноси. Колкото по-възприемчиви сте, толкова по-ангажирани ще бъдете. бъдете вашата общност.\n\nНастройте автоматични тестове за изпълнение на всички входящи приноси и се уверете, че могат да се изпълняват локално от сътрудниците. Изисква всички приноси на код да преминат през тестване, преди да могат да бъдат изпратени. Ще помогне за установяване на минимален стандарт за качество за всички приложения.\n[Необходими са проверки на състоянието](https://help.github.com/articles/about-required-status-checks/) в GitHub може да помогне да се гарантира, че никакви промени не се обединяват, без първо да преминете през тестване.\n\nАко добавите тестове, не забравяйте да обясните как работят във вашия CONTRIBUTING файл.\n\n\n\n### Използвайте инструменти за автоматизиране на основни задачи по поддръжката\n\nДобрата новина за поддържането на популярен проект е, че други поддържащи вероятно са се сблъсквали с подобни проблеми и са създали решение за него.\n\nИма [различни налични инструменти](https://github.com/showcases/tools-for-open-source) за подпомагане на автоматизирането на някои аспекти на работата по поддръжката. Няколко примера:\n\n* [semantic-release](https://github.com/semantic-release/semantic-release) автоматизирайте вашите версии\n* [mention-bot](https://github.com/facebook/mention-bot) споменете възможни рецензенти за заявки за рул\n* [Danger](https://github.com/danger/danger) помага за автоматизиране на прегледа на кода\n\nЗа доклади за грешки и други общи приноси GitHub има [Шаблони за проблеми и заявки за изтегляне](https://github.com/blog/2111-issue-and-pull-request-templates), които можете да създадете, за да рационализирате комуникацията, която получавате. Можете също да конфигурирате [имейл филтри](https://github.com/blog/2203-email-updates-about-your-own-activity)за управление на вашите имейл известия.\n\nАко искате да станете малко по-напреднали, ръководствата за стил могат да стандартизират приноса към проекта и да ги направят по-лесни за преглед и приемане.\n\nВъпреки това, ако вашите стандарти са твърде сложни, те могат да увеличат бариерите пред приноса. Уверете се, че добавяте само правила, за да улесните живота на всички.\n\nАко не сте сигурни какво инструменти, които да използвате, вижте какво правят други популярни проекти, особено тези във вашата екосистема. Например какво Как изглежда процесът на принос за други модули на Node? Използването на подобни инструменти и подходи също ще улесни. Направете своя процес по-познат на вашите целеви сътрудници.\n\n## То е добре пауза\n\nРаботата с отворен код някога ви е носила радост. Може би сега е така започват да ви карат да се чувствате отбягващи или виновни.\n\nМоже би се чувствате претоварени или нарастващо чувство на страх, когато мислите за вашите проекти. И междувременно се натрупват проблеми и заявки за изтегляне.\n\nПрегарянето е реален и всеобхватен проблем в работата с отворен код, особено сред поддържащите. Като поддържащ, вашето щастие е неподлежащо на обсъждане изискване за оцеляването на всеки проект с отворен код.\n\nВъпреки че трябва да се разбира от само себе си, вземете си почивка! Не трябва да чакате, докато се почувствате изморени, за да си вземете почивка. @brettcannon, разработчик на Python, реши да вземете [едномесечна ваканция](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) след 14 години OSS доброволчество.\n\nКато всеки друг вид работа, редовните почивки ще ви поддържат мотивирани. свежи, щастливи и развълнувани от работата си.\n\n\n\nПонякога може да е трудно да си вземете почивка от работата с отворен код, когато чувствате, че целият свят има нужда от вас. Хората може дори да се опитат да ви накарат да се чувствате виновни, че сте се отдалечили.\n\nНаправете всичко възможно, за да намерите поддръжка за вашите потребители и общност, докато сте далеч от даден проект. Ако не можете да намерите подкрепата, от която се нуждаете, все пак си направете почивка. Не забравяйте да общувате, когато не сте на разположение, така че хората да не се чувстват объркани от липсата ви на отзивчивост.\n\nПравенето на почивки се отнася и за нещо повече от ваканции. Ако не искате да работите с отворен код през почивните дни или по време на работното време, съобщете тези решения на другите, за да знаят, че няма да ви притесняват.\n\n## Погрижете се първо за себе си!\n\nПоддържането на популярен проект изисква различни умения от ранните етапи на растеж, но е не по-малко възнаграждаващо. Като поддържащ, вие ще практикувате лидерски умения и умения за хора на ниво, което малко хора могат да изпитат. Въпреки че не винаги е лесно да се управлява, поставянето на ясни граници и вземането само на това, което ви кара да се чувствате комфортно, ще ви помогне. за да сте щастливи, актуализирани и продуктивни.\n" }, { "path": "_articles/bg/building-community.md", "content": "---\nlang: bg\ntitle: Изграждане на приветливи общности\ndescription: Изграждане на общност, която насърчава хората да използват, допринасят и образоват с вашия проект\nclass: building\norder: 4\nimage: /assets/images/cards/building.png\nrelated:\n - best-practices\n - coc\n---\n\n## Настройване на вашия проект за успех\n\nТоку-що стартирахте проекта си, разпространявате информацията и хората го следват. Брилянтно! Сега, как да ги накараш да останат?\n\nГостоприемната общност е инвестиция в бъдещето на вашия проект и вашата репутация. Ако вашият проект едва започва да вижда първите си приноси, започнете, като дадете положителен опит на първите сътрудници и ги улеснете да се връщат отново.\n\n### Накарайте хората да се чувстват добре дошли\n\nЕдин от начините да мислите за общността на вашия проект е чрез това, което @MikeMcQuaid нарича [фуния на сътрудниците](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):\n\n![Фуния на сътрудник](/assets/images/building-community/contributor_funnel_mikemcquaid.png)\n\nДокато изграждате общността си, помислете как някой на върха на фунията (потенциален потребител) може теоретично да си проправи път надолу (активен поддържащ). Вашата цел е да намалите триенето на всеки етап от опита на сътрудници. Когато хората имат лесни победи, те ще бъдат стимулирани да правят повече.\n\nЗапочнете с вашата документация: \n\n* **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#напишете-readme) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект.\n* **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#напишете-вашите-указания-за-принос) и поддържате проблемите си актуални.\n* **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво.\n\n[Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията.\n\n* **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне.\n* **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект.\n* **Бъдете непредубедени относно видовете приноси, които ще приемете.** Много сътрудници започват с докладване на грешка или извършване на малка корекция. Има [много начини да допринесете](../how-to-contribute/#какво-означава-да-допринасяш) към проект. Позволете на хората да помагат по начина, по който искат да помогнат.\n* **Ако има принос, с който не сте съгласни,** им благодарете за тяхната идея и [обяснете защо](../best-practices/#научете-се-да-казвате-не) не отговаря на обхвата на проекта , с връзка към съответната документация, ако я имате.\n\n\n\nПовечето сътрудници с отворен код са \"случайни сътрудници\": хора, които допринасят за проект само от време на време. Случаен сътрудник може да няма време да се запознае напълно с вашия проект, така че вашата работа е да го улесните да допринася.\n\nНасърчаването на други сътрудници е инвестиция и във вас самите. Когато дадете възможност на най-големите си фенове да работят с работата, която ги вълнува, има по-малко натиск да правите всичко сами.\n\n### Документирайте всичко\n\n\n\nКогато започвате нов проект, може да ви се стори естествено да запазите работата си в тайна. Но проектите с отворен код процъфтяват, когато документирате процеса си публично.\n\nКогато документирате нещата, повече хора могат да бъдат включени във всяка стъпка от процеса. Може да получите помощ за нещо, от което дори не сте подозирали, че имате нужда.\n\nЗаписването на неща означава повече от просто техническа документация. Всеки път, когато почувствате нужда да напишете нещо или да обсъдите работата си насаме, запитайте се дали можете да я направите публично достояние.\n\nБъдете прозрачни относно пътната карта на вашия проект, типовете приноси, които търсите, как се разглеждат приносите или защо сте взели определени решения.\n\nАко забележите, че много потребители имат същия проблем, моля, документирайте отговорите в README.\n\nЗа срещи помислете за публикуване на вашите бележки или изводи в свързана тема. Обратната връзка, която ще получите от това ниво на прозрачност, може да ви изненада.\n\nДокументирането на всичко се отнася и за работата, която вършите. Ако работите върху голяма актуализация на вашия проект, поставете го в заявка за изтегляне и го маркирайте като работа в процес (WIP). По този начин други хора могат да се почувстват ангажирани в процеса на ранен етап.\n\n### Бъдете отзивчиви\n\nДокато [популяризирате своя проект](../finding-users), хората ще имат обратна връзка за вас. Те може да имат въпроси за това как работят нещата или да се нуждаят от помощ, за да започнат.\n\nОпитайте се да бъдете отзивчиви, когато някой подаде проблем, изпрати заявка за изтегляне или зададе въпрос относно вашия проект. Когато отговаряте бързо, хората ще се почувстват като част от диалог и ще бъдат по-ентусиазирани да участват.\n\nДори и да не можете да прегледате заявката незабавно, потвърждаването й на ранен етап помага да се увеличи ангажираността. Ето как @tdreyno отговори на заявка за изтегляне на [Middleman](https://github.com/middleman/middleman/pull/1466):\n\n![Middleman заявка за изтегляне](/assets/images/building-community/middleman_pr.png)\n\n[Това установи проучване на Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) сътрудниците, които са получили прегледи на кода в рамките на 48 часа, са имали много по-висок процент на възвръщаемост и повторен принос.\n\nДискусиите относно вашия проект може също да се случват другаде в мрежата, като Stack Overflow, Twitter или Reddit. Можете да настроите известия на някои от тези места, така че да получавате известия, когато някой спомене вашия проект.\n\n### Дайте на вашата общност място за събиране\n\nИма две причини да дадете на вашата общност място за събиране.\n\nПървата причина е за тях. Помогнете на хората да се опознаят. Хората с общи интереси неизбежно ще искат място, където да говорят за това. А когато комуникацията е публична и достъпна, всеки може да чете минали архиви, за да се запознае и да участва.\n\nВтората причина е за вас. Ако не дадете на хората обществено място да говорят за вашия проект, те вероятно ще се свържат директно с вас. В началото може да изглежда достатъчно лесно да отговаряте на лични съобщения \"само този път\". Но с течение на времето, особено ако проектът ви стане популярен, ще се почувствате изтощени. Устояйте на изкушението да общувате с хората относно вашия проект насаме. Вместо това ги насочете към определен обществен канал.\n\nПубличната комуникация може да бъде толкова проста, колкото да насочите хората да отворят проблем, вместо да ви изпращат имейл директно или да коментират в блога ви. Можете също така да настроите пощенски списък или да създадете акаунт в Twitter, Slack или IRC канал, за да могат хората да говорят за вашия проект. Или опитайте всичко по-горе!\n\n[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) отделя работни часове през седмица, за да помогне на членовете на общността:\n\n> Kops също така отделя време всяка седмица, за да предлага помощ и насоки на общността. Поддържащите Kops се съгласиха да отделят време, специално посветено на работа с новодошлите, подпомагане с PR и обсъждане на нови функции.\n\nЗабележителни изключения от публичната комуникация са: 1) проблеми със сигурността и 2) чувствителни нарушения на кодекса за поведение. Винаги трябва да имате начин хората да докладват тези проблеми лично. Ако не искате да използвате личния си имейл, настройте специален имейл адрес.\n\n## Разрастване на вашата общност\n\nОбщностите са изключително силни. Тази сила може да бъде благословия или проклятие, в зависимост от това как я владеете. Тъй като общността на вашия проект расте, има начини да му помогнете да се превърне в сила на изграждане, а не на разрушение.\n\n### Не толерирайте лоши актьори\n\nВсеки популярен проект неизбежно ще привлече хора, които вредят, а не помагат на вашата общност. Те могат да започнат ненужни дебати, да се карат за тривиални характеристики или да тормозят другите.\n\nНаправете всичко възможно да приемете политика на нулева толерантност към този тип хора. Ако не бъдат отметнати, негативните хора ще накарат другите хора във вашата общност да се чувстват неудобно. Може дори да си тръгнат.\n\n\n\nРедовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват.\n\nКогато видите, че се появява негативно поведение, направете публично наблюдение за него. Обяснете с приятелски тон защо Такова поведение не е приемливо. Ако проблемът продължава, може да се наложи [да го помолите да напусне](../code-of-conduct/#вашите-отговорности-като-поддържащ). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори.\n\n### Запознайте се с сътрудниците там, където са\n\nДобрата документация става все по-важна, когато вашата общност расте. Случайни сътрудници, които иначе може да не са запознати с вашия проект, четат вашата документация, за да получат бързо контекста, от който се нуждаят.\n\nВъв вашия CONTRIBUTING файл кажете изрично на новите сътрудници как да започнат. Може дори да искате да направите специален раздел за тази цел. [Django](https://github.com/django/django), например, има специална целева страница за посрещане на нови сътрудници.\n\n![Django страница с нови сътрудници](/assets/images/building-community/django_new_contributors.png)\n\nВ опашката си с теми маркирайте грешки, които са подходящи за различни типове сътрудници: например [_\"за начинаещи\"_](https://kentcdodds.com/blog/first-timers-only), _\"добра първа тема\"_ или _\"документация\"_. [Тези маркировки](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) улесняват някой който е нов във вашия проект бързо да сканира вашите теми и първи стъпки.\n\nИ накрая, използвайте вашата документация, за да накарате хората да се чувстват добре дошли на всяка стъпка от процеса.\n\nНикога няма да взаимодействате с повечето хора, които ще участват във вашия проект. Възможно е да има приноси, които не сте получили, защото някой се е почувствал уплашен или не е знаел откъде да започне. Дори няколко мили думи могат да попречат на някого да напусне проекта ви разочарован.\n\nНапример, ето как [Rubinius](https://github.com/rubinius/rubinius/) започва [неговото допринасящо ръководство](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):\n\n> Искаме да започнем, като ви благодарим, че използвате Rubinius. Този проект е труд на любов и ние оценяваме всички потребители, които улавят грешки, правят подобрения на производителността и помагат с документацията. Всеки принос е значим, така че благодарим за участието. Имайки предвид това, ето няколко насоки, които ви молим да следвате, за да можем успешно да се справим с проблема ви.\n\n### Споделете собствеността върху вашия проект\n\n\n\nХората са развълнувани да допринасят за проекти, когато изпитват чувство за собственост. Това не означава, че трябва да преобърнете визията на вашия проект или да приемете приноси, които не искате. Но колкото повече признавате другите, толкова повече те ще останат наоколо.\n\nВижте дали можете да намерите начини да споделите собствеността с вашата общност колкото е възможно повече. Ето няколко идеи:\n\n* **Отбягвайте коригирането на лесни (некритични) грешки.** Вместо това ги използвайте като възможности за набиране на нови сътрудници или наставничество на някой, който би искал да допринесе. В началото може да изглежда неестествено, но инвестицията ви ще се изплати с времето. Например @michaeljoseph помоли сътрудник да изпрати заявка за изтегляне на проблем с [Cookiecutter](https://github.com/audreyr/cookiecutter) по-долу, вместо да го коригира сам.\n\n![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)\n\n* **Стартирайте файл CONTRIBUTORS или AUTHORS във вашия проект**, който изброява всички, които са допринесли за вашия проект, както прави [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md).\n\n* Ако имате значителна общност, **изпратете бюлетин или напишете публикация в блог**, като благодарите на сътрудниците. [Тази седмица в Rust](https://this-week-in-rust.org/) на Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) на Hoodie са два добри примера.\n\n* **Дайте достъп за ангажиране на всеки сътрудник.** @felixge установи, че това кара хората [да бъдат по-развълнувани да усъвършенстват корекциите си](https://felixge.de/2013/03/11/the-pull-request-hack.html) и дори намери нови поддържащи за проекти, по които не е работил от известно време.\n\n* Ако проектът ви е в GitHub, **преместете проекта си от личния си акаунт в [Организация](https://help.github.com/articles/creating-a-new-organization-account/)** и добавете поне един резервен администратор. Организациите улесняват работата по проекти с външни сътрудници.\n\nРеалността е, че [повечето проекти имат само](https://peerj.com/preprints/1233/) един или двама поддържащи, които вършат по-голямата част от работата. Колкото по-голям е вашият проект и колкото по-голяма е вашата общност, толкова по-лесно е да намерите помощ.\n\nВъпреки че не винаги може да намерите някой, който да отговори на обаждането, подаването на сигнал там увеличава шансовете други хора да се включат. И колкото по-рано започнете, толкова по-скоро хората могат да помогнат.\n\n\n\n## Разрешаване на конфликти\n\nВ ранните етапи на вашия проект вземането на важни решения е лесно. Когато искаш да направиш нещо, просто го правиш.\n\nТъй като вашият проект става по-популярен, повече хора ще се интересуват от решенията, които вземате. Дори и да нямате голяма общност от сътрудници, ако вашият проект има много потребители, ще намерите хора, които преценяват решенията или повдигат свои собствени проблеми.\n\nВ по-голямата си част, ако сте култивирали приятелска, уважителна общност и сте документирали процесите си открито, вашата общност трябва да може да намери решение. Но понякога се натъквате на проблем, който е малко по-труден за разрешаване.\n\n### Поставете стандарта за учтивост\n\nКогато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас.\n\nВашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#не-толерирайте-лоши-актьори), за да поддържате дискусията цивилизована и продуктивна.\n\n\n\nДруги хора ви търсят за напътствие. Давайте добър пример. Все още можете да изразите разочарование, нещастие или загриженост, но го направете спокойно.\n\nДа запазите хладнокръвие не е лесно, но демонстрирането на лидерство подобрява здравето на вашата общност. Интернет ви благодари.\n\n### Отнасяйте се към вашия README като към конституция\n\nВашият README е [повече от просто набор от инструкции](../starting-a-project/#напишете-readme). Това също е място да говорите за вашите цели, продуктова визия и пътна карта. Ако хората са прекалено съсредоточени върху обсъждането на достойнствата на определена функция, може да ви помогне да прегледате отново вашия README и да говорите за по-високата визия на вашия проект. Фокусирането върху вашия README също обезличава разговора, така че можете да водите конструктивна дискусия.\n\n### Фокусирайте се върху пътуването, а не върху дестинацията\n\nНякои проекти използват процес на гласуване, за да вземат важни решения. Въпреки че е разумно на пръв поглед, гласуването набляга на достигането до \"отговор\", а не на изслушване и разглеждане на притесненията на другия.\n\nГласуването може да стане политическо, когато членовете на общността се чувстват принудени да си правят услуги или да гласуват по определен начин. Не всеки гласува също, независимо дали е [мълчаливото мнозинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) във вашата общност или настоящи потребители, които не са знаели, че се провежда гласуване.\n\nПонякога е необходим равен вот. Доколкото можете обаче, наблягайте на [\"търсенето на консенсус\"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсуса .\n\nПри процес на търсене на консенсус членовете на общността обсъждат основните опасения, докато не почувстват, че са били адекватно изслушани. Когато останат само второстепенни грижи, общността върви напред. \"Търсене на консенсус\" признава, че една общност може да не е в състояние да достигне до перфектен отговор. Вместо това дава приоритет на слушането и дискусията.\n\n\n\nДори ако всъщност не възприемете процес на търсене на консенсус, като поддържащ проект е важно хората да знаят, че слушате. Да накарате другите хора да се почувстват чути и да се ангажират с разрешаването на притесненията им допринася много за деескалацията на чувствителни ситуации. След това последвайте думите си с действия.\n\nНе бързайте с решение в името на решението. Уверете се, че всички се чувстват чути и че цялата информация е разпространена, преди да преминете към решение.\n\n### Поддържайте разговора фокусиран върху действието\n\nДискусията е важна, но има разлика между продуктивни и непродуктивни разговори.\n\nНасърчавайте дискусията, стига да върви активно към разрешаване. Ако е ясно, че разговорът затихва или се отклонява от темата, заяжданията стават лични или хората се бъзикат за незначителни подробности, време е да го затворите.\n\nПозволяването на тези разговори да продължат е не само лошо за разглеждания проблем, но и за здравето на вашата общност. Изпраща съобщение, че този тип разговори са разрешени или дори насърчавани, и може да обезсърчи хората да повдигат или разрешават бъдещи проблеми.\n\nС всяка точка, изказана от вас или от други, запитайте се: \"Как това ни доближава до решение?\"_\n\nАко разговорът започва да се разплита, попитайте групата _\"Кои стъпки трябва да предприемем по-нататък?\"_, за да пренасочите разговора.\n\nАко разговорът очевидно не води до никъде, няма ясни действия, които да бъдат предприети, или подходящото действие вече е предприето, затворете проблема и обяснете защо сте го затворили.\n\n\n\n### Подбирайте битките си мъдро\n\nВажен е контекстът. Помислете кой участва в разговора и как той представлява останалата част от общността.\n\nВсички в общността разстроени ли са или дори загрижени за това? Или е самотен размирник? Не забравяйте да имате предвид мълчаливите членове на вашата общност, а не само активните гласове.\n\nАко проблемът не представлява по-широките нужди на вашата общност, може просто да се наложи да приемете притесненията на някои хора. Ако това е повтарящ се проблем без ясно решение, моля, насочете ги към предишни дискусии по темата и затворете темата.\n\n### Определете критерий за равновесие на общността\n\nС добро поведение и ясна комуникация повечето трудни ситуации се разрешават. Въпреки това, дори при продуктивна дискусия, може просто да има разлика в мненията за това как да продължите. В тези случаи идентифицирайте човек или група от хора, които могат да служат като балансьор.\n\nНивелирът може да бъде основният поддържащ проекта или може да бъде малка група хора, които вземат решение въз основа на гласуване. В идеалния случай вие сте дефинирали нивелир и свързаната процедура във файл GOVERNANCE, преди да се наложи да го използвате.\n\nВашето решение за вратовръзка трябва да е последна мярка. Разделящите въпроси са възможност за вашата общност да расте и да се учи. Прегърнете тези възможности и използвайте процес на сътрудничество, за да преминете към разрешаване, когато е възможно.\n\n## Общността е ❤️ на отворен код\n\nЗдравите, процъфтяващи общности захранват хилядите часове, вложени в отворен код всяка седмица. Много сътрудници посочват други хора като причина да работят - или да не работят - с отворен код. Като се научите как да се възползвате от тази сила конструктивно, вие ще помогнете на някого да има незабравимо изживяване с отворен код.\n" }, { "path": "_articles/bg/code-of-conduct.md", "content": "---\nlang: bg\ntitle: Вашият кодекс на поведение\ndescription: Улеснявайте здравословното и конструктивно поведение на общността чрез приемане и прилагане на кодекс на поведение.\nclass: coc\norder: 8\nimage: /assets/images/cards/coc.png\nrelated:\n - building\n - leadership\n---\n\n## Защо имам нужда от кодекс на поведение?\n\nКодексът на поведение е документ, който определя очакванията за поведение на участниците във вашия проект. Приемането и прилагането на кодекс на поведение може да помогне за създаването на положителна социална атмосфера за вашата общност.\n\nКодексите на поведение помагат да защитите не само вашите участници, но и себе си. Ако поддържате проект, може да откриете, че непродуктивното отношение на другите участници може да ви накара да се почувствате изтощени или нещастни от работата си с течение на времето.\n\nКодексът на поведение ви дава възможност да улесните здравословното, конструктивно поведение в общността. Проактивността намалява вероятността вие или другите да се уморите от вашия проект и ви помага да предприемете действия, когато някой направи нещо, с което не сте съгласни.\n\n## Създаване на кодекс на поведение\n\nОпитайте се да създадете кодекс на поведение възможно най-рано: в идеалния случай, когато за първи път създавате своя проект.\n\nВ допълнение към съобщаването на вашите очаквания, кодексът на поведение описва следното:\n\n* Където кодексът на поведение влиза в сила _(само при проблеми и заявки за изтегляне или дейности на общността като събития?)_\n* За кого се прилага кодексът на поведение _(членове на общността и поддържащи лица, но какво да кажем за спонсори?)_\n* Какво се случва, ако някой наруши кодекса на поведение\n* Как някой може да докладва за нарушения\n\nКъдето можете, използвайте предшестващо състояние на техниката. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от над 40 000 проекта с отворен код, включително Kubernetes, Rails и Swift.\n\n[Кодексът на поведение на Django](https://www.djangoproject.com/conduct/) и [Кодексът на поведение на гражданите](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) също са два добри примера на кодекс на поведение.\n\nПоставете файл CODE_OF_CONDUCT в основната директория на вашия проект и го направете видим за вашата общност, като го свържете от вашия CONTRIBUTING или README файл.\n\n## Решете как ще наложите своя кодекс на поведение\n\n\n\nТрябва да обясните как вашият кодекс за поведение ще бъде прилаган **_преди_** нарушение. Има няколко причини да го направите:\n\n* Демонстрира, че сте сериозни относно предприемането на действия, когато е необходимо.\n\n* Вашата общност ще се почувства по-уверена, че оплакванията действително се преглеждат.\n\n* Ще уверите вашата общност, че процесът на преглед е честен и прозрачен, ако някога се окажат разследвани за нарушение.\n\nТрябва да дадете на хората личен начин (като имейл адрес) да докладват за нарушение на кодекса на поведение и да обясните кой получава този доклад. Това може да бъде поддържащ, група от поддържащи или работна група за кодекс на поведение.\n\nНе забравяйте, че някой може да поиска да докладва за нарушение на лице, което получава тези доклади. В този случай им дайте възможност да докладват за нарушения на някой друг. Например @ctb и @mr-c [обясняват за техния проект](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):\n\n> Случаи на злоупотреба, тормоз или по друг начин неприемливо поведение могат да бъдат докладвани чрез имейл **khmer-project@idyll.org**, който отива само до C. Titus Brown и Michael R. Crusoe. За да съобщите за проблем, свързан с някой от тях, моля, изпратете имейл до **Judi Brown Clarke, Ph.D.** директора по разнообразието в BEACON Center for the Study of Evolution in Action, Център за науки и технологии на NSF.*\n\nЗа вдъхновение вижте [ръководството за прилагане](https://www.djangoproject.com/conduct/enforcement-manual/) на Django (въпреки че може да не се нуждаете от нещо толкова изчерпателно, в зависимост от размера на вашия проект).\n\n## Налагане на вашия кодекс на поведение\n\nПонякога, въпреки всичките ви усилия, някой ще направи нещо, което нарушава този кодекс. Има няколко начина за справяне с негативното или вредно поведение, когато се появи.\n\n### Съберете информация за ситуацията\n\nОтнасяйте се към гласа на всеки член на общността също толкова важен, колкото и вашия собствен. Ако получите доклад, че някой е нарушил кодекса за поведение, приемете го сериозно и проучете въпроса, дори ако не съвпада с вашия собствен опит с този човек. Това сигнализира на вашата общност, че цените тяхната гледна точка и се доверявате на тяхната преценка.\n\nВъпросният член на общността може да е повторен нарушител, който постоянно кара другите да се чувстват неудобно, или може да е казал или направил нещо само веднъж. И в двата случея могат да бъдат основание за предприемане на действие в зависимост от контекста.\n\nПреди да отговорите, дайте си време да разберете какво се е случило. Прочетете миналите коментари и разговори на човека, за да разберете по-добре кои са те и защо може да са действали по този начин. Опитайте се да съберете гледни точки, различни от вашата собствена, за този човек и неговото поведение.\n\n\n\n### Предприемете подходящи действия\n\nСлед като съберете и обработите достатъчно информация, ще трябва да решите какво да правите. Докато обмисляте следващите си стъпки, не забравяйте, че вашата цел като модератор е да насърчите безопасна, уважителна и съвместна среда. Помислете не само как да се справите с въпросната ситуация, но и как вашият отговор ще повлияе на останалата част от поведението и очакванията на вашата общност в бъдеще.\n\nКогато някой съобщи за нарушение на кодекса на поведение, ваша, а не негова работа е да се справите с него. Понякога репортерът разкрива информация с голям риск за своята кариера, репутация или физическа безопасност. Принуждаването им да се изправят срещу насилника си може да постави репортера в компрометираща позиция. Трябва да поддържате директна комуникация с въпросното лице, освен ако репортерът изрично не поиска друго.\n\nИма няколко начина, по които можете да реагирате на нарушение на кодекса на поведение:\n\n* **Дайте публично предупреждение на въпросното лице** и обяснете как поведението му е повлияло негативно на другите, за предпочитане в канала, където се е случило. Когато е възможно, публичната комуникация предава на останалата част от общността, че приемате кодекса за поведение сериозно. Бъдете мили, но твърди в общуването си.\n\n* **Свържете се лично с въпросното лице**, за да обясните как поведението му е повлияло негативно на другите. Може да искате да използвате личен канал за комуникация, ако ситуацията включва чувствителна лична информация. Ако общувате с някого насаме, добра идея е да изпратите CC на онези, които първи са съобщили за ситуацията, за да знаят, че сте предприели действия. Помолете подалото сигнал лице за съгласие, преди да му изпратите CC.\n\nПонякога не може да се постигне решение. Въпросното лице може да стане агресивно или враждебно, когато се сблъскаш с него или да не промени поведението си. В тази ситуация може да обмислите предприемането на по-строги действия. Например:\n\n* **Забрана на въпросното лице** от проекта, наложено чрез временна забрана за участие във всеки аспект на проекта\n\n* **Забранете за постоянно** лицето от проекта\n\nЗабраната на членове не трябва да се приема с лека ръка и представлява постоянна и непримирима разлика в гледните точки. Трябва да предприемате тези мерки само когато е ясно, че не може да се постигне решение.\n\n## Вашите отговорности като поддържащ\n\nКодексът на поведение не е закон, който се прилага произволно. Вие сте наложителят на кодекса за поведение и е ваша отговорност да следвате правилата, установени от кодекса за поведение.\n\nКато поддържащ вие установявате насоките за вашата общност и налагате тези насоки в съответствие с правилата, изложени във вашия кодекс за поведение. Това означава да приемате сериозно всеки сигнал за нарушение на кодекса за поведение. На репортера се дължи задълбочено и справедливо разглеждане на жалбата им. Ако установите, че поведението, за което са докладвали, не е нарушение, съобщете им го ясно и обяснете защо няма да предприемете действия по него. Какво ще направят с това зависи от тях: да толерират поведението, с което са имали проблем, или да спрат да участват в общността.\n\nДокладът за поведение, което _технически_ не нарушава кодекса за поведение, все още може да показва, че има проблем във вашата общност и вие трябва да проучите този потенциален проблем и да действате съответно. Това може да включва преразглеждане на вашия кодекс за поведение, за да се изясни приемливото поведение и/или разговор с лицето, чието поведение е докладвано, и да му кажете, че макар да не е нарушил кодекса за поведение, те заобикалят ръба на очакваното и правят сигурни участниците се чувстват неудобно.\n\nВ крайна сметка, като поддържащ, вие определяте и налагате стандартите за приемливо поведение. Вие имате способността да оформяте ценностите на общността на проекта и участниците очакват от вас да налагате тези ценности по справедлив и равностоен начин.\n\n## Насърчавайте поведението, което искате да видите в света 🌎\n\nКогато даден проект изглежда враждебен или неприветлив, дори ако това е само един човек, чието поведение се толерира от другите, рискувате да загубите много повече сътрудници, някои от които може дори никога да не срещнете. Не винаги е лесно да приемете или наложите кодекс на поведение, но насърчаването на гостоприемна среда ще помогне на вашата общност да расте.\n" }, { "path": "_articles/bg/finding-users.md", "content": "---\nlang: bg\ntitle: Намиране на потребители за вашия проект\ndescription: Помогнете на вашия проект с отворен код да се развие, като го предоставите в ръцете на щастливи потребители.\nclass: finding\norder: 3\nimage: /assets/images/cards/finding.png\nrelated:\n - beginners\n - building\n---\n\n## Разпространяване на думата\n\nНяма правило, което да казва, че трябва да рекламирате проект с отворен код, когато стартирате. Има много основателни причини да работите с отворен код, които нямат нищо общо с популярността. Вместо да се надявате, че другите ще намерят и използват вашия проект с отворен код, вие трябва да разпространите думата за вашата упорита работа!\n\n## Разберете съобщението си\n\nПреди да започнете действителната работа по популяризиране на вашия проект, трябва да можете да обясните какво прави и защо има значение.\n\nКакво прави вашия проект различен или интересен? Защо го създадохте? Отговорът на тези въпроси сам ще ви помогне да съобщите значението на вашия проект.\n\nНе забравяйте, че хората се включват като потребители и в крайна сметка стават сътрудници, защото вашият проект решава проблем вместо тях. Докато мислите за посланието и стойността на вашия проект, опитайте се да ги видите през призмата на това, което _потребителите и сътрудниците_ може да искат.\n\nНапример, @robb използва примери за код, за да съобщи ясно защо неговият проект, [Картография](https://github.com/robb/Cartography), е полезен:\n\n![Картография README](/assets/images/finding-users/cartography.jpg)\n\nЗа по-задълбочено потапяне в съобщенията вижте упражнението на Mozilla [\"Личности и пътеки\"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) за разработване на потребителски персони.\n\n## Help people find and follow your project\n\n\n\nПомогнете на хората да намерят и запомнят вашия проект, като ги насочите към едно пространство от имена.\n\n**Имайте ясен манипулатор, за да популяризирате работата си.** Twitter манипулатор, GitHub URL или IRC канал е лесен начин да насочите хората към вашия проект. Тези изходи също дават място за събиране на нарастващата общност на вашия проект.\n\nАко все още не желаете да създавате изходи за вашия проект, популяризирайте свой собствен Twitter или GitHub манипулатор във всичко, което правите. Популяризирането на вашия Twitter или GitHub ще позволи на хората да знаят как да се свържат с вас или да следят работата ви. Ако говорите на среща или събитие, уверете се, че вашата информация за контакт е включена във вашата биография или слайдове.\n\n\n\n**Помислете за създаване на уебсайт за вашия проект.** Уеб сайтът прави проекта ви по-удобен и лесен за навигация, особено когато е съчетан с ясна документация и уроци. Наличието на уебсайт също предполага, че вашият проект е активен, което ще накара вашата аудитория да се чувства по-комфортно при използването му. Дайте примери, за да дадете на хората идеи как да използват вашия проект.\n\n[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), съ-създател на Django, каза, че уебсайтът е _\"далеч най-доброто нещо, което направихме с Django в ранните дни\"_ .\n\nАко вашият проект се хоства в GitHub, можете да използвате [GitHub Pages](https://pages.github.com/), за да създадете лесно уебсайт. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) са [няколко примера](https://github.com/showcases/github-pages-examples) от отлични, изчерпателни уебсайтове.\n\n![Начална страница на Vagrant](/assets/images/finding-users/vagrant_homepage.png)\n\nСега, след като имате съобщение за вашия проект и лесен начин за хората да го намерят, нека да излезем и да поговорим с вашата аудитория!\n\n## Отидете там, където е аудиторията на вашия проект (онлайн)\n\nОнлайн обхватът е чудесен начин за бързо споделяне и разпространение на информацията. Използвайки онлайн канали, вие имате потенциала да достигнете до много широка аудитория.\n\nВъзползвайте се от съществуващите онлайн общности и платформи, за да достигнете до вашата аудитория. Ако вашият проект с отворен код е софтуерен проект, вероятно можете да намерите аудиторията си в [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Намерете каналите, от които смятате, че хората ще имат най-голяма полза или ще бъдат развълнувани от вашата работа.\n\n\n\nВижте дали можете да намерите начини да споделите проекта си по подходящи начини:\n\n* **Запознайте се с подходящи проекти и общности с отворен код.** Понякога не е нужно директно да рекламирате проекта си. Ако вашият проект е идеален за специалисти по данни, които използват Python, запознайте се с общността за наука за данни на Python. Когато хората ви опознаят, ще се появят естествени възможности да говорите и споделяте работата си.\n* **Намерете хора, които се сблъскват с проблема, който вашият проект решава.** Потърсете в свързани форуми за хора, които попадат в целевата аудитория на вашия проект. Отговорете на техния въпрос и намерете тактичен начин, когато е подходящо, да предложите вашия проект като решение.\n* **Поискайте обратна връзка.** Представете себе си и работата си на публика, която ще я намери за подходяща и интересна. Бъдете конкретни относно това кой смятате, че ще има полза от вашия проект. Опитайте се да завършите изречението: _\"Мисля, че моят проект наистина ще помогне на X, които се опитват да направят Y_\". Слушайте и отговаряйте на отзивите на другите, вместо просто да популяризирате работата си.\n\nНай-общо казано, фокусирайте се върху това да помагате на другите, преди да поискате неща в замяна. Тъй като всеки може лесно да рекламира проект онлайн, ще има много шум. За да се откроите от тълпата, дайте на хората контекст за това кой сте, а не само това, което искате.\n\nАко никой не обърне внимание или не отговори на първоначалния ви обхват, не се обезсърчавайте! Повечето стартирания на проекти са итеративен процес, който може да отнеме месеци или години. Ако не получите отговор от първия път, опитайте различна тактика или първо потърсете начини да добавите стойност към работата на другите. Популяризирането и стартирането на вашия проект изисква време и отдаденост.\n\n## Отидете там, където е аудиторията на вашия проект (офлайн)\n\n![Публично говорене](/assets/images/finding-users/public_speaking.jpg)\n\nОфлайн събитията са популярен начин за популяризиране на нови проекти пред публика. Те са чудесен начин да достигнете до ангажирана аудитория и да изградите по-дълбоки човешки връзки, особено ако се интересувате от достигане до разработчици.\n\nАко сте [нов в публичното говорене](https://speaking.io/), започнете, като намерите местна среща, която е свързана с езика или екосистемата на вашия проект.\n\n\n\nАко никога преди не сте говорили на събитие, напълно нормално е да се чувствате нервни! Не забравяйте, че публиката ви е там, защото те наистина искат да чуят за работата ви.\n\nДокато пишете речта си, съсредоточете се върху това, което аудиторията ви ще намери за интересно и от което ще извлече полза. Поддържайте езика си приятелски настроен и достъпен. Усмихвайте се, дишайте и се забавлявайте.\n\n\n\nКогато се почувствате готови, обмислете да говорите на конференция, за да популяризирате проекта си. Конференциите могат да ви помогнат да достигнете до повече хора, понякога от цял свят.\n\nПотърсете конференции, които са специфични за вашия език или екосистема. Преди да изпратите своята реч, проучете конференцията, за да пригодите лекцията си за присъстващите и да увеличите шансовете си да бъдете приети да говорите на конференцията. Често можете да добиете представа за аудиторията си, като погледнете говорителите на конференцията.\n\n\n\n## Build a reputation\n\nВ допълнение към стратегиите, описани по-горе, най-добрият начин да поканите хората да споделят и да допринесат за вашия проект е да споделяте и да допринесете за техните проекти.\n\nПодпомагането на новодошлите, споделянето на ресурси и обмисленият принос към чужди проекти ще ви помогнат да изградите положителна репутация. Това, че сте активен член в общността с отворен код, ще помогне на хората да имат контекст за вашата работа и е по-вероятно да обърнат внимание и да споделят вашия проект. Развитието на връзки с други проекти с отворен код може дори да доведе до официални партньорства.\n\n\n\nНикога не е твърде рано или твърде късно да започнете да изграждате репутацията си. Дори ако вече сте стартирали свой собствен проект, продължавайте да търсите начини да помагате на другите.\n\nНяма еднодневно решение за изграждане на аудитория. Спечелването на доверието и уважението на другите отнема време и изграждането на вашата репутация никога не свършва.\n\n## Продължавайте!\n\nМоже да отнеме много време, преди хората да забележат вашия проект с отворен код. Това е добре! Някои от най-популярните проекти днес отнеха години, за да достигнат високи нива на активност. Съсредоточете се върху изграждането на взаимоотношения, вместо да се надявате, че вашият проект спонтанно ще спечели популярност. Бъдете търпеливи и продължавайте да споделяте работата си с тези, които я оценяват.\n" }, { "path": "_articles/bg/getting-paid.md", "content": "---\nlang: bg\ntitle: Получаване на заплащане за работа с отворен код\ndescription: Поддържайте работата си с отворен код, като получите финансова подкрепа за вашето време или за вашия проект.\nclass: getting-paid\norder: 7\nimage: /assets/images/cards/getting-paid.png\nrelated:\n - best-practices\n - leadership\n---\n\n## Защо някои хора търсят финансова подкрепа\n\nГоляма част от работата с отворен код е доброволна. Например, някой може да се натъкне на грешка в проект, който използва, и да изпрати бързо решение, или може да му хареса да бърника с проект с отворен код в свободното си време.\n\n\n\nИма много причини, поради които човек не би искал да получава заплащане за работата си с отворен код.\n\n* **Те може вече да имат работа на пълен работен ден, която обичат,** което им позволява да допринасят за отворен код в свободното си време.\n* **Харесва им да мислят за отворения код като за хоби** или творческо бягство и не искат да се чувстват финансово задължени да работят по проектите си.\n* **Те получават други ползи от приноса си към отворен код,** като например изграждане на репутация или портфолио, усвояване на нови умения или чувство за близост до общност.\n\n\n\nЗа други, особено когато приносът е в ход или изисква значително време, получаването на плащане за принос към отворен код е единственият начин да участват, било защото проектът го изисква, или поради лични причини.\n\nПоддържането на популярни проекти може да бъде значителна отговорност, като отнема 10 или 20 часа на седмица вместо няколко часа на месец.\n\n\n\nПлатената работа също дава възможност на хора от различни сфери на живота да дадат значим принос. Някои хора не могат да си позволят да прекарват неплатено време в проекти с отворен код въз основа на текущото си финансово състояние, дълг или семейни или други задължения за грижа. Това означава, че светът никога не вижда приноси от талантливи хора, които не могат да си позволят да отделят доброволно времето си. Това има етични последици, както @ashedryden [описа](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), тъй като свършената работа е предубедени в полза на онези, които вече имат предимства в живота, които след това получават допълнителни предимства въз основа на техния доброволен принос, докато други, които не могат да бъдат доброволци, след това не получават по-късни възможности, което засилва текущата липса на разнообразие в отворения код общност.\n\n\n\nАко търсите финансова подкрепа, трябва да обмислите два начина. Можете да финансирате собственото си време като сътрудник или можете да намерите организационно финансиране за проекта.\n\n## Финансиране на вашето собствено време\n\nДнес много хора получават заплащане, за да работят на непълен или пълен работен ден с отворен код. Най-често срещаният начин да получите заплащане за времето си е да говорите с вашия работодател.\n\nПо-лесно е да направите аргумент за работа с отворен код, ако вашият работодател действително използва проекта, но бъдете креативни с представянето си. Може би вашият работодател не използва проекта, но той използва Python и поддържането на популярен проект на Python помага за привличането на нови разработчици на Python. Може би това кара вашия работодател да изглежда по-приятелски настроен към разработчиците като цяло.\n\nАко нямате съществуващ проект с отворен код, върху който бихте искали да работите, но предпочитате текущата ви работа да е с отворен код, помолете вашия работодател да отвори част от техния вътрешен софтуер.\n\nМного компании разработват програми с отворен код, за да изградят своята марка и да наемат качествени таланти.\n\n@hueniverse например установи, че има финансови причини, които да оправдаят [инвестицията на Walmart в отворен код](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). И @jamesgpearce установи, че програмата с отворен код на Facebook [има значение](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) при набирането на персонал:\n\n> Тя е тясно свързана с нашата хакерска култура и начина, по който нашата организация се възприемаше. Попитахме нашите служители: \"Знаехте ли за софтуерната програма с отворен код във Facebook?\". Две трети казаха \"Да\". Половината казаха, че програмата е допринесла положително за решението им да работят за нас. Това не са пределни числа и се надявам, че тенденцията ще продължи.\n\nАко вашата компания тръгне по този път, важно е да поддържате ясни границите между общността и корпоративната дейност. В крайна сметка отвореният код се поддържа чрез принос от хора по целия свят и това е по-голямо от която и да е компания или местоположение.\n\n\n\nАко не можете да убедите настоящия си работодател да даде приоритет на работата с отворен код, помислете за намиране на нов работодател, който насърчава приноса на служителите към отворен код. Потърсете компании, които подчертават своята отдаденост на работата с отворен код. Например:\n\n* Някои компании, като [Netflix](https://netflix.github.io/), имат уебсайтове, които подчертават тяхното участие в отворен код\n\nПроекти, които произхождат от голяма компания, като [Go](https://github.com/golang) или [React](https://github.com/facebook/react), will also likely employ people to work on open source.\n\nВ зависимост от вашите лични обстоятелства можете да опитате да съберете пари независимо, за да финансирате работата си с отворен код. Например:\n\n* @Homebrew (и [много други поддържащи и организации](https://github.com/sponsors/community)) финансират работата си чрез [Спонсори на GitHub](https://github.com/sponsors)\n* @gaearon финансира работата си върху [Redux](https://github.com/reactjs/redux) чрез [кампания за групово финансиране на Patreon](https://redux.js.org/)\n* @andrewgodwin финансира работа по миграции на схема на Django [чрез кампания на Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)\n\nИ накрая, понякога проекти с отворен код дават премии за проблеми, за които може да обмислите да помогнете.\n\n* @ConnorChristie успя да получи плащане за [помощ](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol работят по своята JavaScript библиотека [чрез награда за gitcoin](https://gitcoin.co/).\n* @mamiM направи японски преводи за @MetaMask след [изданието беше финансирано от Bounties Network](https://explorer.bounties.network/bounty/134).\n\n## Намиране на финансиране за вашия проект\n\nОсвен договореностите за отделни сътрудници, понякога проектите набират пари от компании, физически лица или други за финансиране на текуща работа.\n\nОрганизационното финансиране може да отиде за плащане на настоящи сътрудници, покриване на разходите за управление на проекта (като такси за хостинг) или инвестиране в нови функции или идеи.\n\nТъй като популярността на отворения код нараства, намирането на финансиране за проекти все още е експериментално, но има няколко общи опции.\n\n### Съберете пари за работата си чрез кампании за групово финансиране или спонсорство\n\nНамирането на спонсорство работи добре, ако вече имате силна публика или репутация или проектът ви е много популярен.\nНяколко примера за спонсорирани проекти включват:\n\n* **[webpack](https://github.com/webpack)** събира пари от компании и физически лица [чрез OpenCollective](https://opencollective.com/webpack)\n* **[Ruby Together](https://rubytogether.org/),** организация с нестопанска цел, която плаща за работата по [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) и други Ruby инфраструктурни проекти\n\n### Създайте поток от приходи\n\nВ зависимост от вашия проект може да имате възможност да таксувате за търговска поддръжка, хоствани опции или допълнителни функции. Няколко примера включват:\n\n* **[Sidekiq](https://github.com/mperham/sidekiq)** предлага платени версии за допълнителна поддръжка\n* **[Travis CI](https://github.com/travis-ci)** предлага платени версии на своя продукт\n* **[Ghost](https://github.com/TryGhost/Ghost)** е организация с нестопанска цел с платена управлявана услуга\n\nНякои популярни проекти, като [npm](https://github.com/npm/cli) и [Docker](https://github.com/docker/docker), дори набират рисков капитал, за да подкрепят растежа на своя бизнес.\n\n### Кандидатствайте за безвъзмездно финансиране\n\nНякои софтуерни фондации и компании предлагат грантове за работа с отворен код. Понякога грантовете могат да се изплащат на физически лица, без да се създава юридическо лице за проекта.\n\n* **[Прочетете документите](https://github.com/rtfd/readthedocs.org)** получи субсидия от [Поддръжка на Mozilla Open Source](https://www.mozilla.org/en-US/grants/)\n* Работата по **[OpenMRS](https://github.com/openmrs)** е финансирана от [Retreat за отворен код на Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees)\n* **[Libraries.io](https://github.com/librariesio)** получи грант от [Фондация Слоун](https://sloan.org/programs/digital-technology)\n* **[Python Software Foundation](https://www.python.org/psf/grants/)** предлага грантове за работа, свързана с Python\n\nЗа по-подробни опции и казуси @nayafia [написа ръководство](https://github.com/nayafia/lemonade-stand) за получаване на заплащане за работа с отворен код. Различните видове финансиране изискват различни умения, така че преценете силните си страни, за да разберете коя опция работи най-добре за вас.\n\n## Изграждане на случай за финансова подкрепа\n\nНезависимо дали вашият проект е нова идея или съществува от години, трябва да очаквате да вложите значителни мисли в идентифицирането на вашия целеви финансист и в представянето на убедителни аргументи.\n\nНезависимо дали искате да платите за собственото си време или да наберете средства за проект, трябва да можете да отговорите на следните въпроси.\n\n### Въздействие\n\nЗащо този проект е полезен? Защо вашите потребители или потенциални потребители го харесват толкова много? Къде ще бъде след пет години?\n\n### Сцепление\n\nОпитайте се да съберете доказателства, че вашият проект има значение, независимо дали става дума за показатели, анекдоти или препоръки. Има ли компании или забележителни хора, които използват вашия проект в момента? Ако не, виден човек го е одобрил?\n\n### Стойност за финансиращия\n\nДо финансиращите, независимо дали вашият работодател или фондация, предоставяща безвъзмездни средства, често се обръщат с възможности. Защо трябва да подкрепят вашия проект пред всяка друга възможност? Как се облагодетелстват те лично?\n\n### Използване на средства\n\nКакво точно ще постигнете с предложеното финансиране? Съсредоточете се върху важни етапи или резултати на проекта, вместо да плащате заплата.\n\n### Как ще получите средствата\n\nФинансиращият има ли някакви изисквания относно изплащането? Например, може да се наложи да сте организация с нестопанска цел или да имате фискален спонсор с нестопанска цел. Или може би средствата трябва да бъдат дадени на отделен изпълнител, а не на организация. Тези изисквания варират между финансиращите, така че не забравяйте да направите проучването си предварително.\n\n\n\n## Експериментирайте и не се отказвайте\n\nСъбирането на пари не е лесно, независимо дали сте проект с отворен код, организация с нестопанска цел или стартиращ софтуер, и в повечето случаи изисква от вас да проявите креативност. Определянето на начина, по който искате да получавате заплащане, извършването на вашите проучвания и поставянето на мястото на вашия финансиращ ще ви помогне да изградите убедителна аргументация за финансиране.\n" }, { "path": "_articles/bg/how-to-contribute.md", "content": "---\nlang: bg\ntitle: Как да допринесете за отворения код\ndescription: Искате ли да допринесете за отворен код? Ръководство за правене на приноси с отворен код за начинаещи и за ветерани.\nclass: contribute\norder: 1\nimage: /assets/images/cards/contribute.png\nrelated:\n - beginners\n - building\n---\n\n## Защо да допринасяте за отворен код?\n\n\n\nПриносът към отворен код може да бъде възнаграждаващ начин за учене, преподаване и изграждане на опит в почти всяко умение, което можете да си представите.\n\nЗащо хората допринасят за отворен код? Много причини!\n\n### Подобрете софтуера, на който разчитате\n\nМного сътрудници с отворен код започват като потребители на софтуер, за който допринасят. Когато намерите грешка в софтуер с отворен код, който използвате, може да искате да погледнете източника, за да видите дали можете да го коригирате сами. Ако случаят е такъв, тогава връщането на корекцията е най-добрият начин да се уверите, че вашите приятели (и вие самите, когато актуализирате до следващото издание) ще могат да се възползват от нея.\n\n### Подобрете съществуващите умения\n\nНезависимо дали става въпрос за кодиране, дизайн на потребителски интерфейс, графичен дизайн, писане или организиране, ако търсите практика, има задача за вас по проект с отворен код.\n\n### Запознайте се с хора, които се интересуват от подобни неща\n\nПроекти с отворен код с топли, гостоприемни общности карат хората да се връщат с години. Много хора създават приятелства за цял живот чрез участието си в отворен код, независимо дали се срещат по време на конференции или късно вечерни онлайн чатове за бурито.\n\n### Намерете ментори и учете другите\n\nРаботата с други по споделен проект означава, че ще трябва да обясните как правите нещата, както и да помолите други хора за помощ. Действията на учене и преподаване могат да бъдат удовлетворяваща дейност за всички участници.\n\n### Изградете публични артефакти, които ви помагат да развиете репутация (и кариера)\n\nПо дефиниция цялата ви работа с отворен код е публична, което означава, че получавате безплатни примери, които да вземете навсякъде като демонстрация на това, което можете да правите.\n\n### Научете умения за хора\n\nОтвореният код предлага възможности за практикуване на лидерски и управленски умения, като разрешаване на конфликти, организиране на екипи от хора и приоритизиране на работата.\n\n### Овластяващо е да можеш да правиш промени, дори малки\n\nНе е нужно да сте сътрудник през целия живот, за да се насладите на участието в отворен код. Случвало ли ви се е да видите печатна грешка в уебсайт и да ви се иска някой да я поправи? В проект с отворен код можете да направите точно това. Отвореният код помага на хората да се чувстват независими от живота си и начина, по който преживяват света, и това само по себе си е удовлетворяващо.\n\n## Какво означава да допринасяш\n\nАко сте нов сътрудник на отворен код, процесът може да бъде смущаващ. Как намирате правилния проект? Ами ако не знаете как да кодирате? Ами ако нещо се обърка?\n\nНе се притеснявайте! Има всякакви начини да се включите в проект с отворен код и няколко съвета ще ви помогнат да извлечете максимума от опита си.\n\n### Не е нужно да добавяте код\n\nЧесто срещано погрешно схващане относно приноса към отворен код е, че трябва да допринесете с код. Всъщност често другите части на проекта са [най-пренебрегвани или пренебрегвани](https://github.com/blog/2195-the-shape-of-open-source). Ще направите _огромна_ услуга на проекта, като предложите да се включите с тези видове принос!\n\n\n\nДори ако обичате да пишете код, други видове приноси са чудесен начин да се включите в проект и да се срещнете с други членове на общността. Изграждането на тези взаимоотношения ще ви даде възможности да работите върху други части на проекта.\n\n### Обичате ли да планирате събития?\n\n* Организирайте семинари или срещи за проекта, [както @fzamperin направи за NodeSchool](https://github.com/nodeschool/organizers/issues/406)\n* Организирайте конференция на проекта (ако има такава)\n* Помогнете на членовете на общността да намерят правилните конференции и да представят предложения за изказване\n\n### Обичате ли да проектирате?\n\n* Преструктурирайте оформленията, за да подобрите използваемостта на проекта\n* Извършете потребителско проучване, за да реорганизирате и прецизирате навигацията или менютата на проекта, [както предлага Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability)\n* Съставете ръководство за стил, за да помогнете на проекта да има последователен визуален дизайн\n* Създайте изкуство за тениски или ново лого, [както направиха сътрудниците на hapi.js](https://github.com/hapijs/contrib/issues/68)\n\n### Обичаш ли да пишеш?\n\n* Напишете и подобрете документацията на проекта, [както @CBID2 направи за документацията на OpenSauced](https://github.com/open-sauced/docs/pull/151)\n* Подгответе папка с примери, показващи как се използва проектът\n* Стартирайте бюлетин за проекта или подредете акценти от пощенския списък, [както направи @opensauced за своя продукт](https://news.opensauced.pizza/about/)\n* Напишете уроци за проекта, [както направиха сътрудниците на PyPA](https://packaging.python.org/)\n* Напишете превод за документацията на проекта, [както @frontendwizard направи за инструкциите за CSS Flexbox предизвикателството на freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)\n\n\n\n### Обичате ли да организирате?\n\n* Връзка към дублирани проблеми и предлагане на теми за нови проблеми, за да поддържате организацията\n* Прегледайте отворените проблеми и предложете затваряне на стари, [както направи @nzakas за ESLint](https://github.com/eslint/eslint/issues/6765)\n* Задавайте изясняващи въпроси по наскоро открити въпроси, за да придвижите дискусията напред\n\n### Обичате ли да кодирате?\n\n* Намерете открит проблем, който да решите, [както @dianjin направи за Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)\n* Попитайте дали можете да помогнете за записването на нова функция\n* Автоматизирайте настройките на проекта\n* Подобрете инструментите и тестването\n\n### Обичате ли да помагате на хората?\n\n* Отговорете на въпроси относно проекта напр. Stack Overflow ([като този пример на Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) или Reddit\n* Отговаряйте на въпроси за хора по отворени въпроси\n* Помогнете за модерирането на дискусионните табла или каналите за разговори\n\n### Обичате ли да помагате на другите да кодират?\n\n* Прегледайте кода на изявленията на други хора\n* Напишете уроци за това как може да се използва проект\n* Предложете да наставлявате друг сътрудник, [както @ereichert направи за @bronzdoc в Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)\n\n### Не е нужно просто да работите върху софтуерни проекти!\n\nДокато \"отворен код\" често се отнася до софтуер, можете да си сътрудничите по почти всичко. Има книги, рецепти, списъци и класове, които се разработват като проекти с отворен код.\n\nНапример:\n\n* @sindresorhus подготвя [списък с \"страхотни\" списъци](https://github.com/sindresorhus/awesome)\n* @h5bp поддържа [списък с потенциални въпроси за интервю](https://github.com/h5bp/Front-end-Developer-Interview-Questions) за кандидати за фронтенд разработчици\n* @stuartlynn и @nicole-a-tesla направиха [колекция от забавни факти за пуфините](https://github.com/stuartlynn/puffin_facts)\n\nДори и да сте разработчик на софтуер, работата по проект за документация може да ви помогне да започнете работа с отворен код. Често е по-малко смущаващо да работите по проекти, които не включват код, а процесът на сътрудничество ще изгради вашата увереност и опит.\n\n## Ориентиране към нов проект\n\n\n\nЗа нещо повече от поправка на печатна грешка, да допринесете за отворен код е като да отидете до група непознати на парти. Ако започнете да говорите за лами, докато те бяха потънали в дискусия за златните рибки, вероятно ще ви погледнат малко странно.\n\nПреди да се включите сляпо със собствените си предложения, започнете, като се научите как да четете стаята. По този начин увеличавате шансовете вашите идеи да бъдат забелязани и чути.\n\n### Анатомия на проект с отворен код\n\nВсяка общност с отворен код е различна.\n\nПрекарването на години в един проект с отворен код означава, че сте се запознали с един проект с отворен код. Преминете към друг проект и може да откриете, че речникът, нормите и стиловете на комуникация са напълно различни.\n\nВъпреки това много проекти с отворен код следват подобна организационна структура. Разбирането на различните роли в общността и цялостния процес ще ви помогне бързо да се ориентирате към всеки нов проект.\n\nТипичен проект с отворен код има следните типове хора:\n\n* **Автор:** Лицето/лицата или организацията, създали проекта\n* **Собственик:** Лицето/лицата, което има административна собственост върху организацията или хранилището (не винаги е същото като оригиналния автор)\n* **Поддържащи:** Сътрудници, които са отговорни за управлението на визията и управлението на организационните аспекти на проекта (Те също могат да бъдат автори или собственици на проекта.)\n* **Сътрудници:** Всеки, който е допринесъл с нещо обратно към проекта\n* **Членове на общността:** Хората, които използват проекта. Те могат да бъдат активни в разговорите или да изразят мнението си за посоката на проекта\n\nПо-големите проекти могат също да имат подкомисии или работни групи, фокусирани върху различни задачи, като инструменти, сортиране, модериране на общността и организиране на събития. Потърсете в уебсайта на даден проект страница за \"екип\" или в хранилището за документация за управление, за да намерите тази информация.\n\nКъм проекта има и документация. Тези файлове обикновено са изброени в горното ниво на хранилището.\n\n* **ЛИЦЕНЗ:** По дефиниция всеки проект с отворен код трябва да има [лиценз за отворен код](https://choosealicense.com). Ако проектът няма лиценз, той не е с отворен код.\n* **README:** README е ръководството с инструкции, което приветства новите членове на общността в проекта. Той обяснява защо проектът е полезен и как да започнете.\n* **ПРИНОС:** Докато README помагат на хората да _използват_ проекта, допринасящите документи помагат на хората да _допринасят_ за проекта. Той обяснява какви видове вноски са необходими и как работи процесът. Въпреки че не всеки проект има ПРИНОСЯЩ файл, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете. Добър пример за ефективно ръководство за принос би било това от [хранилището на документи на Codecademy](https://www.codecademy.com/resources/docs/contribution-guide).\n* **CODE_OF_CONDUCT:** Кодексът за поведение определя основните правила за свързаното поведение на участниците и спомага за създаването на приятелска, гостоприемна среда. Въпреки че не всеки проект има файл CODE_OF_CONDUCT, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете.\n* **Друга документация:** Може да има допълнителна документация, като уроци, инструкции или политики за управление, особено за по-големи проекти като [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).\n\nИ накрая, проектите с отворен код използват следните инструменти за организиране на дискусия. Четенето на архивите ще ви даде добра представа за това как общността мисли и работи.\n\n* **Проследяване на проблеми:** Където хората обсъждат въпроси, свързани с проекта.\n* **Заявки за изтегляне:** Когато хората обсъждат и преглеждат промените, които са в ход, независимо дали са за подобряване на реда код на сътрудника, използването на граматика, използването на изображения и т.н. Някои проекти, като [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), използват определени потоци за действие на GitHub, за да автоматизират и ускорят своите прегледи на кода.\n* **Дискусионни форуми или пощенски списъци:** Някои проекти могат да използват тези канали за теми за разговор (например _\"Как да...\"_ или _\"Какво мислиш за...\"_ вместо грешка отчети или заявки за функции). Други използват инструмента за проследяване на проблеми за всички разговори. Добър пример за това би бил [седмичният бюлетин на CHAOSS](https://chaoss.community/news/)\n* **Синхронен чат канал:** Някои проекти използват чат канали (като Slack или IRC) за непринуден разговор, сътрудничество и бърз обмен. Добър пример за това би била [общността на Discord на EddieHub](http://discord.eddiehub.org/).\n\n## Намиране на проект, за който да допринесете\n\nСега, след като разбрахте как работят проектите с отворен код, време е да намерите проект, за който да допринесете!\n\nАко никога преди не сте допринасяли за отворения код, приемете съвет от президента на САЩ Джон Ф. Кенеди, който веднъж каза: \"Не питайте какво вашата страна може да направи за вас – попитайте какво можете да направите вие за вашата страна.\"_\n\n\n\nПриносът към отворения код се случва на всички нива, във всички проекти. Не е нужно да мислите прекалено много какъв точно ще бъде първият ви принос или как ще изглежда.\n\nВместо това започнете, като помислите за проектите, които вече използвате или искате да използвате. Проектите, за които ще участвате активно, са тези, към които се връщате.\n\nВ рамките на тези проекти, всеки път, когато се хванете, че мислите, че нещо може да бъде по-добро или различно, действайте според инстинкта си.\n\nОтвореният код не е изключителен клуб; направено е от хора точно като вас. \"Отворен код\" е просто фантастичен термин за третиране на световните проблеми като поправими.\n\nМоже да сканирате README и да намерите повредена връзка или правописна грешка. Или сте нов потребител и сте забелязали, че нещо е счупено, или проблем, който смятате, че наистина трябва да бъде в документацията. Вместо да го игнорирате и да продължите напред, или да помолите някой друг да го поправи, вижте дали можете да помогнете, като се включите. Това е смисълът на отворения код!\n\n> Според проучване, проведено от Игор Щайнмахер и други изследователи на компютърните науки, [28% от случайните приноси](https://www.igor.pro.br/publica/papers/saner2016.pdf) в отворен код са документация, като като корекции на печатни грешки, преформатиране или писане на превод.\n\nАко търсите съществуващи проблеми, които можете да коригирате, всеки проект с отворен код има страница `/contribute`, която подчертава лесни за начинаещи проблеми, с които можете да започнете. Отидете до главната страница на хранилището в GitHub и добавете `/contribute` в края на URL адреса (например [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).\n\nМожете също да използвате един от следните ресурси, за да ви помогне да откриете и допринесете за нови проекти:\n\n* [GitHub Explore](https://github.com/explore/)\n* [Open Source Friday](https://opensourcefriday.com)\n* [First Timers Only](https://www.firsttimersonly.com/)\n* [CodeTriage](https://www.codetriage.com/)\n* [24 Pull Requests](https://24pullrequests.com/)\n* [Up For Grabs](https://up-for-grabs.net/)\n* [First Contributions](https://firstcontributions.github.io)\n* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)\n* [OpenSauced](https://opensauced.pizza/)\n\n### Контролен списък, преди да допринесете\n\nКогато намерите проект, за който искате да допринесете, направете бързо сканиране, за да се уверите, че проектът е подходящ за приемане на приноси. В противен случай вашата упорита работа може никога да не получи отговор.\n\nЕто един удобен контролен списък, за да оцените дали даден проект е добър за нови сътрудници.\n\n**Отговаря на определението за отворен код**\n\n
\n \n \n
\n\n**Проектът активно приема вноски**\n\nПогледнете активността на комит в главния клон. В GitHub можете да видите тази информация в раздела Insights на началната страница на хранилище, като например [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\nСлед това разгледайте проблемите на проекта.\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\nСега направете същото за заявките за изтегляне на проекта.\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n**Проектът е приветлив**\n\nПроект, който е приятелски настроен и гостоприемен, сигнализира, че те ще бъдат възприемчиви към нови сътрудници.\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n\n\n## Как да изпратите принос\n\nНамерихте проект, който харесвате, и сте готови да дадете своя принос. Най-накрая! Ето как да получите своя принос по правилния начин.\n\n### Ефективна комуникация\n\nНезависимо дали сте сътрудник еднократно, или се опитвате да се присъедините към общност, работата с други е едно от най-важните умения, които ще развиете в отворен код.\n\n\n\nПреди да отворите проблем или заявка за изтегляне, или да зададете въпрос в чата, имайте предвид тези моменти, за да помогнете на вашите идеи да се реализират ефективно.\n\n**Дайте контекст.** Помогнете на другите да навлязат бързо. Ако попаднете на грешка, обяснете какво се опитвате да направите и как да я възпроизведете. Ако предлагате нова идея, обяснете защо смятате, че би била полезна за проекта (не само за вас!).\n\n> 😇 _\"X не се случва, когато направя Y\"_\n>\n> 😢 _\"X е повреден! Моля, поправете го.\"_\n\n**Напишете си домашното предварително.** Добре е да не знаете нещата, но покажете, че сте опитали. Преди да поискате помощ, не забравяйте да проверите README на проекта, документацията, проблемите (отворени или затворени), пощенския списък и потърсете в интернет за отговор. Хората ще го оценят, когато демонстрирате, че се опитвате да учите.\n\n> 😇 _\"Не съм сигурен как да внедря X. Проверих помощните документи и не намерих никакви споменавания.\"_\n>\n> 😢 _\"Как да направя X?\"_\n\n**Поддържайте заявките кратки и директни.** Подобно на изпращането на имейл, всеки принос, без значение колко прост или полезен, изисква преглед от някой друг. Много проекти имат повече входящи заявки, отколкото хора, които могат да помогнат. Бъдете кратки. Ще увеличите шанса някой да може да ви помогне.\n\n> 😇 _\"Бих искал да напиша урок за API.\"_\n>\n> 😢 _\"Онзи ден карах по магистралата и спрях за газ и тогава ми хрумна тази невероятна идея за нещо, което трябва да направим, но преди да обясня това, нека ви покажа...\"_\n\n**Пазете цялата комуникация публична.** Въпреки че е изкушаващо, не се свързвайте лично с поддържащите, освен ако не трябва да споделите чувствителна информация (като проблем със сигурността или сериозно нарушение на поведението). Когато поддържате разговора публичен, повече хора могат да научат и да се възползват от вашия обмен. Дискусиите могат сами по себе си да бъдат принос.\n\n> 😇 _(като коментар) \"@-maintainer Здравейте! Как да продължим с този PR?\"_\n>\n> 😢 _(като имейл) \"Здравейте, съжалявам, че ви безпокоя по имейл, но се чудех дали сте имали възможност да прегледате моя PR\"_\n\n**Добре е да задавате въпроси (но бъдете търпеливи!).** Всеки е бил нов в проекта в някакъв момент и дори опитните сътрудници трябва да навлизат в крак, когато разглеждат нов проект. По същия принцип дори дългогодишните поддържащи не винаги са запознати с всяка част от проекта. Покажете им същото търпение, което бихте искали те да проявяват към вас.\n\n> 😇 _\"Благодаря, че разгледахте тази грешка. Следвах вашите предложения. Ето резултата.\"_\n>\n> 😢 _\"Защо не можете да решите проблема ми? Това не е ли вашият проект?\"_\n\n**Уважавайте решенията на общността.** Вашите идеи може да се различават от приоритетите или визията на общността. Те могат да предложат обратна връзка или да решат да не следват вашата идея. Въпреки че трябва да обсъждате и търсите компромис, поддържащите трябва да живеят с вашето решение по-дълго, отколкото вие ще го направите. Ако не сте съгласни с тяхната посока, винаги можете да работите върху своя собствена вилица или да започнете свой собствен проект.\n\n> 😇 _\"Разочарован съм, че не можете да подкрепите моя случай на употреба, но както обяснихте, той засяга само малка част от потребителите, разбирам защо. Благодаря, че ме изслушахте.\"_\n>\n> 😢 _\"Защо не подкрепите моя случай на употреба? Това е неприемливо!\"_\n\n**Преди всичко го поддържайте елегантно.** Отвореният код се състои от сътрудници от цял свят. Контекстът се губи между езиците, културите, географията и часовите зони. Освен това писмената комуникация прави по-трудно предаването на тон или настроение. Предполагайте добри намерения в тези разговори. Добре е учтиво да отхвърлите идея, да поискате повече контекст или да изясните допълнително позицията си. Просто се опитайте да оставите интернет по-добро място, отколкото когато сте го намерили.\n\n### Събиране на контекст\n\nПреди да предприемете нещо, направете бърза проверка, за да се уверите, че идеята ви не е била обсъждана другаде. Прегледайте README на проекта, проблеми (отворени и затворени), пощенски списък и Stack Overflow. Не е нужно да прекарвате часове в разглеждане на всичко, но бързото търсене на няколко ключови термина върши дълъг път.\n\nАко не можете да намерите идеята си другаде, вие сте готови да предприемете ход. Ако проектът е в GitHub, вероятно ще комуникирате, като направите следното:\n\n* **Повдигане на проблем:** Това е като започване на разговор или дискусия\n* **Заявките за изтегляне** са за започване на работа по решение.\n* **Канали за комуникация:** Ако проектът има определен Discord, IRC или Slack канал, помислете дали да започнете разговор или да поискате разяснение относно вашия принос.\n\nПреди да отворите проблем или заявка за изтегляне, проверете допринасящите документи на проекта (обикновено файл, наречен CONTRIBUTING или в README), за да видите дали трябва да включите нещо конкретно. Например, те могат да поискат да следвате шаблон или да изискват да използвате тестове.\n\nАко искате да направите значителен принос, отворете проблем, който да попитате, преди да работите по него. Полезно е да гледате проекта известно време (в GitHub, [можете да щракнете върху \"Гледане\"](https://help.github.com/articles/watching-repositories/), за да бъдете уведомени за всички разговори) и да стигнете до познавайте членовете на общността, преди да вършите работа, която може да не бъде приета.\n\n\n\n### Отваряне на проблем\n\nОбикновено трябва да отворите проблем в следните ситуации:\n\n* Докладвайте за грешка, която не можете да разрешите сами\n* Обсъдете тема или идея на високо ниво (например общност, визия или политики)\n* Предложете нова функция или друга идея за проект\n\nСъвети за комуникация по проблеми:\n\n* **Ако видите отворен проблем, с който искате да се заемете**, коментирайте проблема, за да уведомите хората, че работите по него. По този начин е по-малко вероятно хората да дублират вашата работа.\n* **Ако даден проблем е открит преди известно време,** е възможно той да се адресира някъде другаде или вече да е разрешен, така че коментирайте, за да поискате потвърждение, преди да започнете работа.\n* **Ако сте отворили проблем, но сте разбрали отговора по-късно сами,** коментирайте проблема, за да уведомите хората, след което затворете проблема. Дори документирането на този резултат е принос към проекта.\n\n### Отваряне на заявка за изтегляне\n\nОбикновено трябва да отворите заявка за изтегляне в следните ситуации:\n\n* Изпратете малки корекции като печатна грешка, повредена връзка или очевидна грешка.\n* Започнете работа по принос, който вече е поискан или който вече сте обсъждали в даден брой.\n\nЗаявката за изтегляне не трябва да представлява завършена работа. Обикновено е по-добре да отворите заявка за изтегляне рано, така че другите да могат да гледат или да дадат обратна връзка за напредъка ви. Просто го отворете като \"чернова\" или маркирайте като \"WIP\" (Работа в процес) в реда за тема или в секциите \"Бележки към рецензентите\", ако са предоставени (или можете просто да създадете свой собствен. Подобно на това: `**## Бележки към рецензента**`). Винаги можете да добавите още ангажименти по-късно.\n\nАко проектът е в GitHub, ето как да изпратите заявка за изтегляне:\n\n* **[Разклонете хранилището](https://guides.github.com/activities/forking/)** и го клонирайте локално. Свържете вашето локално към оригиналното хранилище \"нагоре по веригата\", като го добавите като дистанционно. Изтегляйте често промените от \"нагоре по веригата\", така че да сте в течение, така че когато изпратите заявката си за изтегляне, конфликтите при сливане ще бъдат по-малко вероятни. (Вижте по-подробни инструкции [тук](https://help.github.com/articles/syncing-a-fork/).)\n* **[Създайте клон](https://guides.github.com/introduction/flow/)** за вашите редакции.\n* **Посочете всички съответни проблеми** или подкрепяща документация във вашия PR (например \"Затваря #37.\")\n* **Включете екранни снимки преди и след**, ако вашите промени включват разлики в HTML/CSS. Плъзнете и пуснете изображенията в тялото на вашата заявка за изтегляне.\n* **Тествайте промените си!** Стартирайте промените си срещу всички съществуващи тестове, ако съществуват, и създайте нови, когато е необходимо. Важно е да се уверите, че вашите промени не нарушават съществуващия проект.\n* **Допринесете в стила на проекта** според възможностите си. Това може да означава използване на отстъпи, точка и запетая или коментари по различен начин, отколкото бихте направили във вашето собствено хранилище, но улеснява поддържащия да слива, другите да разбират и поддържат в бъдеще.\n\nАко това е първата ви заявка за изтегляне, вижте [Направете заявка за изтегляне](http://makeapullrequest.com/), която @kentcdodds създаде като видеоурок с инструкции. Можете също така да практикувате да правите заявка за изтегляне в хранилището [Първи вноски](https://github.com/Roshanjossey/first-contributions), създадено от @Roshanjossey.\n\n## Какво се случва, след като изпратите своя принос\n\nПреди да започнем да празнуваме, едно от следните ще се случи, след като изпратите своя принос:\n\n### 😭 Не получавате отговор\n\nНадяваме се, че сте [проверили проекта за признаци на активност](#контролен-списък-преди-да-допринесете), преди да направите принос. Дори при активен проект обаче е възможно вашият принос да не получи отговор.\n\nАко не сте получили отговор повече от седмица, е честно да отговорите учтиво в същата тема, като помолите някого за преглед. Ако знаете името на подходящия човек, който да прегледа вашия принос, можете да го споменете с @ в тази нишка.\n\n**Не се свързвайте лично с този човек**; не забравяйте, че публичната комуникация е жизненоважна за проектите с отворен код.\n\nАко дадете учтиво напомняне и все още не получите отговор, възможно е никой никога да не отговори. Чувството не е страхотно, но не позволявайте това да ви обезсърчава! 😄 Има много възможни причини, поради които не сте получили отговор, включително лични обстоятелства, които може да са извън вашия контрол. Опитайте се да намерите друг проект или начин да допринесете. Ако не друго, това е добра причина да не инвестирате твърде много време в даването на принос, преди другите членове на общността да са ангажирани и отзивчиви.\n\n### 🚧 Някой иска промени във вашия принос\n\nОбичайно е да бъдете помолени да направите промени във вашия принос, независимо дали това е обратна връзка относно обхвата на вашата идея или промени в кода ви.\n\nКогато някой поиска промени, бъдете отзивчиви. Те са отделили време да прегледат приноса ви. Да отвориш PR и да си тръгнеш е лоша форма. Ако не знаете как да правите промени, проучете проблема и след това поискайте помощ, ако имате нужда от нея. Добър пример за това би била [обратната връзка, която друг сътрудник е дал на @a-m-lamb относно тяхната заявка за изтегляне към документите на Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).\n\nАко вече нямате време да работите по проблема поради причини като разговорът продължава от месеци и обстоятелствата ви са се променили или не можете да намерите решение, уведомете поддържащия, за да може отворете проблема за някой друг, като [@RitaDee направи за проблем в хранилището за приложения на OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).\n\n### 👎 Вашият принос не се приема\n\nВашият принос може или не може да бъде приет в крайна сметка. Надяваме се, че вече не сте вложили твърде много работа в него. Ако не сте сигурни защо не е приет, е напълно разумно да помолите поддържащия за обратна връзка и разяснение. В крайна сметка обаче ще трябва да уважите, че това е тяхно решение. Не спорете и не бъдете враждебни. Винаги сте добре дошли да се разклоните и да работите върху собствената си версия, ако не сте съгласни!\n\n### 🎉 Вашият принос се приема\n\nУра! Успешно направихте принос с отворен код!\n\n## Направи го! 🎉\n\nНезависимо дали току-що сте направили първия си принос с отворен код или търсите нови начини да допринесете, надяваме се, че сте вдъхновени да предприемете действие. Дори ако вашият принос не е бил приет, не забравяйте да благодарите, когато поддържащият положил усилия да ви помогне. Отвореният код е направен от хора като вас: един проблем, заявка за изтегляне, коментар или дай пет наведнъж.\n" }, { "path": "_articles/bg/index.html", "content": "---\nlayout: index\ntitle: Ръководства за отворен код\nlang: bg\npermalink: /bg/\n---\n" }, { "path": "_articles/bg/leadership-and-governance.md", "content": "---\nlang: bg\ntitle: Лидерство и управление\ndescription: Разрастващите се проекти с отворен код могат да се възползват от формалните правила за вземане на решения.\nclass: leadership\norder: 6\nimage: /assets/images/cards/leadership.png\nrelated:\n - best-practices\n - metrics\n---\n\n## Разбиране на управлението за вашия разрастващ се проект\n\nВашият проект се разраства, хората са ангажирани и вие сте ангажирани да поддържате това нещо. На този етап може да се чудите как да включите редовни сътрудници на проекта във вашия работен процес, независимо дали става дума за даване на достъп за ангажимент или разрешаване на дебати в общността. Ако имате въпроси, ние имаме отговори.\n\n## Какви са примерите за официални роли, използвани в проекти с отворен код?\n\nМного проекти следват подобна структура за роли на сътрудници и признание.\n\nКакво всъщност означават тези роли обаче, зависи изцяло от вас. Ето няколко типа роли, които може да разпознаете:\n\n* **Поддържащ**\n* **Сътрудник**\n* **Комитер**\n\n**За някои проекти \"поддържащите\"** са единствените хора в проект с достъп за ангажиране. В други проекти те са просто хората, които са изброени в README като поддържащи.\n\nПоддържащият не е задължително да е някой, който пише код за вашия проект. Може да е някой, който е свършил много работа по евангелизирането на вашия проект, или писмена документация, която е направила проекта по-достъпен за другите. Независимо от това, което прави всеки ден, поддържащият вероятно е някой, който се чувства отговорен за посоката на проекта и се е ангажирал да го подобри.\n\n**\"Сътрудник\" може да бъде всеки**, който коментира проблем или заявка за изтегляне, хора, които добавят стойност към проекта (независимо дали става въпрос за сортиране на проблеми, писане на код или организиране на събития), или всеки с обединена заявка за изтегляне (може би най-тясната дефиниция на сътрудник).\n\n\n\n**Терминът \"извършител\"** може да се използва за разграничаване на достъпа за ангажиране, който е специфичен тип отговорност, от други форми на принос.\n\nВъпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#какво-означава-да-допринасяш), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения.\n\n\n\n## Как да формализирам тези лидерски роли?\n\nФормализирането на вашите лидерски роли помага на хората да се чувстват собственост и казва на другите членове на общността към кого да търсят помощ.\n\nЗа по-малък проект определянето на лидери може да бъде толкова просто, колкото добавянето на техните имена към вашия README или текстов файл CONTRIBUTORS.\n\nЗа по-голям проект, ако имате уебсайт, създайте страница на екип или избройте ръководителите на проекта си там. Например [Postgres](https://github.com/postgres/postgres/) има [изчерпателна екипна страница](https://www.postgresql.org/community/contributors/) с кратки профили за всеки участник.\n\nАко вашият проект има много активна общност на сътрудници, можете да сформирате \"основен екип\" от поддържащи или дори подкомитети от хора, които поемат отговорност за различни проблемни области (например сигурност, сортиране на проблеми или поведение на общността). Позволете на хората да се самоорганизират и доброволно изпълняват ролите, които ги вълнуват най-много, вместо да ги възлагат.\n\n\n\nЛидерските екипи може да искат да създадат определен канал (като в IRC) или да се срещат редовно, за да обсъждат проекта (като в Gitter или Google Hangout). Можете дори да направите тези срещи публични, така че други хора да могат да слушат. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), например, [поема работно време всяка седмица](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs).\n\nСлед като сте установили лидерски роли, не забравяйте да документирате как хората могат да ги постигнат! Установете ясен процес за това как някой може да стане поддържащ или да се присъедини към подкомисия във вашия проект и го напишете във вашия GOVERNANCE.md.\n\nИнструменти като [Vossibility](https://github.com/icecrime/vossibility-stack) могат да ви помогнат публично да проследите кой (или не) прави принос към проекта. Документирането на тази информация избягва възприемането на общността, че поддържащите са клика, която взема решенията си частно.\n\nИ накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#споделете-собствеността-върху-вашия-проект).\n\n## Кога трябва да дам на някого достъп за ангажиране?\n\nНякои хора смятат, че трябва да дадете достъп за ангажиране на всеки, който направи принос. Това може да насърчи повече хора да почувстват собственост върху вашия проект.\n\nОт друга страна, особено за по-големи, по-сложни проекти, може да искате да дадете достъп за ангажиране само на хора, които са демонстрирали своя ангажимент. Няма един правилен начин да го направите - направете това, което ви прави най-удобно!\n\nАко вашият проект е в GitHub, можете да използвате [защитени клонове](https://help.github.com/articles/about-protected-branches/), за да управлявате кой може да насочва към определен клон и при какви обстоятелства.\n\n\n\n## Какви са някои от общите структури на управление за проекти с отворен код?\n\nИма три общи структури на управление, свързани с проекти с отворен код.\n\n* **BDFL:** BDFL означава \"Доброжелателен диктатор за цял живот\". При тази структура един човек (обикновено първоначалният автор на проекта) има последната дума за всички основни решения по проекта. [Python](https://github.com/python) е класически пример. По-малките проекти вероятно са BDFL по подразбиране, защото има само един или двама поддържащи. Проект, който произхожда от компания, може също да попадне в категорията BDFL.\n\n* **Меритокрация:** (Забележка: терминът \"меритокрация\" носи отрицателни конотации за някои общности и има [сложна социална и политическа история](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** При меритокрацията на активните участници в проекти (тези, които демонстрират \"заслуги\") се дава официална роля за вземане на решения. Решенията обикновено се вземат въз основа на чист консенсус при гласуване. Концепцията за меритокрация е въведена от [Фондация Apache](https://www.apache.org/); [всички проекти на Apache](https://www.apache.org/index.html#projects-list) са меритокрации. Вноски могат да се правят само от лица, представляващи себе си, а не от компания.\n\n* **Либерален принос:** При либерален модел на принос хората, които вършат най-много работа, се признават за най-влиятелни, но това се основава на текуща работа, а не на исторически принос. Решенията за големи проекти се вземат въз основа на процес на търсене на консенсус (обсъждане на основните оплаквания), а не на чисто гласуване, и се стремят да включват възможно най-много гледни точки на общността. Популярни примери за проекти, които използват либерален модел на принос, включват [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/).\n\nКое трябва да използвате? От теб зависи! Всеки модел има предимства и компромиси. И въпреки че в началото може да изглеждат доста различни, и трите модела имат повече общо, отколкото изглежда. Ако се интересувате от приемането на един от тези модели, вижтеthese templates:\n\n* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)\n* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)\n* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)\n\n## Имам ли нужда от документи за управление, когато стартирам проекта си?\n\nНяма подходящ момент да запишете управлението на вашия проект, но е много по-лесно да го дефинирате, след като видите как се развива динамиката на вашата общност. Най-добрата (и най-трудната) част от управлението с отворен код е, че е оформено от общността!\n\nНякои ранни документи обаче неизбежно ще допринесат за управлението на вашия проект, така че започнете да записвате каквото можете. Например, можете да дефинирате ясни очаквания за поведение или как работи вашият процес на сътрудник, дори при стартирането на вашия проект.\n\nАко сте част от компания, стартираща проект с отворен код, струва си да проведете вътрешна дискусия преди стартирането за това как вашата компания очаква да поддържа и да взема решения за напредъка на проекта. Можете също така да искате публично да обясните нещо конкретно за това как вашата компания ще (или няма!) да бъде включена в проекта.\n\n\n\n## Какво се случва, ако корпоративните служители започнат да изпращат вноски?\n\nУспешните проекти с отворен код се използват от много хора и компании и някои компании може в крайна сметка да имат потоци от приходи, които в крайна сметка да са свързани с проекта. Например, една компания може да използва кода на проекта като един компонент в предлагането на търговска услуга.\n\nТъй като проектът се използва по-широко, хората, които имат опит в него, стават все по-търсени - вие може да сте един от тях! - и понякога ще получават заплащане за работата, която вършат в проекта.\n\nВажно е търговската дейност да се третира като нормална и просто като още един източник на енергия за развитие. Разбира се, платените разработчици не трябва да получават специално отношение спрямо неплатените; всеки принос трябва да бъде оценен според техническите си качества. Въпреки това, хората трябва да се чувстват комфортно да участват в търговска дейност и да се чувстват комфортно да посочват своите случаи на употреба, когато спорят в полза на определено подобрение или функция.\n\n\"Комерсиален\" е напълно съвместим с \"отворен код\". \"Търговски\" просто означава, че някъде има замесени пари – че софтуерът се използва в търговията, което е все по-вероятно, тъй като даден проект получава приемане. (Когато софтуер с отворен код се използва като част от продукт с неотворен код, цялостният продукт все още е \"патентован\" софтуер, въпреки че, подобно на отворен код, може да се използва за търговски или нетърговски цели.)\n\nКато всеки друг, комерсиално мотивираните разработчици печелят влияние в проекта чрез качеството и количеството на техния принос. Очевидно програмист, който получава заплащане за времето си, може да е в състояние да направи повече от някой, който не получава заплащане, но това е добре: плащането е само един от многото възможни фактори, които могат да повлияят на това колко прави някой. Поддържайте дискусиите по проекта си фокусирани върху приноса, а не върху външните фактори, които позволяват на хората да направят този принос.\n\n## Нуждая ли се от юридическо лице, което да поддържа моя проект?\n\nНямате нужда от юридическо лице, за да поддържате вашия проект с отворен код, освен ако не боравите с пари.\n\nНапример, ако искате да създадете търговски бизнес, ще искате да създадете C Corp или LLC (ако сте базирани в САЩ). Ако просто работите по договор, свързан с вашия проект с отворен код, можете да приемате пари като едноличен собственик или да създадете LLC (ако сте базирани в САЩ).\n\nАко искате да приемате дарения за вашия проект с отворен код, можете да настроите бутон за дарение (с помощта на PayPal или Stripe, например), но парите няма да се приспадат от данъци, освен ако не сте квалифицирана организация с нестопанска цел (501c3, ако вие сте в САЩ).\n\nМного проекти не желаят да преминат през неприятностите при създаването на организация с нестопанска цел, така че вместо това намират фискален спонсор с нестопанска цел. Фискален спонсор приема дарения от ваше име, обикновено в замяна на процент от дарението. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) и [Open Collective](https://opencollective.com/opensource) са примери за организации, които служат като фискални спонсори за проекти с отворен код.\n\n\n\nАко вашият проект е тясно свързан с определен език или екосистема, може да има и свързана софтуерна основа, с която можете да работите. Например [Python Software Foundation](https://www.python.org/psf/) помага за поддръжката на [PyPI](https://pypi.org/), мениджъра на пакети на Python и [Node.js Foundation](https://foundation.nodejs.org/) помага за поддръжката на [Express.js](https://expressjs.com/), базирана на възли рамка.\n" }, { "path": "_articles/bg/legal.md", "content": "---\nlang: bg\ntitle: Правната страна на отворения код\ndescription: Всичко, което някога сте се чудили за правната страна на отворения код, и няколко неща, които не сте се чудили.\nclass: legal\norder: 10\nimage: /assets/images/cards/legal.png\nrelated:\n - contribute\n - leadership\n---\n\n## Разбиране на правните последици от отворения код\n\nСподелянето на вашата творческа работа със света може да бъде вълнуващо и възнаграждаващо изживяване. Това може да означава и куп правни неща, за които не сте знаели, че трябва да се тревожите. За щастие, с това ръководство не е нужно да започвате от нулата. (Преди да се задълбочите, не забравяйте да прочетете нашия [отказ от отговорност](/notices/).)\n\n## Защо хората се интересуват толкова много от правната страна на отворения код?\n\nРадвам се, че попита! Когато правите творческо произведение (като писане, графики или код), това произведение е под изключителни авторски права по подразбиране. Тоест законът предполага, че като автор на вашето произведение вие имате думата какво другите могат да правят с него.\n\nКато цяло това означава, че никой друг не може да използва, копира, разпространява или модифицира вашата работа, без да бъде изложен на риск от премахване, разклащане или съдебни спорове.\n\nОтвореният код обаче е необичайно обстоятелство, тъй като авторът очаква други да използват, променят и споделят работата. Но тъй като правното подразбиране все още е изключително авторско право, трябва изрично да дадете тези разрешения с лиценз.\n\nТези правила се прилагат и когато някой допринася за вашия проект. Без лиценз или друго споразумение всички приноси са изключителна собственост на техните автори. Това означава, че никой – дори вие – не може да използва, копира, разпространява или променя техния принос.\n\nИ накрая, вашият проект може да има зависимости с лицензионни изисквания, за които не сте знаели. Общността на вашия проект или политиките на вашия работодател може също да изискват вашият проект да използва конкретни лицензи с отворен код. Ще разгледаме тези ситуации по-долу.\n\n## Публичните GitHub проекти с отворен код ли са?\n\nКогато [създадете нов проект](https://help.github.com/articles/creating-a-new-repository/) в GitHub, имате опцията да направите хранилището **частно** или **публично**.\n\n![Създаване на хранилище](/assets/images/legal/repo-create-name.png)\n\n**Да направите своя проект в GitHub публичен не е същото като да лицензирате проекта си.** Публичните проекти са обхванати от [Условията за ползване на GitHub](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), което позволява на другите да преглеждат и разклоняват вашия проект, но иначе работата ви идва без разрешения.\n\nАко искате други да използват, разпространяват, модифицират или допринасят обратно към вашия проект, трябва да включите лиценз с отворен код. Например, някой не може законно да използва която и да е част от вашия GitHub проект в своя код, дори ако е публичен, освен ако изрично не му дадете правото да го направи.\n\n## Просто ми дайте обобщение за това, от което се нуждая, за да защитя проекта си.\n\nИмате късмет, защото днес лицензите за отворен код са стандартизирани и лесни за използване. Можете да копирате и поставите съществуващ лиценз директно във вашия проект.\n\n[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) са [популярни лицензи за отворен код](https://innovationgraph.github.com/global-metrics/licenses), но има и други опции за избор. Можете да намерите пълния текст на тези лицензи и инструкции как да ги използвате на [choosealicense.com](https://choosealicense.com/).\n\nКогато създадете нов проект в GitHub, ще бъдете [помолени да добавите лиценз](https://help.github.com/articles/open-source-licensing/).\n\n\n\n## Кой лиценз с отворен код е подходящ за моя проект?\n\nТрудно е да сгрешите с [MIT License](https://choosealicense.com/licenses/mit/), ако започвате с празен лист. Той е кратък, лесен за разбиране и позволява на всеки да прави каквото и да е, стига да пази копие от лиценза, включително вашето известие за авторски права. Ще можете да пуснете проекта под различен лиценз, ако някога се наложи.\n\nВ противен случай изборът на правилния лиценз с отворен код за вашия проект зависи от вашите цели.\n\nВашият проект много вероятно има (или ще има) **зависимости**, всяка от които ще има собствен лиценз с отворен код с условия, които трябва да спазвате. Например, ако сте с отворен код за Node.js проект, вероятно ще използвате библиотеки от Node Package Manager (npm).\n\nЗависимости с **разрешителни лицензи** като [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc) и [BSD](https://choosealicense.com/licenses/bsd-3-clause) ви позволяват да лицензирате проекта си както искате.\n\nЗависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със \"силен\" лиценз за копиралефт като [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), или [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) изисква да изберете идентичен или [съвместим лиценз](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) за вашия проект. Библиотеки с \"ограничен\" или \"слаб\" лиценз за копиралефт като [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) и [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) могат да бъдат включени в проекти с произволен лиценз, при условие че следвате [допълнителните правила](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) посочват те.\n \nМожете също така да разгледате **общностите**, които се надявате да използвате и да допринесете за вашия проект:\n\n* **Искате ли вашият проект да бъде използван като зависимост от други проекти?** Вероятно най-добре е да използвате най-популярния лиценз в съответната общност. Например [MIT](https://choosealicense.com/licenses/mit/) е най-популярният лиценз за [npm библиотеки](https://libraries.io/search?platforms=NPM).\n* **Искате ли вашият проект да се хареса на големия бизнес?** Големият бизнес може да се утеши от изричен патентен лиценз от всички сътрудници. В този случай [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) покрива вас (и тях).\n* **Искате ли вашият проект да се хареса на сътрудници, които не искат техният принос да се използва в софтуер със затворен код?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (ако те също не желаят да допринасят за услуги със затворен код) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) ще мине добре.\n\nВашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#моят-проект-има-ли-нужда-от-споразумение-за-допълнителен-сътрудник) за насоки.\n\nКогато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense.com/non-software/).\n\n## Какво ще стане, ако искам да сменя лиценза на моя проект?\n\nПовечето проекти никога не се нуждаят от промяна на лицензи. Но понякога обстоятелствата се променят.\n\nНапример, докато вашият проект расте, той добавя зависимости или потребители, или вашата компания променя стратегии, всяка от които може да изисква или иска различен лиценз. Освен това, ако сте пропуснали да лицензирате проекта си от самото начало, добавянето на лиценз е на практика същото като промяната на лицензите. Има три основни неща, които трябва да имате предвид, когато добавяте или променяте лиценза на вашия проект:\n\n**Сложно е.** Определянето на съвместимостта и съответствието на лиценза и кой притежава авторските права може да стане сложно и объркващо много бързо. Преминаването към нов, но съвместим лиценз за нови версии и приноси е различно от повторното лицензиране на всички съществуващи приноси. Включете юридическия си екип при първия намек за всяко желание за промяна на лицензи. Дори ако имате или можете да получите разрешение от притежателите на авторските права на вашия проект за промяна на лиценза, помислете за въздействието на промяната върху другите потребители и сътрудници на вашия проект. Мислете за промяната на лиценза като за \"управленско събитие\" за вашия проект, което е по-вероятно да протече гладко с ясна комуникация и консултация със заинтересованите страни във вашия проект. Още повече причина да изберете и използвате подходящ лиценз за вашия проект от самото му начало!\n\n**Съществуващият лиценз на вашия проект.** Ако съществуващият лиценз на вашия проект е съвместим с лиценза, който искате да промените, можете просто да започнете да използвате новия лиценз. Това е така, защото ако лиценз A е съвместим с лиценз B, вие ще спазвате условията на A, докато спазвате условията на B (но не непременно обратното). Така че, ако в момента използвате разрешителен лиценз (напр. MIT), можете да промените на лиценз с повече условия, стига да запазите копие от лиценза на MIT и всички свързани бележки за авторски права (т.е. да продължите да спазвате минималните условия на лиценза на MIT). Но ако текущият ви лиценз не е разрешителен (напр. copyleft или нямате лиценз) и не сте единственият притежател на авторските права, не можете просто да промените лиценза на вашия проект на MIT. По същество, с разрешителен лиценз, притежателите на авторските права на проекта са дали предварително разрешение за промяна на лицензите.\n\n**Съществуващи носители на авторски права на вашия проект.** Ако вие сте единственият сътрудник на вашия проект, тогава вие или вашата компания сте единственият носител на авторските права на проекта. Можете да добавите или промените какъвто лиценз вие или вашата компания искате. В противен случай може да има други притежатели на авторски права, от които се нуждаете от съгласие, за да промените лицензите. Кои са те? [Хората, които имат ангажименти във вашия проект](https://github.com/thehale/git-authorship) е добро място да започнете. Но в някои случаи авторските права ще се държат от работодателите на тези хора. В някои случаи хората ще са направили само минимален принос, но няма твърдо и бързо правило, че приносите под определен брой редове код не са обект на авторско право. Какво да правя? Зависи. За сравнително малък и млад проект може да е възможно да накарате всички съществуващи сътрудници да се съгласят с промяна на лиценза в проблем или заявка за изтегляне. За големи и дълготрайни проекти може да се наложи да потърсите много сътрудници и дори техните наследници. Mozilla отне години (2001-2006), за да прелицензира Firefox, Thunderbird и свързания софтуер.\n\nКато алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза.\n\n## Моят проект има ли нужда от споразумение за допълнителен сътрудник?\n\nВероятно не. За по-голямата част от проектите с отворен код лицензът с отворен код имплицитно служи както за входящ (от сътрудници), така и за изходящ (към други сътрудници и потребители) лиценз. Ако вашият проект е в GitHub, Общите условия на GitHub правят \"inbound=outbound\" [изрично по подразбиране](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license).\n\nДопълнително споразумение за сътрудник – често наричано Споразумение за лиценз на сътрудник (CLA) – може да създаде административна работа за поддържащите проекта. Колко работа добавя едно споразумение зависи от проекта и изпълнението. Обикновено споразумение може да изисква сътрудниците да потвърдят с едно щракване, че имат правата, необходими за принос съгласно лиценза за отворен код на проекта. По-сложно споразумение може да изисква правен преглед и подписване от работодателите на сътрудниците.\n\nОсвен това, чрез добавяне на \"бумащина\", която според някои е ненужна, трудна за разбиране или несправедлива (когато получателят на споразумението получава повече права от сътрудниците или обществеността чрез лиценза за отворен код на проекта), допълнително споразумение за сътрудник може да се възприеме като недружелюбно към общността на проекта.\n\n\n\nНякои ситуации, в които може да искате да обмислите споразумение за допълнителен сътрудник за вашия проект, включват:\n\n* Вашите адвокати искат всички сътрудници изрично да приемат (_подписват_, онлайн или офлайн) условията за принос, може би защото смятат, че самият лиценз за отворен код не е достатъчен (въпреки че е!). Ако това е единствената грижа, споразумение за сътрудник, което потвърждава лиценза за отворен код на проекта, трябва да е достатъчно. [Лицензионното споразумение за jQuery Individual Contributor](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) е добър пример за леко споразумение за допълнителен сътрудник.\n* Вие или вашите адвокати искате разработчиците да декларират, че всеки ангажимент, който правят, е разрешен. Изискването за [Сертификат за произход на разработчици](https://developercertificate.org/) е колко проекта постигат това. Например общността Node.js [използва](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) от техния предишен CLA. Една проста опция за автоматизиране на прилагането на DCO във вашето хранилище е [DCO Probot](https://github.com/probot/dco).\n* Вашият проект използва лиценз с отворен код, който не включва изрично предоставяне на патент (като MIT) и се нуждаете от разрешение за патент от всички сътрудници, някои от които може да работят за компании с големи патентни портфейли, които биха могли да бъдат използвани за насочване към вас или други сътрудници и потребители на проекта. [Лицензионното споразумение за личен сътрудник на Apache](https://www.apache.org/licenses/icla.pdf) е често използвано допълнително споразумение за сътрудник, което има предоставяне на патент, отразяващо това, което се намира в Лиценза на Apache 2.0.\n* Вашият проект е под лиценз за копиралефт, но също така трябва да разпространявате собствена версия на проекта. Ще трябва всеки сътрудник да ви прехвърли авторски права или да ви предостави (но не на обществеността) разрешителен лиценз. [Споразумението за сътрудник на MongoDB](https://www.mongodb.com/legal/contributor-agreement) е пример за този тип споразумение.\n* Смятате, че вашият проект може да се наложи да промени лицензите през целия си живот и искате участниците да се съгласят предварително с такива промени.\n\nАко все пак трябва да използвате допълнително споразумение за сътрудници с вашия проект, обмислете използването на интеграция като [CLA помощник](https://github.com/cla-assistant/cla-assistant), за да сведете до минимум разсейването на сътрудниците.\n\n## Какво трябва да знае правният екип на моята компания?\n\nАко пускате проект с отворен код като служител на компанията, първо, вашият правен екип трябва да знае, че сте проект с отворен код.\n\nЗа добро или лошо, помислете да ги уведомите дори ако това е личен проект. Вероятно имате \"споразумение за интелектуална собственост на служителите\" с вашата компания, което им дава известен контрол върху вашите проекти, особено ако изобщо са свързани с бизнеса на компанията или използвате ресурси на компанията за разработване на проекта. Вашата компания _би трябвало_ лесно да ви даде разрешение и може би вече го е направила чрез удобно за служителите IP споразумение или фирмена политика. Ако не, можете да преговаряте (например да обясните, че вашият проект служи на целите на компанията за професионално обучение и развитие за вас) или да избягвате да работите по проекта си, докато не намерите по-добра компания.\n\n**Ако търсите проект с отворен код за вашата компания**, тогава определено ги уведомете. Вашият правен екип вероятно вече има политики за това какъв лиценз с отворен код (и може би допълнително споразумение за сътрудници) да използва въз основа на бизнес изискванията и експертния опит на компанията за гарантиране, че вашият проект е в съответствие с лицензите на неговите зависимости. Ако не, вие и те имате късмет! Вашият правен екип трябва да е нетърпелив да работи с вас, за да разберете тези неща. Някои неща, за които да помислите:\n\n* **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](https://choosealicense.com/no-license/#for-users), и ако не можете да получите такъв, спрете да използвате техния код във вашия проект.\n\n* **Търговски тайни:** Помислете дали има нещо в проекта, което компанията не иска да направи достъпно за широката общественост. Ако е така, можете да отворите останалата част от проекта си, след като извлечете материала, който искате да запазите поверителен.\n\n* **Патенти:** Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал [публично разкриване](https://en.wikipedia.org/wiki/Public_disclosure)? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници ([вижте по-горе](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)).\n\n* **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#избягване-на-конфликти-с-имена). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код.\n\n* **Поверителност:** Вашият проект събира ли данни за потребители? \"Домашен телефон\" към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби.\n\nАко пускате първия проект с отворен код на вашата компания, горното е повече от достатъчно, за да преминете (но не се притеснявайте, повечето проекти не би трябвало да предизвикват големи притеснения).\n\nВ по-дългосрочен план вашият правен екип може да направи повече, за да помогне на компанията да извлече повече от участието си в отворен код и да остане в безопасност:\n\n* **Правила за приноса на служителите:** Помислете за разработване на корпоративна политика, която определя как вашите служители допринасят за проекти с отворен код. Ясната политика ще намали объркването сред вашите служители и ще им помогне да допринесат за проекти с отворен код в най-добрия интерес на компанията, независимо дали като част от работата им или в свободното им време. Добър пример е [Модел IP и политика за принос с отворен код](https://ospo.co/blog/crafting-your-open-source-contribution-policy/) на Rackspace.\n\n\n\n* **Какво да публикувате:** [(Почти) всичко?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Ако вашият правен екип разбира и е инвестирани в стратегията на вашата компания за отворен код, те ще могат най-добре да помогнат, вместо да пречат на вашите усилия.\n* **Съответствие:** Дори ако вашата компания не пуска проекти с отворен код, тя използва чужд софтуер с отворен код. [Осъзнаването и процесът](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) могат да предотвратят главоболия, забавяния на продукти и съдебни дела .\n\n\n\n* **Патенти:** Вашата компания може да пожелае да се присъедини към [Open Invention Network](https://www.openinventionnetwork.com/), споделен защитен патентен пул за защита на използването на големи проекти с отворен код от членовете, или да проучи друго [алтернативно патентно лицензиране](https://www.eff.org/document/hacking-patent-system-2016).\n* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#нуждая-ли-се-от-юридическо-лице-което-да-поддържа-моя-проект).\n" }, { "path": "_articles/bg/maintaining-balance-for-open-source-maintainers.md", "content": "---\nlang: bg\ntitle: Поддържане на баланс за поддържащите отворен код\ndescription: Съвети за самообслужване и избягване на прегаряне като поддържащ.\nclass: balance\norder: 0\nimage: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png\n---\n\nТъй като популярността на проекта с отворен код нараства, става важно да поставите ясни граници, които да ви помогнат да поддържате баланс, за да останете освежени и продуктивни в дългосрочен план.\n\nЗа да придобием представа за опита на поддържащите и техните стратегии за намиране на баланс, проведохме семинар с 40 членове на общността на поддържащите, което ни позволи да се поучат от техния опит от първа ръка с бърнаут в отворен код и практиките, които са им помогнали да поддържат баланс в работата си. Тук влиза в действие концепцията за лична екология.\n\nИ така, какво е лична екология? Като описано от Rockwood Leadership Institute, то включва \"поддържане на баланс, темпо и ефективност за поддържане на енергията ни през целия живот.\" Това рамкира нашите разговори, помагайки на поддържащите да разпознаят своите действия и приноси като части от по-голяма екосистема, която се развива с течение на времето. Бърнаут, синдром в резултат на хроничен стрес на работното място, както [дефиниран от СЗО](https://icd.who.int/browse/2025-01/foundation/en#129180281) , не е необичайно сред поддържащите. Това често води до загуба на мотивация, невъзможност за фокусиране и липса на съпричастност към сътрудниците и общността, с която работите.\n\n\n\nВъзприемайки концепцията за лична екология, поддържащите могат проактивно да избягват прегарянето, да дават приоритет на грижата за себе си и да поддържат чувство за баланс, за да вършат най-добрата си работа.\n\n## Съвети за самообслужване и избягване на прегаряне като поддържащ персонал:\n\n### Определете вашите мотивации за работа с отворен код\n\nОтделете време, за да помислите кои части от поддръжката с отворен код ви зареждат с енергия. Разбирането на вашата мотивация може да ви помогне да приоритизирате работата по начин, който ви държи ангажирани и готови за нови предизвикателства. Независимо дали става въпрос за положителната обратна връзка от потребителите, радостта от сътрудничеството и общуването с общността или удовлетворението от гмуркането в кода, разпознаването на вашите мотивации може да ви помогне да насочите фокуса си.\n\n### Помислете какво ви кара да излизате от баланс и да сте стресирани\n\nВажно е да разберем какво ни кара да изгаряме. Ето няколко общи теми, които видяхме сред поддържащите отворен код:\n\n* **Липса на положителна обратна връзка:** Много по-вероятно е потребителите да се свържат, когато имат оплакване. Ако всичко работи добре, те са склонни да мълчат. Може да е обезкуражаващо да видите нарастващ списък от проблеми без положителната обратна връзка, показваща как вашият принос прави разликата.\n\n\n\n* **Да не казваш \"не\":** Може да е лесно да поемеш повече отговорности, отколкото би трябвало за проект с отворен код. Независимо дали е от потребители, сътрудници или други поддържащи – ние не винаги можем да оправдаем техните очаквания.\n\n\n\n* **Да работиш сам:** Да си поддържащ може да бъде невероятно самотен. Дори ако работите с група поддържащи, последните няколко години бяха трудни за свикване на разпределени екипи лично.\n\n\n\n* **Няма достатъчно време или ресурси:** Това е особено вярно за поддържащи доброволци, които трябва да жертват свободното си време, за да работят по проект.\n\n\n\n* **Противоречиви изисквания:** Отвореният код е пълен с групи с различни мотивации, които могат да бъдат трудни за ориентиране. Ако ви се плаща да работите с отворен код, интересите на вашия работодател понякога могат да бъдат в противоречие с общността.\n\n\n\n### Внимавайте за признаци на прегаряне\n\nМожете ли да поддържате темпото си 10 седмици? 10 месеца? 10 години?\n\nИма инструменти като [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) от [@shaunagm](https://github.com/shaunagm), които могат да ви помогнат помислете върху текущото си темпо и вижте дали има някакви корекции, които можете да направите. Някои поддържащи също използват технология за носене, за да проследяват показатели като качество на съня и променливост на сърдечната честота (и двете свързани със стреса).\n\n\n\n### От какво се нуждаете, за да продължите да поддържате себе си и общността си?\n\nТова ще изглежда различно за всеки поддържащ и ще се променя в зависимост от вашата фаза от живота и други външни фактори. Но ето няколко теми, които чухме:\n\n* **Разчитайте на общността:** Делегирането и намирането на сътрудници може да облекчи работното натоварване. Наличието на множество точки за контакт за даден проект може да ви помогне да си починете, без да се притеснявате. Свържете се с други поддържащи и по-широката общност – в групи като [Maintainer Community](http://maintainers.github.com/). Това може да бъде чудесен ресурс за партньорска подкрепа и обучение.\n\n Можете също така да търсите начини да се ангажирате с потребителската общност, така че да можете редовно да чувате обратна връзка и да разбирате въздействието на вашата работа с отворен код.\n\n* **Разгледайте финансирането:** Независимо дали търсите малко пари за пица или се опитвате да преминете на пълен работен ден към отворен код, има много ресурси, които да ви помогнат! Като първа стъпка помислете дали да не включите [Спонсорите на GitHub](https://github.com/sponsors), за да позволите на други да спонсорират вашата работа с отворен код. Ако обмисляте да преминете към пълен работен ден, кандидатствайте за следващия кръг на [GitHub Accelerator](http://accelerator.github.com/).\n\n\n\n* **Използвайте инструменти:** Разгледайте инструменти като [GitHub Copilot](https://github.com/features/copilot/) и [GitHub Actions](https://github.com/features/actions), за да автоматизирате светски задачи и освободете времето си за по-значими приноси.\n\n\n\n* **Почивка и презареждане:** Отделете време за вашите хобита и интереси извън отворен код. Вземете почивни дни, за да се отпуснете и да се подмладите – и задайте своя [статус в GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), за да отразява вашата наличност! Добрият нощен сън може да направи голяма разлика в способността ви да поддържате усилията си в дългосрочен план.\n\n Ако намирате определени аспекти от вашия проект за особено приятни, опитайте се да структурирате работата си, така че да можете да я изживявате през целия си ден.\n\n\n\n* **Задайте граници:** Не можете да кажете \"да\" на всяка молба. Това може да бъде толкова просто, колкото да кажете: \"Не мога да стигна до това в момента и нямам планове за бъдещето\" или да посочите какво искате да правите и какво да не правите в README. Например, можете да кажете: \"Аз обединявам само PR-и, които имат ясно изброени причини, поради които са направени\", или \"Преглеждам проблемите само в четвъртък от 18 до 19 часа\". Това определя очакванията за другите и ви дава нещо да посочите в други моменти, за да помогнете за намаляване на изискванията от сътрудници или потребители във вашето време.\n\n\n\n Научете се да сте твърди в спирането на токсичното поведение и негативните взаимодействия. Добре е да не давате енергия на неща, които не ви интересуват.\n\n\n\n\n\nНе забравяйте, че личната екология е постоянна практика, която ще се развива, докато напредвате във вашето пътуване с отворен код. Като приоритизирате грижата за себе си и поддържате чувството за баланс, можете да допринесете за общността с отворен код ефективно и устойчиво, гарантирайки както вашето благополучие, така и успеха на вашите проекти в дългосрочен план.\n\n## Допълнителни ресурси\n\n* [Maintainer Community](http://maintainers.github.com/)\n* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon\n* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg \n* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge\n* [SustainOSS](https://sustainoss.org/)\n* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)\n* [Saying No](https://mikemcquaid.com/saying-no/), Mike McQuaid\n* [Governing Open](https://governingopen.com/)\n* Програмата на семинара е ремиксирана от поредицата на [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/)\n\n## Сътрудници\n\nМного благодаря на всички поддържащи, които споделиха своя опит и съвети с нас за това ръководство!\n\nТова ръководство е написано от [@abbycabs](https://github.com/abbycabs) с принос от: \n\n[@agnostic-apollo](https://github.com/agnostic-apollo)\n[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)\n[@antfu](https://github.com/antfu)\n[@anthonyronda](https://github.com/anthonyronda)\n[@CBID2](https://github.com/CBID2)\n[@Cli4d](https://github.com/Cli4d)\n[@confused-Techie](https://github.com/confused-Techie)\n[@danielroe](https://github.com/danielroe)\n[@Dexters-Hub](https://github.com/Dexters-Hub)\n[@eddiejaoude](https://github.com/eddiejaoude)\n[@Eugeny](https://github.com/Eugeny)\n[@ferki](https://github.com/ferki)\n[@gabek](https://github.com/gabek)\n[@geromegrignon](https://github.com/geromegrignon)\n[@hynek](https://github.com/hynek)\n[@IvanSanchez](https://github.com/IvanSanchez)\n[@karasowles](https://github.com/karasowles)\n[@KoolTheba](https://github.com/KoolTheba)\n[@leereilly](https://github.com/leereilly)\n[@ljharb](https://github.com/ljharb)\n[@nightlark](https://github.com/nightlark)\n[@plarson3427](https://github.com/plarson3427)\n[@Pradumnasaraf](https://github.com/Pradumnasaraf)\n[@RichardLitt](https://github.com/RichardLitt)\n[@rrousselGit](https://github.com/rrousselGit)\n[@sansyrox](https://github.com/sansyrox)\n[@schlessera](https://github.com/schlessera)\n[@shyim](https://github.com/shyim)\n[@smashah](https://github.com/smashah)\n[@ssalbdivad](https://github.com/ssalbdivad)\n[@The-Compiler](https://github.com/The-Compiler)\n[@thehale](https://github.com/thehale)\n[@thisisnic](https://github.com/thisisnic)\n[@tudoramariei](https://github.com/tudoramariei)\n[@UlisesGascon](https://github.com/UlisesGascon)\n[@waldyrious](https://github.com/waldyrious) + много други!\n" }, { "path": "_articles/bg/metrics.md", "content": "---\nlang: bg\ntitle: Показатели за отворен код\ndescription: Вземете информирани решения, за да помогнете на вашия проект с отворен код да процъфтява, като измервате и проследявате неговия успех.\nclass: metrics\norder: 9\nimage: /assets/images/cards/metrics.png\nrelated:\n - finding\n - best-practices\n---\n\n## Защо да измервате нещо?\n\nДанните, когато се използват разумно, могат да ви помогнат да вземете по-добри решения като поддържащ отворен код.\n\nС повече информация можете:\n\n* Разберете как потребителите реагират на нова функция\n* Разберете откъде идват новите потребители\n* Идентифицирайте и решете дали да поддържате извънреден случай на употреба или функционалност\n* Определете количествено популярността на вашия проект\n* Разберете как се използва вашият проект\n* Събирайте пари чрез спонсорства и безвъзмездни средства\n\nНапример [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) открива, че Google Анализ им помага да приоритизират работата:\n\n> Homebrew се предоставя безплатно и се управлява изцяло от доброволци в свободното им време. В резултат на това нямаме ресурсите да направим подробни потребителски проучвания на потребителите на Homebrew, за да решим как най-добре да проектираме бъдещи функции и да дадем приоритет на текущата работа. Анонимните обобщени потребителски анализи ни позволяват да приоритизираме поправки и функции въз основа на това как, къде и кога хората използват Homebrew.\n\nПопулярността не е всичко. Всеки влиза в отворен код по различни причини. Ако целта ви като поддържащ отворен код е да покажете работата си, да сте прозрачни относно кода си или просто да се забавлявате, показателите може да не са важни за вас.\n\nАко се интересувате от разбирането на вашия проект на по-дълбоко ниво, прочетете за начини да анализирате дейността на вашия проект.\n\n## Откритие\n\nПреди някой да може да използва или да допринесе обратно за вашия проект, той трябва да знае, че той съществува. Запитайте се: _хората намират ли този проект?_\n\n![Графика на трафика](/assets/images/metrics/repo_traffic_graphs_tooltip.png)\n\nАко вашият проект се хоства в GitHub, [можете да видите](https://help.github.com/articles/about-repository-graphs/#traffic) колко хора попадат на вашия проект и откъде идват. От страницата на вашия проект щракнете върху \"Прозрения\", след това върху \"Трафик\". На тази страница можете да видите:\n\n* **Общ брой показвания на страници:** Ви казва колко пъти е бил прегледан вашият проект\n\n* **Общ брой уникални посетители:** Ви казва колко души са видели проекта Ви\n\n* **Препоръчващи сайтове:** Ви казва откъде идват посетителите. Този показател може да ви помогне да разберете къде да достигнете до аудиторията си и дали усилията ви за промоция работят.\n\n* **Популярно съдържание:** Ви казва къде отиват посетителите във вашия проект, разбити по показвания на страници и уникални посетители.\n\n[Звездите на GitHub](https://help.github.com/articles/about-stars/) също могат да помогнат за предоставяне на основна мярка за популярност. Въпреки че звездите на GitHub не са непременно свързани с изтегляния и използване, те могат да ви кажат колко хора обръщат внимание на работата ви.\n\nМоже също да искате да [проследите откриваемостта на конкретни места](https://opensource.com/business/16/6/pirate-metrics): например Google PageRank, трафик от препоръчани потребители от уебсайта на вашия проект или препоръчани потребители от други отворени изходни проекти или уебсайтове.\n\n## Използване\n\nХората намират вашия проект в това диво и лудо нещо, което наричаме интернет. В идеалния случай, когато видят вашия проект, те ще се почувстват принудени да направят нещо. Вторият въпрос, който ще искате да зададете е: _хората използват ли този проект?_\n\nАко използвате мениджър на пакети, като npm или RubyGems.org, за разпространение на вашия проект, може да сте в състояние да проследявате изтеглянията на вашия проект.\n\nВсеки мениджър на пакети може да използва малко по-различна дефиниция на \"изтегляне\" и изтеглянията не са непременно свързани с инсталиранията или използването, но предоставя някаква базова линия за сравнение. Опитайте да използвате [Libraries.io](https://libraries.io/), за да проследявате статистическите данни за използването в много популярни мениджъри на пакети.\n\nАко вашият проект е в GitHub, отворете отново страницата \"Трафик\". Можете да използвате [графиката за клониране](https://github.com/blog/1873-clone-graphs), за да видите колко пъти вашият проект е бил клониран за даден ден, разбити на общия брой клонинги и уникални клонинги.\n\n![Графика за клониране](/assets/images/metrics/clone_graph.png)\n\nАко употребата е ниска в сравнение с броя на хората, които са открили вашия проект, трябва да имате предвид два проблема. Или:\n\n* Вашият проект не преобразува успешно вашата аудитория, или\n* Привличате грешната аудитория\n\nНапример, ако вашият проект попадне на първа страница на Hacker News, вероятно ще видите скок в откриването (трафик), но по-нисък процент на реализация, защото достигате до всички в Hacker News. Ако обаче вашият Ruby проект бъде представен на Ruby конференция, е по-вероятно да видите висок процент на реализация от целева аудитория.\n\nОпитайте се да разберете откъде идва вашата аудитория и помолете другите за обратна връзка на страницата на вашия проект, за да разберете с кой от тези два проблема се сблъсквате.\n\nСлед като разберете, че хората използват вашия проект, може да искате да опитате да разберете какво правят с него. Надграждат ли го, като разклоняват вашия код и добавят функции? Използват ли го за наука или за бизнес?\n\n## Задържане\n\nХората намират вашия проект и го използват. Следващият въпрос, който ще искате да си зададете, е: _хората допринасят ли обратно за този проект?_\n\nНикога не е твърде рано да започнете да мислите за сътрудници. Без други хора да се намесят, рискувате да се поставите в нездравословна ситуация, в която вашият проект е _популярен_ (много хора го използват), но не е _поддържан_ (няма достатъчно време за поддръжка, за да отговори на търсенето).\n\nЗадържането също така изисква [приток на нови сътрудници](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), тъй като предишните активни сътрудници в крайна сметка ще продължат напред към други неща.\n\nПримери за показатели на общността, които може да искате да проследявате редовно, включват:\n\n* **Общ брой сътрудници и брой ангажименти на сътрудник:** Ви казва колко сътрудници имате и кой е повече или по-малко активен. В GitHub можете да видите това под \"Прозрения\" -> \"Сътрудници\". В момента тази графика отчита само сътрудници, които са се ангажирали с клона по подразбиране на хранилището.\n\n![Графика на сътрудник](/assets/images/metrics/repo_contributors_specific_graph.png)\n\n* **Първи, случайни и повторни сътрудници:** Помага ви да проследите дали получавате нови сътрудници и дали те се връщат. (Случайните сътрудници са сътрудници с малък брой ангажименти. Дали това е един комит, по-малко от пет ангажимента или нещо друго зависи от вас.) Без нови сътрудници общността на вашия проект може да изпадне в застой.\n\n* **Брой отворени проблеми и отворени заявки за изтегляне:** Ако тези числа станат твърде високи, може да се нуждаете от помощ при сортирането на проблеми и прегледите на кода.\n\n* **Брой _отворени_ проблеми и _отворени_ заявки за изтегляне:** Отворените проблеми означават, че някой се интересува достатъчно от вашия проект, за да отвори проблем. Ако този брой се увеличи с течение на времето, това предполага, че хората се интересуват от вашия проект.\n\n* **Видове приноси:** Например ангажименти, коригиране на правописни грешки или грешки или коментиране на проблем.\n\n\n\n## Поддържаща дейност\n\nИ накрая, ще искате да затворите цикъла, като се уверите, че поддържащите вашия проект са в състояние да се справят с обема на получените вноски. Последният въпрос, който ще искате да си зададете е: _отговарям ли (или ние) на нашата общност?_\n\nНеотзивчивите поддържащи се превръщат в пречка за проекти с отворен код. Ако някой изпрати принос, но никога не получи отговор от поддържащия, той може да се почувства обезсърчен и да напусне.\n\n[Изследване от Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) предполага, че отзивчивостта на поддържащия е критичен фактор за насърчаване на повтарящи се приноси.\n\nПомислете за [проследяване колко време отнема на вас (или на друг поддържащ) да отговорите на приносите](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), дали проблем или заявка за изтегляне. Отговорът не изисква предприемане на действие. Може да бъде толкова просто, колкото да кажете: _\"Благодаря за вашето изпращане! Ще прегледам това през следващата седмица.\"_\n\nМожете също да измерите времето, необходимо за преминаване между етапите в процеса на принос, като например:\n\n* Средно време, през което проблемът остава отворен\n* Дали проблемите се затварят от PRте\n* Дали остарелите проблеми се затварят\n* Средно време за обединяване на заявка за изтегляне\n\n## Използвайте 📊, за да научите за хората\n\nРазбирането на показателите ще ви помогне да изградите активен, разрастващ се проект с отворен код. Дори и да не проследявате всеки показател на таблото за управление, използвайте рамката по-горе, за да фокусирате вниманието си върху типа поведение, което ще помогне на вашия проект да процъфтява.\n\n[CHAOSS](https://chaoss.community/) е гостоприемна общност с отворен код, фокусирана върху анализи, показатели и софтуер за здравето на общността.\n" }, { "path": "_articles/bg/security-best-practices-for-your-project.md", "content": "---\nlang: bg\ntitle: Най-добри практики за сигурност за вашия проект\ndescription: Укрепете бъдещето на вашия проект, като изградите доверие чрез основни практики за сигурност – от многофакторна автентификация (MFA) и сканиране на код до безопасно управление на зависимостите и отчитане на частни уязвимости.\nclass: security-best-practices\norder: -1\nimage: /assets/images/cards/security-best-practices.png\n---\n\nКато оставим настрана грешките и новите функции, дълголетието на един проект зависи не само от неговата полезност, но и от доверието, което печели от своите потребители. Силните мерки за сигурност са важни, за да се запази това доверие. Ето някои важни действия, които можете да предприемете, за да подобрите значително сигурността на вашия проект.\n\n## Уверете се, че всички привилегировани участници са активирали многофакторно удостоверяване (MFA)\n\n### Злонамерен участник, който успее да се представи за привилегирован участник във вашия проект, ще причини катастрофални щети.\n\nСлед като получи привилегирован достъп, този участник може да промени вашия код, за да го накара да извършва нежелани действия (напр. да копае криптовалута), или може да разпространява зловреден софтуер в инфраструктурата на вашите потребители, или може да има достъп до частни хранилища за код, за да открадне интелектуална собственост и чувствителни данни, включително идентификационни данни за други услуги.\n\nMFA предоставя допълнителен слой сигурност срещу поглъщане на акаунт. След като бъде активирана, трябва да влезете с потребителското си име и парола и да предоставите друга форма на удостоверяване, която само вие знаете или до която имате достъп.\n\n## Защитете кода си като част от работния процес на разработка\n\n### Уязвимостите в сигурността на вашия код са по-евтини за отстраняване, когато бъдат открити в началото на процеса, отколкото по-късно, когато се използват в продукцията.\n\nИзползвайте инструмент за статично тестване на сигурността на приложенията (SAST), за да откриете уязвимости в сигурността на вашия код. Тези инструменти работят на ниво код и не се нуждаят от среда за изпълнение, следователно могат да бъдат изпълнени в началото на процеса и могат да бъдат безпроблемно интегрирани в обичайния ви работен процес на разработка, по време на изграждането или по време на фазите на преглед на кода.\n\nВсе едно квалифициран експерт да прегледа вашето хранилище за код, помагайки ви да откриете често срещани уязвимости в сигурността, които биха могли да се крият на видно място, докато кодирате.\n\nКак да изберете вашия SAST инструмент?\nПроверете лиценза: Някои инструменти са безплатни за проекти с отворен код. Например GitHub CodeQL или SemGrep.\nПроверете покритието за вашия(ите) език(ци)\n\n* Изберете такъв, който лесно се интегрира с инструментите, които вече използвате, със съществуващия ви процес. Например, по-добре е, ако предупрежденията са налични като част от съществуващия ви процес и инструмент за преглед на код, вместо да използвате друг инструмент, за да ги видите.\n* Пазете се от фалшиви положителни резултати! Не искате инструментът да ви забавя без причина!\n* Проверете функциите: някои инструменти са много мощни и могат да проследяват дефекти (пример: GitHub CodeQL), някои предлагат генерирани от изкуствен интелект предложения за корекции, а трети улесняват писането на персонализирани заявки (пример: SemGrep).\n\n## Не споделяйте тайните си\n\n### Чувствителни данни, като API ключове, токени и пароли, понякога могат случайно да бъдат добавени към вашето хранилище.\n\nПредставете си следния сценарий: Вие сте администратор на популярен проект с отворен код, в който участват разработчици от цял ​​свят. Един ден, сътрудник, без да знае, добавя към хранилището някои API ключове на услуга на трета страна. Няколко дни по-късно, някой намира тези ключове и ги използва, за да влезе в услугата без разрешение. Услугата е компрометирана, потребителите на вашия проект изпитват прекъсвания и репутацията на проекта ви е засегната. Като администратор, вие сте изправени пред трудните задачи за отмяна на компрометирани тайни, разследване на злонамерени действия, които атакуващият би могъл да извърши с тази тайна, уведомяване на засегнатите потребители и внедряване на корекции.\n\nЗа да се предотвратят подобни инциденти, съществуват решения за \"сканиране на тайни\", които ви помагат да откриете тези тайни в кода си. Някои инструменти като GitHub Secret Scanning и Trufflehog от Truffle Security могат да ви попречат да ги преместите в отдалечени клонове, а някои инструменти автоматично ще отменят някои тайни вместо вас.\n\n## Проверете и актуализирайте зависимостите си\n\n### Зависимостите във вашия проект могат да имат уязвимости, които компрометират сигурността му. Ръчното поддържане на зависимостите актуални може да бъде отнемаща време задача.\n\nПредставете си: проект, изграден върху здравата основа на широко използвана библиотека. Библиотеката по-късно открива голям проблем със сигурността, но хората, които са изградили приложението, използвайки я, не знаят за него. Чувствителни потребителски данни остават изложени на риск, когато атакуващ се възползва от тази слабост и се нахвърли, за да ги грабне. Това не е теоретичен случай. Точно това се случи с Equifax през 2017 г.: Те не успяха да актуализират зависимостта си от Apache Struts след известието, че е открита сериозна уязвимост. Тя беше експлоатирана и скандалният пробив в Equifax засегна данните на 144 милиона потребители.\n\nЗа да предотвратят подобни сценарии, инструменти за анализ на състава на софтуера (SCA), като Dependabot и Renovate, автоматично проверяват вашите зависимости за известни уязвимости, публикувани в публични бази данни като NVD или GitHub Advisory Database, и след това създават заявки за изтегляне, за да ги актуализират до безопасни версии. Поддържането на актуалност с най-новите безопасни версии на зависимостите предпазва вашия проект от потенциални рискове.\n\n## Избягвайте нежелани промени със защитени клонове\n\n### Неограниченият достъп до основните ви клонове може да доведе до случайни или злонамерени промени, които могат да въведат уязвимости или да нарушат стабилността на проекта ви.\n\nНов участник получава достъп за запис в основния клон и случайно публикува промени, които не са тествани. След това се разкрива сериозен пропуск в сигурността, благодарение на последните промени. За да се предотвратят подобни проблеми, правилата за защита на клоновете гарантират, че промените не могат да бъдат публикувани или обединявани във важни клонове, без първо да бъдат прегледани и да преминат през определени проверки за състояние. С тази допълнителна мярка сте в по-голяма безопасност и по-добре, гарантирайки първокласно качество всеки път.\n\n## Настройте механизъм за прием на данни за докладване на уязвимости\n\n### Добра практика е да улесните потребителите си да докладват за грешки, но големият въпрос е: когато тази грешка има въздействие върху сигурността, как могат безопасно да ви я докладват, без да ви поставят в цел за злонамерени хакери?\n\nПредставете си: Изследовател по сигурността открива уязвимост във вашия проект, но не намира ясен или сигурен начин да я докладва. Без определен процес, той може да създаде публичен проблем или да го обсъди открито в социалните медии. Дори и да е добронамерен и да предложи поправка, ако го направи с публична заявка за изтегляне, други ще я видят, преди да бъде обединена! Това публично разкриване ще изложи уязвимостта на злонамерени лица, преди да имате шанс да я отстраните, което потенциално ще доведе до експлойт от нулев ден, атакуващ вашия проект и неговите потребители.\n\n### Политика за сигурност\n\nЗа да избегнете това, публикувайте политика за сигурност. Политиката за сигурност, дефинирана във файл `SECURITY.md`, описва подробно стъпките за докладване на проблеми със сигурността, създава прозрачен процес за координирано разкриване и установява отговорностите на екипа на проекта за справяне с докладваните проблеми. Тази политика за сигурност може да бъде толкова проста, колкото \"Моля, не публикувайте подробности в публичен проблем или PR, изпратете ни личен имейл на security@example.com\", но може да съдържа и други подробности, като например кога могат да очакват да получат отговор от вас. Всичко, което може да помогне за ефективността и ефикасността на процеса на разкриване.\n\n### Частно докладване на уязвимости\n\nНа някои платформи можете да рационализирате и подобрите процеса си на управление на уязвимости, от приемане до излъчване, с частни проблеми. В GitLab това може да се направи с частни проблеми. В GitHub това се нарича частно докладване на уязвимости (PVR). PVR позволява на поддържащите да получават и адресират доклади за уязвимости, всичко това в рамките на платформата GitHub. GitHub автоматично ще създаде частен fork за писане на корекциите и проект на съобщение за сигурност. Всичко това остава поверително, докато не решите да разкриете проблемите и да публикувате корекциите. За да се затвори цикълът, ще бъдат публикувани съобщения за сигурност, които ще информират и защитават всички ваши потребители чрез техния SCA инструмент.\n\n## Заключение: Няколко стъпки за вас, огромно подобрение за вашите потребители\n\nТези няколко стъпки може да ви се сторят лесни или основни, но те са от голяма полза за по-голяма сигурност на вашия проект за неговите потребители, защото ще осигурят защита срещу най-често срещаните проблеми.\n\n## Сътрудници\n\n### Много благодарности на всички администратори, които споделиха своя опит и съвети с нас за това ръководство!\n\nТова ръководство е написано от [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) с приноси от: \n\n[@JLLeitschuh](https://github.com/JLLeitschuh)\n[@intrigus-lgtm](https://github.com/intrigus-lgtm) + много други!\n" }, { "path": "_articles/bg/starting-a-project.md", "content": "---\nlang: bg\ntitle: Стартиране на проект с отворен код\ndescription: Научете повече за света на отворения код и се пригответе да стартирате свой собствен проект.\nclass: beginners\norder: 2\nimage: /assets/images/cards/beginner.png\nrelated:\n - finding\n - building\n---\n\n## \"Какво\" и \"защо\" на отворения код\n\nЗначи обмисляте да започнете с отворен код? Честито! Светът оценява вашия принос. Нека поговорим какво е отворен код и защо хората го правят.\n\n### Какво означава \"отворен код\"?\n\nКогато даден проект е с отворен код, това означава, че **всеки е свободен да използва, изучава, променя и разпространява вашия проект за всякакви цели.** Тези разрешения се прилагат чрез [лиценз за отворен код](https://opensource.org/licenses).\n\nОтвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код.\n\n_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като \"свободен софтуер с отворен код\" (FOSS) или \"безплатен софтуер с отворен код\" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#отворен-код-означава-ли-безплатно).\n\n### Защо хората отварят кода на работата си?\n\n\n\n[Има много причини](https://ben.balter.com/2015/11/23/why-open-source/), поради които дадено лице или организация би искала да отвори проект с отворен код. Някои примери включват:\n\n* **Сътрудничество:** Проектите с отворен код могат да приемат промени от всеки по света. [Exercism](https://github.com/exercism/), например, е платформа за упражнения по програмиране с над 350 участници.\n\n* **Приемане и ремиксиране:** Проектите с отворен код могат да се използват от всеки за почти всякакви цели. Хората дори могат да го използват за изграждане на други неща. [WordPress](https://github.com/WordPress), например, стартира като разклонение на съществуващ проект, наречен [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).\n\n* **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) или [Съединените щати](https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Да шифроваме](https://github.com/letsencrypt).\n\nОтвореният код също не е само за софтуер. Можете да отворите всичко - от набори от данни до книги. Разгледайте [GitHub Explore](https://github.com/explore) за идеи какво още можете да отворите.\n\n### Отворен код означава ли \"безплатно\"?\n\nЕдно от най-големите предимства на отворения код е, че не струва пари. \"Безплатно\" обаче е страничен продукт от общата стойност на отворения код.\n\nТъй като [лицензът с отворен код изисква](https://opensource.org/definition-annotated/) всеки да може да използва, променя и споделя вашия проект за почти всякакви цели, самите проекти обикновено са безплатни. Ако използването на проекта струва пари, всеки може законно да направи копие и вместо това да използва безплатната версия.\n\nВ резултат на това повечето проекти с отворен код са безплатни, но \"безплатно\" не е част от определението за отворен код. Има начини за таксуване за проекти с отворен код индиректно чрез двойно лицензиране или ограничени функции, като същевременно се спазва официалното определение за отворен код.\n\n## Трябва ли да стартирам собствен проект с отворен код?\n\nКраткият отговор е да, защото независимо от резултата, стартирането на собствен проект е чудесен начин да научите как работи отвореният код.\n\nАко никога преди не сте отваряли проект с отворен код, може да се притеснявате какво ще кажат хората или дали някой изобщо ще забележи. Ако това звучи като вас, не сте сами!\n\nРаботата с отворен код е като всяка друга творческа дейност, независимо дали е писане или рисуване. Може да ви е страшно да споделяте работата си със света, но единственият начин да станете по-добри е да практикувате – дори и да нямате публика.\n\nАко все още не сте убедени, отделете малко време, за да помислите какви може да са вашите цели.\n\n### Поставяне на вашите цели\n\nЦелите могат да ви помогнат да разберете върху какво да работите, на какво да кажете \"не\" и къде имате нужда от помощ от другите. Започнете, като се запитате _защо използвам този проект с отворен код?_\n\nНяма един правилен отговор на този въпрос. Може да имате множество цели за един проект или различни проекти с различни цели.\n\nАко единствената ви цел е да покажете работата си, може дори да не искате принос и дори да го кажете във вашия README. От друга страна, ако искате сътрудници, ще инвестирате време в ясна документация и ще накарате новодошлите да се почувстват добре дошли.\n\n\n\nС разрастването на проекта ви, общността ви може да се нуждае от нещо повече от код - от вас. Отговарянето на проблеми, прегледът на кода и евангелизирането на вашия проект са важни задачи в проект с отворен код.\n\nМакар че времето, което отделяте за задачи, които не са свързани с кодиране, ще зависи от размера и обхвата на вашия проект, вие трябва да сте подготвени като поддържащ да се справите с тях сами или да намерите някой, който да ви помогне.\n\n**Ако сте част от компания, предлагаща проект с отворен код,** се уверете, че вашият проект разполага с необходимите вътрешни ресурси, за да процъфтява. Ще искате да определите кой е отговорен за поддържането на проекта след стартирането и как ще споделите тези задачи с вашата общност.\n\nАко имате нужда от специален бюджет или персонал за промоция, операции и поддържане на проекта, започнете тези разговори отрано.\n\n\n\n### Принос към други проекти\n\nАко целта ви е да научите как да си сътрудничите с други или да разберете как работи отворен код, помислете дали да допринесете за съществуващ проект. Започнете с проект, който вече използвате и харесвате. Приносът към проект може да бъде толкова прост, колкото коригиране на правописни грешки или актуализиране на документация.\n\nАко не сте сигурни как да започнете като сътрудник, вижте нашето [Как да допринесете за ръководство с отворен код](../how-to-contribute/).\n\n## Стартиране на ваш собствен проект с отворен код\n\nНяма идеално време за отваряне на вашата работа. Можете да отворите кода на идея, в процес на работа или след години на затворен код.\n\nНай-общо казано, трябва да отворите своя проект, когато се чувствате комфортно другите да гледат и дават обратна връзка за работата ви.\n\nБез значение на кой етап решите да отворите проекта си, всеки проект трябва да включва следната документация:\n\n* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository)\n* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change)\n* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/)\n* [Code of conduct](../code-of-conduct/)\n\nКато поддържащ, тези компоненти ще ви помогнат да съобщите очакванията, да управлявате приносите и да защитите законните права на всички (включително вашите собствени). Те значително увеличават шансовете ви за положително преживяване.\n\nАко вашият проект е в GitHub, поставянето на тези файлове в основната ви директория с препоръчаните файлови имена ще помогне на GitHub да ги разпознае и автоматично да ги покаже на вашите читатели.\n\n### Избор на лиценз\n\nЛицензът с отворен код гарантира, че други могат да използват, копират, модифицират и допринасят обратно към вашия проект без последствия. Освен това ви предпазва от трудни правни ситуации. **Трябва да включите лиценз, когато стартирате проект с отворен код.**\n\nЛегалната работа не е забавна. Добрата новина е, че можете да копирате и поставите съществуващ лиценз във вашето хранилище. Ще отнеме само минута, за да защитите упоритата си работа.\n\n[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) са най-популярните лицензи с отворен код, но [има и други опции](https://choosealicense.com), от които да избирате.\n\nКогато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на лиценз с отворен код ще направи вашия проект GitHub отворен код.\n\n![Изберете лиценз](/assets/images/starting-a-project/repository-license-picker.png)\n\nАко имате други въпроси или притеснения относно правните аспекти на управлението на проект с отворен код, [ние ще ви покрием](../legal/).\n\n### Напишете README\n\nREADME правят повече от това да обяснят как да използвате вашия проект. Те също така обясняват защо вашият проект има значение и какво могат да правят вашите потребители с него.\n\nВ README опитайте да отговорите на следните въпроси:\n\n* Какво прави този проект?\n* Защо този проект е полезен?\n* Как да започна?\n* Къде мога да получа повече помощ, ако имам нужда от нея?\n\nМожете да използвате вашия README, за да отговорите на други въпроси, като например как се справяте с приносите, какви са целите на проекта и информация за лицензи и приписване. Ако не искате да приемате принос или вашият проект все още не е готов за производство, запишете тази информация.\n\n\n\nПонякога хората избягват да пишат README, защото смятат, че проектът е незавършен или не искат приноси. Всичко това са много добри причини да напиша такъв.\n\nЗа повече вдъхновение опитайте да използвате [ръководството \"Направете README\" на @dguo](https://www.makeareadme.com/) или [шаблона README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) на @PurpleBooth за да напишете пълен README.\n\nКогато включите файл README в основната директория, GitHub автоматично ще го покаже на началната страница на хранилището.\n\n### Напишете вашите указания за принос\n\nCONTRIBUTING файл казва на вашата публика как да участва във вашия проект. Например можете да включите информация за:\n\n* Как да подадете доклад за грешка (опитайте да използвате [шаблони за заявка за проблем и изтегляне](https://github.com/blog/2111-issue-and-pull-request-templates))\n* Как да предложим нова функция\n* Как да настроите вашата среда и да стартирате тестове\n\nВ допълнение към техническите подробности, файлът CONTRIBUTING е възможност да съобщите вашите очаквания за приноси, като например:\n\n* Типовете приноси, които търсите\n* Вашата пътна карта или визия за проекта\n* Как сътрудниците трябва (или не трябва) да се свързват с вас\n\nИзползването на топъл, приятелски тон и предлагането на конкретни предложения за принос (като например писане на документация или създаване на уебсайт) може да помогне много на новодошлите да се почувстват добре дошли и развълнувани да участват.\n\nНапример [Active Admin](https://github.com/activeadmin/activeadmin/) започва [своето ръководство за принос](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) с:\n\n> Първо, благодаря ви, че обмислихте да допринесете за Active Admin. Именно хора като вас правят Active Admin толкова страхотен инструмент.\n\nВ най-ранните етапи на вашия проект, вашият CONTRIBUTING файл може да бъде прост. Винаги трябва да обяснявате как да докладвате бъгове или проблеми с файлове, както и всякакви технически изисквания (като тестове), за да направите принос.\n\nС течение на времето може да добавите други често задавани въпроси към вашия CONTRIBUTING файл. Записването на тази информация означава, че по-малко хора ще ви задават едни и същи въпроси отново и отново.\n\nЗа повече помощ при писането на вашия CONTRIBUTING файл вижте @nayafia [шаблон за ръководство за допринасяне](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) или @mozilla [\"Как да Създайте CONTRIBUTING.md\"](https://mozillascience.github.io/working-open-workshop/contributing/).\n\nВръзка към вашия ПРИНОСЕН файл от вашия README, така че повече хора да го видят. Ако [поставите файла CONTRIBUTING в хранилището на вашия проект](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub автоматично ще се свърже с вашия файл, когато участник създаде проблем или отваря заявка за изтегляне.\n\n![Указания за принос](/assets/images/starting-a-project/Contributing-guidelines.jpg)\n\n### Създаване на кодекс на поведение\n\n\n\nИ накрая, кодексът на поведение помага да се определят основните правила за поведение на участниците във вашия проект. Това е особено ценно, ако стартирате проект с отворен код за общност или компания. Кодексът на поведение ви дава възможност да улесните здравословното, конструктивно поведение в общността, което ще намали стреса ви като поддържащ.\n\nЗа повече информация вижте нашето [Ръководство за кодекс на поведение](../code-of-conduct/).\n\nВ допълнение към комуникацията _как_ очаквате да се държат участниците, кодексът за поведение също има тенденция да описва към кого се отнасят тези очаквания, кога се прилагат и какво да направите, ако възникне нарушение.\n\nПодобно на лицензите с отворен код, има и нововъзникващи стандарти за кодекси за поведение, така че не е нужно да пишете свои собствени. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от [над 40 000 проекта с отворен код](https://www.contributor-covenant.org/adopters), включително Kubernetes, Rails и Swift. Без значение кой текст използвате, трябва да сте готови да наложите своя кодекс на поведение, когато е необходимо.\n\nПоставете текста директно във файл CODE_OF_CONDUCT във вашето хранилище. Съхранявайте файла в главната директория на вашия проект, за да е лесен за намиране, и свържете към него от вашия README.\n\n## Наименуване и брандиране на вашия проект\n\nБрандирането е повече от крещящо лого или закачливо име на проект. Става въпрос за това как говорите за вашия проект и до кого достигате с вашето послание.\n\n### Избор на правилното име\n\nИзберете име, което е лесно за запомняне и в идеалния случай дава някаква представа какво прави проектът. Например:\n\n* [Sentry](https://github.com/getsentry/sentry) следи приложенията за докладване на сривове\n* [Thin](https://github.com/macournoyer/thin) е бърз и лесен Ruby уеб сървър\n\nАко надграждате върху съществуващ проект, използването на тяхното име като префикс може да ви помогне да изясните какво прави вашият проект (например [node-fetch](https://github.com/bitinn/node-fetch) носи `window .fetch` към Node.js).\n\nПомислете за яснотата преди всичко. Каламбурите са забавни, но не забравяйте, че някои вицове може да не се преведат в други култури или хора с различен опит от вашия. Някои от вашите потенциални потребители може да са служители на компанията: не искате да ги карате да се чувстват неудобно, когато трябва да обясняват вашия проект по време на работа!\n\n### Избягване на конфликти с имена\n\n[Проверете за проекти с отворен код с подобно име](http://ivantomic.com/projects/ospnc/), особено ако споделяте същия език или екосистема. Ако името ви се припокрива с популярен съществуващ проект, може да объркате аудиторията си.\n\nАко искате уебсайт, Twitter манипулатор или други свойства да представляват вашия проект, уверете се, че можете да получите имената, които искате. В идеалния случай [запазете тези имена сега](https://instantdomainsearch.com/) за спокойствие, дори ако все още не възнамерявате да ги използвате.\n\nУверете се, че името на вашия проект не нарушава никакви търговски марки. Една компания може да поиска от вас да премахнете проекта си по-късно или дори да предприеме съдебни действия срещу вас. Просто не си струва риска.\n\nМожете да проверите [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) за конфликти на търговски марки. Ако сте в компания, това е едно от нещата, с които вашият [правен екип може да ви помогне](../legal/).\n\nИ накрая, направете бързо търсене в Google за името на вашия проект. Ще могат ли хората лесно да намерят вашия проект? Показва ли се нещо друго в резултатите от търсенето, което не бихте искали да виждат?\n\n### Как пишете (и кодирате) също влияе върху вашата марка!\n\nПрез целия живот на вашия проект ще пишете много: README, уроци, документи на общността, отговаряне на проблеми, може би дори бюлетини и пощенски списъци.\n\nНезависимо дали става въпрос за официална документация или случаен имейл, вашият стил на писане е част от марката на вашия проект. Помислете как бихте могли да възприемете публиката си и дали това е тонът, който искате да предадете.\n\n\n\nИзползването на топъл, приобщаващ език (като \"тях\", дори когато се отнася до един човек) може много да помогне на вашия проект да се почувства добре дошъл за новите сътрудници. Придържайте се към простия език, тъй като много от вашите читатели може да не са носители на английски език.\n\nОсвен начина, по който пишете думи, вашият стил на кодиране може също да стане част от марката на вашия проект. [Angular](https://angular.io/guide/styleguide) и [jQuery](https://contribute.jquery.org/style-guide/js/) са два примера за проекти със строги стилове и насоки за кодиране.\n\nНе е необходимо да пишете стилово ръководство за вашия проект, когато току-що започвате, и може да откриете, че така или иначе ви харесва да включвате различни стилове на кодиране във вашия проект. Но трябва да предвидите как вашият стил на писане и кодиране може да привлече или обезсърчи различни типове хора. Най-ранните етапи на вашия проект са вашата възможност да създадете прецедента, който искате да видите.\n\n## Вашият контролен списък преди стартиране\n\nГотови ли сте да отворите вашия проект? Ето контролен списък за помощ. Поставете отметка във всички квадратчета? Готови сте за работа! [Щракнете върху \"публикувай\"](https://help.github.com/articles/making-a-private-repository-public/) и се потупайте по рамото.\n\n**Документация**\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n**Код**\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n**Хора**\n\nАко сте физическо лице:\n\n
\n \n \n
\n\nАко сте компания или организация:\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n## Направи го!\n\nПоздравления за първия ви проект с отворен код. Без значение от резултата, публичната работа е дар за общността. С всеки ангажимент, коментар и заявка за изтегляне вие създавате възможности за себе си и за другите да се учат и да растат.\n" }, { "path": "_articles/bn/best-practices.md", "content": "---\nlang: bn\ntitle: রক্ষণাবেক্ষণকারিদের জন্য আর্দশ অনুশীলন\ndescription: নথিপত্র পক্রিয়াকরন থেকে শুরু করে সম্প্রদায়কে উন্নত করার ক্ষেত্রে, অপনার জীবনকে সহজ করুন একজন ওপেন সোর্স রক্ষণাবেক্ষণকারি হিসাবে।\nclass: best-practices\norder: 5\nimage: /assets/images/cards/best-practices.png\nrelated:\n - metrics\n - leadership\n---\n\n## রক্ষণাবেক্ষণকারী বলতে কী বোঝায়?\n\nআপনি যদি একটি ওপেন সোর্স প্রকল্প রক্ষণাবেক্ষণ করেন যেটা অনেক লোক ব্যবহার করে, আপনি হয়ত লক্ষ্য করেছেন যে আপনি কম কোডিং করছেন এবং সমস্যাগুলিতে বেশি সাড়া দিচ্ছেন।\n\nএকটি প্রকল্পের প্রাথমিক পর্যায়ে, আপনি নতুন নতুন পরিকল্পনা নিয়ে পরীক্ষা-নিরীক্ষা করবেন এবং আপনার ইচ্ছার উপর ভিত্তি করে সিদ্ধান্ত নিবেন। কিন্তু আপনার প্রকল্পের জনপ্রিয়তা বাড়ার সাথে সাথে আপনি নিজেকে আপনার ব্যবহারকারী এবং অবদানকারীদের সাথে বেশি কাজ করতে দেখবেন।\n\nএকটা প্রকল্প রক্ষণাবেক্ষণ করতে কোডিং করার থেকেও বেশি কিছুর প্রয়োজন। এই কাজগুলো বেশির ভাগ সময়ই অপ্রত্যাশিত হয়ে থাকে, কিন্তু এগুলো প্রকল্প বড় করার মতোই সমান গুরুত্তপূর্ণ্য। নথিপত্র পক্রিয়াকরন থেকে শুরু করে সম্প্রদায়কে উন্নত করার ক্ষেত্রে, অপনার জীবনকে সহজ করার জন্য আমরা কিছু উপায় একত্রিত করেছি।\n\n## আপনার প্রক্রিয়া নথিভুক্ত করা\n\nরক্ষণাবেক্ষণকারি হিসেবে আপনার সব থেকে গুরুত্তপূর্ণ্য কাজগুলোর মধ্যে একটি হচ্ছে লিখে রাখা।\n\nনথিভূক্ত করা শুধুমাত্র আপনার নিজের চিন্তাভাবনাকে স্পষ্ট করে না, এটি অন্যদেরকে আপনার কাছে জানতে চাওয়ার আগেই আপনার প্রয়োজন বা প্রত্যাশা বুঝতে সাহায্য করে।\n\nযখন কোন কিছু আপনার লক্ষের সাথে না মিলে, তখন নথিপত্র লেখা থাকলে না বলতে সুবিধা হয়। এটা অন্যদেরকে আপনার সাথে একসাথে কাজ করা এবং সাহায্য করাকেও সহজ করে দেয়। আপনি কখনোই জানবেন না কে আপনার প্রকল্প পড়তে অথবা ব্যবহার করতে পারে।\n\nযদি আপনি সম্পূর্ণ্য বিস্তারিত ভাবে নাও লিখেন, তবে একদম না লেখার থেকে খসড়া বুলেট পয়েন্ট আকারে লেখা ভাল।\n\nআপনার নথিপত্র হালনাগাদ(আপডেট) করতে ভুলবেন না। আপনি যদি সর্বদা এটা করতে নাও পারেন তবে আপনার পুরানো নথিগুলো মুছুন অথবা এটি পুরানো বলে চিহ্নিত করুন যাতে অবদানকারীরা জানে যে এখানে পুরাতন নথি হালনাগাদ করার মাধ্যমে তারা এই প্রকল্পে অবদান রাখতে পারে৷\n\n### আপনার কর্ম-পরিকল্পনা লিখুন\n\nআপনার প্রকল্পের লক্ষ্যগুলো লেখার মাধ্যমে শুরু করুন। এগুলো আপনার রিডমি(README) ফাইলে সংযুক্ত করুন, অথবা ভিশন(VISION) নামে আলাদা ফাইল তৈরি করুন। যদি অন্য কোন গুরুত্তপুর্ণ্য জিনিস থাকে যেটা অন্যদের সাহায্য করবে যেমন প্রকল্পের রোডম্যাপ ইত্যাদি, সেগুলো সবার জন্য উন্মুক্ত করে দিন।\n\nএকটি স্পষ্ট এবং নথিভূক্ত কর্ম-পরিকল্পনা আপনাকে প্রকৃত লক্ষে অবিচল রাখবে এবং অন্যান্য অবদানকারীদের মাধ্যমে \"scope creep\" হওয়া অর্থাৎ প্রকৃত লক্ষ্য থেকে ধীরে ধীরে দূরে সরে যাওয়া এড়াতে সাহায্য করবে।\n\nউদাহরণস্বরূপ @lord আবিষ্কার করলো যে একটি প্রকল্পের কর্ম-পরিকল্পনা তাকে বুঝতে সাহায্য করে কোন অনুরোধগুলিতে(requests) সময় ব্যয় করা উচিত। যখন সে প্রথম [Slate](https://github.com/lord/slate) এর ফিচার(বৈশিষ্ট) সংযুক্ত করার অনুরোধ পায় এবং যে তার প্রকল্পের লক্ষ্য থেকে দূরে সরে যায়, তখন সে একজন নতুন রক্ষণাবেক্ষণকারী হিসেবে অনুতপ্ত হয়।\n\n\n\n### অন্যদেরকে আপনার প্রত্যাশাগুলো জানান\n\nনিয়মকানুন(Rules) লিপিবদ্ধ করা খুবই যন্ত্রণাদায়ক। অনেক সময় আপনার মনে হতে পারে আপনি অন্যদের আচরণ তদারকি করছেন অথবা সকল আনন্দ-বিনোদনের গলা চেপে ধরছেন।\n\nযদি নিয়মকানুন লিপিবদ্ধ করা এবং ন্যায্য ভাবে প্রয়োগ করা হয়, যতকিছুই হোক, ভাল নিয়মকানুন রক্ষণাবেক্ষণকারীদের ক্ষমতা বৃদ্ধি করে। এটা আপনাকে এমন কাজ করতে বাধ্য হওয়া থেকে রক্ষা করে যা আপনি করতে চান না।\n\nআপনার প্রকল্পের বেশির ভাগ মানুষ আপনার বা আপনার পরিস্থিতি সম্পর্কে কিছুই জানে না। তারা মনে করতে পারে যে আপনি এটি নিয়ে কাজ করার জন্য টাকা পান, বিশেষ করে যদি এটি এমন কিছু হয় যা তারা নিয়মিত ব্যবহার করে এবং নির্ভর করে। হয়তো এক সময় আপনি আপনার প্রকল্পে অনেক সময় দিয়েছিলেন, কিন্তু এখন আপনি নতুন চাকরি বা পরিবার সদস্যদের নিয়ে ব্যস্ত।\n\nএগুলোর সবই পুরপুরি ঠিক আছে! শুধু এটা নিশ্চিত করুন যে অন্যরা আপনার পরিস্থিতিগুলো যেন জানে।\n\nপ্রকল্প রক্ষণাবেক্ষণ যদি আপনার পার্ট-টাইম বা সম্পূর্ণভাবে স্বেচ্ছাসেবামূলক হয়, তবে আপনি কতটুকু সময় দিতে পারবেন সে সম্পর্কে সৎ থাকুন। এটা সেই সময়ের সমান নয় যেটা আপনি মনে করছেন প্রকল্পের প্রয়োজন বা অন্যরা আপনার কাছ থেকে যে পরিমান সময় চাচ্ছে।\n\nলিখে রাখার মত কিছু নিয়মকানুন হচ্ছেঃ\n\n* কিভাবে একটি অবদান পর্যালোচনা(reviewed) এবং গ্রহণ করা হবে (_তাদের কি টেষ্ট(test) প্রয়োজন? নাকি ইস্যু টেমপ্লেট(issue template) প্রয়োজন?_)\n* কোন ধরনের অবদান আপনি গ্রহন করবেন (_আপনার কি কোন নির্দিষ্ট অংশের কোডিং এ সাহায্য প্রয়োজন?_)\n* কখন ফলো-আপ করা উপযুক্ত (_যেমন, 'আপনি ৭ দিনের মধ্যে একজন রক্ষণাবেক্ষণকারীর কাছ থেকে প্রতিউত্তর আশা করতে পারেন। যদি এই সময়ের মধ্যে কোন প্রতিউত্তর না পান, তবে থ্রেডটি পিং করতে স্বচ্ছন্দ বোধ করুন(feel free to ping the thread)।_)\n* আপনি এই প্রকল্পে কতটুকু সময় ব্যয় করবেন (_যেমন, \"আমরা এই প্রকল্পে প্রতি সপ্তাহে শুধুমাত্র ৫ ঘন্টা সময় ব্যয় করবো\"_)\n\n[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) এগুলো হচ্ছে রক্ষণাবেক্ষণকারী এবং অবদানকারীদের জন্য মৌলিক নিয়ম সহ কিছু প্রকল্পের উদাহরণ।\n\n## যোগাযোগ সর্বজনীন রাখুন\n\nআপনার কথোপকথনগুলোও নথিভুক্ত করতে ভুলবেন না। যতটা সম্ভব, প্রকল্প-সংক্রান্ত সব যোগাযোগ প্রকাশ্যে রাখুন। কেউ যদি ব্যক্তিগতভাবে ফিচার অনুরোধ বা সাহায্যের জন্য যোগাযোগ করে, তাহলে বিনয়ের সঙ্গে তাকে পাবলিক প্ল্যাটফর্মে (যেমন ইস্যু ট্র্যাকার বা মেইলিং লিস্টে) আসতে বলুন।\n\nরক্ষণাবেক্ষণকারীদের সঙ্গে কোনো গুরুত্বপূর্ণ সিদ্ধান্ত যদি ব্যক্তিগতভাবে নেন, তাহলে সেটার সারসংক্ষেপ প্রকাশ্যে লিখে রাখুন।\n\nএতে নতুন কেউ কমিউনিটিতে যোগ দিলেও পুরোনো সদস্যদের মতো একই তথ্য পাবে।\n\n## \"না\" বলতে শেখা\n\nআপনি সবকিছু লিখে রেখেছেন। তবুও সবাই যে সেটা পড়বে—এমনটা বাস্তবে হয় না। তাই মাঝে মাঝে অন্যদের মনে করিয়ে দিতে হবে।\n\nলিখিত নিয়ম থাকলে, \"না\" বলা ব্যক্তিগত আক্রমণ মনে হয় না।\n\n\"আপনার অবদান এই প্রকল্পের লক্ষ্য অনুযায়ী নয়\" \nএটা বলা অনেক সহজ— \n\"আমি আপনার অবদান পছন্দ করিনি\" বলার চেয়ে।\n\nএকজন মেইনটেইনার (maintainer) হিসেবে আপনি এমন অনেক পরিস্থিতির সম্মুখীন হবেন যেখানে **'না' বলাটা জরুরি**। যেমন: এমন কোনো ফিচারের অনুরোধ যা প্রকল্পের পরিধির বাইরে, কেউ যখন মূল আলোচনা থেকে বিচ্যুত হয়ে অপ্রাসঙ্গিক কথা বলে, অথবা অন্যদের জন্য অপ্রয়োজনীয় কাজ করা।\n\n### কথোপকথন বন্ধুত্বপূর্ণ রাখুন\n\nআপনার সমস্যাটির উপর \"না\" বলার অনুশীলন করার সবচেয়ে গুরুত্বপূর্ণ জায়গাগুলির মধ্যে একটি হল অনুরোধের সারি টানা। একজন প্রকল্প রক্ষণাবেক্ষণকারী হিসাবে, আপনি অনিবার্যভাবে এমন পরামর্শ পাবেন যা আপনি গ্রহণ করতে চান না।\n\nহয়তো অবদান আপনার প্রকল্পের পরিধি পরিবর্তন করে অথবা আপনার দৃষ্টিভঙ্গির সাথে মেলে না। হয়তো ধারণাটি ভালো, কিন্তু বাস্তবায়ন দুর্বল।\n\nকারণ যাই হোক না কেন, আপনার প্রকল্পের মান পূরণ করে না এমন অবদানগুলিকে কৌশলে পরিচালনা করা সম্ভব।\n\nযদি আপনি এমন কোনও অবদান পান যা আপনি গ্রহণ করতে চান না, তাহলে আপনার প্রথম প্রতিক্রিয়া হতে পারে তা উপেক্ষা করা অথবা ভান করা যে আপনি এটি দেখেননি। এটি করলে অন্য ব্যক্তির অনুভূতিতে আঘাত লাগতে পারে এবং এমনকি আপনার সম্প্রদায়ের অন্যান্য সম্ভাব্য অবদানকারীদেরও হতাশ করতে পারে।\n\n\n\nঅপরাধবোধ বা ভালো হতে চাও বলে অবাঞ্ছিত অবদান খোলা রাখবেন না। সময়ের সাথে সাথে, আপনার উত্তর না দেওয়া সমস্যা এবং জনসংযোগ আপনার প্রকল্পে কাজ করাকে আরও বেশি চাপপূর্ণ এবং ভীতিকর করে তুলবে।\n\nযেসব অবদান আপনি গ্রহণ করতে চান না তা অবিলম্বে বন্ধ করে দেওয়া ভালো। যদি আপনার প্রকল্প ইতিমধ্যেই একটি বড় ধরনের ব্যাকলগের কারণে ভুগছে, তাহলে @steveklabnik-এর কাছে [সমস্যাগুলি দক্ষতার সাথে কীভাবে সমাধান করা যায়](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) তার পরামর্শ আছে ।\n\nদ্বিতীয়ত, অবদান উপেক্ষা করা আপনার সম্প্রদায়ের কাছে একটি নেতিবাচক সংকেত পাঠায়। কোনও প্রকল্পে অবদান রাখা ভীতিকর হতে পারে, বিশেষ করে যদি এটি কারও প্রথমবারের মতো হয়। এমনকি যদি আপনি তাদের অবদান গ্রহণ না করেন, তবুও এর পিছনে থাকা ব্যক্তিকে স্বীকৃতি দিন এবং তাদের আগ্রহের জন্য তাদের ধন্যবাদ জানান। এটি একটি বড় প্রশংসা!\n\nযদি আপনি কোন অবদান গ্রহণ করতে না চান:\n\n* তাদের অবদানের জন্য **ধন্যবাদ।**\n* কেন এটি প্রকল্পের আওতায় **আসে না তা ব্যাখ্যা করুন এবং যদি পারেন, তাহলে উন্নতির জন্য স্পষ্ট পরামর্শ দিন। সদয় হোন, কিন্তু দৃঢ় থাকুন।**\n* **প্রাসঙ্গিক ডকুমেন্টেশনের লিঙ্ক** , যদি আপনার কাছে থাকে। যদি আপনি এমন জিনিসের জন্য বারবার অনুরোধ লক্ষ্য করেন যা আপনি গ্রহণ করতে চান না, তাহলে পুনরাবৃত্তি এড়াতে সেগুলি আপনার ডকুমেন্টেশনে যোগ করুন।\n* **অনুরোধটি বন্ধ করুন**\n\nউত্তর দিতে ১-২ বাক্যের বেশি বাক্য ব্যবহার করা উচিত নয়। উদাহরণস্বরূপ, যখন [সেলেরির](https://github.com/celery/celery/) একজন ব্যবহারকারী উইন্ডোজ-সম্পর্কিত ত্রুটির কথা জানান, তখন @berkerpeksag নিম্নলিখিত বাক্য [ব্যবহার করে উত্তর দেন](https://github.com/celery/celery/issues/3383) :\n\n![Celery screenshot](/assets/images/best-practices/celery.png)\n\nযদি না বলার চিন্তা তোমাকে ভয় পায়, তাহলে তুমি একা নও। @jessfraz যেমনটি [বলেছেন](https://blog.jessfraz.com/post/the-art-of-closing/) :\n\n> আমি মেসোস, কুবারনেটস, ক্রোমিয়াম, এই ধরণের বিভিন্ন ওপেন সোর্স প্রকল্পের রক্ষণাবেক্ষণকারীদের সাথে কথা বলেছি এবং তারা সকলেই একমত যে রক্ষণাবেক্ষণকারী হওয়ার সবচেয়ে কঠিন অংশগুলির মধ্যে একটি হল আপনি যে প্যাচগুলি চান না সেগুলিকে \"না\" বলা।\n\nকারো অবদান গ্রহণ করতে না চাওয়ার জন্য দোষী বোধ করো না। @shykes [এর মতে , ওপেন সোর্সের প্রথম নিয়ম হল:](https://twitter.com/solomonstre/status/715277134978113536) _\"না সাময়িক, হ্যাঁ চিরকাল।\"_ অন্য ব্যক্তির উৎসাহের প্রতি সহানুভূতিশীল হওয়া ভালো, তবে অবদান প্রত্যাখ্যান করা এবং এর পেছনের ব্যক্তিকে প্রত্যাখ্যান করা একই কথা নয়।\n\nপরিশেষে, যদি কোন অবদান যথেষ্ট ভালো না হয়, তাহলে তা গ্রহণ করার জন্য আপনার কোন বাধ্যবাধকতা নেই। আপনার প্রকল্পে যখন লোকেরা অবদান রাখে তখন সদয় এবং প্রতিক্রিয়াশীল হোন, তবে কেবল সেই পরিবর্তনগুলি গ্রহণ করুন যা আপনি সত্যিই বিশ্বাস করেন যে আপনার প্রকল্পকে আরও ভালো করে তুলবে। আপনি যত বেশি না বলার অভ্যাস করবেন, ততই এটি সহজ হয়ে উঠবে। প্রতিশ্রুতি দিন।\n\n### সক্রিয় থাকুন\n\nপ্রথমেই অবাঞ্ছিত অবদানের পরিমাণ কমাতে, আপনার অবদান নির্দেশিকায় আপনার প্রকল্পের অবদান জমা দেওয়া এবং গ্রহণের প্রক্রিয়া ব্যাখ্যা করুন।\n\nযদি আপনি খুব বেশি নিম্নমানের অবদান পান, তাহলে অবদানকারীদের আগে থেকে কিছু কাজ করতে বলুন, উদাহরণস্বরূপ:\n\n* একটি ইস্যু বা জনসংযোগ টেমপ্লেট/চেকলিস্ট পূরণ করুন\n* পিআর জমা দেওয়ার আগে একটি সমস্যা খুলুন\n\nযদি তারা আপনার নিয়ম না মানে, তাহলে অবিলম্বে সমস্যাটি বন্ধ করুন এবং আপনার ডকুমেন্টেশনের দিকে নির্দেশ করুন।\n\nযদিও এই পদ্ধতিটি প্রথমে অপ্রীতিকর মনে হতে পারে, তবুও সক্রিয় থাকা আসলে উভয় পক্ষের জন্যই ভালো। এটি এমন সম্ভাবনা কমায় যে কেউ আপনার অনেক সময় নষ্ট করা কাজের বিনিময়ে এমন একটি পুল রিকোয়েস্টে ফেলবে যা আপনি গ্রহণ করবেন না। এবং এটি আপনার কাজের চাপ পরিচালনা করা সহজ করে তোলে।\n\n\n\nকখনও কখনও, যখন আপনি না বলেন, তখন আপনার সম্ভাব্য অবদানকারী বিরক্ত হতে পারেন বা আপনার সিদ্ধান্তের সমালোচনা করতে পারেন। যদি তাদের আচরণ প্রতিকূল হয়ে ওঠে, তাহলে [পরিস্থিতি শান্ত করার জন্য পদক্ষেপ নিন](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) অথবা এমনকি যদি তারা গঠনমূলকভাবে সহযোগিতা করতে ইচ্ছুক না হয়, তাহলে তাদের আপনার সম্প্রদায় থেকে সরিয়ে দিন।\n\n### পরামর্শ গ্রহণ করুন\n\nহয়তো আপনার কমিউনিটির কেউ নিয়মিত এমন অবদান জমা দেন যা আপনার প্রকল্পের মান পূরণ করে না। বারবার প্রত্যাখ্যানের সম্মুখীন হওয়া উভয় পক্ষের জন্যই হতাশাজনক হতে পারে।\n\nযদি দেখেন যে কেউ আপনার প্রকল্প সম্পর্কে উৎসাহী, কিন্তু একটু মসৃণতার প্রয়োজন, তাহলে ধৈর্য ধরুন। প্রতিটি পরিস্থিতিতে স্পষ্টভাবে ব্যাখ্যা করুন কেন তাদের অবদান প্রকল্পের প্রত্যাশা পূরণ করে না। তাদের পা ভিজিয়ে দেওয়ার জন্য _\"ভালো প্রথম সমস্যা\"_ হিসাবে চিহ্নিত একটি সমস্যা, যেমন একটি সহজ বা কম অস্পষ্ট কাজের দিকে তাদের নির্দেশ করার চেষ্টা করুন । যদি আপনার সময় থাকে, তাহলে তাদের প্রথম অবদানের মাধ্যমে তাদের পরামর্শ দেওয়ার কথা বিবেচনা করুন, অথবা আপনার সম্প্রদায়ের অন্য কাউকে খুঁজে বের করুন যিনি তাদের পরামর্শ দিতে ইচ্ছুক হতে পারেন।\n\n## আপনার সম্প্রদায়কে কাজে লাগান\n\nআপনাকে সবকিছু নিজে করতে হবে না। আপনার প্রকল্পের সম্প্রদায়টি একটি কারণে বিদ্যমান! এমনকি যদি আপনার এখনও একটি সক্রিয় অবদানকারী সম্প্রদায় না থাকে, যদি আপনার অনেক ব্যবহারকারী থাকে, তাহলে তাদের কাজে লাগান।\n\n### কাজের চাপ ভাগ করে নিন\n\nযদি আপনি অন্যদের সাহায্য করার জন্য খুঁজছেন, তাহলে আশেপাশে জিজ্ঞাসা করে শুরু করুন।\n\nনতুন অবদানকারীদের আকর্ষণ করার একটি উপায় হল [এমন সমস্যাগুলিকে স্পষ্টভাবে লেবেল করা যা নতুনদের জন্য যথেষ্ট সহজ](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) । এরপর GitHub প্ল্যাটফর্মের বিভিন্ন স্থানে এই সমস্যাগুলি তুলে ধরবে, যার ফলে তাদের দৃশ্যমানতা বৃদ্ধি পাবে।\n\nযখন আপনি নতুন অবদানকারীদের বারবার অবদান রাখতে দেখেন, তখন আরও দায়িত্ব প্রদানের মাধ্যমে তাদের কাজকে স্বীকৃতি দিন। অন্যরা কীভাবে ইচ্ছা করলে নেতৃত্বের ভূমিকায় পরিণত হতে পারে তা নথিভুক্ত করুন।\n\nঅন্যদেরকে [প্রকল্পের মালিকানা ভাগাভাগি](https://opensource.guide/building-community/#share-ownership-of-your-project) করতে উৎসাহিত করলে আপনার নিজের কাজের চাপ অনেকাংশে কমতে পারে, যেমন @lmccart তার প্রকল্প, [p5.js-](https://github.com/processing/p5.js) এ আবিষ্কার করেছেন।\n\n\n\nযদি আপনার প্রকল্প থেকে সরে যেতে হয়, হয় বিরতিতে অথবা স্থায়ীভাবে, তাহলে অন্য কাউকে আপনার দায়িত্ব নিতে বলার মধ্যে কোনও লজ্জার কিছু নেই।\n\nযদি অন্যরা এর নির্দেশনা সম্পর্কে উৎসাহী হয়, তাহলে তাদের অনুমতি দিন অথবা আনুষ্ঠানিকভাবে অন্য কারো কাছে নিয়ন্ত্রণ হস্তান্তর করুন। যদি কেউ আপনার প্রকল্পটি তৈরি করে এবং অন্য কোথাও সক্রিয়ভাবে এটি রক্ষণাবেক্ষণ করে, তাহলে আপনার মূল প্রকল্পের ফর্কের সাথে লিঙ্ক করার কথা বিবেচনা করুন। এটা খুবই ভালো যে এত মানুষ আপনার প্রকল্পটি টিকে থাকতে চায়!\n\n@progrium [দেখেছেন যে তার প্রকল্প,](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) [ডোক্কুর](https://github.com/dokku/dokku) জন্য দৃষ্টিভঙ্গি নথিভুক্ত করা , প্রকল্প থেকে সরে আসার পরেও সেই লক্ষ্যগুলিকে বাঁচিয়ে রাখতে সাহায্য করেছে:\n\n> আমি একটি উইকি পাতা লিখেছিলাম যেখানে আমি কী চাই এবং কেন চাই তা বর্ণনা করা হয়েছিল। কোনও কারণে, রক্ষণাবেক্ষণকারীরা প্রকল্পটি সেই দিকে নিয়ে যেতে শুরু করায় আমার অবাক লেগেছিল! আমি যেভাবে এটি করেছি ঠিক সেভাবেই কি এটি ঘটেছিল? সবসময় নয়। কিন্তু তবুও এটি প্রকল্পটিকে আমি যা লিখেছিলাম তার কাছাকাছি নিয়ে এসেছিল।\n\n### অন্যদের তাদের প্রয়োজনীয় সমাধান তৈরি করতে দিন\n\nযদি আপনার প্রকল্পের কাজ সম্পর্কে কোনও সম্ভাব্য অবদানকারীর ভিন্ন মতামত থাকে, তাহলে আপনি তাদের নিজস্ব কৌশল অবলম্বন করতে উৎসাহিত করতে পারেন।\n\nকোনও প্রকল্প তৈরি করা খারাপ কিছু হতে পারে না। প্রকল্পগুলি অনুলিপি এবং সংশোধন করতে সক্ষম হওয়া ওপেন সোর্সের সেরা দিকগুলির মধ্যে একটি। আপনার সম্প্রদায়ের সদস্যদের তাদের নিজস্ব ফোর্কের উপর কাজ করতে উৎসাহিত করা তাদের প্রয়োজনীয় সৃজনশীল আউটলেট সরবরাহ করতে পারে, আপনার প্রকল্পের দৃষ্টিভঙ্গির সাথে সাংঘর্ষিক না হয়ে।\n\n\n\nএকই কথা প্রযোজ্য সেই ব্যবহারকারীর ক্ষেত্রেও যারা সত্যিই এমন একটি সমাধান চান যা তৈরি করার জন্য আপনার কাছে ব্যান্ডউইথ নেই। API এবং কাস্টমাইজেশন হুক অফার করলে অন্যরা সরাসরি উৎস পরিবর্তন না করেই তাদের নিজস্ব চাহিদা পূরণ করতে পারে। @orta [দেখেছেন যে](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) CocoaPods-এর জন্য উৎসাহিত প্লাগইনগুলি \"কিছু আকর্ষণীয় ধারণা\" তৈরি করেছে:\n\n> এটা প্রায় অনিবার্য যে একবার কোনও প্রকল্প বড় হয়ে গেলে, রক্ষণাবেক্ষণকারীদের নতুন কোড কীভাবে প্রবর্তন করা হবে সে সম্পর্কে অনেক বেশি রক্ষণশীল হতে হবে। আপনি \"না\" বলতে পারদর্শী হয়ে উঠবেন, কিন্তু অনেকেরই বৈধ চাহিদা থাকে। তাই, পরিবর্তে আপনি আপনার টুলটিকে একটি প্ল্যাটফর্মে রূপান্তরিত করতে বাধ্য হবেন।\n\n## রোবটগুলো আনুন\n\nঠিক যেমন কিছু কাজ আছে যা অন্যরা আপনাকে সাহায্য করতে পারে, তেমনি এমন কিছু কাজও আছে যা কোনও মানুষের কখনও করা উচিত নয়। রোবট আপনার বন্ধু। রক্ষণাবেক্ষণকারী হিসেবে আপনার জীবনকে সহজ করতে এগুলি ব্যবহার করুন।\n\n### আপনার কোডের মান উন্নত করার জন্য পরীক্ষা এবং অন্যান্য চেকের প্রয়োজন।\n\nআপনার প্রকল্পটি স্বয়ংক্রিয় করার সবচেয়ে গুরুত্বপূর্ণ উপায়গুলির মধ্যে একটি হল পরীক্ষা যোগ করা।\n\nপরীক্ষাগুলি অবদানকারীদের আত্মবিশ্বাসী বোধ করতে সাহায্য করে যে তারা কোনও কিছু ভাঙবে না। এগুলি আপনার জন্য অবদানগুলি পর্যালোচনা করা এবং দ্রুত গ্রহণ করা সহজ করে তোলে। আপনি যত বেশি প্রতিক্রিয়াশীল হবেন, আপনার সম্প্রদায় তত বেশি জড়িত হতে পারবে।\n\nসমস্ত আগত অবদানের উপর স্বয়ংক্রিয় পরীক্ষা সেট আপ করুন এবং নিশ্চিত করুন যে আপনার পরীক্ষাগুলি স্থানীয়ভাবে অবদানকারীদের দ্বারা সহজেই চালানো যেতে পারে। জমা দেওয়ার আগে সমস্ত কোড অবদানগুলিকে আপনার পরীক্ষায় উত্তীর্ণ হতে হবে। আপনি সমস্ত জমা দেওয়ার জন্য মানের একটি ন্যূনতম মান নির্ধারণ করতে সহায়তা করবেন। GitHub-এ [প্রয়োজনীয় স্থিতি পরীক্ষা](https://help.github.com/articles/about-required-status-checks/) নিশ্চিত করতে সাহায্য করতে পারে যে আপনার পরীক্ষাগুলি পাস না করে কোনও পরিবর্তন একত্রিত না হয়।\n\nযদি আপনি পরীক্ষা যোগ করেন, তাহলে আপনার CONTRIBUTING ফাইলে সেগুলি কীভাবে কাজ করে তা ব্যাখ্যা করতে ভুলবেন না।\n\n\n\n### মৌলিক রক্ষণাবেক্ষণের কাজগুলি স্বয়ংক্রিয় করতে সরঞ্জামগুলি ব্যবহার করুন\n\nThe good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.\n\nএকটি জনপ্রিয় প্রকল্প রক্ষণাবেক্ষণের বিষয়ে সুসংবাদ হল যে অন্যান্য রক্ষণাবেক্ষণকারীরা সম্ভবত একই ধরণের সমস্যার সম্মুখীন হয়েছেন এবং তাদের জন্য একটি সমাধান তৈরি করেছেন।\n\n[রক্ষণাবেক্ষণ কাজের কিছু দিক স্বয়ংক্রিয় করতে সাহায্য করার জন্য বিভিন্ন ধরণের সরঞ্জাম উপলব্ধ](https://github.com/showcases/tools-for-open-source) রয়েছে । কয়েকটি উদাহরণ:\n\n* [semantic-release](https://github.com/semantic-release/semantic-release) আপনার রিলিজগুলিকে স্বয়ংক্রিয় করে তোলে\n* [mention-bot](https://github.com/facebook/mention-bot) পুল রিকোয়েস্টের জন্য সম্ভাব্য পর্যালোচকদের উল্লেখ করেছে\n* [Danger](https://github.com/danger/danger) কোড পর্যালোচনা স্বয়ংক্রিয় করতে সাহায্য করে\n* [no-response](https://github.com/probot/no-response) - সেই সমস্যাগুলি বন্ধ করে দেয় যেখানে লেখক আরও তথ্যের জন্য অনুরোধের জবাব দেননি\n* [dependabot](https://github.com/dependabot) আপনার নির্ভরতা ফাইলগুলি প্রতিদিন পুরানো প্রয়োজনীয়তার জন্য পরীক্ষা করে এবং যে কোনওটির জন্য পৃথক পুল অনুরোধ খোলে।\n\nবাগ রিপোর্ট এবং অন্যান্য সাধারণ অবদানের জন্য, GitHub-এ [Issue Templates এবং Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates) রয়েছে , যা আপনি আপনার প্রাপ্ত যোগাযোগকে সহজতর করার জন্য তৈরি করতে পারেন। @TalAter আপনার সমস্যা এবং PR টেমপ্লেট লিখতে সাহায্য করার জন্য একটি [Choose Your Own Adventure নির্দেশিকা তৈরি করেছে।](https://www.talater.com/open-source-templates/#/)\n\nআপনার ইমেল বিজ্ঞপ্তিগুলি পরিচালনা করতে, আপনি অগ্রাধিকার অনুসারে সংগঠিত করার জন্য [ইমেল ফিল্টার সেট আপ করতে পারেন।](https://github.com/blog/2203-email-updates-about-your-own-activity)\n\nআপনি যদি আরও একটু উন্নত হতে চান, তাহলে স্টাইল গাইড এবং লিন্টারগুলি প্রকল্পের অবদানগুলিকে মানসম্মত করতে পারে এবং সেগুলি পর্যালোচনা এবং গ্রহণ করা সহজ করে তুলতে পারে।\n\nতবে, যদি আপনার মানদণ্ডগুলি খুব জটিল হয়, তাহলে অবদানের ক্ষেত্রে বাধাগুলি আরও বাড়িয়ে তুলতে পারে। নিশ্চিত করুন যে আপনি কেবলমাত্র পর্যাপ্ত নিয়ম যুক্ত করছেন যাতে প্রত্যেকের জীবন সহজ হয়।\n\nযদি আপনি নিশ্চিত না হন যে কোন টুলগুলি ব্যবহার করবেন, তাহলে অন্যান্য জনপ্রিয় প্রকল্পগুলি কী করে, বিশেষ করে আপনার ইকোসিস্টেমের মধ্যে সেগুলি দেখুন। উদাহরণস্বরূপ, অন্যান্য নোড মডিউলগুলির জন্য অবদান প্রক্রিয়াটি কেমন দেখায়? অনুরূপ টুল এবং পদ্ধতি ব্যবহার করলে আপনার প্রক্রিয়াটি আপনার লক্ষ্য অবদানকারীদের কাছে আরও পরিচিত হবে।\n\n## বিরতি দেওয়া ঠিক আছে\n\nওপেন সোর্স কাজ একসময় আপনাকে আনন্দ দিত। হয়তো এখন এটি আপনাকে এড়িয়ে চলা বা অপরাধবোধ করা শুরু করেছে।\n\nহয়তো তুমি যখন তোমার প্রকল্পগুলো নিয়ে ভাবো, তখন তুমি অভিভূত বোধ করো অথবা ভয়ের অনুভূতি ক্রমশ বাড়ছে। আর এরই মধ্যে, সমস্যা এবং পুল রিকোয়েস্টের স্তূপ জমতে থাকে।\n\nওপেন সোর্স কাজের ক্ষেত্রে, বিশেষ করে রক্ষণাবেক্ষণকারীদের মধ্যে, বার্নআউট একটি বাস্তব এবং ব্যাপক সমস্যা। একজন রক্ষণাবেক্ষণকারী হিসেবে, যেকোনো ওপেন সোর্স প্রকল্পের টিকে থাকার জন্য আপনার সুখ একটি অ-আলোচনাযোগ্য প্রয়োজনীয়তা।\n\nযদিও এটা বলাই বাহুল্য, একটু বিরতি নাও! ছুটি কাটানোর জন্য ক্লান্ত বোধ না করা পর্যন্ত অপেক্ষা করা উচিত নয়। @brettcannon, একজন পাইথন কোর ডেভেলপার, ১৪ বছর স্বেচ্ছাসেবক OSS কাজের পর [এক মাসব্যাপী ছুটি নেওয়ার সিদ্ধান্ত নিয়েছেন।](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/)\n\nঅন্য যেকোনো কাজের মতোই, নিয়মিত বিরতি আপনাকে সতেজ, খুশি এবং আপনার কাজের ব্যাপারে উত্তেজিত রাখবে।\n\n\n\nকখনও কখনও, যখন মনে হয় সকলের আপনার প্রয়োজন, তখন ওপেন সোর্স কাজ থেকে বিরতি নেওয়া কঠিন হতে পারে। এমনকি লোকেরা আপনাকে দূরে সরে যাওয়ার জন্য দোষী বোধ করানোর চেষ্টা করতে পারে।\n\nকোনও প্রকল্প থেকে দূরে থাকাকালীন আপনার ব্যবহারকারী এবং সম্প্রদায়ের জন্য সহায়তা খুঁজে বের করার জন্য যথাসাধ্য চেষ্টা করুন। যদি আপনি আপনার প্রয়োজনীয় সহায়তা খুঁজে না পান, তবে তবুও বিরতি নিন। যখন আপনি উপলব্ধ থাকবেন না তখন যোগাযোগ করতে ভুলবেন না, যাতে আপনার প্রতিক্রিয়াশীলতার অভাবের কারণে লোকেরা বিভ্রান্ত না হয়।\n\nবিরতি নেওয়া কেবল ছুটির সময়ের জন্যই প্রযোজ্য নয়। যদি আপনি সপ্তাহান্তে বা কাজের সময়ে ওপেন সোর্স কাজ করতে না চান, তাহলে সেই প্রত্যাশাগুলো অন্যদের কাছে পৌঁছে দিন, যাতে তারা আপনাকে বিরক্ত না করে।\n\n## আগে নিজের যত্ন নাও!\n\nএকটি জনপ্রিয় প্রকল্প রক্ষণাবেক্ষণের জন্য বৃদ্ধির প্রাথমিক পর্যায়ের তুলনায় ভিন্ন দক্ষতার প্রয়োজন হয়, তবে এটি কম ফলপ্রসূ নয়। একজন রক্ষণাবেক্ষণকারী হিসেবে, আপনি নেতৃত্ব এবং ব্যক্তিগত দক্ষতা এমন পর্যায়ে অনুশীলন করবেন যা খুব কম লোকই অনুভব করতে পারে। যদিও এটি পরিচালনা করা সবসময় সহজ নয়, স্পষ্ট সীমানা নির্ধারণ করা এবং আপনি যা নিয়ে স্বাচ্ছন্দ্য বোধ করেন কেবল তা গ্রহণ করা আপনাকে সুখী, সতেজ এবং উৎপাদনশীল থাকতে সাহায্য করবে।\n" }, { "path": "_articles/bn/building-community.md", "content": "---\nlang: bn\ntitle: Building Welcoming Communities\ndescription: Building a community that encourages people to use, contribute to, and evangelize your project.\nclass: building\norder: 4\nimage: /assets/images/cards/building.png\nrelated:\n - best-practices\n - coc\n---\n\n## Setting your project up for success\n\nYou'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?\n\nA 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.\n\n### Make people feel welcome\n\nOne 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/):\n\n![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)\n\nAs 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.\n\nStart with your documentation:\n\n* **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.\n* **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date.\n* **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.\n\n[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.\n\n* **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.\n* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.\n* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.\n* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#না-বলতে-শেখা) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.\n\n\n\nThe 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.\n\nEncouraging 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.\n\n### Document everything\n\n\n\nWhen 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.\n\nWhen 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.\n\nWriting 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.\n\nBe transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions.\n\nIf you notice multiple users running into the same problem, document the answers in the README.\n\nFor meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you.\n\nDocumenting 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.\n\n### Be responsive\n\nAs 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.\n\nTry 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.\n\nEven 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):\n\n![Middleman pull request](/assets/images/building-community/middleman_pr.png)\n\n[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.\n\nConversations 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.\n\n### Give your community a place to congregate\n\nThere are two reasons to give your community a place to congregate.\n\nThe 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.\n\nThe 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.\n\nPublic 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!\n\n[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members:\n\n> 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.\n\nNotable 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.\n\n## Growing your community\n\nCommunities 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.\n\n### Don't tolerate bad actors\n\nAny 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.\n\nDo 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.\n\n\n\nRegular 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.\n\nWhen 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.\n\n### Meet contributors where they're at\n\nGood 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.\n\nIn 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.\n\n![Django new contributors page](/assets/images/building-community/django_new_contributors.png)\n\nIn 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.\n\nFinally, use your documentation to make people feel welcome at every step of the way.\n\nYou 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.\n\nFor example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):\n\n> 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.\n\n### Share ownership of your project\n\n\n\nPeople 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.\n\nSee if you can find ways to share ownership with your community as much as possible. Here are some ideas:\n\n* **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.\n\n![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)\n\n* **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.\n\n* 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.\n\n* **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.\n\n* 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.\n\nThe reality is that [most projects only have](https://peerj.com/preprints/1233/) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help.\n\nWhile 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.\n\n\n\n## Resolving conflicts\n\nIn the early stages of your project, making major decisions is easy. When you want to do something, you just do it.\n\nAs 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.\n\nFor 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.\n\n### Set the bar for kindness\n\nWhen 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.\n\nYour 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.\n\n\n\nOther people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly.\n\nKeeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you.\n\n### Treat your README as a constitution\n\nYour 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.\n\n### Focus on the journey, not the destination\n\nSome 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.\n\nVoting 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.\n\nSometimes, 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.\n\nUnder 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.\n\n\n\nEven 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.\n\nDon'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.\n\n### Keep the conversation focused on action\n\nDiscussion is important, but there is a difference between productive and unproductive conversations.\n\nEncourage 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.\n\nAllowing 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.\n\nWith every point made by you or by others, ask yourself, _\"How does this bring us closer to a resolution?\"_\n\nIf the conversation is starting to unravel, ask the group, _\"Which steps should we take next?\"_ to refocus the conversation.\n\nIf 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.\n\n\n\n### Pick your battles wisely\n\nContext is important. Consider who is involved in the discussion and how they represent the rest of the community.\n\nIs 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.\n\nIf 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.\n\n### Identify a community tiebreaker\n\nWith 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.\n\nA 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.\n\nYour 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.\n\n## Community is the ❤️ of open source\n\nHealthy, 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.\n" }, { "path": "_articles/bn/code-of-conduct.md", "content": "---\nlang: bn\ntitle: Your Code of Conduct\ndescription: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct.\nclass: coc\norder: 8\nimage: /assets/images/cards/coc.png\nrelated:\n - building\n - leadership\n---\n\n## Why do I need a code of conduct?\n\nA 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.\n\nCodes 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.\n\nA 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.\n\n## Establishing a code of conduct\n\nTry to establish a code of conduct as early as possible: ideally, when you first create your project.\n\nIn addition to communicating your expectations, a code of conduct describes the following:\n\n* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_\n* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_\n* What happens if someone violates the code of conduct\n* How someone can report violations\n\nWherever 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.\n\nThe [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.\n\nPlace 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.\n\n## Deciding how you'll enforce your code of conduct\n\n\n\nYou should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so:\n\n* It demonstrates that you are serious about taking action when it's needed.\n\n* Your community will feel more reassured that complaints actually get reviewed.\n\n* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation.\n\nYou 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.\n\nDon'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):\n\n> 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.\\*\n\nFor 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).\n\n## Enforcing your code of conduct\n\nSometimes, 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.\n\n### Gather information about the situation\n\nTreat 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.\n\nThe 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.\n\nBefore 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.\n\n\n\n### Take appropriate action\n\nAfter 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.\n\nWhen 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.\n\nThere are a few ways you might respond to a code of conduct violation:\n\n* **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.\n\n* **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.\n\nSometimes, 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:\n\n* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project\n\n* **Permanently ban** the person from the project\n\nBanning 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.\n\n## Your responsibilities as a maintainer\n\nA 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.\n\nAs 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.\n\nA 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.\n\nIn 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.\n\n## Encourage the behavior you want to see in the world 🌎\n\nWhen 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.\n" }, { "path": "_articles/bn/finding-users.md", "content": "---\nlang: bn\ntitle: Finding Users for Your Project\ndescription: Help your open source project grow by getting it in the hands of happy users.\nclass: finding\norder: 3\nimage: /assets/images/cards/finding.png\nrelated:\n - beginners\n - building\n---\n\n## Spreading the word\n\nThere's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. Instead of hoping others will find and use your open source project, you have to spread the word about your hard work!\n\n## Figure out your message\n\nBefore you start the actual work of promoting your project, you should be able to explain what it does, and why it matters.\n\nWhat makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance.\n\nRemember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ might want.\n\nFor example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:\n\n![Cartography README](/assets/images/finding-users/cartography.jpg)\n\nFor a deeper dive into messaging, check out Mozilla's [\"Personas and Pathways\"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.\n\n## Help people find and follow your project\n\n\n\nHelp people find and remember your project by pointing them to a single namespace.\n\n**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene.\n\nIf you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides.\n\n\n\n**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide examples to give people ideas for how to use your project.\n\n[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _\"by far the best thing we did with Django in the early days\"_.\n\nIf your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.\n\n![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)\n\nNow that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!\n\n## Go where your project's audience is (online)\n\nOnline outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.\n\nTake advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.\n\n\n\nSee if you can find ways to share your project in relevant ways:\n\n* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work.\n* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution.\n* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _\"I think my project would really help X, who are trying to do Y_\". Listen and respond to others' feedback, rather than simply promoting your work.\n\nGenerally speaking, focus on helping others before asking for things in return. Because anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want.\n\nIf nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. Promoting and launching your project takes time and dedication.\n\n## Go where your project's audience is (offline)\n\n![Public speaking](/assets/images/finding-users/public_speaking.jpg)\n\nOffline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.\n\nIf you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project.\n\n\n\nIf you've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work.\n\nAs you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun.\n\n\n\nWhen you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world.\n\nLook for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's speakers.\n\n\n\n## Build a reputation\n\nIn addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects.\n\nHelping newcomers, sharing resources, and making thoughtful contributions to others' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships.\n\n\n\nIt's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others.\n\nThere is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends.\n\n## Keep at it!\n\nIt may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it.\n" }, { "path": "_articles/bn/getting-paid.md", "content": "---\nlang: bn\ntitle: Getting Paid for Open Source Work\ndescription: Sustain your work in open source by getting financial support for your time or your project.\nclass: getting-paid\norder: 7\nimage: /assets/images/cards/getting-paid.png\nrelated:\n - best-practices\n - leadership\n---\n\n## Why some people seek financial support\n\nMuch of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.\n\n\n\nThere are many reasons why a person would not want to be paid for their open source work.\n\n* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time.\n* **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.\n* **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.\n\n\n\nFor 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.\n\nMaintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.\n\n\n\nPaid 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.\n\n\n\nIf 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.\n\n## Funding your own time\n\nToday, 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.\n\nIt'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.\n\nIf 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.\n\nMany companies are developing open source programs to build their brand and recruit quality talent.\n\n@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:\n\n> 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.\n\nIf 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.\n\n\n\nIf 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:\n\n* Some companies, like [Netflix](https://netflix.github.io/), have websites that highlight their involvement in open source\n\nProjects 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.\n\nDepending on your personal circumstances, you can try raising money independently to fund your open source work. For example:\n\n* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors)\n* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/)\n* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django)\n\nFinally, sometimes open source projects put bounties on issues that you might consider helping with.\n\n* @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/).\n* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134).\n\n## Finding funding for your project\n\nBeyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.\n\nOrganizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.\n\nAs open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.\n\n### Raise money for your work through crowdfunding campaigns or sponsorships\n\nFinding sponsorships works well if you have a strong audience or reputation already, or your project is very popular.\nA few examples of sponsored projects include:\n\n* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack)\n* **[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\n\n### Create a revenue stream\n\nDepending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include:\n\n* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support\n* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product\n* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service\n\nSome popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth.\n\n### Apply for grant funding\n\nSome 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.\n\n* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)\n* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees)\n* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)\n* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work\n\nFor 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.\n\n## Building a case for financial support\n\nWhether 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.\n\nWhether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions.\n\n### Impact\n\nWhy is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years?\n\n### Traction\n\nTry 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?\n\n### Value to funder\n\nFunders, 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?\n\n### Use of funds\n\nWhat, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary.\n\n### How you'll receive the funds\n\nDoes 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.\n\n\n\n## Experiment and don't give up\n\nRaising 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.\n" }, { "path": "_articles/bn/how-to-contribute.md", "content": "---\nlang: bn\ntitle: How to Contribute to Open Source\ndescription: Want to contribute to open source? A guide to making open source contributions, for first-timers and veterans.\nclass: contribute\norder: 1\nimage: /assets/images/cards/contribute.png\nrelated:\n - beginners\n - building\n---\n\n## Why contribute to open source?\n\n\n\nContributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine.\n\nWhy do people contribute to open source? Plenty of reasons!\n\n### Improve software you rely on\n\nLots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it.\n\n### Improve existing skills\n\nWhether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project.\n\n### Meet people who are interested in similar things\n\nOpen source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos.\n\n### Find mentors and teach others\n\nWorking with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved.\n\n### Build public artifacts that help you grow a reputation (and a career)\n\nBy definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do.\n\n### Learn people skills\n\nOpen source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work.\n\n### It's empowering to be able to make changes, even small ones\n\nYou don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying.\n\n## What it means to contribute\n\nIf you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong?\n\nNot to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience.\n\n### You don't have to contribute code\n\nA common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions!\n\n\n\nEven if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.\n\n### Do you like planning events?\n\n* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406)\n* Organize the project's conference (if they have one)\n* Help community members find the right conferences and submit proposals for speaking\n\n### Do you like to design?\n\n* Restructure layouts to improve the project's usability\n* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability)\n* Put together a style guide to help the project have a consistent visual design\n* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68)\n\n### Do you like to write?\n\n* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)\n* Curate a folder of examples showing how the project is used\n* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)\n* Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/)\n* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077)\n\n\n\n### Do you like organizing?\n\n* Link to duplicate issues, and suggest new issue labels, to keep things organized\n* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)\n* Ask clarifying questions on recently opened issues to move the discussion forward\n\n### Do you like to code?\n\n* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560)\n* Ask if you can help write a new feature\n* Automate project setup\n* Improve tooling and testing\n\n### Do you like helping people?\n\n* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit\n* Answer questions for people on open issues\n* Help moderate the discussion boards or conversation channels\n\n### Do you like helping others code?\n\n* Review code on other people's submissions\n* Write tutorials for how a project can be used\n* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666)\n\n### You don't just have to work on software projects!\n\nWhile \"open source\" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.\n\nFor example:\n\n* @sindresorhus curates a [list of \"awesome\" lists](https://github.com/sindresorhus/awesome)\n* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates\n* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)\n\nEven if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience.\n\n## Orienting yourself to a new project\n\n\n\nFor anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely.\n\nBefore jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard.\n\n### Anatomy of an open source project\n\nEvery open source community is different.\n\nSpending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.\n\nThat said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.\n\nA typical open source project has the following types of people:\n\n* **Author:** The person/s or organization that created the project\n* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author)\n* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.)\n* **Contributors:** Everyone who has contributed something back to the project\n* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction\n\nBigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a \"team\" page, or in the repository for governance documentation, to find this information.\n\nA project also has documentation. These files are usually listed in the top level of a repository.\n\n* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.\n* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.\n* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide).\n* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.\n* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs).\n\nFinally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.\n\n* **Issue tracker:** Where people discuss issues related to the project.\n* **Pull requests:** Where people discuss and review changes that are in progress, whether it's to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews.\n* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _\"How do I...\"_ or _\"What do you think about...\"_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/)\n* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/).\n\n## Finding a project to contribute to\n\nNow that you've figured out how open source projects work, it's time to find a project to contribute to!\n\nIf you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _\"Ask not what your country can do for you - ask what you can do for your country.\"_\n\n\n\nContributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look.\n\nInstead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to.\n\nWithin those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct.\n\nOpen source isn't an exclusive club; it's made by people just like you. \"Open source\" is just a fancy term for treating the world's problems as fixable.\n\nYou might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!\n\n> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation.\n\nIf you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).\n\nYou can also use one of the following resources to help you discover and contribute to new projects:\n\n* [GitHub Explore](https://github.com/explore/)\n* [Open Source Friday](https://opensourcefriday.com)\n* [First Timers Only](https://www.firsttimersonly.com/)\n* [CodeTriage](https://www.codetriage.com/)\n* [24 Pull Requests](https://24pullrequests.com/)\n* [Up For Grabs](https://up-for-grabs.net/)\n* [First Contributions](https://firstcontributions.github.io)\n* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)\n* [OpenSauced](https://opensauced.pizza/)\n\n### A checklist before you contribute\n\nWhen you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response.\n\nHere's a handy checklist to evaluate whether a project is good for new contributors.\n\n**Meets the definition of open source**\n\n
\n \n \n
\n\n**Project actively accepts contributions**\n\nLook at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\nNext, look at the project's issues.\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\nNow do the same for the project's pull requests.\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n**Project is welcoming**\n\nA project that is friendly and welcoming signals that they will be receptive to new contributors.\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n
\n \n \n
\n\n\n\n## How to submit a contribution\n\nYou've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way.\n\n### Communicating effectively\n\nWhether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source.\n\n\n\nBefore you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.\n\n**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!).\n\n> 😇 _\"X doesn't happen when I do Y\"_\n>\n> 😢 _\"X is broken! Please fix it.\"_\n\n**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.\n\n> 😇 _\"I'm not sure how to implement X. I checked the help docs and didn't find any mentions.\"_\n>\n> 😢 _\"How do I X?\"_\n\n**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.\n\n> 😇 _\"I'd like to write an API tutorial.\"_\n>\n> 😢 _\"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you...\"_\n\n**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.\n\n> 😇 _(as a comment) \"@-maintainer Hi there! How should we proceed on this PR?\"_\n>\n> 😢 _(as an email) \"Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR\"_\n\n**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you.\n\n> 😇 _\"Thanks for looking into this error. I followed your suggestions. Here's the output.\"_\n>\n> 😢 _\"Why can't you fix my problem? Isn't this your project?\"_\n\n**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.\n\n> 😇 _\"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening.\"_\n>\n> 😢 _\"Why won't you support my use case? This is unacceptable!\"_\n\n**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.\n\n### Gathering context\n\nBefore doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.\n\nIf you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following:\n\n* **Raising an Issue:** These are like starting a conversation or discussion\n* **Pull requests** are for starting work on a solution.\n* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.\n\nBefore you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests.\n\nIf you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click \"Watch\"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted.\n\n\n\n### Opening an issue\n\nYou should usually open an issue in the following situations:\n\n* Report an error you can't solve yourself\n* Discuss a high-level topic or idea (for example, community, vision or policies)\n* Propose a new feature or other project idea\n\nTips for communicating on issues:\n\n* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.\n* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.\n* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.\n\n### Opening a pull request\n\nYou should usually open a pull request in the following situations:\n\n* Submit small fixes such as a typo, a broken link or an obvious error.\n* Start work on a contribution that was already asked for, or that you've already discussed, in an issue.\n\nA pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a \"draft\" or mark as a \"WIP\" (Work in Progress) in the subject line or \"Notes to Reviewers\" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later.\n\nIf the project is on GitHub, here's how to submit a pull request:\n\n* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original \"upstream\" repository by adding it as a remote. Pull in changes from \"upstream\" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).)\n* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.\n* **Reference any relevant issues** or supporting documentation in your PR (for example, \"Closes #37.\")\n* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.\n* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project.\n* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.\n\nIf this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.\n\n## What happens after you submit your contribution\n\nBefore we start celebrating, one of the following will happen after you submit your contribution:\n\n### 😭 You don't get a response\n\nHopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response.\n\nIf you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.\n\n**Don't reach out to that person privately**; remember that public communication is vital to open source projects.\n\nIf you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.\n\n### 🚧 Someone requests changes to your contribution\n\nIt's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code.\n\nWhen someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286).\n\nIf you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346).\n\n### 👎 Your contribution doesn't get accepted\n\nYour contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree!\n\n### 🎉 Your contribution gets accepted\n\nHooray! You've successfully made an open source contribution!\n\n## You did it! 🎉\n\nWhether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time.\n" }, { "path": "_articles/bn/index.html", "content": "---\nlayout: index\ntitle: ওপেন সোর্স নির্দেশিকা\nlang: bn\npermalink: /bn/\n---\n" }, { "path": "_articles/bn/leadership-and-governance.md", "content": "---\nlang: bn\ntitle: Leadership and Governance\ndescription: Growing open source projects can benefit from formal rules for making decisions.\nclass: leadership\norder: 6\nimage: /assets/images/cards/leadership.png\nrelated:\n - best-practices\n - metrics\n---\n\n## Understanding governance for your growing project\n\nYour 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.\n\n## What are examples of formal roles used in open source projects?\n\nMany projects follow a similar structure for contributor roles and recognition.\n\nWhat these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:\n\n* **Maintainer**\n* **Contributor**\n* **Committer**\n\n**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.\n\nA 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.\n\n**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).\n\n\n\n**The term \"committer\"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.\n\nWhile 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.\n\n\n\n## How do I formalize these leadership roles?\n\nFormalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.\n\nFor a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.\n\nFor 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.\n\nIf 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.\n\n\n\nLeadership 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).\n\nOnce 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.\n\nTools 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.\n\nFinally, 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).\n\n## When should I give someone commit access?\n\nSome 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.\n\nOn 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!\n\nIf 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.\n\n\n\n## What are some of the common governance structures for open source projects?\n\nThere are three common governance structures associated with open source projects.\n\n* **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.\n\n* **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.\n\n* **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/).\n\nWhich 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:\n\n* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)\n* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)\n* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)\n\n## Do I need governance docs when I launch my project?\n\nThere 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!\n\nSome 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.\n\nIf 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.\n\n\n\n## What happens if corporate employees start submitting contributions?\n\nSuccessful 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.\n\nAs 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.\n\nIt'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.\n\n\"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.)\n\nLike 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.\n\n## Do I need a legal entity to support my project?\n\nYou don't need a legal entity to support your open source project unless you're handling money.\n\nFor 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).\n\nIf 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).\n\nMany projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects.\n\n\n\nIf 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.\n" }, { "path": "_articles/bn/legal.md", "content": "---\nlang: bn\ntitle: The Legal Side of Open Source\ndescription: Everything you've ever wondered about the legal side of open source, and a few things you didn't.\nclass: legal\norder: 10\nimage: /assets/images/cards/legal.png\nrelated:\n - contribute\n - leadership\n---\n\n## Understanding the legal implications of open source\n\nSharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).)\n\n## Why do people care so much about the legal side of open source?\n\nGlad 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.\n\nIn general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.\n\nOpen source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.\n\nThese rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.\n\nFinally, 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.\n\n## Are public GitHub projects open source?\n\nWhen 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**.\n\n![Create repository](/assets/images/legal/repo-create-name.png)\n\n**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions.\n\nIf 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.\n\n## Just give me the TL;DR on what I need to protect my project.\n\nYou'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.\n\n[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).\n\nWhen you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/).\n\n\n\n## Which open source license is appropriate for my project?\n\nIt's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.\n\nOtherwise, picking the right open source license for your project depends on your objectives.\n\nYour project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm).\n\nDependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want.\n\nDependencies with **copyleft licenses** require closer attention. Including any library with a \"strong\" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a \"limited\" or \"weak\" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify.\n\nYou may also want to consider the **communities** you hope will use and contribute to your project:\n\n* **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).\n* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.\n* **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.\n\nYour **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance.\n\nWhen 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/).\n\n## What if I want to change the license of my project?\n\nMost projects never need to change licenses. But occasionally circumstances change.\n\nFor 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:\n\n**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!\n\n**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.\n\n**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? [People who have commits in your project](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.\n\nAlternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.\n\n## Does my project need an additional contributor agreement?\n\nProbably 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).\n\nAn 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.\n\nAlso, 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.\n\n\n\nSome situations where you may want to consider an additional contributor agreement for your project include:\n\n* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.\n* 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).\n* 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.\n* 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.\n* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.\n\nIf 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.\n\n## What does my company's legal team need to know?\n\nIf you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project.\n\nFor 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.\n\n**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:\n\n* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses ([see above](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.\n\n* **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.\n\n* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)).\n\n* **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.\n\n* **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.\n\nIf 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).\n\nLonger term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:\n\n* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://ospo.co/blog/crafting-your-open-source-contribution-policy/).\n\n\n\n* **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.\n* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits.\n\n\n\n* **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).\n* **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).\n" }, { "path": "_articles/bn/maintaining-balance-for-open-source-maintainers.md", "content": "---\nlang: bn\nuntranslated: false\ntitle: ওপেন সোর্স রক্ষণাবেক্ষণকারীদের জন্য ভারসাম্য বজায় রাখা\ndescription: একজন রক্ষণাবেক্ষণকারী হিসেবে নিজের যত্ন নেওয়ার এবং বার্নআউট এড়ানোর জন্য টিপস।\nclass: balance\norder: 0\nimage: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png\n---\n\nএকটি ওপেন সোর্স প্রকল্পের জনপ্রিয়তা বৃদ্ধির সাথে সাথে, দীর্ঘমেয়াদে সতেজ এবং উৎপাদনশীল থাকার জন্য ভারসাম্য বজায় রাখতে স্পষ্ট সীমানা নির্ধারণ করা গুরুত্বপূর্ণ হয়ে ওঠে।\n\nরক্ষণাবেক্ষণকারীদের অভিজ্ঞতা এবং ভারসাম্য খুঁজে বের করার কৌশল সম্পর্কে অন্তর্দৃষ্টি পেতে, আমরা [রক্ষণাবেক্ষণকারী সম্প্রদায়ের](http://maintainers.github.com/) ৪০ জন সদস্যের সাথে একটি কর্মশালা পরিচালনা করেছি , যেখানে আমরা ওপেন সোর্সে বার্নআউটের সাথে তাদের প্রত্যক্ষ অভিজ্ঞতা এবং তাদের কাজে ভারসাম্য বজায় রাখতে সাহায্য করেছে এমন অনুশীলনগুলি থেকে শিখতে পেরেছি। এখানেই ব্যক্তিগত বাস্তুবিদ্যার ধারণাটি কার্যকর হয়।\n\nতাহলে, ব্যক্তিগত বাস্তুবিদ্যা কী? [রকউড লিডারশিপ ইনস্টিটিউটের বর্ণনা](https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism) অনুসারে , এর মধ্যে রয়েছে \" **আমাদের শক্তি সারা জীবন ধরে ধরে রাখার জন্য ভারসাম্য, গতি এবং দক্ষতা বজায় রাখা ।\" এটি আমাদের কথোপকথনকে কাঠামোবদ্ধ করে, রক্ষণাবেক্ষণকারীদের তাদের কর্ম এবং অবদানকে সময়ের সাথে সাথে বিকশিত হওয়া একটি বৃহত্তর বাস্তুতন্ত্রের অংশ হিসাবে স্বীকৃতি দিতে সাহায্য করে।** [WHO দ্বারা সংজ্ঞায়িত](https://icd.who.int/browse/2025-01/foundation/en#129180281) দীর্ঘস্থায়ী কর্মক্ষেত্রের চাপের ফলে সৃষ্ট একটি সিন্ড্রোম, বার্নআউট, রক্ষণাবেক্ষণকারীদের মধ্যে অস্বাভাবিক নয়। এর ফলে প্রায়শই প্রেরণা হ্রাস পায়, মনোযোগ দিতে অক্ষমতা হয় এবং আপনার সাথে কাজ করা অবদানকারী এবং সম্প্রদায়ের প্রতি সহানুভূতির অভাব দেখা দেয়।\n\n\n\nব্যক্তিগত বাস্তুতন্ত্রের ধারণাটি গ্রহণ করে, রক্ষণাবেক্ষণকারীরা সক্রিয়ভাবে বার্নআউট এড়াতে পারেন, নিজের যত্নকে অগ্রাধিকার দিতে পারেন এবং তাদের সর্বোত্তম কাজ করার জন্য ভারসাম্যের অনুভূতি বজায় রাখতে পারেন।\n\n## রক্ষণাবেক্ষণকারী হিসেবে নিজের যত্ন নেওয়ার এবং বার্নআউট এড়ানোর জন্য টিপস:\n\n### ওপেন সোর্সে কাজ করার জন্য আপনার অনুপ্রেরণাগুলি চিহ্নিত করুন।\n\nওপেন সোর্স রক্ষণাবেক্ষণের কোন কোন অংশ আপনাকে উজ্জীবিত করে তা নিয়ে চিন্তা করার জন্য সময় নিন। আপনার অনুপ্রেরণাগুলি বোঝা আপনাকে এমনভাবে কাজকে অগ্রাধিকার দিতে সাহায্য করতে পারে যা আপনাকে নিযুক্ত রাখে এবং নতুন চ্যালেঞ্জের জন্য প্রস্তুত রাখে। ব্যবহারকারীদের কাছ থেকে ইতিবাচক প্রতিক্রিয়া, সম্প্রদায়ের সাথে সহযোগিতা এবং সামাজিকীকরণের আনন্দ, অথবা কোডে ডুব দেওয়ার সন্তুষ্টি, আপনার অনুপ্রেরণাগুলি স্বীকৃতি দেওয়া আপনার ফোকাসকে নির্দেশিত করতে সহায়তা করতে পারে।\n\n### [](https://opensource.guide/maintaining-balance-for-open-source-maintainers/#reflect-on-what-causes-you-to-get-out-of-balance-and-stressed-out)আপনার ভারসাম্য নষ্ট হওয়ার এবং চাপের কারণ কী তা নিয়ে ভাবুন।\n\nআমাদের কেন ক্লান্তি আসে তা বোঝা গুরুত্বপূর্ণ। ওপেন সোর্স রক্ষণাবেক্ষণকারীদের মধ্যে আমরা যে কয়েকটি সাধারণ বিষয় দেখেছি তা এখানে দেওয়া হল:\n\n* **ইতিবাচক প্রতিক্রিয়ার অভাব:** ব্যবহারকারীরা অভিযোগ করলে যোগাযোগ করার সম্ভাবনা অনেক বেশি। সবকিছু ঠিকঠাক থাকলে, তারা চুপ করে থাকে। ইতিবাচক প্রতিক্রিয়া ছাড়াই সমস্যার ক্রমবর্ধমান তালিকা দেখা হতাশাজনক হতে পারে, যেখানে আপনার অবদান কীভাবে পরিবর্তন আনছে তা দেখানো হচ্ছে।\n\n