From b07469384c25e0e1f303273f7e573bedcb2a1181 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Thu, 18 Mar 2021 18:51:08 +0330 Subject: [PATCH 001/629] Create fa.yml Initial translation done. --- _data/locales/fa.yml | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 _data/locales/fa.yml diff --git a/_data/locales/fa.yml b/_data/locales/fa.yml new file mode 100644 index 00000000000..dd41c8e0717 --- /dev/null +++ b/_data/locales/fa.yml @@ -0,0 +1,31 @@ +en: + locale_name: Farsi + nav: + about: درباره + contribute: مشارکت + index: + lead: نرم‌افزار متن باز توسط افرادی مشابه شما ساخته شده است. اینجا می‌توانید راه اندازی و رشد دادن پروژه خود را یاد بگیرید. + opensourcefriday: امروز جمعه‌اس! چند ساعت صرف مشارکت در نرم افزاری کن که عاشقش هستی + article: + table_of_contents: فهرست مطالب + back_to_all_guides: بازگشت به صفحه اصلی + related_guides: راهنماهای مرتبط + footer: + contribute: + heading: مشارکت + description: پیشنهاد یا نظری داری؟ این مطلب به صورت متن باز منتشر شد. می‌تونی در بهبودش کمک کنی. + button: مشارکت می‌کنم + subscribe: + heading: در ارتباط باش + description: اولین نفر ی باش که در خصوص آخرین نکات و ترفندهای متن باز در گیتهاب باخبر میشه. + label: آدرس ایمیل + button: شروع اشتراک + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] با [love] توسط [github] و [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: عشق + # Label for the contributors link + friends_label: دوستان From 0df69de78f0350c7ff94504c8ac3c027a2f17b16 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Thu, 18 Mar 2021 19:01:23 +0330 Subject: [PATCH 002/629] Just started to translate guides. Just started to translate guides. --- _articles/fa/best-practices.md | 287 ++++++++++++ _articles/fa/building-community.md | 280 +++++++++++ _articles/fa/code-of-conduct.md | 120 +++++ _articles/fa/finding-users.md | 163 +++++++ _articles/fa/getting-paid.md | 192 ++++++++ _articles/fa/how-to-contribute.md | 535 ++++++++++++++++++++++ _articles/fa/index.html | 6 + _articles/fa/leadership-and-governance.md | 165 +++++++ _articles/fa/legal.md | 166 +++++++ _articles/fa/metrics.md | 132 ++++++ _articles/fa/starting-a-project.md | 362 +++++++++++++++ 11 files changed, 2408 insertions(+) create mode 100644 _articles/fa/best-practices.md create mode 100644 _articles/fa/building-community.md create mode 100644 _articles/fa/code-of-conduct.md create mode 100644 _articles/fa/finding-users.md create mode 100644 _articles/fa/getting-paid.md create mode 100644 _articles/fa/how-to-contribute.md create mode 100644 _articles/fa/index.html create mode 100644 _articles/fa/leadership-and-governance.md create mode 100644 _articles/fa/legal.md create mode 100644 _articles/fa/metrics.md create mode 100644 _articles/fa/starting-a-project.md diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md new file mode 100644 index 00000000000..c1894f66eaf --- /dev/null +++ b/_articles/fa/best-practices.md @@ -0,0 +1,287 @@ +--- +lang: fa +title: بهترین روال‌های تجربه شده برای نگهدارنده‌ها +description: زندگی خود را به عنوان یک نگهدارنده‌ی اوپن سورس آسان‌تر کنید؛ از ثبت‌کردن فرآیندها گرفته تا بهره‌بردن از اجتماع‌تان. +class: best-practices +toc: + what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?" + documenting-your-processes: "Documenting your processes" + learning-to-say-no: "Learning to say no" + leverage-your-community: "Leverage your community" + bring-in-the-robots: "Bring in the robots" + its-okay-to-hit-pause: "It’s okay to hit pause" +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## What does it mean to be a maintainer? + +If 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. + +In 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. + +Maintaining 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. + +## Documenting your processes + +Writing things down is one of the most important things you can do as a maintainer. + +Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask. + +Writing 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. + +Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all. + +Remember 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. + +### Write down your project's vision + +Start 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. + +Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions. + +For 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). + + + +### Communicate your expectations + +Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun. + +Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do. + +Most 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. + +All of this is perfectly okay! Just make sure other people know about it. + +If 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. + +Here are a few rules that are worth writing down: + +* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_) +* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_) +* 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."_) +* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_) + +[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. + +### Keep communication public + +Don'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. + +If 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. + +That way, anybody who joins your community will have access to the same information as someone who's been there for years. + +## Learning to say no + +You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists. + +Having everything written down, however, helps depersonalize situations when you do need to enforce your rules. + +Saying no isn't fun, but _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_. + +Saying 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. + +### Keep the conversation friendly + +One 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. + +Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor. + +Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards. + +If 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. + + + +Don'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. + +It'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). + +Secondly, 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! + +If you don't want to accept a contribution: + +* **Thank them** for their contribution +* **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. +* **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. +* **Close the request** + +You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383): + +![Celery screenshot](/assets/images/best-practices/celery.png) + +If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/): + +> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want. + +Don'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. + +Ultimately, 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. + +### Be proactive + +To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide. + +If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example: + +* Fill out a issue or PR template/checklist +* Open an issue before submitting a PR + +If they don't follow your rules, close the issue immediately and point to your documentation. + +While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage. + + + +Sometimes, 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. + +### Embrace mentorship + +Maybe 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. + +If 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. + +## Leverage your community + +You 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. + +### Share the workload + +If you're looking for others to pitch in, start by asking around. + +One 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. + +When 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. + +Encouraging 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). + + + +If 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. + +If 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! + +@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: + +> 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. + +### Let others build the solutions they need + +If 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. + +Forking 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. + + + +The 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": + +> 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. + +## Bring in the robots + +Just 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. + +### Require tests and other checks to improve the quality of your code + +One of the most important ways you can automate your project is by adding tests. + +Tests 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. + +Set 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. + +If you add tests, make sure to explain how they work in your CONTRIBUTING file. + + + +### Use tools to automate basic maintenance tasks + +The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it. + +There 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: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases +* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests +* [Danger](https://github.com/danger/danger) helps automate code review +* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information +* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds + +For 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. + +To 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. + +If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept. + +However, 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. + +If 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. + +## It's okay to hit pause + +Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty. + +Perhaps 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. + +Burnout 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. + +Although 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. + +Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work. + + + +Sometimes, 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. + +Do 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. + +Taking 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. + +## Take care of yourself first! + +Maintaining 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. diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md new file mode 100644 index 00000000000..a86c8b26c55 --- /dev/null +++ b/_articles/fa/building-community.md @@ -0,0 +1,280 @@ +--- +lang: en +title: Building Welcoming Communities +description: Building a community that encourages people to use, contribute to, and evangelize your project. +class: building +toc: + setting-your-project-up-for-success: "Setting your project up for success" + growing-your-community: "Growing your community" + resolving-conflicts: "Resolving conflicts" +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Setting your project up for success + +You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around? + +A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back. + +### Make people feel welcome + +One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more. + +Start with your documentation: + +* **Make it easy for someone to use your project.** [A friendly README](../starting-a-project/#writing-a-readme) and clear code examples will make it easier for anyone who lands on your project to get started. +* **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date. +* **Good first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level. + +[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. + +* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back. +* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project. +* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help. +* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it. + + + +The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute. + +Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself. + +### Document everything + + + +When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public. + +When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed. + +Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public. + +Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions. + +If you notice multiple users running into the same problem, document the answers in the README. + +For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you. + +Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on. + +### Be responsive + +As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started. + +Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating. + +Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466): + +![Middleman pull request](/assets/images/building-community/middleman_pr.png) + +[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution. + +Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project. + +### Give your community a place to congregate + +There are two reasons to give your community a place to congregate. + +The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate. + +The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel. + +Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members: + +> 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. + +Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address. + +## Growing your community + +Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction. + +### Don't tolerate bad actors + +Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others. + +Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave. + + + +Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate. + +When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations. + +### Meet contributors where they're at + +Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need. + +In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors. + +![Django new contributors page](/assets/images/building-community/django_new_contributors.png) + +In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started. + +Finally, use your documentation to make people feel welcome at every step of the way. + +You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration. + +For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue. + +### Share ownership of your project + + + +People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around. + +See if you can find ways to share ownership with your community as much as possible. Here are some ideas: + +* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself. + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does. + +* 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. + +* **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. + +* 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. + +The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help. + +While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help. + + + +## Resolving conflicts + +In the early stages of your project, making major decisions is easy. When you want to do something, you just do it. + +As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own. + +For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address. + +### Set the bar for kindness + +When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you. + +Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive. + + + +Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly. + +Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you. + +### Treat your README as a constitution + +Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion. + +### Focus on the journey, not the destination + +Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns. + +Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place. + +Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus. + +Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion. + + + +Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions. + +Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution. + +### Keep the conversation focused on action + +Discussion is important, but there is a difference between productive and unproductive conversations. + +Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down. + +Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues. + +With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_ + +If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation. + +If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it. + + + +### Pick your battles wisely + +Context is important. Consider who is involved in the discussion and how they represent the rest of the community. + +Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices. + +If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread. + +### Identify a community tiebreaker + +With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker. + +A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it. + +Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible. + +## Community is the ❤️ of open source + +Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience. diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md new file mode 100644 index 00000000000..0b21e42d458 --- /dev/null +++ b/_articles/fa/code-of-conduct.md @@ -0,0 +1,120 @@ +--- +lang: en +title: Your Code of Conduct +description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. +class: coc +toc: + why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?" + establishing-a-code-of-conduct: "Establishing a code of conduct" + deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct" + enforcing-your-code-of-conduct: "Enforcing your code of conduct" + your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer" +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Why do I need a code of conduct? + +A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community. + +Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time. + +A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with. + +## Establishing a code of conduct + +Try to establish a code of conduct as early as possible: ideally, when you first create your project. + +In addition to communicating your expectations, a code of conduct describes the following: + +* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_ +* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_ +* What happens if someone violates the code of conduct +* How someone can report violations + +Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. + +The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples. + +Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file. + +## Deciding how you'll enforce your code of conduct + + + +You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so: + +* It demonstrates that you are serious about taking action when it's needed. + +* Your community will feel more reassured that complaints actually get reviewed. + +* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation. + +You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group. + +Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> 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.* + +For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project). + +## Enforcing your code of conduct + +Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up. + +### Gather information about the situation + +Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment. + +The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context. + +Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior. + + + +### Take appropriate action + +After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward. + +When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise. + +There are a few ways you might respond to a code of conduct violation: + +* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication. + +* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them. + +Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example: + +* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project + +* **Permanently ban** the person from the project + +Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached. + +## Your responsibilities as a maintainer + +A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes. + +As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community. + +A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable. + +In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way. + +## Encourage the behavior you want to see in the world 🌎 + +When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow. diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md new file mode 100644 index 00000000000..84ec4c6e7ca --- /dev/null +++ b/_articles/fa/finding-users.md @@ -0,0 +1,163 @@ +--- +lang: en +title: Finding Users for Your Project +description: Help your open source project grow by getting it in the hands of happy users. +class: finding +toc: + spreading-the-word: "Spreading the word" + figure-out-your-message: "Figure out your message" + help-people-find-and-follow-your-project: "Help people find and follow your project" + go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)" + go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)" + build-a-reputation: "Build a reputation" +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Spreading the word + +There'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! + +## Figure out your message + +Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters. + +What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance. + +Remember 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. + +For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +For 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. + +## Help people find and follow your project + + + +Help people find and remember your project by pointing them to a single namespace. + +**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. These outlets also give your project's growing community a place to convene. + +If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. + + + +**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. + +[@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"_. + +If 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. + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +Now 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! + +## Go where your project's audience is (online) + +Online 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. + +Take 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. + + + +See if you can find ways to share your project in relevant ways: + +* **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. +* **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. +* **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. + +Generally 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. + +If 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. + +## Go where your project's audience is (offline) + +![Public speaking](/assets/images/finding-users/public_speaking.jpg) + +Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers. + +If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. + + + +If 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. + +As 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. + + + +When 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. + +Look 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. + + + +## Build a reputation + +In 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. + +Helping 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. + + + +It'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. + +There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends. + + + +## Keep at it! + +It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it. diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md new file mode 100644 index 00000000000..42d75af5b33 --- /dev/null +++ b/_articles/fa/getting-paid.md @@ -0,0 +1,192 @@ +--- +lang: en +title: Getting Paid for Open Source Work +description: Sustain your work in open source by getting financial support for your time or your project. +class: getting-paid +toc: + why-some-people-seek-financial-support: "Why some people seek financial support" + funding-your-own-time: "Funding your own time" + finding-funding-for-your-project: "Finding funding for your project" + building-a-case-for-financial-support: "Building a case for financial support" +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Why some people seek financial support + +Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. + + + +There are many reasons why a person would not want to be paid for their open source work. + +* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time. +* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects. +* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community. + + + +For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons. + +Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month. + + + +Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community. + + + +If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project. + +## Funding your own time + +Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. + +It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general. + + + +If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software. + +Many companies are developing open source programs to build their brand and recruit quality talent. + +@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting: + +> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues. + +If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location. + + + +If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example: + +* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source +* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees + +Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. + +Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: + +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) +* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) +* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +Finally, sometimes open source projects put bounties on issues that you might consider helping with. + +* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/). +* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). + +## Finding funding for your project + +Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. + +Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas. + +As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. + +### Raise money for your work through crowdfunding campaigns or sponsorships + +Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular. +A few examples of sponsored projects include: + +* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack) +* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803) +* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects + +### Create a revenue stream + +Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support +* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product +* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service + +Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. + +### Apply for grant funding + +Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology) +* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work + +For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you. + +## Building a case for financial support + +Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case. + +Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions. + +### Impact + +Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years? + +### Traction + +Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it? + +### Value to funder + +Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit? + +### Use of funds + +What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary. + +### How you'll receive the funds + +Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand. + + + +## Experiment and don't give up + +Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding. diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md new file mode 100644 index 00000000000..81158f6f25a --- /dev/null +++ b/_articles/fa/how-to-contribute.md @@ -0,0 +1,535 @@ +--- +lang: en +title: How to Contribute to Open Source +description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans. +class: contribute +toc: + why-contribute-to-open-source: "Why contribute to open source?" + what-it-means-to-contribute: "What it means to contribute" + orienting-yourself-to-a-new-project: "Orienting yourself to a new project" + finding-a-project-to-contribute-to: "Finding a project to contribute to" + how-to-submit-a-contribution: "How to submit a contribution" + what-happens-after-you-submit-a-contribution: "What happens after you submit a contribution" +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Why contribute to open source? + + + +Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine. + +Why do people contribute to open source? Plenty of reasons! + +### Improve software you rely on + +Lots of open source contributors start by being users of software they contribute to. When you find a bug in 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. + +### Improve existing skills + +Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. + +### Meet people who are interested in similar things + +Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos. + +### Find mentors and teach others + +Working 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. + +### Build public artifacts that help you grow a reputation (and a career) + +By 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. + +### Learn people skills + +Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work. + +### It's empowering to be able to make changes, even small ones + +You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying. + +## What it means to contribute + +If 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? + +Not 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. + +### You don't have to contribute code + +A 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! + + + +Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project. + + + +### Do you like planning events? + +* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Organize the project's conference (if they have one) +* Help community members find the right conferences and submit proposals for speaking + +### Do you like to design? + +* Restructure layouts to improve the project's usability +* 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) +* Put together a style guide to help the project have a consistent visual design +* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) + +### Do you like to write? + +* Write and improve the project's documentation +* Curate a folder of examples showing how the project is used +* Start a newsletter for the project, or curate highlights from the mailing list +* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Write a translation for the project's documentation + + + +### Do you like organizing? + +* Link to duplicate issues, and suggest new issue labels, to keep things organized +* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) +* Ask clarifying questions on recently opened issues to move the discussion forward + +### Do you like to code? + +* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Ask if you can help write a new feature +* Automate project setup +* Improve tooling and testing + +### Do you like helping people? + +* 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 +* Answer questions for people on open issues +* Help moderate the discussion boards or conversation channels + +### Do you like helping others code? + +* Review code on other people's submissions +* Write tutorials for how a project can be used +* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### You don't just have to work on software projects! + +While "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. + +For example: + +* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) +* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates +* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) + +Even 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. + +## Orienting yourself to a new project + + + +For 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. + +Before 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. + +### Anatomy of an open source project + +Every open source community is different. + +Spending 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. + +That 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. + +A typical open source project has the following types of people: + +* **Author:** The person/s or organization that created the project +* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author) +* **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.) +* **Contributors:** Everyone who has contributed something back to the project +* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction + +Bigger 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. + +A project also has documentation. These files are usually listed in the top level of a repository. + +* **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. +* **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. +* **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. +* **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. +* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects. + +Finally, 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. + +* **Issue tracker:** Where people discuss issues related to the project. +* **Pull requests:** Where people discuss and review changes that are in progress. +* **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. +* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. + +## Finding a project to contribute to + +Now that you've figured out how open source projects work, it's time to find a project to contribute to! + +If 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."_ + +Contributing 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. + +Instead, 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. + +Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. + +Open 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. + +You 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! + +> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation. + +If 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)). + +You can also use one of the following resources to help you discover and contribute to new projects: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://www.sourcesort.com/) + +### A checklist before you contribute + +When 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. + +Here's a handy checklist to evaluate whether a project is good for new contributors. + +**Meets the definition of open source** + +
+ + +
+ +**Project actively accepts contributions** + +Look at the commit activity on the master branch. On GitHub, you can see this information on a repository's homepage. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Next, look at the project's issues. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Now do the same for the project's pull requests. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Project is welcoming** + +A project that is friendly and welcoming signals that they will be receptive to new contributors. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## How to submit a contribution + +You'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. + +### Communicating effectively + +Whether 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. + + + +Before 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. + +**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!). + +> 😇 _"X doesn't happen when I do Y"_ +> +> 😢 _"X is broken! Please fix it."_ + +**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn. + +> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ +> +> 😢 _"How do I X?"_ + +**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. + +> 😇 _"I'd like to write an API tutorial."_ +> +> 😢 _"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..."_ + +**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. + +> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_ +> +> 😢 _(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"_ + +**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. + +> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_ +> +> 😢 _"Why can't you fix my problem? Isn't this your project?"_ + +**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. + +> 😇 _"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."_ +> +> 😢 _"Why won't you support my use case? This is unacceptable!"_ + +**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. + +### Gathering context + +Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. + +If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request: + +* **Issues** are like starting a conversation or discussion +* **Pull requests** are for starting work on a solution +* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one + +Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. + +If 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. + + + +### Opening an issue + +You should usually open an issue in the following situations: + +* Report an error you can't solve yourself +* Discuss a high-level topic or idea (for example, community, vision or policies) +* Propose a new feature or other project idea + +Tips for communicating on issues: + +* **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. +* **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. +* **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. + +### Opening a pull request + +You should usually open a pull request in the following situations: + +* Submit trivial fixes (for example, a typo, a broken link or an obvious error) +* Start work on a contribution that was already asked for, or that you've already discussed, in an issue + +A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later. + +If the project is on GitHub, here's how to submit a pull request: + +* **[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/).) +* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. +* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.") +* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. +* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project. +* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. + +If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. + +## What happens after you submit a contribution + +You did it! Congratulations on becoming an open source contributor. We hope it's the first of many. + +After you submit a contribution, one of the following will happen: + +### 😭 You don't get a response. + +Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. + +If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread. + +**Don't** reach out to that person privately; remember that public communication is vital to open source projects. + +If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. + +### 🚧 Someone requests changes to your contribution. + +It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. + +When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. + +If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over. + +### 👎 Your contribution doesn't get accepted. + +Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! + +### 🎉 Your contribution gets accepted. + +Hooray! You've successfully made an open source contribution! + +## You did it! + +Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time. diff --git a/_articles/fa/index.html b/_articles/fa/index.html new file mode 100644 index 00000000000..627d4f8ebb0 --- /dev/null +++ b/_articles/fa/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: Guías de código abierto +lang: es +permalink: /es/ +--- diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md new file mode 100644 index 00000000000..b8006c30107 --- /dev/null +++ b/_articles/fa/leadership-and-governance.md @@ -0,0 +1,165 @@ +--- +lang: en +title: Leadership and Governance +description: Growing open source projects can benefit from formal rules for making decisions. +class: leadership +toc: + understanding-governance-for-your-growing-project: "Understanding governance for your growing project" + what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?" + how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?" + when-should-i-give-someone-commit-access: "When should I give someone commit access?" + what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?" + do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?" + what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?" + do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?" +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Understanding governance for your growing project + +Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers. + +## What are examples of formal roles used in open source projects? + +Many projects follow a similar structure for contributor roles and recognition. + +What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize: + +* **Maintainer** +* **Contributor** +* **Committer** + +**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. + +A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it. + +**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor). + + + +**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution. + +While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill. + + + +## How do I formalize these leadership roles? + +Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help. + +For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file. + +For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor. + +If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them. + + + +Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md. + +Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately. + +Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project). + +## When should I give someone commit access? + +Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project. + +On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable! + +If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances. + + + +## What are some of the common governance structures for open source projects? + +There are three common governance structures associated with open source projects. + +* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category. + +* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company. + +* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). + +Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates: + +* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## Do I need governance docs when I launch my project? + +There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community! + +Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch. + +If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project. + + + +## What happens if corporate employees start submitting contributions? + +Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering. + +As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project. + +It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature. + +"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.) + +Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions. + +## Do I need a legal entity to support my project? + +You don't need a legal entity to support your open source project unless you're handling money. + +For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US). + +If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US). + +Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. + + + +If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md new file mode 100644 index 00000000000..ed6cf093fd5 --- /dev/null +++ b/_articles/fa/legal.md @@ -0,0 +1,166 @@ +--- +lang: en +title: The Legal Side of Open Source +description: Everything you've ever wondered about the legal side of open source, and a few things you didn't. +class: legal +toc: + why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?" + are-public-github-projects-open-source: "Are public GitHub projects open source?" + just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project" + which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?" + what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?" + does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?" + what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?" +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## Understanding the legal implications of open source + +Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).) + +## Why do people care so much about the legal side of open source? + +Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it. + +In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. + +Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions. + +If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you. + +Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. + +## Are public GitHub projects open source? + +When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**. + +![Create repository](/assets/images/legal/repo-create-name.png) + +**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. + +If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. + +## Just give me the TL;DR on what I need to protect my project. + +You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). + +When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). + + + +## Which open source license is appropriate for my project? + +If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. + +Otherwise, picking the right open source license for your project depends on your objectives. + +Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. + +On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. + +You may also want to consider the **communities** you hope will use and contribute to your project: + +* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). +* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. +* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. + +Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know). + +When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). + +## What if I want to change the license of my project? + +Most projects never need to change licenses. But occasionally circumstances change. + +For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license: + +**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! + +**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. + +**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. + +Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. + +## Does my project need an additional contributor agreement? + +Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. + +Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community. + + + +Some situations where you may want to consider an additional contributor agreement for your project include: + +* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. +* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). +* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. +* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. +* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. + +If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. + +## What does my company's legal team need to know? + +If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project. + +For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company. + +**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: + +* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. + +* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. + +* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). + +* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. + +* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. + +If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). + +Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: + +* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). + + + +* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts. +* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. + + + +* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). +* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project). diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md new file mode 100644 index 00000000000..080b3eea9d4 --- /dev/null +++ b/_articles/fa/metrics.md @@ -0,0 +1,132 @@ +--- +lang: en +title: Open Source Metrics +description: Make informed decisions to help your open source project thrive by measuring and tracking its success. +class: metrics +toc: + why-measure-anything: "Why measure anything?" + discovery: "Discovery" + usage: "Usage" + retention: "Retention" + maintainer-activity: "Maintainer activity" +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Why measure anything? + +Data, when used wisely, can help you make better decisions as an open source maintainer. + +With more information, you can: + +* Understand how users respond to a new feature +* Figure out where new users come from +* Identify, and decide whether to support, an outlier use case or functionality +* Quantify your project's popularity +* Understand how your project is used +* Raise money through sponsorships and grants + +For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work: + +> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew. + +Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you. + +If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity. + +## Discovery + +Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_ + +![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see: + +* **Total page views:** Tells you how many times your project was viewed + +* **Total unique visitors:** Tells you how many people viewed your project + +* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working. + +* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors. + +[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work. + +You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites. + +## Usage + +People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_ + +If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads. + +Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers. + +If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners. + +![Clone graph](/assets/images/metrics/clone_graph.png) + +If usage is low compared to the number of people discovering your project, there are two issues to consider. Either: + +* Your project isn't successfully converting your audience, or +* You're attracting the wrong audience + +For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience. + +Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing. + +Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business? + +## Retention + +People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_ + +It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand). + +Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things. + +Examples of community metrics that you may want to regularly track include: + +* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository. + +![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant. + +* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews. + +* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project. + +* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue. + + + +## Maintainer activity + +Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_ + +Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave. + +[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions. + +Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_ + +You could also measure the time it takes to move between stages in the contribution process, such as: + +* Average time an issue remains open +* Whether issues get closed by PRs +* Whether stale issues get closed +* Average time to merge a pull request + +## Use 📊 to learn about people + +Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive. diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md new file mode 100644 index 00000000000..1ace069082f --- /dev/null +++ b/_articles/fa/starting-a-project.md @@ -0,0 +1,362 @@ +--- +lang: en +title: Starting an Open Source Project +description: Learn more about the world of open source and get ready to launch your own project. +class: beginners +toc: + the-what-and-why-of-open-source: "The what and why of open source" + should-i-launch-my-own-open-source-project: "Should I launch my own open source project?" + launching-your-own-open-source-project: "Launching your own open source project" + naming-and-branding-your-project: "Naming and branding your project" + your-pre-launch-checklist: "Your pre-launch checklist" +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## The "what" and "why" of open source + +So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it. + +### What does "open source" mean? + +When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses). + +Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions. + +_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge). + +### Why do people open source their work? + + + +[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include: + +* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors. + +* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt). + +Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source. + +### Does open source mean "free of charge"? + +One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value. + +Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. + +As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source. + +## Should I launch my own open source project? + +The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works. + +If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone! + +Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience. + +If you're not yet convinced, take a moment to think about what your goals might be. + +### Setting your goals + +Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_ + +There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals. + +If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome. + + + +As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project. + +While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you. + +**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community. + +If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early. + + + +### Contributing to other projects + +If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation. + +If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/). + +## Launching your own open source project + +There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source. + +Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work. + +No matter which stage you decide to open source your project, every project should include the following documentation: + +* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Code of conduct](../code-of-conduct/) + +As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience. + +If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers. + +### Choosing a license + +An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.** + +Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from. + +When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source. + +![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) + +If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/). + +### Writing a README + +READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it. + +In your README, try to answer the following questions: + +* What does this project do? +* Why is this project useful? +* How do I get started? +* Where can I get more help, if I need it? + +You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down. + + + +Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one. + +For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. + +When you include a README file in the root directory, GitHub will automatically display it on the repository homepage. + +### Writing your contributing guidelines + +A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on: + +* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates)) +* How to suggest a new feature +* How to set up your environment and run tests + +In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as: + +* The types of contributions you're looking for +* Your roadmap or vision for the project +* How contributors should (or should not) get in touch with you + +Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. + +For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with: + +> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. + +In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution. + +Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again. + +For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). + +Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. + +![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Establishing a code of conduct + + + +Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer. + +For more information, check out our [Code of Conduct guide](../code-of-conduct/). + +In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs. + +Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. + +Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README. + +## Naming and branding your project + +Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message. + +### Choosing the right name + +Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example: + +* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting +* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server + +If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js). + +Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work! + +### Avoiding name conflicts + +[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. + +If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet. + +Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk. + +You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/). + +Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see? + +### How you write (and code) affects your brand, too! + +Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists. + +Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey. + + + +Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers. + +Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. + +It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. + +## Your pre-launch checklist + +Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back. + +**Documentation** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Code** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**People** + +If you're an individual: + +
+ + +
+ +If you're a company or organization: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## You did it! + +Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow. From 507a96461ec1a3e067d98805d27fbe82e8c1810f Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Thu, 18 Mar 2021 19:05:47 +0330 Subject: [PATCH 003/629] First paragraphs translated. --- _articles/fa/best-practices.md | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md index c1894f66eaf..a0726de88fd 100644 --- a/_articles/fa/best-practices.md +++ b/_articles/fa/best-practices.md @@ -3,13 +3,6 @@ lang: fa title: بهترین روال‌های تجربه شده برای نگهدارنده‌ها description: زندگی خود را به عنوان یک نگهدارنده‌ی اوپن سورس آسان‌تر کنید؛ از ثبت‌کردن فرآیندها گرفته تا بهره‌بردن از اجتماع‌تان. class: best-practices -toc: - what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?" - documenting-your-processes: "Documenting your processes" - learning-to-say-no: "Learning to say no" - leverage-your-community: "Leverage your community" - bring-in-the-robots: "Bring in the robots" - its-okay-to-hit-pause: "It’s okay to hit pause" order: 5 image: /assets/images/cards/best-practices.png related: @@ -17,13 +10,14 @@ related: - leadership --- -## What does it mean to be a maintainer? +## نگهدارنده بودن به چه معناست؟ -If 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. +اگر شما نگه‌دارنده‌ی پروژه‌ای اوپن سورس باشید که افراد زیادی از آن استفاده می‌کنند، حتما متوجه شده‌اید که کمتر مشغول به کدنویسی هستید و بیشتر نقش پاسخگویی به مشکلات را بر عهده‌ی خود دارید. -In 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. +در مراحل اولیه‌ی هر پروژه‌ای، شما ایده‌های جدیدی را امتحان می‌کنید و بر اساس آنچه می‌خواهید تصمیم‌گیری می‌کنید. با افزایش محبوبیت پروژه، متوجه می‌شوید که بیشتر مشغول کار با کاربران و همکاران خود خواهید بود. + +نگهداری یک پروژه، به چیزی بیشتر از کدنویسی نیاز دارد. این وظایف اغلب به صورت ناگهانی پیش می‌آیند؛ اما آن‌ها به همان اندازه‌ی پروژه‌ی در حال رشد مهم هستند. ما برای آسان‌تر کردن زندگی‌تان چند روش آماده کرده‌ایم؛ از مراحل ثبت کردن فرآیند گرفته تا بهره‌بردن از اجتماع‌تان. -Maintaining 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. ## Documenting your processes From 5cccdbd611d6b573f5b972c36e772bc1b6e395d7 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Wed, 14 Apr 2021 15:43:19 +0430 Subject: [PATCH 004/629] first one has just finished. Translation first article has just finished. --- _articles/fa/best-practices.md | 240 +++++++++++++++++---------------- _articles/fa/index.html | 6 +- 2 files changed, 130 insertions(+), 116 deletions(-) diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md index a0726de88fd..8a7a7b9006d 100644 --- a/_articles/fa/best-practices.md +++ b/_articles/fa/best-practices.md @@ -19,263 +19,277 @@ related: نگهداری یک پروژه، به چیزی بیشتر از کدنویسی نیاز دارد. این وظایف اغلب به صورت ناگهانی پیش می‌آیند؛ اما آن‌ها به همان اندازه‌ی پروژه‌ی در حال رشد مهم هستند. ما برای آسان‌تر کردن زندگی‌تان چند روش آماده کرده‌ایم؛ از مراحل ثبت کردن فرآیند گرفته تا بهره‌بردن از اجتماع‌تان. -## Documenting your processes +## ثبت کردن فرآیندها -Writing things down is one of the most important things you can do as a maintainer. +نوشتن مطالب، یکی از مهم‌ترین کارهایی است که می‌توانید به عنوان نگهدارنده انجام دهید. -Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask. +ثبت کردن مطالب، نه تنها باعث شفافیت تفکر شما می‌شود، بلکه به دیگران کمک می‌کند تا حتی بدون پرسیدن سوالی، با احتیاجات و انتظارات شما آشنا شوند. -Writing 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. +نوشتن مطالب، نه گفتن به چیزی که به درد شما نمی‌خورد را آسان‌تر می‌کند. همچنین فرآیند کمک کردن به شما را برای سایرین آسان‌تر می‌کند. شما هرگز نمی‌دانید که چه کسی ممکن است پروژه‌ی شما را مطالعه یا از آن استفاده کند. -Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all. +حتی اگر از پاراگراف‌های طولانی استفاده نمی‌کنید!، نوشتن نکات مهم بهتر از چیزی ننوشتن است. -Remember 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. +به یاد داشته باشید که نوشتن مطالب را به روز نگه دارید. اگر همیشه قادر به انجام این کار نیستید، مطالب قدیمی خود را حذف کنید یا مشخص کنید که این مطالب منسوخ شده‌اند تا مانع به روز رسانی‌های مشارکت‌کنندگان نشوید. -### Write down your project's vision -Start 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. +### چشم انداز خودتان از پروژه را یادداشت کنید -Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions. +با نوشتن هدف‌های خودتان از پروژه، شروع کنید. آن‌ها را به «README» (من را بخوانید) خود اضافه کنید یا یک فایل جداگانه به نام «VISION » (چشم انداز) ایجاد کنید. اگر موارد دیگری وجود دارد که می‌تواند به شما کمک کند؛ مانند نقشه‌ی راه پروژه، آن‌ها را نیز به صورت عمومی منتشر کنید. -For 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). +داشتن چشم‌اندازی واضح و ثبت شده، شما را متمرکز نگه می‌دارد و به شما کمک می‌کند تا از بسط یا تغییرات در اهداف اولیه جلوگیری شود. + +به عنوان مثال، @lord، متوجه شد که داشتن چشم‌انداز پروژه به او کمک می‌کند تا بفهمد برای کدام درخواست‌ها وقت بگذارد. به عنوان یک نگهدارنده‌ی جدید، وقتی اولین درخواست خود را برای [Slate](https://github.com/lord/slate) دریافت کرد، از عدم پایبندی به اهداف پروژه‌ی خود پشیمان شد. -### Communicate your expectations +### انتظارات خود را اعلام کنید + +نوشتن قوانین، می‌تواند اعصاب خردکن باشد. گاهی اوقات ممکن است این حس را داشته باشید که در حال کنترل رفتار دیگران و یا از بین بردن هیجان و لذت در میان دیگران هستید. -Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun. +با این حال، اگر قوانین، مناسب و به طور عادلانه‌ای نوشته و اجرا شوند باعث نگهداری هر چه بهتر می‌شوند. این قوانین، جلوی کارهایی که نمی‌خواهید انجام دهید را می‌گیرد. -Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do. +اکثر افرادی که با پروژه‌ی شما روبرو می‌شوند، چیزی از شما و شرایط شما نمی‌دانند. ممکن است فرض کنند که شما برای کار کردن بر روی پروژه حقوق می‌گیرید، به ویژه اگر آن پروژه چیزی باشد که آن‌ها مرتباً استفاده می‌کنند و به آن وابستگی دارند. ممکن است زمانی وقت زیادی را صرف پروژه‌ی خود می‌کردید، اما اکنون مشغول کار یا گذران زمان با خانواده‌ی خود هستید. -Most 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. +شما مرتکب کار اشتباهی نشده‌اید! ولی اطمینان حاصل کنید که بقیه‌ هم راجع به این مسائل اطلاع داشته باشند. -All of this is perfectly okay! Just make sure other people know about it. +اگر نگهداری پروژه برای شما کاری نیمه وقت است یا کاملاً داوطلبانه است، درمورد آن صادق باشید و روشن کنید که چقدر زمان برای این کار دارید. این مسئله با میزان زمانی که شما فکر می‌کنید پروژه به آن نیاز دارد یا مدت زمانی که دیگران می‌خواهند شما در آن صرف کنید، یکی نیست و با هم فرق می‌کند. -If 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. +در اینجا چند قانون داریم که به یاد داشتن آن‌ها ارزش دارد: -Here are a few rules that are worth writing down: +* مشارکت چگونه تعریف و پذیرفته می‌شود (_آیا نیاز به آزمون دارد؟ یا قالب طرح مشکل؟_) +* انواع مشارکت‌هایی که می‌پذیرید (_آیا فقط برای قسمت‌های خاصی از کد خود کمک می‌خواهید؟_) +* چه زمانی برای پیگیری مناسب است (_به عنوان مثال، «شما در طی 7 روز از نگهدارنده می‌توانید انتظار پاسخگویی داشته باشید. اگر تا آن موقع خبری نشد، یادآوری کنید._) +* چه مدت زمان صرف پروژه می‌کنید (_به عنوان مثال، «ما فقط 5 ساعت در هفته برای این پروژه وقت می‌گذاریم»_) -* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_) -* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_) -* 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."_) -* How much time you spend on the project (_for example, "We only spend about 5 hours per week on this project"_) +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), و [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) نمونه‌هایی از پروژه‌ها با دستور‌العمل‌هایی برای نگهدارندگان و مشارکت‌کنندگان هستند. -[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), 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. +### ابلاغیه‌های خود را به صورت عمومی اعلام کنید -### Keep communication public +تعاملات خود با بیرون را نیز ثبت کنید. در هر جایی که ممکن بود، ابلاغیه‌های مربوط به پروژ‌ه‌ی خود را به صورت عمومی اعلام کنید. اگر کسی خواست که به طور خصوصی درباره‌ی درخواستی یا پشتیبانی با شما به گفتگو بپردازد، مودبانه او را به کانال ارتباطی عمومی، همچون فهرست پستی (mailing list) یا «issue tracker» هدایت کنید. -Don'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. +اگر با سایر نگهدارنده‌ها ملاقات کردید یا در خلوت تصمیم مهمی گرفتید، این مکالمه‌ها را به صورت عمومی ثبت کنید؛ حتی اگر بخواهد به صورت پست کردن یادداشت‌هایتان باشد. -If 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. +به این ترتیب، هر کسی که به انجمن شما بپیوندد به همان اطلاعاتی که سال‌ها در آنجا بوده است، دسترسی خواهد داشت. -That way, anybody who joins your community will have access to the same information as someone who's been there for years. -## Learning to say no +## نه گفتن، را یاد بگیرید -You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists. +شما مطالب خود را ثبت کردید. در حالت ایده آل، همه نوشته‌ها و مستندات شما را می‌خوانند، اما در واقع، شما باید به دیگران وجود این اطلاعات را نیز یادآوری کنید. -Having everything written down, however, helps depersonalize situations when you do need to enforce your rules. +درصورتی که لازم باشد قوانین خود را اجرا کنید، با نوشتن و ثبت کردن همه چیز، به شما کمک می‌کند تا شرایط را از حالت شخصی‌سازی شده در‌آورید. -Saying no isn't fun, but _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_. +نه گفتن، لذت‌بخش نیست؛ اما گفتن «مشارکت شما با معیارهای این پروژه مطابقت ندارد» کمتر از «من مشارکت با شما را دوست ندارم»، به شخصیت طرف برمی‌خورد. -Saying 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. +نه گفتن در بسیاری از شرایطی که به عنوان نگهدارنده با آن روبرو خواهید شد، به کار می‌آید: درخواست‌هایی که با ویژگی‌های پروژه‌ی شما متناسب نیستند، کسی که بحث را به بیراهه می‌کشاند، انجام کارهای غیرضروری برای دیگران. -### Keep the conversation friendly -One 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. +### دوستانه با دیگران ارتباط برقرار کنید -Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor. +یکی از مهم‌ترین جاهایی که شما باید تمرین نه گفتن را انجام دهید، در سر برخی از مسائل و «درخواست‌های pull» ای است که از شما می‌شود. به عنوان نگهدارنده‌ی پروژه، ناگزیر پیشنهادهایی دریافت خواهید کرد که نمی‌خواهید آن‌ها را بپذیرید. -Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards. +چونکه شاید آن مشارکت، اهداف پروژه‌ی شما را تغییر دهد یا با چشم‌انداز شما مطابقت نداشته باشد. یا شاید ایده خوب باشد، ولی اجرای آن ضعیف باشد. -If 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. +صرف نظر از هرچه که دلیل بخواهد باشد، می‌توان مشارکت‌هایی را که مطابق با استانداردهای پروژه‌ی شما نیستند را با درایت مدیریت کرد. + +اگر مشارکتی به شما پیشنهاد بشود که نخواهید آن را بپذیرید؛ اولین واکنش شما ممکن است نادیده گرفتن آن یا تظاهر به ندیدن آن باشد. انجام این کار می‌تواند به احساسات طرف مقابل ضربه بزند و حتی باعث کاهش انگیزه‌ی سایر مشارکت‌کنندگان بالقوه‌ی اجتماع (community) شما شود. -Don'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. +مشارکت ناخواسته را صرف اینکه آدم خوبی به نظر برسید، ادامه ندهید زیرا در ادامه‌ی راه احساس گناه خواهید کرد. با گذشت زمان، مسائل و روابط عمومی بی‌پاسخ باعث می‌شود که کارتان روی پروژه بسیار استرس‌زا و ترسناک پیش برود. -It'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). +بهتر است فوراً به مشارکت‌هایی که آن‌ها را نمی‌خواهید، پایان دهید. اکر پروژه شما از کمبود بک لاگ رنج می برد, @steveklabnik در مقاله [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) پیشنهاداتی در این خصوص ارائه کرده است. -Secondly, 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! +ثانیاً، بی‌توجهی به مشارکت‌هایتان، سیگنال‌های منفی‌ای به درون اجتماع می‌فرستد. مشارکت در هر پروژه‌ای می‌تواند دلهره‌آور باشد، خصوصاً اگر برای اولین بار باشد که در پروژه‌ای شرکت می‌کنید. حتی اگر مشارکت آن‌ها را قبول نکردید، از آن شخص تشکر کرده و از توجه او سپاسگزار باشید. کار پسندیده‌ای است! -If you don't want to accept a contribution: +اگر نمی‌خواهید مشارکت کسی را قبول کنید: -* **Thank them** for their contribution -* **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. -* **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. -* **Close the request** +* از توجه آن‌ها **تشکر کنید**. +* **توضیح دهید که چرا نمی‌توانید با آن‌ها همکاری داشته باشید** و اگر می‌توانید، پیشنهادهای واضحی را برای بهبود آن‌ها برای آینده ارائه دهید؛ مهربان باشید، اما مصمم. +* در صورت داشتن دسترسی، آن‌ها را **به مستندات مربوطه ارجاع دهید**. اگر با درخواست‌های مکرر برای مواردی که نمی‌خواهید آن‌ها را بپذیرید، مواجه شدید؛ آن موارد را برای جلوگیری از مکررات به مستندات خود اضافه کنید. +* **درخواست مشارکت را ببندید**. -You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383): +شما به 1 یا 2 جمله بیشتر، برای پاسخگویی نیاز نخواهید داشت. به عنوان مثال، هنگامی که [celery](https://github.com/celery/celery/)، خطایی مربوط به ویندوز را گزارش داد، «berkerpeksag» [اینگونه پاسخ](https://github.com/celery/celery/issues/3383) داد: ![Celery screenshot](/assets/images/best-practices/celery.png) -If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/): +اگر فکر نه گفتن شما را وحشت زده می‌کند، بدانید که شما تنها نیستید. همانطور که @jessfraz می‌گوید: + +> من با نگهدارنده‌هایی از پروژه‌های اوپن سورس مختلف مانندMesos» ،«Kubernetes» «Chromium صحبت کرده‌ام و همه موافق هستند که یکی از سخت‌ترین قسمت‌های نگهدارنده بودن، «نه» گفتن به اصلاحاتی است که نمی‌خواهید. -> 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. +در نپذیرفتن پیشنهاد مشارکت کسی، احساس گناه نکنید. [طبق گفته‌ی](https://twitter.com/solomonstre/status/715277134978113536) @shykes، اولین قانون پروژه‌های اوپن سورس این است که: «نه موقتی‌ست، بله برای همیشه». در حالی که همدردی با اشتیاق فرد دیگر، چیز پسندیده‌ای است؛ اما رد کردن پیشنهاد مشارکت به معنای رد کردن هویت فرد پشت سر آن پیشنهاد نیست. -Don'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. +ختم کلام این است که اگر مشارکت با دیگری به اندازه کافی خوب نباشد، شما ملزم به پذیرفتن هیچ تعهدی نیستید. وقتی دیگران در پروژه‌ی شما مشارکت می‌کنند، مهربان و پاسخگو باشید؛ اما فقط تغییراتی را قبول کنید که واقعاً معتقد هستید پروژه‌ی شما را بهتر می‌کند. هر چه در نه گفتن، تمرین بیشتری داشته باشید؛ گفتن آن راحت‌تر می‌شود. به شما قول می‌دهم. -Ultimately, 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. +### فعال باشید -### Be proactive +برای کاهش حجم مشارکت‌های ناخواسته در وهله‌ی اول، روند پروژه خود را در راهنمای ارسال و پذیرش مشارکت‌ها توضیح دهید. -To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide. +اگر درخواست‌های مشارکت بسیار کم کیفیت دریافت می‌کنید، از افراد متقاضی بخواهید کمی قبل از ارسال پیشنهاد، کارهایی انجام دهند؛ به عنوان مثال: -If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example: * Fill out a issue or PR template/checklist -* Open an issue before submitting a PR +* قبل از ارسال درخواست Pull یک گزارش اشکال ارسال کنند. -If they don't follow your rules, close the issue immediately and point to your documentation. +اگر از قوانین شما پیروی نکردند، بلافاصله درخواست را رد کنید و آن‌ها را به راهنمای ارسال مرجوع کنید. -While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage. +اگرچه ممکن است در ابتدا این رویکرد کمی خشن به نظر برسد، اما فعال بودن برای هر دو طرف خوب است. در نتیجه این احتمال را کاهش می‌دهد که کسی ساعت‌های زیادی صرف «درخواست Pull»ی که شما آن را قبول نخواهید کرد، نکند. و ثانیا حجم کاری شما را نیز کمتر می‌کند و مدیریت آن ساده‌تر می‌شود -Sometimes, 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. +بعضی اوقات، وقتی نه می‌گویید، مشارکت‌کننده‌ی بالقوه ممکن است ناراحت شود یا از تصمیم شما انتقاد کند. اگر آن‌ها خصومت‌آمیز رفتار کردند و اگر نخواستند به طور سازنده همکاری کنند، [قدم‌هایی را برای خنثی کردن موقعیت](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) بردارید یا حتی آن‌ها را از اجتماع خودتان اخراج کنید. + +### با آعوش باز، پذیرای راهنمایی‌ و مشاوره باشید + +شاید کسانی در اجتماع شما باشند که مرتباً درخواست‌های مشارکتی پیشنهاد می‌کنند که با استانداردهای پروژه‌ی شما مطابقت نداشته باشد. مسلما رد شدن پیاپی برای هر دو طرف، طاقت‌فرساست. + +اگر دیدید کسی مشتاق پروژه‌ی شما است، اما به کمی پیشرفت نیاز دارد، صبور باشید. در هر شرایطی به روشنی توضیح دهید که چرا مشارکت آن‌ها متناسب با انتظارات پروژه‌ی شما نیست. سعی کنید ابتدا وظایفی ساده‌تر و با ابهامات کمتر به آن‌ها بسپرید تا به قول معروف «آماده‌ی کار شوند». اگر وقت داشتید، در اولین مشارکت، آن‌ها را راهنمایی کنید، یا شخص دیگری را در اجتماع خود پیدا کنید که تمایل به راهنمایی کردن آن‌ها داشته باشد. -### Embrace mentorship -Maybe 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. +## از اجتماع خود بهره ببرید -If 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. +لازم نیست همه‌ی کارها را خودتان انجام دهید. دلیلی دارد که پروژه‌ی شما، اجتماعی برای خود دارد! حتی اگر هنوز اجتماعی فعال ندارید، اگر کاربران زیادی دارید، کارها را به آن‌ها بسپرید. -## Leverage your community +### حجم کار را با دیگران تقسیم کنید -You 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. +اگر می‌خواهید که دیگران به شما کمک کنند، از آن‌ها درخواست کنید. -### Share the workload +راهی برای جذب مشارکت‌کنندگان این است که کارها را از نظر سختی درجه‌بندی کنید و [کارهای ساده را به مبتدی‌ها بسپرید](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). سپس GitHub این موضوعات را در فضاهای مختلف خودش به نمایش می‌گذارد و باعث افزایش دیده شدن آن‌ها می‌شود. -If you're looking for others to pitch in, start by asking around. +وقتی مشاهده کردید که مشارکت‌کنندگان جدید به صورت مکرر همکاری می‌کنند، با دادن مسئولیت‌های بیشتر، آن‌ها را تصدیق کنید و به رسمیت بشناسید. مشخص کنید که چگونه دیگران می‌توانند در صورت اشتیاق به جایگاه‌های رهبری دست یابند. -One 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. -When 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. +همانطور که @lmccart در پروژه‌ی خود متوجه شد، تشویق دیگران [به اشتراک گذاشتن مالکیت پروژه](../building-community/#share-ownership-of-your-project) می‌تواند حجم کاری شما را بسیار کاهش دهد[p5.js](https://github.com/processing/p5.js). -Encouraging 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). -If 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. +اگر لازم است کمی از پروژه‌ی خود فاصله بگیرید، یا وقفه‌ای در آن ایجاد کنید یا به طور کلی کنار بکشید؛ به هیچ وجه شرم‌آمور نیست که از شخص دیگری بخواهید مسئولیت کار شما را به عهده بگیرد. -If 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! +اگر افراد دیگری مشتاق این هستند، به آن‌ها اجازه‌ی دسترسی دهید یا کنترل پروژه را به طور رسمی به شخص دیگری بسپارید. اگر کسی پروژه‌ی شما را به چند شاخه تبدیل کرد و به طور فعال آن را در جای دیگری نگهداری کرد، پیوند دادن پروژه‌ی اصلی خود به شاخه را مد نظر قرار دهید. این خیلی خوب است که مردم می‌خواهند پروژه شما ادامه یابد! -@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: -> 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. +@progrium [متوجه شد]( https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) که ثبت کردن چشم‌انداز [پروژه](https://github.com/dokku/dokku)، کمک کرد تا آن اهداف حتی پس از کنار کشیدن او ادامه یابند: -### Let others build the solutions they need -If 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. +> من یک صفحه‌ در ویکی نوشتم و آنچه را که می‌خواهم و چرایی آن را توصیف کردم. بنا به دلایلی برای من تعجب‌آور بود که نگهدارندگان شروع به انتقال پروژه به سمت و سوی دلخواه خود کردند! آیا آنطور که می‌خواستم، پیش رفت؟ نه همیشه. ولی پروژه را به آنچه که نوشته‌ بودم، نزدیک‌تر کرد. + +### به دیگران اجازه دهید تا راه‎‌حل‌های مورد نیاز خودشان را طراحی کنند + +اگر فرد مشارکت‌کننده‌ای نظر دیگری در مورد کاری که پروژه باید انجام دهد داشته باشد، بهتر است که آن‌ها را با مهربانی تشویق به کار بر روی شاخه‌ی خودشان از پروژه بکنید. + +به چند شاخه تقسیم کردن پروژه، الزاما چیز بدی نیست. امکان کپی و اصلاح پروژه‌ها، یکی از بهترین ویژگی‌های اوپن سورس بودن است. تشویق اجتماع (community) خودتان به کار بر روی شاخه‌های خودشان می‌تواند فضای خلاقانه‌ی مورد نیاز را فراهم آورد، بدون اینکه با چشم‌اندازهای پروژه‌ی شما تداخلی ایجاد کند. -Forking 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. -The 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": +این موضوع همچنین درمورد کاربری صدق می‌کند که واقعاً نیاز به راه‌حلی دارد که ظرفیت طراحی آن را ندارید. ارائه‌ی APIها و هوک‌های سفارشی‌سازی (customization hooks)، بدون نیاز به تغییر مستقیم سورس، می‌توانند به دیگران در تأمین نیازهاشان کمک کنند. @orta [متوجه شد](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) که افزونه‌های پرورشی برای «CocoaPods» منجر به «برخی از جالب‌ترین ایده‌ها» شد: + -> 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. +> تقریباً اجتناب‌ناپذیر به نظر می‌رسد که به محض بزرگ‌تر شدن پروژه، نگهدارنده‌ها باید در مورد نحوه تعریف کدهای جدید بسیار محافظه‌کارانه‌تر عمل کنند. شاید در گفتن «نه» تبحر پیدا کرده باشید، اما هنوز بسیاری از مردم نیازهایی معقول و منطقی دارند. بنابراین، در نهایت ابزار شما به یک پلتفرم تبدیل می‌شود. -## Bring in the robots +## از ربات‌ها استفاده کنید -Just 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. +همانطور که وظایفی وجود دارد که دیگران می‌توانند در انجام آن‌ها به شما کمک کنند، وظایفی نیز وجود دارد که هیچ انسانی هرگز نباید آن‌ها را انجام دهد. ربات‌ها دوست شما هستند. به عنوان یک نگهدارنده، از آن‌ها برای سهولت زندگی خود استفاده کنید. -### Require tests and other checks to improve the quality of your code +### برای بهبود کیفیت کدهای خود، از تست‌ها و دیگر ابزار استفاده کنید. -One of the most important ways you can automate your project is by adding tests. +یکی از مهم‌ترین راه‌ها برای اتوماتیک کردن پروژه‌ی خود، افزودن تست است. -Tests 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. +تست‌ها به مشارکت‌کنندگان کمک می‌کند تا اطمینان داشته باشند که چیزی را خراب نمی‎کنند. تست‌ها، همچنین بررسی و پذیرش سریع مشارکت‌ها را برای شما آسان می‌کند. هر چقدر از خود علاقه‌ی بیشتری نمایش دهید و مشتاق‌تر باشید، اجتماع شما مشارکت بیشتری خواهد داشت. -Set 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. +تست‌های خودکاری را طراحی کنید که برای همه مشارکت‌های آتی اجرا شود و اطمینان حاصل کنید که تست‌های شما به راحتی توسط مشارکت‌کنندگان قابل اجرا باشند. قبول کردن درخواست‌های مشارکت در کدها را ملزم به قبول شدن در آن تست بکنید. با این کار، حداقل استاندارد کیفیتی را برای همه‌ی درخواست‌ها تعیین می‌کنید. [با بررسی وضعیت](https://help.github.com/articles/about-required-status-checks/) در GitHub می‌توانید اطمینان حاصل کنید که بدون گذراندن تست‌های شما اجازه‌ی هیچ گونه تغییری داده نمی‌شود. -If you add tests, make sure to explain how they work in your CONTRIBUTING file. +اگر تست‌هایی اضافه کردید، حتماً نحوه‌ی کارکرد آن‌ها را در فایل «CONTRIBUTING» (مشارکت) خود توضیح دهید. -### Use tools to automate basic maintenance tasks +### از ابزارها برای اتوماتیک کردن کارهای ساده‌ی نگهداری استفاده کنید -The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it. +خبر خوب در مورد نگهداری پروژه‌های محبوب این است که نگهدارندگان دیگر احتمالاً با مسائل مشابهی روبرو شده‌اند و راه‌حلی از قبل برای آن طراحی کرده‌اند. -There 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: +[ابزارهای متنوعی برای کمک](https://github.com/showcases/tools-for-open-source) به اتوماتیک کردن برخی جنبه‌های کار نگهداری وجود دارد. به عنوان مثال: -* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases -* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests -* [Danger](https://github.com/danger/danger) helps automate code review -* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information -* [dependabot-preview](https://github.com/marketplace/dependabot-preview) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds -For 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. +* ابزار [emantic-release](https://github.com/semantic-release/semantic-release)، عرضه نسخه‌های جدید شما را اتوماتیک می‌کند. +* ابزار [mention-bot](https://github.com/facebook/mention-bot)، به بازبین‌های بالقوه برای «درخواست pull»ها خبر می دهد. +* ابزار [Danger](https://github.com/danger/danger)، به بررسی و بازبینی اتوماتیک کد کمک می‌کند. +* ابزار [no-response](https://github.com/probot/no-response)، مسائلی را که نویسنده به درخواست‌ها برای اطلاعات بیشتر پاسخ نداده است، می‌بندد. +* ابزار [dependabot-preview](https://github.com/marketplace/dependabot-preview)، هر روز «فایل‌های وابسته» (مثل کتابخانه‌ها یا کلاس‌های جانبی یا ماژول‌ها) شما را از نظر الزامات منسوخ شده بررسی می‌کند و «درخواست‌های pull» را برای هر موردی که پیدا می‌کند، باز می‌کند. -To 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. +برای گزارش اشکالات (bug) و سایر مشارکت‌های متداول، GitHub دارای [قالب‌های طرح مشکل و قالب‌های درخواست‌های pull](https://github.com/blog/2111-issue-and-pull-request-templates) است، که می‌توانید برای کارآمد ساختن ارتباطاتی که دریافت می‌کنید، استفاده کنید. «TalAter»، برای کمک کردن به شما برای طرح مشکلات و مسائل روابط عمومی (PR templates)، ابزار [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) را ساخت. -If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept. +برای مدیریت اعلان‌های ایمیل خود، می‌توانید [فیلترهای ایمیل](https://github.com/blog/2203-email-updates-about-your-own-activity) را تنظیم کنید تا ایمیل‌ها براساس اولویت سازماندهی شوند. -However, 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. +اگر می خواهید فراتر از حد معمول باشید، شیوه‌نامه‌ها (style guides) و ابزار «linters» می‌توانند مشارکت‌های پروژه را استاندارد کرده و بررسی و پذیرش آن‌ها را آسان کنند. -If 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. +اگرچه اگر استانداردهای شما بسیار پیچیده باشد، می تواند موانع و مسائل مشارکت را افزایش دهند. مطمئن شوید که فقط به اندازه‌ی کافی قوانینی را برای در آسایش قرار گرفتن دیگران اضافه کنید. -## It's okay to hit pause +اگر مطمئن نیستید که از چه ابزاری استفاده کنید، به سایر پروژه‌های معروف به ویژه آن پروژه‌هایی که مربوط به اکوسیستم خودتان است، توجه کنید. به عنوان مثال، فرآیند مشارکت برای سایر ماژول‌های «Node»، چگونه است؟ همچنین استفاده از ابزارها و رویکردهای مشابه، فرآیند کارتان را برای مشارکت‌کنندگان‌ شما آشناتر می‌کند. -Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty. -Perhaps 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. +## اشکالی ندارد اگر که وقفه‌ای در کار خود ایجاد کنید -Burnout 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. +کار کردن به صورت اوپن سورس برای شما شادی آورد. شاید اکنون باعث شده است شما احساس انزواطلبی داشته باشید یا احساس گناه کنید. -Although 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. +شاید وقتی به پروژه‌های خود فکر می‌کنید بیش از حد احساس آشفتگی و یا احساس ترس می‌کنید. و در همین حال، «مشکلات» و «درخواست‌های pull» روی هم انباشته می‌شود. -Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work. +فرسودگی و خسته شدن از کار، مسئله‌ای واقعی و فراگیر در پروژه‌های اوپن سورس است؛ مخصوصاً در میان نگهدارندگان. به عنوان یک فرد نگهدارنده، خوشحالی و رضایت شما برای بقای هر پروژه‌ی‌ اوپن سورسی، ضروری است. + +پس نیازی به گفتن نیست؛ به خودتان استراحت بدهید! نیازی نیست تا سر حد خستگی و فرسودگی پیش بروید تا سپس به تعطیلات بروید. @brettcannon، توسعه‌دهنده‌ی پایتون، [تصمیم گرفت پس از 14 سال کار داوطلبانه در OSS، به تعطیلات یک ماهه برود](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/). + +درست مانند هر کار دیگری، تعطیلات منظم، شما را باطراوت نگه می‌دارد و باعث خوشحالی و هیجان شما نسبت به کارتان می‌شود. -Sometimes, 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. +گاهی اوقات، زمان‌هایی که حس می‌کنید همه به شما احتیاج دارند؛ ممکن است فاصله گرفتن از پروژه‌ی اوپن سورس سخت باشد. حتی ممکن است دیگران، شما را به خاطر فاصله گرفتن سرزنش کنند. + +در حالی که از پروژه فاصله گرفتید، تلاش خود را برای یافتن پشتیبانی از کاربران و اجتماع خود بکنید. اگر نتوانستید پشتیبانی دیگران را به دست آورید، به هر حال کار خودتان را بکنید و فاصله‌ای را که نیاز دارید از پروژه بگیرید. زمانی که حضور نداشتید، حتماً ارتباط خود را با دیگران حفظ کنید؛ تا مردم از نبود پاسخگویی گیج نشوند. -Do 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. +فاصله گرفتن، فقط منحصر به تعطیلات می‌شود. اگر نمی‌خواهید آخر هفته‌ یا در ساعات کاری، پروژه‌های اوپن سورس انجام دهید، این را به اطلاع دیگران برسانید تا بدانند که در آن اوقات مزاحم شما نشوند. -Taking 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. -## Take care of yourself first! +## ابتدا به فکر خودتان باشید! -Maintaining 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. +نگهداری یک پروژه‌ی محبوب به مهارت‌های متفاوتی در مقایسه با مهارت‌های مراحل اولیه‌ی رشد نیاز دارد، اما به همان میزان پاداش بیشتری هم خواهد داشت. به عنوان یک نگهدارنده، شما باید مهارت‌های رهبری و شخصی در سطحی فرای دیگران داشته باشید. اگرچه مدیریت آن همیشه آسان نیست، اما تعیین مرزهای مشخص و تنها پذیرفتن آنچه که با آن راحت هستید به شما کمک می‌کند تا شاد، سرحال و کارآمد باشید. diff --git a/_articles/fa/index.html b/_articles/fa/index.html index 627d4f8ebb0..0bb1b27c4bd 100644 --- a/_articles/fa/index.html +++ b/_articles/fa/index.html @@ -1,6 +1,6 @@ --- layout: index -title: Guías de código abierto -lang: es -permalink: /es/ +title: راهنماهای متن‌باز +lang: fa +permalink: /fa/ --- From e6722bfa3311d799e8d8665d6d35e221a01774be Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Wed, 14 Apr 2021 19:09:55 +0430 Subject: [PATCH 005/629] Translation started. --- _articles/fa/finding-users.md | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md index 84ec4c6e7ca..7c7d85fe8e4 100644 --- a/_articles/fa/finding-users.md +++ b/_articles/fa/finding-users.md @@ -1,15 +1,8 @@ --- lang: en -title: Finding Users for Your Project -description: Help your open source project grow by getting it in the hands of happy users. +title: پیدا کردن کاربر برای پروژه‌هایتان +description: با داشتن کاربرانی راضی و خوشحال، به پروژه‌ی اوپن سورس خود کمک کنید تا رشد کند.. class: finding -toc: - spreading-the-word: "Spreading the word" - figure-out-your-message: "Figure out your message" - help-people-find-and-follow-your-project: "Help people find and follow your project" - go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)" - go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)" - build-a-reputation: "Build a reputation" order: 3 image: /assets/images/cards/finding.png related: @@ -17,17 +10,18 @@ related: - building --- -## Spreading the word +## به اطلاع همگان برسانید -There'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! +هیچ قانونی وجود ندارد که بگوید هنگام راه‌اندازی، باید پروژه‌ی اوپن سورس را تبلیغ کنید. دلایل رضایت‌بخش زیادی برای کار کردن در پروژه‌ای اوپن سورس وجود دارد که هیچ ارتباطی با محبوبیت ندارد. به جای امیدواری برای اینکه دیگران پروژه‌ی اوپن سورس شما را پیدا کنند و از آن استفاده کنند، باید در مورد پروژه و سخت‌کوشی خودتان صحبت کنید و آن را به گوش دیگران برسانید! -## Figure out your message +## از پیامی که می‌خواهید به گوش دیگران برسانید، اطمینان حاصل کنید -Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters. +قبل از اینکه شروع به تبلیغ و ترویج پروژه‌ بکنید، باید بتوانید که کارآیی و چرایی اهمیت آن را توضیح بدهید. -What makes your project different or interesting? Why did you create it? Answering these questions for yourself will help you communicate your project's significance. +چه چیزی موجب تفاوت و جالب بودن پروژه‌ی شما نسبت به دیگر پروژه‌ها می‌شود؟ به چه منظور آن را ساختید؟ پاسخ دادن به این سوالات، به شما کمک می‌کند تا به اهمیت پروژه‌ی خودتان پی ببرید و آن را واضح‌تر بیان کنید. + +به یاد داشته باشید به این دلیل که پروژه‌ی شما مشکلی را برای کاربران برطرف می‌کند؛ افراد به عنوان کاربر به پروژه‌ی شما ملحق می‌شوند و در نهایت به عنوان یک مشارکت‌کننده معرفی می‌شوند. همانطور که درباره‌ی پیام و ارزش پروژه‌‌ی خود فکر می‌کنید، سعی کنید آن‌ها را از دریچه‌ی آنچه که کاربران و مشارکت‌کنندگان می‌خواهند نظاره کنید. -Remember 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. For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful: From acbd9580ed514dc74b8ca8f0fbfd6da3a8aea690 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Thu, 15 Apr 2021 17:22:05 +0430 Subject: [PATCH 006/629] Initial translation done. --- _articles/fa/finding-users.md | 85 +++++++++++++++++------------------ 1 file changed, 42 insertions(+), 43 deletions(-) diff --git a/_articles/fa/finding-users.md b/_articles/fa/finding-users.md index 7c7d85fe8e4..b45a68c823f 100644 --- a/_articles/fa/finding-users.md +++ b/_articles/fa/finding-users.md @@ -23,135 +23,134 @@ related: به یاد داشته باشید به این دلیل که پروژه‌ی شما مشکلی را برای کاربران برطرف می‌کند؛ افراد به عنوان کاربر به پروژه‌ی شما ملحق می‌شوند و در نهایت به عنوان یک مشارکت‌کننده معرفی می‌شوند. همانطور که درباره‌ی پیام و ارزش پروژه‌‌ی خود فکر می‌کنید، سعی کنید آن‌ها را از دریچه‌ی آنچه که کاربران و مشارکت‌کنندگان می‌خواهند نظاره کنید. -For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful: +به عنوان مثال، @robb از کدها استفاده می‌کند تا به طور واضح اهمیت پروژه‌ی خود را نشان دهد؛ نقشه‌نگاری [Cartography](https://github.com/robb/Cartography) مفید واقع می‌شود: ![Cartography README](/assets/images/finding-users/cartography.jpg) -For 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. +برای درک بهتر مفهوم، مورد [Personas and Pathways](https://mozillascience.github.io/working-open-workshop/personas_pathways/) موزیلا (Mozilla) را برای توسعه‌ی پرسونای کاربران بررسی کنید -## Help people find and follow your project +## مردم را در پیدا کردن و دنبال کردن پروژه‌ی خودتان یاری کنید -Help people find and remember your project by pointing them to a single namespace. +طوری باشد که با اشاره‌ای کوچک، مردم پروژه‌ی شما را به یاد بیاورند. -**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. +**برای توسعه‌ی پروژه‌ی خود، کاملا بر کار خویش آگاه و از آن اطمینان داشته باشید. ** یک آدرس توییتری، آدرس GitHub یا کانال IRC راهی آسان برای مشایعت و هدایت افراد به سمت پروژه‌ی خودتان است. این رسانه‌ها همچنین به اجتماع در حال رشد پروژه‌ی شما، محلی برای تجمع و تبادل نظر می‌دهند. -If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. +اگر هنوز مایل به راه‌اندازی رسانه‌هایی برای پروژه‌ی خودتان نیستید، در همه‌ی کارهایی که انجام می‌دهید Twitter یا GitHub خود را ترویج دهید. توسعه و تبلیغ Twitter یا GitHub به مردم این امکان را می‌دهد تا با شما در ارتباط باشند یا کارهای شما را دنبال کنند. اگر در جلسه یا رویدادی صحبت می‌کنید، اطمینان حاصل کنید تا اطلاعات تماس شما در مشخصات شما یا اسلایدها آمده باشد. + -**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. +**ساخت وب‌سایتی را برای پروژه‌ی خود مد نظر قرار دهید.** داشتن وب‌سایت، پروژه‌ی شما را دوستانه‌تر و برای وب‌گردی و گشت‌زنی ساده‌تر می‌کند؛ به ویژه هنگامی که با مستندات و آموزش‌های واضح همراه باشد. داشتن یک وب سایت همچنین بیانگر این است که پروژه‌ی شما فعال است که همین باعث می‌شود مخاطبان شما احساس راحتی بیشتری در استفاده از آن داشته باشند. مثال‌هایی را ارائه دهید تا به افراد در مورد چگونگی استفاده از پروژه‌تان ایده بدهد. -[@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"_. - -If 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. +[@Adrianholovaty](https://news.ycombinator.com/item?id=7531689)، یکی از سازند‌گان شرکت «Django» گفت که وب‌سایت «بهترین کاری بود که می‌توانستیم برای Django در آن روزهای اولیه انجام دهیم». اگر پروژه‌ی شما در GitHub باشد، می‌توانید با استفاده از [GitHub Pages](https://pages.github.com/)، به راحتی وب‌سایت ایجاد کنید. [Yeoman](http://yeoman.io/)، [Vagrant](https://www.vagrantup.com/) و [Middleman](https://middlemanapp.com/) چند نمونه از وب‌سایت‌های عالی و جامع هستند. ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) -Now 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! +اکنون که برای پروژه‌ی خود رسالت و راهی آسان برای یافتن پروژه‌تان توسط مردم دارید، وقت آن است که بیرون بزنیم و با مخاطبان ارتباط برقرار کنیم و با آن‌ها صحبت کنیم! -## Go where your project's audience is (online) +## هر جا که مخاطبان شما بودند، شما هم به آنجا بروید (آنلاین) -Online 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. +اطلاع‌رسانی آنلاین، روشی عالی برای به اشتراک گذاشتن و انتقال سریع اخبار و اطلاعات است. با استفاده از مجرا‌های آنلاین، این امکان را خواهید داشت که به مخاطبان بسیار گسترده‌ای دسترسی پیدا کنید. -Take 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. +برای دسترسی به مخاطبان خود از ارتباطات‌ و بسترهای آنلاین موجود استفاده کنید. اگر پروژه‌ی اوپن سورس شما پروژه‌ای نرم‌افزاری است، احتمالاً بتوانید مخاطبان خود را در [Stack Overflow](https://stackoverflow.com/) ،[Hacker News](https://news.ycombinator.com/) یا [Quora](https://www.quora.com/) پیدا کنید. کانال‌هایی را پیدا کنید که فکر می‌کنید مردم در آن از کار شما بیشترین استفاده را می‌برند یا مشتاق آن هستند. -See if you can find ways to share your project in relevant ways: +ببینید آیا می‌توانید روش‌هایی برای به اشتراک گذاشتن پروژه خود به صورت متناسبی پیدا کنید: + +* **با پروژه‌ها و انجمن‌های اوپن سورس مرتبط و مدنظرتان آشنا شوید.** گاهی اوقات، لازم نیست که مستقیماً پروژه‌ی خود را تبلیغ کنید. اگر پروژه‌ی شما برای متخصصین علم داده که از پایتون استفاده می‌کنند عالی است، با انجمن علوم داده‌ی پایتون ملاقات کنید و آشنا شوید. هنگامی که مردم با شما آشنا شوند، فرصت‌ها به صورت خودکار و طبیعی برای بحث و گقت و گو و به اشتراک گذاشتن کارهای شما بوجود می‌آید. +* **افرادی که مشکلاتی دارند و پروژه‌ی شما، آن مشکلات را حل و فصل می‌کند را پیدا کنید. ** از طریق تالارهای گفتگوی (فروم‌ها) مرتبط، به جستجوی افرادی که می‌توانند مخاطبانِ هدفِ پروژه‌ی شما باشند، بپردازید. به سوالات آن‌ها پاسخ دهید و در زمانی مناسب، روشی مدبرانه تعبیه کنید تا پروژه‌ی خود را به عنوان یک راه‌حل پیشنهاد دهید. +* **از انتقادات و پیشنهادات روی‌گردان نباشید.** خود و کارهایتان را به مخاطب‌هایی مرتبط و متناسب که به کار شما علاقه دارند، معرفی کنید. مخاطبان خود را بشناسید و کسانی که از پروژه‌ی شما سود و منفعت حاصل می‌کنند را مشخص کنید. سعی کنید این جمله را کامل کنید: «من فکر می‌کنم پروژه‌ی من واقعاً به X، که در تلاش برای انجام کار Y است، کمک خواهد کرد». به جای اینکه صرفاً فقط کار خود را تبلیغ کنید، به بازخورد دیگران گوش دهید و پاسخگو باشید. -* **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. -* **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. -* **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. +به طور کلی، به کمک کردن به دیگران تمرکز کنید قبل از اینکه چیزهایی را در عوض درخواست کنید؛ چونکه که اگر هر کسی بخواهد پروژه‌های خودش را به صورت آنلاین تبلیغ کند، همهمه و شلوغی زیادی بر پا خواهد شد. برای اینکه در جمعی شناخته شوید، سعی کنید خود را به دیگران معرفی کنید و نه اینکه فقط آنچه که می‌خواهید را بازگو کنید. -Generally 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. +اگر کسی به فعالیت‌های اولیه‌ی شما پاسخی نداد و یا توجه نکرد، ناامید نشوید! اکثر راه‌اندازی‌های پروژه‌ها، فرآیندهایی هستند که باید چندین و چندین بار تکرار شوند که ممکن است ماه‌ها یا سال‌ها به طول انجامد. اگر بار اول پاسخی دریافت نکردید، تاکتیک دیگری را امتحان کنید یا ابتدا به دنبال روش‌هایی برای افزودن ارزش به کار دیگران باشید. راه‌اندازی و توسعه‌ی پروژه، به وقت و تعهد نیاز دارد. -If 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. -## Go where your project's audience is (offline) +## هر جا که مخاطبان شما بودند، شما هم به آنجا بروید (آفلاین) ![Public speaking](/assets/images/finding-users/public_speaking.jpg) -Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers. +رویدادهای آفلاین، روشی متداول برای تبلیغ پروژه‌های جدید برای مخاطبان است. این رویدادها راهی عالی برای دستیابی به مخاطبان مشتاق و ایجاد ارتباطات انسانی عمیق‌تر هستند؛ به خصوص که اگر شما می‌خواهید با توسعه‌دهندگان ارتباط برقرار کنید. -If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. +اگر [تجربه‌ی چندانی در حوزه‌ی سخنرانی در عموم](https://speaking.io/), ندارید و تازه‌کار هستید، با پیدا کردن یک جلسه‌ی محلی که مرتبط با محتوا یا اکوسیستم پروژه‌ی خودتان است شروع کنید. -If 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. +اگر قبلاً هرگز در رویدادی صحبت نکرده‌اید، اینکه استرس داشته باشید، کاملاً طبیعی است! به یاد داشته باشید که مخاطبان شما آنجا هستند زیرا واقعاً می‌خواهند در مورد کارهای شما بشنوند. +هنگام نوشتن سخنرانی خود، بر آنچه که مخاطبان جالب می‌پندارند و از آن ارزش و درسی می‌گیرند، تمرکز کنید. دوستانه و صمیمانه سخن بگویید. لبخند به لب داشته باشید، تنفس کنید و لذت ببرید. -As 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. +هنگامی که کار را بر روی متن سخنرانی خود آغاز می‌کنید، خواه هر چه موضوع سخنرانی شما باشد، اگر سخنرانی خود را همانند داستانی که برای مردم تعریف می‌کنید تصور کنید، می‌تواند به شما کمک بسزایی بکند. -When 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. - -Look 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. +به دنبال کنفرانس‌هایی باشید که مرتبط با محتوا یا اکوسیستم مورد نظر شما باشد. قبل از ارسال سخنرانی خود، در مورد کنفرانس تحقیق کنید تا سخنرانی خود را برای حاضران تنظیم و اصلاح کرده و در نتیجه شانس پذیرفته شدن برای سخنرانی در کنفرانس را افزایش دهید. شما همچنین می‌توانید با مراجعه به لیست سخنرانان کنفرانس، از نوع و کیفیت مخاطبان خود آگاه شوید. -## Build a reputation +## برای خود اعتبار و شهرت دست و پا کنید -In 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. +علاوه بر استراتژی‌های ذکر شده در بالا، بهترین راه برای دعوت مردم برای به اشتراک‌‌گذاری و مشارکت در پروژه‌ی شما، اشتراک و مشارکت در پروژه‌های آن‌ها است. -Helping 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. +کمک به تازه‌واردان، به اشتراک گذاشتن منابع و مشارکت مدبرانه در پروژه‌های دیگران به شما کمک می‌کند تا اعتبار خوبی برای خود بسازید. اگر عضوی فعال در اجتماع (انجمن) اوپن سورس باشید به شما کمک می‌کند تا مردم کار و محتوای شما را بشناسند و احتمال اینکه به پروژه شما توجه کنند و آن را به اشتراک بگذارند، بیشتر می‌شود. توسعه‌ی روابط با سایر پروژه‌های اوپن سورس، می‌تواند منجر به مشارکت و همکاری رسمی شود. -It'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. +برای ایجاد و کسب اعتبار، هیچوقت خیلی زود و یا خیلی دیر نیست. حتی اگر پروژه‌ی خود را از قبل راه‌اندازی کرده‌اید، به جستجوی راه‌هایی برای کمک به دیگران ادامه دهید. برای ایجاد و جذب مخاطب، هیچ راه‌حل یک شبه‌ای وجود ندارد. -There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends. +جلب اعتماد و احترامِ دیگران نیازمند زمان است و هیچ پایانی برای ایجاد و کسب اعتبار وجود ندارد -## Keep at it! +## تسلیم نشوید! -It may take a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it. +ممکن است مدت‌ها تا اینکه مردم متوجه پروژه‌ی اوپن سورس شما شوند طول بکشد. هیچ اشکالی نداره! برخی از محبوب‌ترین پروژه‌های امروزی، برای رسیدن به سطح بالایی از فعالیت، سال‌ها به طول انجامید. به جای اینکه امیدوار باشید پروژه‌ی شما به طور خود به خود محبوبیت پیدا کند، بر ایجاد روابط متمرکز شوید. صبور باشید و مدام کار خود را با کسانی که قدر آن را می‌دانند به اشتراک بگذارید. From 6c838b193d085fbe5b47dfea3521e1f6f5b8a0a6 Mon Sep 17 00:00:00 2001 From: BobAnkh Date: Fri, 16 Apr 2021 14:41:34 +0800 Subject: [PATCH 007/629] Fix a typo of zh-hans translation --- _articles/zh-hans/legal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md index 314eef32804..28bfca47a9d 100644 --- a/_articles/zh-hans/legal.md +++ b/_articles/zh-hans/legal.md @@ -119,7 +119,7 @@ redirect_from: /zh-cn/legal/ **如果你们的开源项目是为了你们的公司，**那么绝对要让他们知道。根据公司的业务需求和专业知识，你们的法律团队可能已经制定了有关开放源代码许可协议（以及可能还有其他贡献者协议）的政策，以确保您的项目符合其依赖关系的许可协议。如果不是这样，你们和他们很幸运！你们的法律团队应该渴望与你们合作，把这个东西搞清楚。你们需要思考这些事： -* **第三方资源：**你们的项目有其他人创建的依赖或者使用他人的代码？如果这些事开源项目，你们需要遵守第三方资源的开源许可协议。首先，选择与第三方资源的开放源许可协议一起使用的许可协议（见上文）。如果你们的项目修改或者发布第三方开源资源，那么你们法律团队还想知道你们符合第三方开源许可协议的其他条件，例如保留版权声明。如果你们使用了其他没有开源许可协议的代码，那么你们可能会要求第三方资源的维护者[添加一个开源许可协议](https://choosealicense.com/no-license/#for-users)，要是你们得不到许可，你们只能停止使用他们的代码。 +* **第三方资源：**你们的项目有其他人创建的依赖或者使用他人的代码？如果这些是开源项目，你们需要遵守第三方资源的开源许可协议。首先，选择与第三方资源的开放源许可协议一起使用的许可协议（见上文）。如果你们的项目修改或者发布第三方开源资源，那么你们法律团队还想知道你们符合第三方开源许可协议的其他条件，例如保留版权声明。如果你们使用了其他没有开源许可协议的代码，那么你们可能会要求第三方资源的维护者[添加一个开源许可协议](https://choosealicense.com/no-license/#for-users)，要是你们得不到许可，你们只能停止使用他们的代码。 * **商业机密：**请考虑项目中是否有公司不想对外公开的东西。如果是这样的话，你们只能开源项目的一部分，得保护好公司的商业机密。 From 166ab18e16c1444de190f0c393fed4f4f428a063 Mon Sep 17 00:00:00 2001 From: BobAnkh Date: Fri, 16 Apr 2021 14:48:16 +0800 Subject: [PATCH 008/629] Fix a typo of zh-hant translation --- _articles/zh-hant/legal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/zh-hant/legal.md b/_articles/zh-hant/legal.md index 4d1de93e01a..87b7dd670f3 100644 --- a/_articles/zh-hant/legal.md +++ b/_articles/zh-hant/legal.md @@ -119,7 +119,7 @@ redirect_from: /zh-tw/legal/ **如果你們的開源專案是爲了你們的公司，**絕對需要讓他們知道。根據公司的業務需求和專業知識，你們的法律團隊可能已經制定了有關開放源程式碼許可協議（以及可能還有其他貢獻者協議）的政策，以確保您的專案符合其依賴關係的許可協議。如果不是這樣，你們和他們很幸運！你們的法律團隊應該渴望與你們合作，把這個東西搞清楚。你們需要思考這些事： -* **第三方資源：**你們的專案有其他人創建的依賴或者使用他人的程式碼？如果這些事開源專案，你們需要遵守第三方資源的開源許可協議。首先，選擇與第三方資源的開放源許可協議一起使用的許可協議（見上文）。如果你們的專案修改或者發佈第三方開源資源，那麼你們法律團隊還想知道你們符合第三方開源許可協議的其他條件，例如保留版權聲明。如果你們使用了其他沒有開源許可協議的程式碼，那麼你們可能會要求第三方資源的維護者[添加一個開源許可協議](https://choosealicense.com/no-license/#for-users)，要是你們得不到許可，你們只能停止使用他們的程式碼。 +* **第三方資源：**你們的專案有其他人創建的依賴或者使用他人的程式碼？如果這些是開源專案，你們需要遵守第三方資源的開源許可協議。首先，選擇與第三方資源的開放源許可協議一起使用的許可協議（見上文）。如果你們的專案修改或者發佈第三方開源資源，那麼你們法律團隊還想知道你們符合第三方開源許可協議的其他條件，例如保留版權聲明。如果你們使用了其他沒有開源許可協議的程式碼，那麼你們可能會要求第三方資源的維護者[添加一個開源許可協議](https://choosealicense.com/no-license/#for-users)，要是你們得不到許可，你們只能停止使用他們的程式碼。 * **商業機密：**請考慮專案中是否有公司不想對外公開的東西。如果是這樣的話，你們只能開源專案的一部分，得保護好公司的商業機密。 From e84c6228cd1e60096963b70fbed5a1c1892e384e Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Sat, 17 Apr 2021 18:25:48 +0430 Subject: [PATCH 009/629] Initial translation done. --- _articles/fa/how-to-contribute.md | 431 +++++++++++++++--------------- 1 file changed, 214 insertions(+), 217 deletions(-) diff --git a/_articles/fa/how-to-contribute.md b/_articles/fa/how-to-contribute.md index 81158f6f25a..71ff96fd79c 100644 --- a/_articles/fa/how-to-contribute.md +++ b/_articles/fa/how-to-contribute.md @@ -1,15 +1,8 @@ --- -lang: en -title: How to Contribute to Open Source -description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans. +lang: fa +title: چگونه در یک پروژه‌ی متن باز مشارکت کنیم +description: می‌خواهید در یک پروژه‌ی متن باز مشارکت کنید؟ در ادامه‌ی مقاله نحوه‌ی مشارکت در یک پروژه‌ی متن باز برای افراد مبتدی و باتجربه شرح داده شده است. class: contribute -toc: - why-contribute-to-open-source: "Why contribute to open source?" - what-it-means-to-contribute: "What it means to contribute" - orienting-yourself-to-a-new-project: "Orienting yourself to a new project" - finding-a-project-to-contribute-to: "Finding a project to contribute to" - how-to-submit-a-contribution: "How to submit a contribution" - what-happens-after-you-submit-a-contribution: "What happens after you submit a contribution" order: 1 image: /assets/images/cards/contribute.png related: @@ -17,210 +10,212 @@ related: - building --- -## Why contribute to open source? +## چرایی مشارکت در یک پروژه‌ی متن باز؟ -Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine. +زمانی که در پروژه‌های متن باز مشارکت می‌کنید، چیزهای زیادی یاد می‌گیرد یا یاد می‌دهید، حتی می‌توانید در هر مهارتی که تصورش را می‌کنید تجربه کسب کنید. -Why do people contribute to open source? Plenty of reasons! +چرا افراد در پروژه‌های متن باز مشارکت می‌کنند؟ خب، دلایل زیادی وجود دارد! -### Improve software you rely on +### نرم‌افزاری که به آن متکی هستید را بهبود می‌دهید -Lots of open source contributors start by being users of software they contribute to. When you find a bug in 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. +مشارکت‌کننده‌ها مشارکت خود از پروژه‌هایی شروع می‌کنند که کاربر آن می‌شوند. زمانی که در نرم‌افزار یک پروژه‌ی متن باز باگ یا خطایی مشاهده کردید، در صورتی که توانایی برطرف کردن آن را داشته باشید می‌توانید به سرس کد آن نگاهی بیندازید و خودتان اصلاحیه‌ای برایش بنویسید. اگر با چنین موردی روبه‌رو شدید، مشارکت در اصلاح آن باگ بهترین راه برای مطمئن کردن دوستان (و خودتان مخصوصاً زمانی که نسخه‌ی بعدی آن به روز شود) باشد که می‌تواند مزیت‌های داشته باشد. -### Improve existing skills +### مهارت‌های موجودتان تقویت می‌شود -Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. +اگر به دنبال تمرین کدنویسی، طراحی رابط‌کاربری کاربر، طراحی گرافیک، نویسندگی یا سازماندهی کردن هستید، پروژه‌ی متن باز این تمرین‌ها را در اختیارتان قرار می‌دهد. -### Meet people who are interested in similar things +### با افرادی ملاقات می‌کنید که علایق‌شان با شما مشابه است -Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos. +پروژه‌های متن باز با انجمن‌های گرم و گیرایش باعث می‌شود افرادی که در آن حضور دارند برای سال‌ها به آن مراجعه کنند. حتی بسیاری هستند که به واسطه‌ی همکاری‌شان در راه‌اندازی کنفرانس‌ها یا چت‌های آنلاین شبانه‌شان درباره‌ی burritos ، روابط دوستانه‌ی طولانی مدتی دارند. -### Find mentors and teach others +### استاد پیدا می‌کنید و به دیگران آموزش می‌دهید -Working 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. +کار کردن با دیگران در پروژه‌های مشترک شما را مجبور می‌کند نحوه‌ی انجام دادن کارها را توضیح دهید و به همان اندازه هم از دیگران کمک بخواهید. هر کسی می‌تواند خود را درگیری فعالیت‌های یادگیری و آموزشی کند. -### Build public artifacts that help you grow a reputation (and a career) +### محصولی عمومی تولید کنید که به رشد اعتبار و حرفه‌ی کاری‌تان کمک کند -By 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. +بر اساس تعریف، تمام پروژه‌های متن باز شما عمومی هستند. به این معنا که نمونه پروژه‌ها را دریافت می‌کنید و می‌توانید آن را همه جا ببرید و نشان دهید که چه کارهایی می‌توانید با آن انجام دهید. -### Learn people skills +### مهارت‌های دیگران را یاد می‌گیرید -Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work. +روژه‌های متن باز فرصتی فراهم می‌کنند که به واسطه‌ی آن می‌توانید مهارت‌های مدیریت و رهبری پروژه‌ی خود مانند برطرف کردن تضادها، سازماندهی کردن تیم و اولیت بندی کارها، را تقویت کنید. -### It's empowering to be able to make changes, even small ones +### به شما قدرت اعمال تغییرات هرچند کوچک را می‌دهد -You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying. +لازم نیست برای لذت بردن از همکاری در یک پروژه‌ی متن باز، به یک مشارکت‌کننده‌ی درازمدت تبدیل شوید. تا حالا شده در یک وب‌سایت چند غلط‌های املائی ببینید و دوست داشتید یک نفر آن را اصلاح کند؟ خب، گر چنین حالتی برای پروژه‌تان به وجود بیاید، به راحتی می‌توانید آن را برطرف کنید. پروژه‌ی متن باز می‌تواند به افراد کمک کند تا شرکتی که در آن فعالیت می‌کنند و نحوه‌ی کسب کردن تجربه‌شان را از زندگی خود مهم‌تر بدانند و همین مسئله حس رضایت‌بخشی به آن‌ها می‌دهد. -## What it means to contribute +## مشارکت به چه معناست؟ -If 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? +اگر در مشارکت یک پروژه‌ی متن باز تازه‌وارد هستید، فرآیند آن می‌تواند ترسناک باشد. شما چگونه یک پروژه درست برای مشارکت کردن در آن را انتخاب می‌کنید؟ اگر چیزی از کد نویسی ندانید، چی؟ اگر چیزی درست پیش نرود، چی؟ -Not 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. +خب، نگران نباشید! راه‌های زیادی برای مشارکت در پروژه‌های متن باز وجود دارد که در ادامه‌ی مقاله مواردی از آن‌ها را می‌آوریم که می‌تواند به بدست آوردن تجربه‌های بیشتر به شما کمک کند. -### You don't have to contribute code +### الزماً قرار نیست در فرایند کدنویسی مشارکت کنید -A 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! +یک دید غلط و مرسومی که برای مشارکت در پروژه‌های متن باز وجود دارد این است که فکر می‌کنند برای مشارکت در آن باید حتما کدنویسی شود. در حقیقت، [اغلب بخش‌های دیگر پروژه](https://github.com/blog/2195-the-shape-of-open-source) است که از آن غفلت یا بیش از حد به آن توجه می‌شود. شما با برطرف کردن مشکلات و مشارکت در آن بخش‌ها لطف بزرگی به پروژه‌های متن باز می‌کنید. -Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project. +حتی اگر هم به کدنویسی در پروژه علاقه‌مند باشید، روش‌های دیگر مشارکت بهترین راه‌برای درگیر شدن در یک پروژه و ملاقات با اعضای انجمن‌های دیگر وجود دارد. ساختن این روابط به شما فرصت‌هایی می‌دهد تا در بخش‌های دیگر پروژه مشارکت کنید. -### Do you like planning events? +### آیا به برگزاری رویدادها علاقه‌مند هستید؟ -* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) -* Organize the project's conference (if they have one) -* Help community members find the right conferences and submit proposals for speaking +* ورکشاپ (کارگاه‌ها) را سازماندهی یا جلسات پروژه را برگزار کنید، مانند کاری که @fzamperin برای [NodeSchool](https://github.com/nodeschool/organizers/issues/406) انجام داد +* در صورت داشتن، برای یک پروژه کنفرانس برگزار کنید +* به اعضای انجمن کمک کنید تا کنفرانس‌های درستی پیدا و برای کنفرانس پرپوزال خود را ارسال کنند. -### Do you like to design? +### آیا به طراحی علاقه‌مند هستید؟ -* Restructure layouts to improve the project's usability -* 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) -* Put together a style guide to help the project have a consistent visual design -* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) +* با هدف افزایش قابلیت استفاده به بهبود ساختار برنامه ها کمک کنید. +* مشابه [دروپال](https://www.drupal.org/community-initiatives/drupal-core/usability) می‌توانید با هدف بهبود رابط کاربری اقدام به کاربرپژوهی و مطالعاتی از این دست کنید. +* با جمع آوری و یک کاسه کردن الگوهای طراحی به کار گرفته شده در پروژه یک شیونه نامه (استایل گاید) متمرکز ایجاد کنید. +* اقدام به خلق کارهای هنری مثل طراحی لوگو یا تی شرت مخصوص کنید. مثل کاری که [hapi.js](https://github.com/hapijs/contrib/issues/68) انجام داد. -### Do you like to write? +### آیا به نویسندگی در پروژه علاقه‌مند هستید؟ -* Write and improve the project's documentation -* Curate a folder of examples showing how the project is used -* Start a newsletter for the project, or curate highlights from the mailing list -* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194) -* Write a translation for the project's documentation +* اسناد پروژه را بنویسید و اصلاح کنید +* پوشه‌ی نمونه‌ها را تنظیم کنید تا نحوه‌ی استفاده‌ی پروژه را نشان دهد +* برای پروژه یک خبرنامه راه‌اندازی کنید، یا شاخصه‌های آن را نوشته و تنظیم کنید +* برای پروژه، مطالب آموزشی بنویسید، مانند مشارکت‌کننده‌هایی که برای [PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194) مطالب آموزشی نوشتند +* مستندات پروژه را به زبانی دیگر ترجمه کنید -### Do you like organizing? +### آیا به سازماندهی پروژه علاقه‌مند هستید؟ -* Link to duplicate issues, and suggest new issue labels, to keep things organized -* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) -* Ask clarifying questions on recently opened issues to move the discussion forward +* برای سازماندهی کردن همه چیز، مشکلات تکراری را لینک کنید و مسائل جدیدی مطرح کنید +* با مسئله‌های (issue) باز رودرو شوید و پیشنهاد دهید مسائل قدیمی حل شوند، مانند کاری که @nzakas برای [ESLin](https://github.com/eslint/eslint/issues/6765) انجام داد +* برای پیشبرد بحث، سوالات شفافی درباره‌ی مسائل باز اخیر بپرسید -### Do you like to code? +### آیا به کدنویسی علاقه دارید؟ -* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) -* Ask if you can help write a new feature -* Automate project setup -* Improve tooling and testing +* مسائل باز و حل نشده را پیدا و حل کنید، مانند کاری که @dianjin برای [Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) انجام داد +* اگر می‌توانید برای اعمال یک ویژگی جدید به پروژه کمک کنید، درخواست‌تان را مطرح کنید +* نصب پروژه را خودکار کنید +* ابزارهای مرتبط و تسهیل کننده و تست پروژه را تقویت کنید -### Do you like helping people? +### آیا از کمک کردن به مردم لذت می‌برید؟ -* 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 -* Answer questions for people on open issues -* Help moderate the discussion boards or conversation channels +* به سوالاتی که افراد درباره‌ی پروژه در سایت‌هایی مانند Stack، Postgres، یا Reddit می‌پرسند، جواب بدهید +* سوالات افرادی که مسائل حل نشده‌ای دارند را جواب بدهید +* در اداره کانال‌های گفتگو و تالارهای گفتمان مشارکت کنید -### Do you like helping others code? +### آیا دوست دارید در کدنویسی به دیگران کمک کنید؟ -* Review code on other people's submissions -* Write tutorials for how a project can be used -* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) +* کدنویسی سایر افراد را بررسی کنید +* برای نحوه‌ی استفاده‌ی یک پروژه‌ی متن باز، مطلب آموزشی بنویسید +* یک مشارکت کننده دیگر که می‌شناسید را پیشنهاد دهید، [مثل کاری که @ereichert در Rust برای @bronzdoc کرد][like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666). + +### لازم نیست فقط روی پروژه‌های نرم‌افزاری وقت صرف کنید! -### You don't just have to work on software projects! +با اینکه بیشتر پروژه‌های متن باز به نرم‌افزارها اطلاق می‌شود، اما می‌توانید هرچیزی از جمله کتاب‌ها، دستورالعمل، لیست چیزهای مختلف و کلاس‌ها را در پروژه‌های متن باز توسعه دهید. -While "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. +به عنوان مثال: -For example: +* @sindresorhus [لیست‌هایی موسوم به «awesome»](https://github.com/sindresorhus/awesome) گردآوری و تنظیم می‌کند +* @h5bp [یک لیست حاوی سوالاتی جهت مصاحبه برای توسعه دهندگان فرانت اند](https://github.com/h5bp/Front-end-Developer-Interview-Questions) را نگهداری و مرتب می‌کند +* @stuartivnn و @nicole-a-tesla [مجموعه‌ای از حقایق جالب درباره‌ی طوطی دریایی](https://github.com/stuartlynn/puffin_facts) ایجاد کرده‌اند. -* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) -* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates -* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) +حتی اگر توسعه‌دهنده‌ی نرم‌افزار هم باشید، کار روی اسناد یک پروژه می‌توانید به شما کمک کند تا پروژه‌ی متن بازتان را شروع کنید. کار روی پروژه‌هایی که کدنویسی کمتری دارد اغلب ترس کمتری دارد و فرآیند همکاری در آن باعث می‌شود اعتمادبه‌نفس و تجربه‌ی شما افزایش پیدا کند. -Even 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. - -## Orienting yourself to a new project +## ورود و وفق دادن خودمان به یک پروژه جدید -For 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. +مشارکت کردن در یک پروژه‌ی متن باز که بیشتر از اصلاح غلط‌هایی املائی است، مانند وارد شدن به پارتی غریبه‌هاست. اگر در این پارتی درباره ماهی قرمز بحث عمیقی شکل گرفته، شما درباره‌ی لاماها صحبت کنید، احتمالاً نگاه عجیبی به شما می‌شود. + +بنابراین، قبل از اینکه کورکورانه با پیشنهادهای‌تان وارد کاری شوید، یاد بگیرید که چگونه در چت روم‌ها گفتگو کنید. این کار شانس شما را برای شنیده شدن و توجه به ایده‌هایتان را بالا می‌برد. -Before 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. -### Anatomy of an open source project +### آناتومی یک پروژه‌ی متن باز -Every open source community is different. +جامعه‌ها در پروژه‌های متن باز متفاوت هستند. -Spending 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. +زمانی که سال‌ها روی یک پروژه‌ی متن باز صرف می‌کنید، باید آن پروژه‌ی متن باز را بشناسید. از طرفی، زمانی هم که به پروژه‌ی متفاوتی منتقل می‌شوید، لغات، قوائد و سبک ارتباطاتی آن که ممکن است کاملاً متفاوت باشد را باید پیدا کنید. -That 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. +گفته می‌شود بیشتر پروژه‌های متن باز از یک ساختار سازماندهی مشابه پیروی می‌کنند. شناخت و درک نقش‌ها در جوامع مختلف و فرآیند کلی آن به شما کمک می‌کند به سرعت وارد هر پروژه‌ی جدیدی شوید. -A typical open source project has the following types of people: +افراد مختلفی در یک پروژه‌ی متن باز معمولی مشارکت می‌کنند: -* **Author:** The person/s or organization that created the project -* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author) -* **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.) -* **Contributors:** Everyone who has contributed something back to the project -* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction +* **نویسنده:** شخص یا سازمانی که یک پروژه را خلق می‌کند +* **صاحب مالک:** شخص یا اشخاصی که صاحب اداری آن سازمان یا مخزن هستند (البته صاحب پروژه همیشه با نویسنده‌ی اصلی یکسان نیست) +* **مسئول‌نگهداری پروژه:** مشارکت‌کننده‌هایی که مسئول پیش بردن چشم انداز و مدیریت جنبه‌های سازمانی یک پروژه باشند (این افراد همچنین می‌توانند نویسنده یا صاحب پروژه باشند) +* **مشارکت‌کننده:** هر کسی که در پروژه مشارکت داشته باشد +* **اعضای انجمن:** افرادی که از پروژه استفاده می‌کنند، می‌توانند مکالمات فعالانه‌ای داشته باشند یا نظرات‌شان را برای مسیر دادن به پروژه ابراز کنند -Bigger 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. +پروژه‌های بزرگ‌تر همچنین ممکن است زیرکمیته‌ها یا گروه‌های کاری داشته باشند که روی وظایف متفاوتی مانند مجهز کردن، triage (تریاژ)، معتدل کردن انجمن و سازماندهی رویداد متمرکز می‌شوند. زمانی که به صفحه‌ی «تیم» پروژه‌ی یک وب‌سایت، یا مخزن مراجعه کنید، می‌توانید اطلاعات این زیرکمیته‌ها و نقش افراد کلیدی را مشاهده کنید. -A project also has documentation. These files are usually listed in the top level of a repository. +پروژه‌های متن باز اسناد مختلفی دارند که این فایل‌ها معمولا در بالای لیست مخزن قرار می‌گیرند. -* **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. -* **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. -* **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. -* **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. -* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects. +* **لایسنس/ گواهینامه (LICENSE):** طبق تعریف، هر پروژه‌ی متن بازی باید لایسنس مخصوص به خود را داشته باشد. اگر یک پروژه لایسنس نداشته باشد، اصلاً متن باز محسوب نمی‌شود +* **فایل README:** فایل README یک دستورالعمل ساختاری برای تمام اعضای جدید انجمن است که می‌توانند آن را مطالعه می‌کنند. در این فایل به خوبی آورده شده که پروژه‌ی در دست چه فوایدی دارد و چگونه باید از آن استفاده کرد +* **فایل CONTRIBUTING:** زمانی که یک فایل README می‌تواند به مردم برای استفاده از پروژه کمک کنند، فایل CONTRIBUTING هم می‌تواند برای مشارکت افراد در پروژه به شما و به آن‌ها کمک کند. در این فایل توضیح داده شده که به چه نوع مشارکتی نیاز است و فرآیند کاری پروژه به چه نحوه است. با اینکه هر پروژه فایل CONTRIBUTING ندارد، اما در صورت وجود چنین فایلی در پروژه می‌تواند به افراد مختلف سیگنال مشارکت در پروژه بدهد. +* **CODE_OF_CONDUCT:** در فایل code of conduct می‌توانید قوائدی که شرکت‌کنندگان باید با در نظر گرفتن آن به صورت دوستانه و راحت و در یک محیط پذیرا با سایرین برخورد کنند را بنویسید. با اینکه هر پروژه ممکن است حاوی این فایل نباشد، اما زمانی که یک پروژه‌ی متن باز این فایل را داشته باشد، به مشارکت‌کننده‌ها این سیگنال را می‌فرستد می‌توانند در پروژه مشارکت داشته باشند. این فایل تقریباً حاوی توصیه‌هایی رفتاری برای تعامل است. +* **اسناد دیگر:** یک پروژه‌ی متن باز به خصوص پروژه‌های بزرگ‌تر ممکن است حاوی اسناد دیگری مانند فایل‌های آموزشی، بازنگری فنی، راهنمای گام به گام (walkthroughs)، یا سیاست‌های دولتی باشند. -Finally, 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. +در نهایت، پروژه‌های متن باز برای سازماندهی بحث‌ها از ابزارهای زیر استفاده می‌کنند. مطالعه‌ی آرشیو پروژه‌ها می‌تواند دید خوبی از نحوه‌ی فکر و کار انجمن‌ها بدهد. -* **Issue tracker:** Where people discuss issues related to the project. -* **Pull requests:** Where people discuss and review changes that are in progress. -* **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. -* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. +* **ایشو ترکر (Issue tracker):** جایی که افراد درباره‌ی مشکلات مرتبط با پروژه بحث می‌کنند +* **درخواست Pull (Pull requests):** جایی که افراد درباره‌ی تغییرات جاری بحث و بازبینی می‌کنند. +* **انجمن گفتگو یا خبرنامه های ایمیلی:** برخی از پروژه ها ممکن است برای موضوعات نیازمند بحث و گفتگو از انجمن های گفتگو یا خبرنامه ایمیلی به جای ایشو ترکر استفاده کنند. البته برخی دیگر ممکن است همین کار را به صورت کامل در بخش ایشو ترکر انجام دهند. +* **Synchronous chat channel:** بعضی از پروژه‌های از کانال‌های چت مانند Slack یا IRC برای مکالمات محاوره‌ای، همکاری یا تبادلات سریع استفاده می‌کنند. -## Finding a project to contribute to +## یافتن یک پروژه جهت مشارکت کردن در آن -Now that you've figured out how open source projects work, it's time to find a project to contribute to! +اکنون می‌دانید نحوه‌ی کار یک پروژه‌ی متن باز چگونه است. بنابراین، زمانش رسیده تا برای مشارکت، یک پروژه‌ی متن باز پیدا کنید! -If 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."_ +اگر قبلا در هیچ پروژه‌ی متن بازی مشارکت نداشته‌اید، نصیحت رئیس جمهور آمریکا، جان. اف. کندی را بشنوید که گفت:«نگویید کشورتان برای شما چه کار کرده– بپرسید شما برای کشورتان چه کار کرده‌اید.» -Contributing 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. +مشارکت‌کننده‌ها در تمام سطح‌های می‌توانند در پروژه‌های متن باز مشارکت کنند. لازم نیست بیش از حد به ذهن خود فشار بیاورید که اولین مشارکت شما در یک پروژه دقیقاً به چه صورت است، یا اولین مشارکت‌تان در آن پروژه چگونه خواهد شد. -Instead, 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. +در عوض، به پروژه‌هایی فکر کنید که قبلا استفاده شده، یا می‌خواهید استفاده کنید. پروژه‌هایی که به صورت فعال در آن مشارکت می‌کنید، پروژه‌هایی هستند که برمی‌گردند. -Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. +هر زمان در چنین پروژه‌هایی به این موضوع فکر کردید که می‌توانستید بهتر از این یا متفاوت‌تر باشد، بهتر است از روی غریزه کار کنید. -Open 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. +فکر نکنید یک پروژه‌ی متن باز انحصاری است، چون پروژه‌های متن باز توسط افرادی مانند شما طراحی شده است. یک پروژه‌ی متن باز تنها یک لفظ فانتزی برای برطرف کردن و حل مشکلات در دنیاست. -You 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! +شما در پروژه‌های متن باز می‌توانید فایل README را مطالعه، لینک‌های خراب و غلط‌های املائی را پیدا و برطرف کنید. شما و کاربران جدیدتان هم می‌توانند متوجه مشکل یا مسئله‌ای شوند که فکر کی‌کند باید از اسناد پروژه باشد. به جای نادیده گرفتن، عبور کردن یا سپردن آن مسائل به افراد دیگر، برای اصلاح آن مشکلات می‌توانید کمک کنید. این تمام چیزی است که یک پروژه‌ی متن باز می‌تواند داشته باشد! -> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation. +> [28% از مشارکت‌کننده‌های معمولی](https://www.igor.pro.br/publica/papers/saner2016.pdf) روی اسناد پروژه‌ی متن باز مانند اصلاح غلط‌های املائی، شکل ‌دهی مجدد، یا نوشتن ترجمه مشارکت می‌کنند. -If 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)). +اگر به دنبال مسائل موجود پروژه‌ی متن بازتان هستید تا آن را برطرف کنید، می‌توانید وارد صفحه‌ی `/contribute` هر پروژه‌ی متن باز شوید که مشکلات را برای تازه‌واردها برجسته می‌کند. شما می‌توانید با حل کردن آن مشکلات، در مشارکت پروژه‌ی متن باز همکاری داشته باشد. برای این منظور می‌توانید به صفحه‌ی اصلی repository (مخزن) در سایت GitHub مراجعه کنید و کلمه‌ی `/contribute` را به انتهای آدرس URL آن اضافه کنید. به عنوان مثال: +[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). -You can also use one of the following resources to help you discover and contribute to new projects: +شما همچنین می‌توانید از منابع زیر برای کشف و مشارکت در پروژه‌های جدید کمک بگیرید: * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) @@ -232,304 +227,306 @@ You can also use one of the following resources to help you discover and contrib * [First Contributions](https://firstcontributions.github.io) * [SourceSort](https://www.sourcesort.com/) -### A checklist before you contribute +### بررسی چک لیست قبل از مشارکت در پروژه‌ی متن باز -When 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. +زمانی که پروژه‌ی مورد علاقه‌تان برای مشارکت را پیدا کردید، نگاهی سریعی داشته باشید که آیا آن پروژه مناسب است تا درخواست همکاری‌تان را بفرستید. در غیر این صورت، کار پُرتلاش شما ممکن است هیچوقت به نتیجه نرسد. -Here's a handy checklist to evaluate whether a project is good for new contributors. +در ادامه می‌تواند چک لیست دستی را ببینید که می‌تواند مشارکت‌کننده‌های جدید یک پروژه را ارزیابی کند. -**Meets the definition of open source** +**پروژه با تعریف پروژه‌ی متن باز مطابقت داشته باشد**
-**Project actively accepts contributions** - -Look at the commit activity on the master branch. On GitHub, you can see this information on a repository's homepage. +**پروژه‌ی متن باز به صورت فعالانه‌ای حضور مشارکت‌کننده‌ها را قبول می‌کند** +نگاهی به کامیت های اخیر در شاخه اصلی بیاندازید. در گیت‌هاب این این مورد در صفحه اصلی مخزن دیده می‌شود.
-Next, look at the project's issues. +در قدم بعدی به مسائل پروژه (issue) نگاهی بیندازید.
-Now do the same for the project's pull requests. +حالا، تمام این مراحل را برای درخواست ادغام یا Pull Request پروژه هم در نظر بگیرید.
-**Project is welcoming** +**پروژه پذیرای مشارکت است** -A project that is friendly and welcoming signals that they will be receptive to new contributors. +زمانی که یک پروژه‌ی متن باز پذیرای مشارکت‌کننده‌های جدید باشد، سیگنال‌های دوستانه‌ای برای مشارکت‌کننده‌ها می‌فرستد.
-## How to submit a contribution +## چگونه درخواست مشارکت را ارسال کنیم -You'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. +زمانی که پروژه‌ی مورد علاقه‌تان را پیدا کردید، آماده‌ی مشارکت در آن می‌شوید و در نهایت باید راهی برای ارسال مشارکت خود به آن پیدا کنید. -### Communicating effectively +### ارتباط موثر -Whether 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. +خواه مشارکت‌کننده‌ی یک‌باره باشید، یا سعی داشته باشید در یک انجمن عضو شوید، کار کردن با دیگران می‌تواند یکی از مهم‌ترین مهارت‌هایی باشد که در مشارکت در پروژه‌ی متن باز می‌توانید آن‌ را توسعه و بهبود دهید. -Before 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. +قبل از درخواست ادغام یا باز کردن issue در بخش گزارش مسئله یا پرسیدن سوال در چت، نکته‌های زیر را در نظر داشته باشید تا به شما کمک کند تا ایده‌هایتان کارآمد و موثرتر باشد. -**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!). +**ارائه‌ی زمینه:** به دیگران کمک کنید تا سرعت خود را افزایش دهند. اگر خطایی پیدا کردید و در حال برطرف کردن آن هستید، به دیگران توضیح دهید که سعی دارید چه کاری انجام می‌دهید و چگونه آن مشکل را حل می‌کنید. اگر ایده‌ی جدیدی هم پیشنهاد می‌دهید، نه تنها برای خود، بلکه برای دیگران توضیح دهید که چرا فکر می‌کنید این ایده‌ی شما می‌تواند برای پروژه مفید باشد. -> 😇 _"X doesn't happen when I do Y"_ +> 😇 _"زمانی که Y را انجام می‌دهم، X اتفاق نمی‌افتد"_ > -> 😢 _"X is broken! Please fix it."_ +> 😢 _"X به مشکل برخورد کرده است! لطفا برطرفش کنید."_ -**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn. +**تکالیف‌تان را از قبل انجام دهید.** اگر چیزی نمی‌دانید مشکلی نیست، اما باید نشان دهید که تلاش‌تان را می‌کنید. قبل از اینکه از دیگران کمک بخواهید، مطمئن شوید که فایل README، اسناد، مسائل حل شده یا حل نشده، لیست پست پروژه را خوانده‌اید، یا در اینترنت به دنبال جواب‌تان گشته‌اید. وقتی تلاش‌تان برای یادگیری را نشان می‌دهید، مورد توجه تحسین دیگران قرار می‌گیرید -> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ +> 😇 _"مطمئن نیستم چگونه X را اجرا کنم. برای پیدا کردن جواب، فایل‌ها را بررسی کردم و هیچ جوابی نگرفتم."_ > -> 😢 _"How do I X?"_ +> 😢 _"چگونه مسئله X را برطرف کنم؟"_ -**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. +**درخواست‌ها را مختصر و مفید مطرح کنید** هر مشارکتی مانند ارسال یک ایمیل، بدون در نظر گرفتن ساده یا مفید بودنش، به توجه‌ی دیگران نیاز دارد. معمولاً درخواست‌ها و سوالات اکثر پروژه‌ها از افرادی که می‌خواهند به آن‌ها جواب بدهند بیشتر است. بنابراین، درخواست‌ها باید مختصر باشد. با کوتاه بودن درخواست‌ها به افراد شانس بیشتری می‌دهید تا فرصت کمک کردن به شما را پیدا کنند. -> 😇 _"I'd like to write an API tutorial."_ +> 😇 _"تمایل دارم یک فایل آموزشی API بنویسم"_ > -> 😢 _"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..."_ +> 😢 _"زمانی که در بزرگ‌راه در حال رانندگی کردن بودم، کنار یک پمپ بنزین توقف کردم و ایده‌ی شگفت‌انگیزی به ذهنم رسید که باید آن را عملی کنیم، اما قبل از توضیح، اجازه دهید ایده‌ام را به شما نشان بدهم ..."_ -**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. +**تمام ارتباطات و تعاملات را به صورت عمومی نگهدارید.** هرچند وسوسه‌کننده است، اما به طور خصوصی با مسئول‌نگهداری پروژه تماس نگیرید مگر اینکه لازم باشد اطلاعات حساس مانند مسائل امنیتی یا نقض رفتار جدیدی را رد و بدل کنید. زمانی که مکالمه‌ی شما عمومی شود، افراد بیشتری از تبادیل این ارتباطات یاد می‌گیرند و بهره می‌گیرند. بحث و گفتگوها می‌تواند خودبه خود کمک‌رسان باشد. -> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_ +> 😇 (در کامنت) «@-مسئول‌نگهداری: سلام! چگونه درخواست ادغام را پیش ببریم؟"_ > -> 😢 _(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"_ +> 😢 (در ایمیل) «سلام، ببخشید از طریق ایمیل مزاحم می‌شم، اما نمی‌دانم که می‌توانید درخواست ادغام من را بررسی کنید.»_ -**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. +**سوال کردن عیب نیست (اما صبور باشید!).** هرکسی در ابتدای کار در پروژه تازه‌وارد بوده است. حتی مشارکت‌کننده‌های باتجربه زمانی که به پروژه‌ی جدیدی مراجعه می‌کنند، باید سرعت خود را افزایش دهند. با این حساب، حتی مسئول‌نگهدارهای طولانی مدت هم همیشه با تمام بخش‌های یک پروژه آشنا نیستند. بنابراین، سعی کنید صبور باشید تا فرصت نشان دادن آن را به شما بدهند. -> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_ +> 😇 _"بابت بررسی کردن این خطا ممنونم. پیشنهادهای شما را دنبال می‌کنم. این خروجی کار است"_ > -> 😢 _"Why can't you fix my problem? Isn't this your project?"_ +> 😢 _"چرا مشکل من را نمی‌توانید حل کنید؟ این پروژه مگر پروژه‌ی شما نیست؟"_ -**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. +**به تصمیمات انجمن احترام بگذارید.** ایده‌های شما ممکن است با اولویت‌ها و دید انجمن متفاوت باشد. آن‌ها یا می‌توانند به ایده‌های شما بازخورد بدهند یا آن را دنبال نکنند. درحالی‌که باید بحث و گفتگو کنید و به دنبال مصالحه باشید، مسئول‌نگهداری باید با تصمیمات شما بیشتر از شما زندگی کند. اگر با مسیر آن‌ها مخالف هستید، همیشه می‌توانید روی کار خود تمرکز کنید و پروژه‌ی خودتان را شروع کنید. -> 😇 _"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."_ +> 😇 _"ناامید شدم که نمی‌توانید پرونده‌ی من را پشتیبانی کنید، اما همانطور که توضیح دادید این مسئله تنها روی بخشی از کاربران تاثیر می‌گذارد. متوجه هستم چرا. بابت شنیدن پیامم ممنون هستم"_ > -> 😢 _"Why won't you support my use case? This is unacceptable!"_ +> 😢 _"چرا مورد من را پشتیبانی نمی‌کنید؟ این کار شما غیرقابل قبول است!"_ -**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. +**فراتر از همه اینها.** مشارکت‌کننده‌های سراسر دنیا پروژه‌های متن باز را می‌سازند. متن‌های پروژه‌ها می‌تواند با زبان‌ها، فرهنگ‌ها، جغرافیاها و مناطق زمانی زیادی باشد. مدل ارتباط نوشتاری رساندن لحن و حالت مشارکت‌کننده‌های یک پروژه را مشکل می‌کند. اما نیت خیر تمام این گفتگوها را در نظر داشته باشید. خوب است که ایده‌ی خود را مودبانه منتقل کنید، متن و محتوای بیشتری درخواست کنید، یا موقعیت‌تان را روشن‌تر کنید. فقط سعی کنید اینترنت را از زمانی که وارد شدید، را جای بهتری کرده باشید ### Gathering context -Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. +قبل از اینکه کاری انجام دهید، به سرعت بررسی کنید و مطمئن شوید که ایده‌ی شما در هیج جای مورد بحث قرار نگرفته باشد. فایل README، مسائل حل‌شده یا حل‌نشده، لیست پست و گفتگوهای Stack را به طور سرسری مطالعه کنید. لازم نیست ساعت‌ها صرف خواندن آن‌ها کنید، اما جستجوی سریع درباره‌ی کلمات کلیدی می‌تواند تا حد زیادی به شما کمک کند -If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request: +اگر ایده‌ی شما در جای دیگری مطرح نشده بود، می‌توانید آن را بیان کنید. اگر پروژه در GitHub باشد، با باز کردن Issue یا درخواست ادغام Pull Request احتمالاً می‌توانید مکالمه داشته باشید: -* **Issues** are like starting a conversation or discussion -* **Pull requests** are for starting work on a solution -* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one +* **Issues** مانند شروع یک مکالمه یا گفتگو است +* **Pull Requests** برای کار روی راه‌حل است +* **سایر راه های ارتباطی راه‌های ارتباطی** مانند شفاف‌سازی، نحوه‌ی پرسیدن سوال (How-to question)، پرسیدن سوال در Stack، IRC، Slack یا دیگر کانال‌های چت است، البته اگر یک پروژه چنین راه‌های ارتباطی را باز گذاشته باشد. -Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. +قبل از باز کردن issue یا درخواست ادغام، اسناد مشارکت پروژه را بررسی کنید که معمولاً در فایل‌هایی به نام CONTRIBUTING یا README آورده شدند تا چیزهای خاصی که دنبالش هستید را مطالعه کنید. به عنوان مثال، آن‌ها ممکن است از شما درخواست کنند الگوها را پیروی کنید یا به این نیاز داشته باشند که از این تست‌ها استفاده کنند. -If 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. +اگر در یک پروژه مشارکت عمیق و اساسی داشته باشید، قبل از مشارکت در پروژه، یک issue باز کنید و سوال کنید. این کار مفید است و باعث می‌شود پروژه‌ی شما مدتی مشاهده شود. (در سایت GitHub می‌توانید [روی «Watch» کلیک کنید](https://help.github.com/articles/watching-repositories/) تا از تمام مکالمات مطلع شوید)، و قبل از انجام دادم کار که ممکن است پذیرفته نشود، اعضای انجمن را بشناسید. -### Opening an issue +### باز کردن Issue یا طرح سوال و گفتگو + +در موقعیت‌های زیر معمولاً باید یک issue باز کنید: + +* جهت گزارش خطایی که خودتان نمی‌توانید آن را حل کنید +* درباره‌ی موضوعات یا ایده‌ی سطح بالا بحث کنید (به عنوان مثال، درباره‎ی جامعه، دیدگاه یا سیاست‌ها) +* ویژگی جدید یا ایده‌ی جدیدی برای پروژه پیشنهاد دهید -You should usually open an issue in the following situations: +نکاتی برای برقراری ارتباط با مشکلات issues: -* Report an error you can't solve yourself -* Discuss a high-level topic or idea (for example, community, vision or policies) -* Propose a new feature or other project idea +* **اگر با مسئله‌ی بازی روبه‌رو شدید که می‌خواهید آن را برطرف کنید**، کامنت کردن برای یک مسئله به افراد اجازه می‌دهد بدانند که شما این مسئله را باز کردید. به این ترتیب، افراد احتمالاً کمتر با مشکلات مشابه‌ی شما برخورد می‌کنند +* **اگر یک issue مدتی پیش باز بوده است**، احتمال دارد جای دیگر به آن جواب داده شده باشد، یا قبلا حل شده است. بنابراین، قبل از شروع کار می‌توانید برای تایید حل شدن یا حل نشدن آن درخوست کامنت بدهید. +* **اگر یک issue باز کردید**، اما جواب آن را بعدها متوجه شدید، روی issue کامنت بگذارید تا مردم متوجه شوند، سپس issue را ببندید. حتی با نوشتن اسناد می‌تواند سهمی در مشارکت پروژه داشته باشید. -Tips for communicating on issues: +### ارسال Pull request (درخواست ادغام) -* **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. -* **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. -* **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. +شما معمولاً در موقیعت‌های زیر باید درخواست ادغام باز کنید: -### Opening a pull request +* ارائه اصلاحات ناچیز (به عنوان نمونه، غلط‌های املائی، لینک‌های خراب یا خطاهای مشهود) +* کار کردن روی مشارکتی که قبلا درخواست شده یا درباره‌ی آن بحث و گفتگو شده باشد -You should usually open a pull request in the following situations: +درخواست ادغام لزوماً به معنای پایان کار نیست. معمولاً بهتر است درخواست ادغام را قبلا باز کنید تا دیگران بتوانند آن را مشاهده و بازخوردهای خود را برای پیشرفت شما ارسال کنند. فقط آن را به «WIP» (کار در حال انجام) در کادر عنوان نشانه‌گذاری کنید. شما بعدها می‌توانید کامیت‌های بیشتری اضافه کنید. -* Submit trivial fixes (for example, a typo, a broken link or an obvious error) -* Start work on a contribution that was already asked for, or that you've already discussed, in an issue +اگر پروژه در GitHub باشد، با روش‌های زیر می‌توانید درخواست ادغام ارسال کنید: -A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later. +* **[Fork the repository](https://guides.github.com/activities/forking/)** و یک نسخه برای خودتان کپی کنید. نسخه محلی خود را به مخزن بالادستی متصل کنید. هر از چندگاهی با دستور Pull آخرین نسخه تغییرات در مخزن اصلی را دریافت کنید تا پیش از اینکه تعارضی ما بین نسخه محلی و مخزن ایجاد شد بتوانید با مشکلات احتمالی کمتری تغییرات خود را به سمت مخزن اصلی ارسال کنید. [برای کسب اطلاعات بیشتر اینجا را مرور کنید](https://help.github.com/articles/syncing-a-fork/) +* **[ایجاد یک شاخه](https://guides.github.com/introduction/flow/)** برای اعمال ویرایش ها. +* در حین ارسال ها **به مسائل (issue) مرتبط ارجاع دهید** یا در کامنت مربوط به تغییرات جدید به مستندات مربوطه اشاره کنید.(مثال: این تغییر مشکل مطرح شده در مسئله شماره 37 را برطرف می‌کند.) +* اگر تغییرات شما حاوی تفاوت‌های HTML/CSS باشد، **تصاویر مربوط به قبل و بعد آن را اضافه کنید**. تصاویر را وارد بدنه‌ی درخواست ادغام کنید و رها کنید. +* تغییرات‌تان را **تست کنید!** تغییرات خود را در برابر تست‌های موجود اجرا کنید و در صورت لزوم تغییرات جدیدی خلق کنید. اگر حتی تست‌هایی تعریف نشده بود، مطمئن شوید تغییرات‌تان پروژه‌ی موجود شما را خراب نکند. +* با تمام توانایی‌تان ** الگوها را رعایت کرده و مطابق سبک پروژه مشارکت کنید**. این توانایی می‌تواند به معنای استفاده از تورفتگی‌ها، نقطه ویرگول (semi-colons)، یا کامنت‌های متفاوتی باشد که شما در مخزن‌تان خودتان دارید. این کار ادغام مسئول‌نگهداری را ساده می‌کند، دیگران هم متوجه آن می‌شوند و می‌توانند آن را برای زمان‌های آتی حفظ کنند. -If the project is on GitHub, here's how to submit a pull request: +اگر این اولین درخواست ادغام شماست، فیلم آموزشی [Make a Pull Request](http://makeapullrequest.com/) که @kentcdodds آن را خلق کرده، بررسی کنید. شما همچنین می‌توانید از [Make a Pull Request](https://github.com/Roshanjossey/first-contributions) که توسط @Roshanjossey ایجاد شده به عنوان یک محزن تمرینی برای اولین تجربه خود استفاده کنید. -* **[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/).) -* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. -* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.") -* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. -* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project. -* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. +## بعد از ارسال درخواست مشارکت چه اتفاقی می‌افتد -If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. +شما درخواست‌تان را ارسال کردید! شروع مشارکت‌تان در یک پروژه‌ی متن باز را تبریک می‌گوییم. امیدواریم این اولین قدم‌تان باشد. -## What happens after you submit a contribution +بعد از ارسال درخواست مشارکت‌تان، یکی از اتفاقات زیر رخ می‌دهد: -You did it! Congratulations on becoming an open source contributor. We hope it's the first of many. +### 😭 جوابی دریافت نمی‌کنید. -After you submit a contribution, one of the following will happen: +امیدواریم قبل از ارسال درخواست مشارکت، [چک لیست فعالیت‌های پروژه](#a-checklist-before-you-contribute) را برررسی کرده باشید. هرچند، حتی در پروژه‌ی فعال هم این احتمال وجود دارد که به درخواست مشارکت شما پاسخ ندهند. -### 😭 You don't get a response. +اگر بیش از یک هفته جوابی برایتان ارسال نشد، به طور مودبانه می‌توانید درخواست جواب دهید و از کسی بخواهید درخواست شما را بررسی کند. اگر نام کسی که می‌خواهید درخواست شما را بررسی کند می‌دانید، می توانید به اون اشاره (منشن: با گذاشتن علامت @ در ابتدای نام کاربری) کنید. -Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. +به صورت خصوصی با آن شخص **تماس نگیرید**. به یاد داشته باشید ارتباط عمومی برای پروژه‌ها بسیار حیاتی است. -If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread. +اگر به طور مودبانه درخواست‌هایتان را فرستاده باشید اما هنوز هیچ‌کس پاسخگو نیست، احتمالاً هیچ‌کس هیچوقت پاسخ شما را نخواهد داد. می‌دانیم که حس خوبی ندارد، اما اجازه ندهید این موضوع شما را دلسرد کند چون این اتفاق ممکن است برای همه رخ دهد! -**Don't** reach out to that person privately; remember that public communication is vital to open source projects. +برای برطرف کردن این مشکل دلایل زیادی وجود دارد که به شما می‌گوید چرا پاسخ درخواست‌تان داده نمی‌شود؛ دلایلی مانند شرایط شخصی که ممکن است از کنترل خارج شود. شما می‌تواند پروژه‌ی دیگر یا راهی برای مشارکت پیدا کنید. قبل از اینکه اعضای یک انجمن متهد یا پاسخگو باشند، زمان زیادی را صرف ارسال درخواست مشارکت‌تان نکنید. -If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. +### 🚧 یک نفر برای تغییر درخواست‌تان به شما پیام می‌دهد. -### 🚧 Someone requests changes to your contribution. +مرسوم است کسی بخواهید درخواست مشارکت خود را تغییر دهید، این درخواست تغییر می‌تواند در بازخورد ایده‌ یا در تغییرات کد شما باشد. -It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. +اگر کسی درخواست تغییر برای‌تان ارسال کرد، پاسخگو باشید، چون آن‌ها برای بررسی درخواست مشارکت شما زمان گذاشتند. باز گذاشتن PR (درخواست ادغام) و نادیده گرفتن آن صورت خوبی ندارد. اگر نمی‌دانید چگونه روی درخواست‌تان آن تغییرات را اعمال کنید، مشکلات را جستجو کنید و در صورت نیاز از کسی کمک بخواهید. -When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. +اگر برای برطرف کردن مسائل پروژه دیگر زمان کافی ندارید (به عنوان نمونه، اگر مکالمه‌ی شما ماه‌ها طول کشید، و اکنون شرایط شما تغییر کند)، اجازه دهید مسئول‌نگهداری پروژه از این موضوع مطلع شود تا منتظر جواب شما نباشد. حتی کسی دیگری ممکن است جای شما را بگیرد. -If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over. -### 👎 Your contribution doesn't get accepted. +### 👎 درخواست مشارکت‌تان پذیرفته نشد -Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! +در پایان، درخواست مشارکت‌تان ممکن است پذیرفته شود یا نشود. هرچند، در صورت پذیرفته نشدن درخواست‌تان امیدواریم زمان زیادی روی آن صرف نکرده باشید. اگر مطمئن نیستید که چرا درخواست‌تان پذیرفته نشده، کاملاً معقولانه است که برای درخواست بازخورد و شفاف‌سازی از مسئول‌نگهداری جواب بخواهید. در نهایت، با احترام به تصمیم آن‌ها نباید خشمگین و عصبانی شوید. همیشه می‌توانید پروژه‌ی دیگری انتخاب کنید و اگر هم نمی‌خواهید در پروژه‌ای مشرکت کنید، می‌توانید پروژه‌ی خودتان را داشته باشید! -### 🎉 Your contribution gets accepted. +### 🎉 درخواست مشارکت شما پذیرفته شد. -Hooray! You've successfully made an open source contribution! +هوررا! درخواست مشارکت شما برای پروژه‌ی متن باز موفقیت‌آمیز بوده است -## You did it! +## انجامش دادی! -Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time. +خواه دنبال ارسال درخواست مشارکت خود برای اولین پروژه‌تان باشد، یا دنبال راه یک جدید برای مشارکت در یک پروژه‌ی متن باز باشید، امیدواریم انگیزه این کار را داشته باشید. حتی اگر درخواست‌تان هم پذیرفته نشد، فراموش نکنید از تلاش مسئول‌نگهداری پروژه تشکر کنید که تمام تلاش خود را برای کمک به شما گذاشت. پروژه‌های متن باز، مسائل، درخواست ادغام، کامنت توسط افرادی مانند شما تولید می‌شود. From 93a6a352b19c60492ec5154ffd3635f899f0a437 Mon Sep 17 00:00:00 2001 From: Nova Date: Tue, 20 Apr 2021 12:45:00 -0400 Subject: [PATCH 010/629] Fix broken links --- _articles/best-practices.md | 2 +- _articles/code-of-conduct.md | 2 +- _articles/finding-users.md | 2 +- _articles/getting-paid.md | 2 +- _articles/how-to-contribute.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/_articles/best-practices.md b/_articles/best-practices.md index c125b826beb..1d311457735 100644 --- a/_articles/best-practices.md +++ b/_articles/best-practices.md @@ -272,7 +272,7 @@ Just like any other type of work, taking regular breaks will keep you refreshed, avatar In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.

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

diff --git a/_articles/code-of-conduct.md b/_articles/code-of-conduct.md index 0b21e42d458..1ee5772d1cf 100644 --- a/_articles/code-of-conduct.md +++ b/_articles/code-of-conduct.md @@ -37,7 +37,7 @@ In addition to communicating your expectations, a code of conduct describes the Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. -The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples. +The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples. Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file. diff --git a/_articles/finding-users.md b/_articles/finding-users.md index 84ec4c6e7ca..79ac1bc37f3 100644 --- a/_articles/finding-users.md +++ b/_articles/finding-users.md @@ -116,7 +116,7 @@ As you write your talk, focus on what your audience will find interesting and ge avatar When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.

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

diff --git a/_articles/getting-paid.md b/_articles/getting-paid.md index 42d75af5b33..c150d731e57 100644 --- a/_articles/getting-paid.md +++ b/_articles/getting-paid.md @@ -140,7 +140,7 @@ Depending on your project, you may be able to charge for commercial support, hos * **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product * **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service -Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. +Some popular projects, like [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. ### Apply for grant funding diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md index 81158f6f25a..f3bcf0b445f 100644 --- a/_articles/how-to-contribute.md +++ b/_articles/how-to-contribute.md @@ -230,7 +230,7 @@ You can also use one of the following resources to help you discover and contrib * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### A checklist before you contribute From dedaed07d0eabea3ae3b11bbfbf0ae956eb95ffc Mon Sep 17 00:00:00 2001 From: Nova Date: Tue, 20 Apr 2021 14:57:45 -0400 Subject: [PATCH 011/629] Update links in translated versions --- _articles/de/best-practices.md | 2 +- _articles/de/code-of-conduct.md | 2 +- _articles/de/getting-paid.md | 2 +- _articles/de/how-to-contribute.md | 2 +- _articles/es/best-practices.md | 2 +- _articles/es/code-of-conduct.md | 2 +- _articles/es/getting-paid.md | 2 +- _articles/es/how-to-contribute.md | 2 +- _articles/fr/best-practices.md | 2 +- _articles/fr/code-of-conduct.md | 2 +- _articles/fr/getting-paid.md | 2 +- _articles/fr/how-to-contribute.md | 2 +- _articles/hu/best-practices.md | 2 +- _articles/hu/code-of-conduct.md | 2 +- _articles/hu/getting-paid.md | 2 +- _articles/hu/how-to-contribute.md | 2 +- _articles/id/best-practices.md | 2 +- _articles/id/code-of-conduct.md | 2 +- _articles/id/getting-paid.md | 2 +- _articles/id/how-to-contribute.md | 2 +- _articles/ja/best-practices.md | 2 +- _articles/ja/code-of-conduct.md | 2 +- _articles/ja/getting-paid.md | 2 +- _articles/ja/how-to-contribute.md | 2 +- _articles/ko/best-practices.md | 2 +- _articles/ko/code-of-conduct.md | 2 +- _articles/ko/getting-paid.md | 2 +- _articles/ko/how-to-contribute.md | 2 +- _articles/ms/best-practices.md | 2 +- _articles/ms/code-of-conduct.md | 2 +- _articles/ms/getting-paid.md | 2 +- _articles/ms/how-to-contribute.md | 2 +- _articles/nl/best-practices.md | 2 +- _articles/nl/code-of-conduct.md | 2 +- _articles/nl/getting-paid.md | 2 +- _articles/nl/how-to-contribute.md | 2 +- _articles/pl/best-practices.md | 2 +- _articles/pl/code-of-conduct.md | 2 +- _articles/pl/getting-paid.md | 2 +- _articles/pl/how-to-contribute.md | 2 +- _articles/pt/best-practices.md | 2 +- _articles/pt/code-of-conduct.md | 2 +- _articles/pt/getting-paid.md | 2 +- _articles/pt/how-to-contribute.md | 2 +- _articles/ro/best-practices.md | 2 +- _articles/ro/code-of-conduct.md | 2 +- _articles/ro/getting-paid.md | 2 +- _articles/ro/how-to-contribute.md | 2 +- _articles/ta/best-practices.md | 2 +- _articles/ta/code-of-conduct.md | 2 +- _articles/ta/getting-paid.md | 2 +- _articles/ta/how-to-contribute.md | 2 +- _articles/tr/best-practices.md | 2 +- _articles/tr/code-of-conduct.md | 2 +- _articles/tr/getting-paid.md | 2 +- _articles/tr/how-to-contribute.md | 2 +- _articles/zh-hans/best-practices.md | 2 +- _articles/zh-hans/code-of-conduct.md | 2 +- _articles/zh-hans/how-to-contribute.md | 2 +- _articles/zh-hant/best-practices.md | 2 +- _articles/zh-hant/code-of-conduct.md | 2 +- _articles/zh-hant/how-to-contribute.md | 2 +- 62 files changed, 62 insertions(+), 62 deletions(-) diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md index 10cc7bdd7fa..ce2a28b7e53 100644 --- a/_articles/de/best-practices.md +++ b/_articles/de/best-practices.md @@ -297,7 +297,7 @@ Genau wie bei jeder anderen Art von Arbeit, werden Sie durch regelmäßige Pause _In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important._

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

diff --git a/_articles/de/code-of-conduct.md b/_articles/de/code-of-conduct.md index 7a2c427c733..10d6bcfd834 100644 --- a/_articles/de/code-of-conduct.md +++ b/_articles/de/code-of-conduct.md @@ -31,7 +31,7 @@ Neben der Klarstellung Ihrer Erwartungen beschreibt ein Verhaltenskodex Folgende Wo immer Sie können, nutzen Sie Vorhandenes. Der [Contributor Covenant](https://contributor-covenant.org/) ist ein Verhaltenskodex, der von über 40.000 Open-Source-Projekten wie Kubernetes, Rails und Swift verwendet wird. -Der [Django-Verhaltenskodex](https://www.djangoproject.com/conduct/) und der [Citizen Code of Conduct](http://citizencodeofconduct.org/) sind ebenfalls zwei gute Beispiele. +Der [Django-Verhaltenskodex](https://www.djangoproject.com/conduct/) und der [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sind ebenfalls zwei gute Beispiele. Legen Sie eine CODE_OF_CONDUCT-Datei in das Stammverzeichnis Ihres Projekts und machen Sie sie für Ihre Community sichtbar, indem Sie sie von Ihrer CONTRIBUTING- oder README-Datei verlinken. diff --git a/_articles/de/getting-paid.md b/_articles/de/getting-paid.md index fb4a9413aba..13ac987f875 100644 --- a/_articles/de/getting-paid.md +++ b/_articles/de/getting-paid.md @@ -157,7 +157,7 @@ Abhängig von Ihrem Projekt können Sie kommerziellen Support, gehostete Optione * **[Travis CI](https://github.com/travis-ci)** bietet Bezahlversionen ihres Dienstes * **[Ghost](https://github.com/TryGhost/Ghost)** ist ein Non-Profit mit Bezahldiensten -Einige populäre Projekte, wie z.B. [npm](https://github.com/npm/npm) und [Docker](https://github.com/docker/docker), sammeln sogar Wagniskapital ein, um ihr Wachstum zu unterstützen. +Einige populäre Projekte, wie z.B. [npm](https://github.com/npm/cli) und [Docker](https://github.com/docker/docker), sammeln sogar Wagniskapital ein, um ihr Wachstum zu unterstützen. ### Fördermittel beantragen diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md index b94b7043554..32345204a77 100644 --- a/_articles/de/how-to-contribute.md +++ b/_articles/de/how-to-contribute.md @@ -245,7 +245,7 @@ Weiterhin, können Sie auf folgenden Seiten neue Projekte zum Beitragen entdecke * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Eine Checkliste, bevor Sie einen Beitrag leisten diff --git a/_articles/es/best-practices.md b/_articles/es/best-practices.md index 989e30a368b..fa24072845e 100644 --- a/_articles/es/best-practices.md +++ b/_articles/es/best-practices.md @@ -259,7 +259,7 @@ Al igual que cualquier otro tipo de trabajo, tomar pausas regulares te mantendr& avatar Durante el mantenimiento de WP-CLI, descubrí que tengo que preocuparme por mi felicidad primero, y establecer límites claros en mi participación. El mejor equilibrio que he encontrado es 2-5 horas por semana, como parte de mi horario de trabajo normal. Esto mantiene mi participación una pasión, y de sentirse demasiado como el trabajo. Como priorizo ​​las issues en las que estoy trabajando, puedo hacer progresos regulares en lo que creo que es lo más importante.

-— @danielbachhuber, ["Mis condolencias, ahora eres el mantenedor de un proyecto de código abierto popular"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["Mis condolencias, ahora eres el mantenedor de un proyecto de código abierto popular"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/es/code-of-conduct.md b/_articles/es/code-of-conduct.md index 291cdbe2e1d..78db3337d3d 100644 --- a/_articles/es/code-of-conduct.md +++ b/_articles/es/code-of-conduct.md @@ -31,7 +31,7 @@ Además de comunicar tus expectativas, un código de conducta descri Siempre que sea posible, haga uso del art. El [Contributor Covenant](https://www.contributor-covenant.org/) es un código de conducta usado por más de 40,000 proyectos de software libre, incluyendo Kubernetes, Rails, and Swift. -El [Django Code of Conduct](https://www.djangoproject.com/conduct/) y el [Citizen Code of Conduct](http://citizencodeofconduct.org/) son también dos ejemplos de buenos códigos de conducta. +El [Django Code of Conduct](https://www.djangoproject.com/conduct/) y el [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) son también dos ejemplos de buenos códigos de conducta. Ubica un archivo CODIGO_DE_CONDUCTA en el directorio raíz de tu proyecto, y enlázalo desde tu LEEME, así el mismo se encuentra visible a tu comunidad. diff --git a/_articles/es/getting-paid.md b/_articles/es/getting-paid.md index 873b8bc7d36..178d52ae81f 100644 --- a/_articles/es/getting-paid.md +++ b/_articles/es/getting-paid.md @@ -130,7 +130,7 @@ Dependiendo de tu proyecto, puede que seas capaz de cobrar por soporte comercial * **[Travis CI](https://github.com/travis-ci)** ofrece versiones pagas de su producto. * **[Ghost](https://github.com/TryGhost/Ghost)** es sin fines de lucro con una gestión de servicio paga. -Algunos proyectos populares, como [npm](https://github.com/npm/npm) y [Docker](https://github.com/docker/docker), generan capital de riesgo para soportar el crecimiento de su negocio. +Algunos proyectos populares, como [npm](https://github.com/npm/cli) y [Docker](https://github.com/docker/docker), generan capital de riesgo para soportar el crecimiento de su negocio. ### Suscríbete a subvenciones diff --git a/_articles/es/how-to-contribute.md b/_articles/es/how-to-contribute.md index 18e7d119845..92945d333d2 100644 --- a/_articles/es/how-to-contribute.md +++ b/_articles/es/how-to-contribute.md @@ -217,7 +217,7 @@ Puedes también utilizar algunos de los siguientes recursos para ayudarte * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Una lista de verificación antes de que contribuyas diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md index 25f17f923c6..fc37ddaefa8 100644 --- a/_articles/fr/best-practices.md +++ b/_articles/fr/best-practices.md @@ -261,7 +261,7 @@ Tout comme n'importe quel autre type de travail, prendre des pauses régulières avatar En maintenant le WP-CLI, j'ai découvert que je devais d'abord me rendre heureux et fixer des limites claires sur mon implication. Le meilleur équilibre que j'ai trouvé est de 2 à 5 heures par semaine, dans le cadre de mon horaire de travail normal. Cela maintient ma participation en tant que passion, sans le sentir trop comme du travail. Parce que je priorise les problèmes sur lesquels je travaille, je peux faire des progrès réguliers sur ce que je pense être le plus important.

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

diff --git a/_articles/fr/code-of-conduct.md b/_articles/fr/code-of-conduct.md index 4726143d822..31fd5c870db 100644 --- a/_articles/fr/code-of-conduct.md +++ b/_articles/fr/code-of-conduct.md @@ -31,7 +31,7 @@ En plus de communiquer vos attentes, un code de conduite décrit ce qui suit: Quand vous le pouvez, utilisez l'existant. Le [Contributor Covenant](https://contributor-covenant.org/) est un code de conduite qui est utilisé par plus de 40 000 projets open source, y compris Kubernetes, Rails et Swift. -Le [Django Code of Conduct](https://www.djangoproject.com/conduct/) et le [Citizen Code of Conduct](http://citizencodeofconduct.org/) sont également deux bons exemples de code de conduite. +Le [Django Code of Conduct](https://www.djangoproject.com/conduct/) et le [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sont également deux bons exemples de code de conduite. Placez un fichier CODE_OF_CONDUCT dans le répertoire racine de votre projet et rendez-le visible pour votre communauté en le liant à votre fichier CONTRIBUTING ou README. diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md index 05862fd61f8..a9aa8516c3c 100644 --- a/_articles/fr/getting-paid.md +++ b/_articles/fr/getting-paid.md @@ -130,7 +130,7 @@ En fonction de votre projet, vous pouvez facturer un support commercial, des opt * **[Travis CI](https://github.com/travis-ci)** offre des versions payantes de son produit * **[Ghost](https://github.com/TryGhost/Ghost)** est un organisme à but non lucratif avec un service géré payant -Certains projets populaires, tels que [npm](https://github.com/npm/npm) et [Docker](https://github.com/docker/docker), permettent même de lever du capital-risque pour soutenir la croissance de leur entreprise. +Certains projets populaires, tels que [npm](https://github.com/npm/cli) et [Docker](https://github.com/docker/docker), permettent même de lever du capital-risque pour soutenir la croissance de leur entreprise. ### Demande de financement diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md index 53f3cb81372..bd74af09175 100644 --- a/_articles/fr/how-to-contribute.md +++ b/_articles/fr/how-to-contribute.md @@ -217,7 +217,7 @@ Vous pouvez également utiliser l'une des ressources suivantes pour vous aider * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Une checklist avant de contribuer diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md index c98d032a749..4f0098594bd 100644 --- a/_articles/hu/best-practices.md +++ b/_articles/hu/best-practices.md @@ -265,7 +265,7 @@ Mint minden más munka esetén a rendszeres pihenők tartása felfrissít, boldo avatar A WP-CLI fenntartása során felfedeztem, hogy előbb boldoggá kell tennem magam, és egyértelmű határokat kell meghúznom. A legjobb egyensúlyt számomra a hetente 2-5 óra biztosította, a normál munkám részeként. Ez megőrzi a szenvedélyemet és nem érzem azt, hogy túl sokat dolgoztam volna. Mivel priorizálom a munkákat amelyeken dolgozom, így normálisan haladok a véleményem szerint legfontosabb dolgokkal.

-— @danielbachhuber, ["Fogadd részvétem, mert Te most egy népszerű, nyílt forráskódú projekt karbantartója lettél"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["Fogadd részvétem, mert Te most egy népszerű, nyílt forráskódú projekt karbantartója lettél"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/hu/code-of-conduct.md b/_articles/hu/code-of-conduct.md index b135eccca46..300fc1aaecc 100644 --- a/_articles/hu/code-of-conduct.md +++ b/_articles/hu/code-of-conduct.md @@ -31,7 +31,7 @@ Az elvárásaid mellett a magatartási kódex az alábbiakat írja még le: Lehetőség szerint használj már létező, publikus dokumentumot. A [Contributor Covenant](https://contributor-covenant.org/) egy azonnal használható magatartási kódex, amelyet már több mint 40,000 nyílt forráskódú projekt használ, mint például a Kubernetes, Rails, és a Swift. -A [Django Code of Conduct](https://www.djangoproject.com/conduct/) és a [Citizen Code of Conduct](http://citizencodeofconduct.org/) szintén nagyon jó minták. +A [Django Code of Conduct](https://www.djangoproject.com/conduct/) és a [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) szintén nagyon jó minták. Helyezd el a CODE_OF_CONDUCT állomány a projekt gyökérkönyvtárában, és hivatkozd meg őket a CONTRIBUTING és README állományokból, hogy mindenkinek látható legyen. diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md index 6a5af345930..ea0ac67f4d0 100644 --- a/_articles/hu/getting-paid.md +++ b/_articles/hu/getting-paid.md @@ -136,7 +136,7 @@ A projektedtől függően kérhetsz támogatást szupportért, új funkcióért, * **[Travis CI](https://github.com/travis-ci)** kínál fizetős verziót privát használatra * **[Ghost](https://github.com/TryGhost/Ghost)** alapvetően non-profit, de a felügyelt szolgáltatásért fizetni kell -Néhány híres projekt, mint az [npm](https://github.com/npm/npm) és a [Docker](https://github.com/docker/docker), még kockázati tőkét is bevontak a növekedés finanszírozásához. +Néhány híres projekt, mint az [npm](https://github.com/npm/cli) és a [Docker](https://github.com/docker/docker), még kockázati tőkét is bevontak a növekedés finanszírozásához. ### Jelentkezz pályázatokra diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md index 8c882058d7f..899a77272d0 100644 --- a/_articles/hu/how-to-contribute.md +++ b/_articles/hu/how-to-contribute.md @@ -220,7 +220,7 @@ Az alábbiakban találsz néhány oldalt, amelyek segítenek abban, hogy felfede * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Egy ellenőrző lista, mielőtt részt vennél a projektben diff --git a/_articles/id/best-practices.md b/_articles/id/best-practices.md index 778a6100c7c..73a4b0e9ea1 100644 --- a/_articles/id/best-practices.md +++ b/_articles/id/best-practices.md @@ -259,7 +259,7 @@ Sama halnya seperti pekerjaan lainnya, mengambil liburan secara berkala akan mem avatar Dalam mengelola WP-CLI, Saya menemukan bahwa saya perlu membuat diri saya bahagia terlebih dahulu, dan menentukan batas keterlibatan saya dengan jelas. Keseimbangan terbaik yang saya temukan adalah 2-5 jam per minggu sebagai bagian dari jadwal pekerjaan normal saya. Hal ini menjaga keterlibatan saya sebagai sebuah gairah. Karena saya memprioritaskan masalah-masalah yang saya kerjakan, saya bisa membuat kemajuan berkala tentang apa yang saya anggap penting.

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

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

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

diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md index 26a4dbf6b7c..ba6a7bb6f98 100644 --- a/_articles/ja/code-of-conduct.md +++ b/_articles/ja/code-of-conduct.md @@ -31,7 +31,7 @@ related: できる限り、既存の行動規範を使いましょう。 [Contributor Covenant](https://contributor-covenant.org/) は40,000以上のオープンソースプロジェクトで使われている行動規範で、 Kubernetes 、 Rails 、 Swift でも使われています。 -[Django Code of Conduct](https://www.djangoproject.com/conduct/) や [Citizen Code of Conduct](http://citizencodeofconduct.org/) の2つもよく使われる行動規範です。 +[Django Code of Conduct](https://www.djangoproject.com/conduct/) や [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) の2つもよく使われる行動規範です。 CODE_OF_CONDUCT ファイルをプロジェクトのルートディレクトリに置き、 CONTRIBUTING や README ファイルからリンクを張ってコミュニティの皆がすぐに見れるようにしましょう。 diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md index 225eb1340d1..78873974081 100644 --- a/_articles/ja/getting-paid.md +++ b/_articles/ja/getting-paid.md @@ -134,7 +134,7 @@ related: * **[Travis CI](https://github.com/travis-ci)** は、製品の有償版を提供しています。 * **[Ghost](https://github.com/TryGhost/Ghost)** は、有償のマネージドサービスを提供する非営利サービスです。 -[npm](https://github.com/npm/npm) や [Docker](https://github.com/docker/docker) のような有名なプロジェクトでは、ビジネスの成長を支えるためにベンチャーキャピタルから資金調達をしています。 +[npm](https://github.com/npm/cli) や [Docker](https://github.com/docker/docker) のような有名なプロジェクトでは、ビジネスの成長を支えるためにベンチャーキャピタルから資金調達をしています。 ### 助成金に応募する diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md index 43923ef4afc..1cfd6d87701 100644 --- a/_articles/ja/how-to-contribute.md +++ b/_articles/ja/how-to-contribute.md @@ -217,7 +217,7 @@ README を読んで、壊れたリンクやタイポを見つけるかもしれ * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### コントリビュートする前のチェックリスト diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md index 6ed20b13a3a..2295389f32f 100644 --- a/_articles/ko/best-practices.md +++ b/_articles/ko/best-practices.md @@ -261,7 +261,7 @@ GitHub에서는 버그 제보나 기타 평범한 기여에 사용할 [이슈 avatar In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.

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

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

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

diff --git a/_articles/ms/code-of-conduct.md b/_articles/ms/code-of-conduct.md index bb04a2b1996..fc1e3a051fa 100644 --- a/_articles/ms/code-of-conduct.md +++ b/_articles/ms/code-of-conduct.md @@ -37,7 +37,7 @@ Selain menyampaikan harapan anda, kod tingkah laku menerangkan perkara berikut: Di mana sahaja anda boleh, gunakan seni sebelumnya. [Contributor Covenant](https://contributor-covenant.org/) adalah tatakelakuan drop-in yang digunakan oleh lebih dari 40,000 projek sumber terbuka, termasuk Kubernetes, Rails, dan Swift. -[Django Code of Conduct](https://www.djangoproject.com/conduct/) dan [Citizen Code of Conduct](http://citizencodeofconduct.org/) juga merupakan dua contoh tatakelakuan yang baik. +[Django Code of Conduct](https://www.djangoproject.com/conduct/) dan [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) juga merupakan dua contoh tatakelakuan yang baik. Letakkan fail CODE_OF_CONDUCT di direktori root projek anda, dan jadikan ia dapat dilihat oleh komuniti anda dengan menghubungkannya dari fail CONTRIBUTING atau README anda. diff --git a/_articles/ms/getting-paid.md b/_articles/ms/getting-paid.md index f9c2c3396d9..0a501476712 100644 --- a/_articles/ms/getting-paid.md +++ b/_articles/ms/getting-paid.md @@ -140,7 +140,7 @@ Bergantung pada projek anda, anda mungkin dapat mengenakan bayaran untuk sokonga * **[Travis CI](https://github.com/travis-ci)** menawarkan versi berbayar produknya * **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service -Beberapa projek popular, seperti [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker),malah mengumpulkan modal teroka untuk menyokong pertumbuhan perniagaan mereka. +Beberapa projek popular, seperti [npm](https://github.com/npm/cli) and [Docker](https://github.com/docker/docker),malah mengumpulkan modal teroka untuk menyokong pertumbuhan perniagaan mereka. ### Memohon pembiayaan geran diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md index 55cd3025be8..b50c6906bc5 100644 --- a/_articles/ms/how-to-contribute.md +++ b/_articles/ms/how-to-contribute.md @@ -230,7 +230,7 @@ Anda juga boleh menggunakan salah satu sumber berikut untuk membantu anda menemu * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Senarai semak sebelum anda menyumbang diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md index be4fd139e47..c583c50dcc4 100644 --- a/_articles/nl/best-practices.md +++ b/_articles/nl/best-practices.md @@ -288,7 +288,7 @@ Net als bij elk ander soort werk, zal het nemen van regelmatige pauzes je verfri _In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important._

-— @danielbachhuber, ["Mijn condoleances, u bent nu de onderhouder (_maintainer_) van een populair open source-project"](https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["Mijn condoleances, u bent nu de onderhouder (_maintainer_) van een populair open source-project"](https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

diff --git a/_articles/nl/code-of-conduct.md b/_articles/nl/code-of-conduct.md index d59157706bf..f77c2c91613 100644 --- a/_articles/nl/code-of-conduct.md +++ b/_articles/nl/code-of-conduct.md @@ -37,7 +37,7 @@ In addition to communicating your expectations, a code of conduct describes the Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. -The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples. +The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) are also two good code of conduct examples. Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file. diff --git a/_articles/nl/getting-paid.md b/_articles/nl/getting-paid.md index ae05b842255..7cc2851eff0 100644 --- a/_articles/nl/getting-paid.md +++ b/_articles/nl/getting-paid.md @@ -158,7 +158,7 @@ Afhankelijk van uw project kunt u mogelijk kosten in rekening brengen voor comme * **[Travis CI](https://github.com/travis-ci)** biedt betaalde versies van zijn product * **[Ghost](https://github.com/TryGhost/Ghost)** is een non-profitorganisatie met een betaalde beheerde service -Sommige populaire projecten, zoals [npm](https://github.com/npm/npm) en [Docker](https://github.com/docker/docker), halen zelfs risicokapitaal op om de groei van hun bedrijf te ondersteunen. +Sommige populaire projecten, zoals [npm](https://github.com/npm/cli) en [Docker](https://github.com/docker/docker), halen zelfs risicokapitaal op om de groei van hun bedrijf te ondersteunen. ### Subsidie ​​aanvragen diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md index dc7ee302cab..9b57e9aefa4 100644 --- a/_articles/nl/how-to-contribute.md +++ b/_articles/nl/how-to-contribute.md @@ -241,7 +241,7 @@ U kunt ook een van de volgende bronnen gebruiken om u te helpen bij het ontdekke * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Een checklist voordat u bijdraagt diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md index 0049bc18bbd..3fed2f2d00f 100644 --- a/_articles/pl/best-practices.md +++ b/_articles/pl/best-practices.md @@ -271,7 +271,7 @@ Podobnie jak w przypadku każdego innego rodzaju pracy, regularne przerwy sprawi In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.

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

diff --git a/_articles/pl/code-of-conduct.md b/_articles/pl/code-of-conduct.md index 3e39fbf0d6b..1a2d7a1ef2f 100644 --- a/_articles/pl/code-of-conduct.md +++ b/_articles/pl/code-of-conduct.md @@ -31,7 +31,7 @@ Oprócz przekazywania swoich oczekiwań kodeks postępowania opisuje następują Gdziekolwiek możesz, skorzystaj ze stanu techniki. [Przymierze współautorów](https://contributor-covenant.org/) to rozwijany kodeks postępowania używany przez ponad 40 000 projektów open source, w tym Kubernetes, Rails i Swift. -[Kodeks postępowania Django](https://www.djangoproject.com/conduct/) oraz [Kodeks postępowania obywatelskiego](http://citizencodeofconduct.org/) to także dwa przykłady dobrego kodeksu postępowania. +[Kodeks postępowania Django](https://www.djangoproject.com/conduct/) oraz [Kodeks postępowania obywatelskiego](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) to także dwa przykłady dobrego kodeksu postępowania. Umieść plik CODE_OF_CONDUCT w katalogu głównym projektu i uczyń go widocznym dla społeczności, łącząc go z plikiem CONTRIBUTING lub README. diff --git a/_articles/pl/getting-paid.md b/_articles/pl/getting-paid.md index d5449946bd9..32a1ea63766 100644 --- a/_articles/pl/getting-paid.md +++ b/_articles/pl/getting-paid.md @@ -147,7 +147,7 @@ W zależności od projektu możesz być w stanie pobierać opłaty za wsparcie k * **[Travis CI](https://github.com/travis-ci)** oferuje płatne wersje swojego produktu * **[Ghost](https://github.com/TryGhost/Ghost)** jest organizacją non-profit z płatną usługą zarządzaną -Niektóre popularne projekty, takie jak [npm](https://github.com/npm/npm) oraz [Docker](https://github.com/docker/docker), nawet pozyskały kapitał wysokiego ryzyka w celu wsparcia rozwoju ich działalności. +Niektóre popularne projekty, takie jak [npm](https://github.com/npm/cli) oraz [Docker](https://github.com/docker/docker), nawet pozyskały kapitał wysokiego ryzyka w celu wsparcia rozwoju ich działalności. ### Złóż wniosek o dofinansowanie diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md index 3159d01da87..169f1f50112 100644 --- a/_articles/pl/how-to-contribute.md +++ b/_articles/pl/how-to-contribute.md @@ -233,7 +233,7 @@ Możesz także skorzystać z jednego z następujących zasobów, aby pomóc Ci o * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Lista kontrolna przed wniesieniem wkładu diff --git a/_articles/pt/best-practices.md b/_articles/pt/best-practices.md index 8a26836b6a2..076c3377cb7 100644 --- a/_articles/pt/best-practices.md +++ b/_articles/pt/best-practices.md @@ -261,7 +261,7 @@ Assim como qualquer outro tipo de trabalho, fazer pausas regulares manterão voc avatar Na manutenção do WP-CLI, descobri que preciso me tornar feliz primeiro e estabelecer limites claros sobre meu envolvimento. O melhor equilíbrio que encontrei é 2-5 horas por semana, como parte de meu horário normal de trabalho. Isso mantém meu envolvimento uma paixão, e longe de me sentir como se estivesse no trabalho. Devido a priorização dos problemas que estou trabalhando, posso fazer progressos regulares naquilo que penso ser mais importante.

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

diff --git a/_articles/pt/code-of-conduct.md b/_articles/pt/code-of-conduct.md index 00d4f305288..dc8554899da 100644 --- a/_articles/pt/code-of-conduct.md +++ b/_articles/pt/code-of-conduct.md @@ -31,7 +31,7 @@ Além de comunicar aquilo que você espera, um código de conduta descreve o seg Sempre que possível, use exemplos passados. O [Contributor Covenant](https://contributor-covenant.org/) é um código de conduta que é usado por mais de 40.000 projetos _open source_, incluindo Kubernetes, Rails, e Swift. -O [Django Code of Conduct](https://www.djangoproject.com/conduct/) e o [Citizen Code of Conduct](http://citizencodeofconduct.org/) são, tambémm, outros dois bons exemplos de códigos de conduta. +O [Django Code of Conduct](https://www.djangoproject.com/conduct/) e o [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) são, tambémm, outros dois bons exemplos de códigos de conduta. Coloque um arquivo CODE_OF_CONDUCT no diretório raiz do seu projeto, e faça-o visivel a sua comunidade criando um link para ele no arquivo CONTRIBUTING ou README. diff --git a/_articles/pt/getting-paid.md b/_articles/pt/getting-paid.md index 99df7d76e4e..057948160d4 100644 --- a/_articles/pt/getting-paid.md +++ b/_articles/pt/getting-paid.md @@ -135,7 +135,7 @@ Dependendo do seu projeto, você pode ser capaz de cobrar por suporte comercial, * **[Travis CI](https://github.com/travis-ci)** oferece versões pagas de seu produto * **[Ghost](https://github.com/TryGhost/Ghost)** é uma organização sem fins lucrativos, com um serviço gerenciado pago -Alguns projetos populares, como o [npm](https://github.com/npm/npm) e o [Docker](https://github.com/docker/docker), conseguem até mesmo capital de risco para dar suporte ao crescimento de seu negócio. +Alguns projetos populares, como o [npm](https://github.com/npm/cli) e o [Docker](https://github.com/docker/docker), conseguem até mesmo capital de risco para dar suporte ao crescimento de seu negócio. ### Solicite financiamento de subsídio diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md index 8d1cb746236..f1c4ffd678b 100644 --- a/_articles/pt/how-to-contribute.md +++ b/_articles/pt/how-to-contribute.md @@ -217,7 +217,7 @@ Você também pode usar um dos seguintes recursos para ajudá-lo a descobrir e c * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Um checklist antes de você contribuir diff --git a/_articles/ro/best-practices.md b/_articles/ro/best-practices.md index 3cca2c80edf..97da1e968b6 100644 --- a/_articles/ro/best-practices.md +++ b/_articles/ro/best-practices.md @@ -323,7 +323,7 @@ Exact la fel ca oricare alt fel de muncă, luarea de pauze dese te va păstra re

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

diff --git a/_articles/ro/code-of-conduct.md b/_articles/ro/code-of-conduct.md index 408c7c90fdf..75202870517 100644 --- a/_articles/ro/code-of-conduct.md +++ b/_articles/ro/code-of-conduct.md @@ -37,7 +37,7 @@ Pe lângă comunicarea așteptărilor tale, un cod de conduită descrie următoa Oricând poți, folosește stadiul cunoscut al tehnicii. [Contributor Covenant](https://contributor-covenant.org/) este un cod de conduită ușor de instalat care este folosit de peste 40.000 de proiecte cu sursă deschisă, inclusiv Kubernetes, Rails, și Swift. -[Codul de conduită Django](https://www.djangoproject.com/conduct/) și [Citizen Code of Conduct](http://citizencodeofconduct.org/) sunt de asemenea două exemple bune de coduri de conduită. +[Codul de conduită Django](https://www.djangoproject.com/conduct/) și [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) sunt de asemenea două exemple bune de coduri de conduită. Amplasează un fișier CODE_OF_CONDUCT în directorul rădăcină al proiectului tău, și fă-l vizibil pentru comunitatea ta legând către el din fișierele tale CONTRIBUTING sau README. diff --git a/_articles/ro/getting-paid.md b/_articles/ro/getting-paid.md index d8443f20472..f27918d87b3 100644 --- a/_articles/ro/getting-paid.md +++ b/_articles/ro/getting-paid.md @@ -184,7 +184,7 @@ Depinzând de proiectul tău, ai putea să taxezi sprijin comercial, opțiuni de * **[Travis CI](https://github.com/travis-ci)** oferă versiuni plătite ale produsului său * **[Ghost](https://github.com/TryGhost/Ghost)** este un nonprofit cu un serviciu gestionat plătit -Unele proiecte populare, cum ar fi [npm](https://github.com/npm/npm) și [Docker](https://github.com/docker/docker), chiar strâng capital de risc pentru a susține creșterea afacerii lor. +Unele proiecte populare, cum ar fi [npm](https://github.com/npm/cli) și [Docker](https://github.com/docker/docker), chiar strâng capital de risc pentru a susține creșterea afacerii lor. ### Aplicați pentru finanțare nerambursabilă diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md index 7a52bde8b7f..27e6ea50206 100644 --- a/_articles/ro/how-to-contribute.md +++ b/_articles/ro/how-to-contribute.md @@ -261,7 +261,7 @@ Poți de asemenea folosi una dintre următoarele resurse pentru a te ajuta să d * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### O listă de verificare înainte de a contribui diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md index 1bed55f9bbf..d658f1f89c9 100644 --- a/_articles/ta/best-practices.md +++ b/_articles/ta/best-practices.md @@ -261,7 +261,7 @@ related: avatar WP-CLI ஐ பராமரிப்பதில், முதலில் நான் மகிழ்ச்சியடைந்தேன், என் ஈடுபாட்டின் மீது தெளிவான எல்லைகளை அமைத்தேன். என் சாதாரண பணி அட்டவணையின் ஒரு பகுதியாக, வாரத்திற்கு 2-5 மணிநேரத்தை நான் கண்டிருக்கிறேன். இது என் ஈடுபாடு ஒரு உணர்வு, மற்றும் மிகவும் வேலை உணர்கிறேன் இருந்து வைத்திருக்கிறது. நான் பணிபுரியும் பிரச்சினைகளுக்கு முன்னுரிமை அளிப்பதால், மிக முக்கியமானது என்னவென்று நான் நினைக்கிறேன். நான் பணிபுரியும் பிரச்சினைகளுக்கு முன்னுரிமை அளிப்பதால், நான் மிகவும் முக்கியம் என நினைப்பதில் நான் தொடர்ந்து முன்னேற்றம் செய்ய முடிகிறது.

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

diff --git a/_articles/ta/code-of-conduct.md b/_articles/ta/code-of-conduct.md index 8b8f8c1b78c..33a8c45ff23 100644 --- a/_articles/ta/code-of-conduct.md +++ b/_articles/ta/code-of-conduct.md @@ -31,7 +31,7 @@ related: நீங்கள் எங்கு வேண்டுமானாலும், முந்தைய உபாயத்தை பயன்படுத்தவும். [பங்களிப்பாளரின் உடன்படிக்கை](https://contributor-covenant.org/) என்பது ஒரு நடத்தை விதியாகும், இது குபெர்னீஸ், ரெயில்ஸ் மற்றும் ஸ்விஃப்ட் உள்ளிட்ட 40,000 திறந்த மூல திட்டங்களில் பயன்படுத்தப்படுகிறது. -[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும். +[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும். உங்கள் திட்டத்தின் மூலம் கோப்பகத்தில் CODE_OF_CONDUCT கோப்பை வைக்கவும், மேலும் உங்கள் CONTRIBUTING அல்லது README கோப்பில் இருந்து அதை இணைப்பதன் மூலம் அதை உங்கள் சமூகத்திற்குத் தெரியப்படுத்தவும். diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md index e1f8322e338..29a2861e9eb 100644 --- a/_articles/ta/getting-paid.md +++ b/_articles/ta/getting-paid.md @@ -130,7 +130,7 @@ related: * **[டிராவிஸ் சிஐ](https://github.com/travis-ci)** அதன் தயாரிப்பின் கட்டண பதிப்புகள் வழங்குகிறது * **[கோஸ்ட்](https://github.com/TryGhost/Ghost)** ஒரு இலாப நோக்கமற்றத பணம் செலுத்திய நிர்வகிக்கப்பட்ட சேவை -[என்பிஎம்](https://github.com/npm/npm) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன. +[என்பிஎம்](https://github.com/npm/cli) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன. ### மானிய நிதிக்கு விண்ணப்பிக்கவும் diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md index c27a34f7070..774154464c5 100644 --- a/_articles/ta/how-to-contribute.md +++ b/_articles/ta/how-to-contribute.md @@ -217,7 +217,7 @@ related: * [Up For Grabs](https://up-for-grabs.net/) * [பங்களிப்பாளர்-நிஞ்ஜா](https://contributor.ninja) * [முதல் பங்களிப்புகள்](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### பங்களிக்கும் முன் ஒரு சரிபார்ப்புப் பட்டியல் diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md index 5427fe39a07..3a264e8373a 100644 --- a/_articles/tr/best-practices.md +++ b/_articles/tr/best-practices.md @@ -272,7 +272,7 @@ Tıpkı diğer tüm işlerde olduğu gibi, düzenli molalar vermek de işinizi y avatar WP-CLI’yı geliştirirken, önce kendimi mutlu etmem gerektiğini ve katılımım konusunda net sınırlar koymam gerektiğini keşfettim. Bulduğum en iyi denge, normal çalışma programımın bir parçası olarak haftada 2-5 saat. Bu benim katılımımı bir tutku olarak kalmasını sağlıyor ve iş gibi hissetmekten koruyor. Üzerinde çalıştığım konulara öncelik verdiğim için, en önemli olduğunu düşündüğüm konuda düzenli ilerleme sağlayabiliyorum.

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

diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md index 571fd442f74..afc8f06f843 100644 --- a/_articles/tr/code-of-conduct.md +++ b/_articles/tr/code-of-conduct.md @@ -37,7 +37,7 @@ Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdak Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir. -[Django Davranış Kuralları](https://www.djangoproject.com/conduct/) ve [Vatandaş Davranış Kuralları](http://citizencodeofconduct.org/) da aynı zamanda iki iyi davranış kural listesi örneğidir. +[Django Davranış Kuralları](https://www.djangoproject.com/conduct/) ve [Vatandaş Davranış Kuralları](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) da aynı zamanda iki iyi davranış kural listesi örneğidir. CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTING veya README dosyanızdan bağlantılayarak topluluğunuz tarafından görülebilir hale getirin. diff --git a/_articles/tr/getting-paid.md b/_articles/tr/getting-paid.md index aad2f945d62..eb0cbd47221 100644 --- a/_articles/tr/getting-paid.md +++ b/_articles/tr/getting-paid.md @@ -139,7 +139,7 @@ Projenize bağlı olarak, ticari destek, barındırılan seçenekler veya ek öz * **[Travis CI](https://github.com/travis-ci)** ürünlerinin ücretli sürümlerini sunuyor * **[Ghost](https://github.com/TryGhost/Ghost)** ücretli bir yönetim servisi olan kar amacı gütmeyen bir kurumdur. -[Npm](https://github.com/npm/npm) ve [Docker](https://github.com/docker/docker) gibi bazı popüler projeler iş büyümelerini desteklemek için risk sermayesini desteği arıyorlar. +[Npm](https://github.com/npm/cli) ve [Docker](https://github.com/docker/docker) gibi bazı popüler projeler iş büyümelerini desteklemek için risk sermayesini desteği arıyorlar. ### Hibe fonu için başvur diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index e7b2934ae27..142b1f03e22 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -230,7 +230,7 @@ Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aş * [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) * [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi diff --git a/_articles/zh-hans/best-practices.md b/_articles/zh-hans/best-practices.md index fd8452e4267..c19caffa01a 100644 --- a/_articles/zh-hans/best-practices.md +++ b/_articles/zh-hans/best-practices.md @@ -255,7 +255,7 @@ fork 一个项目不什么坏事情。能复制并且修改别人的代码是开 avatar 我是 WP-CLI 的维护者，我发现我需要首先让自己开心，在开源项目和其他事情之间设定清楚的界限。我发现最好的平衡点就是每周在日常的工作安排中花 2-5 小时在这上面。这会让我从感觉太累到保持持续的激情。因为我给我需要解决的 issue 标上了优先级，从而我能够在我认为重要的事情上有所进展。

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

diff --git a/_articles/zh-hans/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md index bdb8c7dc97c..6e2dcf9716d 100644 --- a/_articles/zh-hans/code-of-conduct.md +++ b/_articles/zh-hans/code-of-conduct.md @@ -32,7 +32,7 @@ redirect_from: /zh-cn/code-of-conduct/ 无论你们在哪里，请使用已有的行为守则。[贡献者盟约](https://www.contributor-covenant.org/)是一个被超过40,000个开源项目（包括Kubernetes, Rails和Swift）所使用的行为守则。 -[Django行为守则](https://www.djangoproject.com/conduct/)和[Citizen行为守则](http://citizencodeofconduct.org/)都是非常好的行为守则。 +[Django行为守则](https://www.djangoproject.com/conduct/)和[Citizen行为守则](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)都是非常好的行为守则。 请将CODE_OF_CONDUCT文件放在你们项目的根目录，并在README中附上其链接，这样对你们的社区是可见的。 diff --git a/_articles/zh-hans/how-to-contribute.md b/_articles/zh-hans/how-to-contribute.md index 59d5093a133..239d3699336 100644 --- a/_articles/zh-hans/how-to-contribute.md +++ b/_articles/zh-hans/how-to-contribute.md @@ -218,7 +218,7 @@ redirect_from: /zh-cn/how-to-contribute/ * [Up For Grabs](https://up-for-grabs.net/) * [像忍者一样贡献](https://contributor.ninja) * [最初的贡献](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### 提交贡献之前的检查列表 diff --git a/_articles/zh-hant/best-practices.md b/_articles/zh-hant/best-practices.md index b0401a04f8e..1a3163e7092 100644 --- a/_articles/zh-hant/best-practices.md +++ b/_articles/zh-hant/best-practices.md @@ -255,7 +255,7 @@ fork一個專案不什麼壞事情。能複製並且修改別人的程式是開 avatar 我是WP-CLI的維護者，我發現我需要首先讓自己開心，在開源專案和其他事情之間設定清楚的界限。我發現最好的平衡點就是每週在日常的工作安排中花2-5小時在這上面。這會讓我從感覺太累到保持持續的激情。因爲我給我需要解決的issue表上了優先級，從而我能夠在我認爲重要的事情上有所進展。

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

diff --git a/_articles/zh-hant/code-of-conduct.md b/_articles/zh-hant/code-of-conduct.md index 10649a5de71..fd0dfc14ea0 100644 --- a/_articles/zh-hant/code-of-conduct.md +++ b/_articles/zh-hant/code-of-conduct.md @@ -32,7 +32,7 @@ redirect_from: /zh-tw/code-of-conduct/ 無論你們在哪裏，請使用已有的行爲守則。[貢獻者盟約](http://contributor-covenant.org/)是一個被超過40，000個開源專案（包括Kubernetes, Rails和Swift）所使用的行爲守則。 -[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](http://citizencodeofconduct.org/)都是非常好的行爲守則。 +[Django行爲守則](https://www.djangoproject.com/conduct/)和[Citizen行爲守則](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/)都是非常好的行爲守則。 請將CODE_OF_CONDUCT文件放在你們專案的根目錄，並在README中附上其鏈接，這樣對你們的社群是可見的。 diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md index 32d16ac5969..c6eb5d96d90 100644 --- a/_articles/zh-hant/how-to-contribute.md +++ b/_articles/zh-hant/how-to-contribute.md @@ -218,7 +218,7 @@ redirect_from: /zh-tw/how-to-contribute/ * [Up For Grabs](http://up-for-grabs.net/) * [貢獻忍者](https://contributor.ninja) * [最初的贡献](https://firstcontributions.github.io) -* [SourceSort](https://www.sourcesort.com/) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### **提交貢獻前應做的檢查清單** From d4b7f76dcef991b7b23dd6413de73cc8742d6819 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Sun, 25 Apr 2021 21:35:04 +0430 Subject: [PATCH 012/629] Initial translation done. --- _articles/fa/getting-paid.md | 160 +++++++++++++++++------------------ 1 file changed, 78 insertions(+), 82 deletions(-) diff --git a/_articles/fa/getting-paid.md b/_articles/fa/getting-paid.md index 42d75af5b33..ddb05d87f00 100644 --- a/_articles/fa/getting-paid.md +++ b/_articles/fa/getting-paid.md @@ -1,13 +1,8 @@ --- -lang: en -title: Getting Paid for Open Source Work -description: Sustain your work in open source by getting financial support for your time or your project. +lang: fa +title: گرفتن دستمزد برای کارهای متن باز +description: با دریافت پشتیبانی‌های مالی در ازای زمانی که می‌گذارید یا به خاطر پروژه‌ای که پیش می‌برید، کار متن باز خود را حمایت کنید. class: getting-paid -toc: - why-some-people-seek-financial-support: "Why some people seek financial support" - funding-your-own-time: "Funding your own time" - finding-funding-for-your-project: "Finding funding for your project" - building-a-case-for-financial-support: "Building a case for financial support" order: 7 image: /assets/images/cards/getting-paid.png related: @@ -15,178 +10,179 @@ related: - leadership --- -## Why some people seek financial support +## چرا برخی افراد به دنبال پشتیبانی‌های‌ مالی هستند -Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. +بیشتر کارهای متن باز داوطلبانه است. به عنوان مثال، کسی ممکن است در پروژه‌ای که از آن استفاده می‌کند با ایرادی (باگ) روبرو شود و راه‌حلی آسان برای ایراد ارائه کند، یا ممکن است کسی در اوقات فراغت خود از دستکاری در پروژه‌ی متن باز لذت ببرد. -There are many reasons why a person would not want to be paid for their open source work. +دلایل زیادی برای مایل نبودن شخص برای دریافت دستمزد در ازای کار متن باز خود، وجود دارد. -* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time. -* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects. -* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community. +* ممکن است از قبل، **کار تمام وقت مورد علاقه‌ی خود را داشته باشند** که به آن‌ها این امکان را می‌دهد تا در اوقات فراغت خود در کارهای متن باز مشارکت داشته باشند. +* آن‌ها از تصور کردن کارهای متن باز **به عنوان یک سرگرمی یا فرآیندی خلاقانه لذت می‌برند** و نمی‌خواهند از نظر مالی ملزم به کار در پروژه‌های خود باشند. +* آن‌ها از طریق مشارکت در کارهای متن باز **از مزایای دیگری برخوردار می‌شوند**، همچون ایجاد نمونه‌کار یا شهرت و اعتباری برای خود، یادگیری مهارت جدید یا احساس نزدیک‌تر بودن و صمیمیت بیشتر با اجتماع. -For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons. +برای دیگران، به ویژه هنگامی که مشارکت‌ها باید ادامه بیابد و یا به زمان قابل توجهی نیاز داشته باشد؛ اگر پروژه به آن‌ها نیاز داشته باشد یا به دلایل شخصی باید به کار ادامه دهند، پرداخت دستمزد برای مشارکت در کار متن باز، تنها راه برای مشارکت است. + +حفظ پروژه‌های پرطرفدار، می‌تواند مسئولیت سنگینی را بر روی دوش افراد بگذارد، می‌تواند بجای چند ساعت در ماه 10 یا 20 ساعت در هفته را به خود اختصاص دهد. -Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month. -Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community. +همچنین کارهای با دستمزد، این امکان برای افراد از اقشار مختلف جامعه را فراهم می‌آورد تا مشارکت‌های قابل‌توجه و معناداری انجام دهند. برخی از افراد، به سبب وضعیت مالی کنونی‌شان، بدهی یا خانواده یا سایر تعهدات، امکان مشارکت بدون دستمزد در پروژه‌های متن باز را ندارند. این بدان معناست که جهان هرگز مشارکت افراد مستعدی را که توانایی مالی برای مشارکت داوطلبانه را ندارند، نمی‌بیند. همانطور که @ashedryden [گفته است](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)، پیامدهایی اخلاقی در این میان وجود دارد، زیرا کسانی که از قبل در زندگی دارای مزایایی هستند، شانس بیشتری در کارهایی که انجام می‌شود دارند، درنتیجه بر اساس مشارکت‌های داوطلبانه‌ی خود مزایای بیشتری کسب می‌کنند، در حالی که سایر افرادی که قادر به داوطلب شدن نیستند، فرصت‌های آتی را از دست می‌دهند، که این عدم تنوع را در اجتماع کنونی (community) متن باز گسترش می‌دهد. -If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project. +اگر به دنبال حمایت‌های مالی هستید، دو راه وجود دارد. می‌توانید زمان مناسب را برای مشارکت پیدا کنید، یا می‌توانید بودجه‌ای برای پروژه‌ی خودتان پیدا کنید. -## Funding your own time +## وقت خود را سرمایه‌گذاری کنید -Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. +امروزه بسیاری از افراد برای کار به صورت پاره وقت یا تمام وقت در پروژه‌های متن باز دستمزد دریافت می‌کنند. متداول‌ترین راه برای دریافت دستمزد برای وقتی که صرف می‌کنید، صحبت کردن با کارفرمای خودتان است. -It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general. +متقاعد کردن کارفرما در پروژه‌ای که واقعا از آن استفاده ‌می‌کند آسان‌تر است، اما در مورد صحبتی که با او خواهید کرد، رویه‌ای خلاقانه در نظر بگیرید. شاید کارفرمای شما از این پروژه استفاده نکند، اما آن‌ها از پایتون استفاده می‌کنند و نگهداری از پروژه‌ی پایتون محبوب به جذب توسعه‌دهندگان جدید پایتون کمک می‌کند. شاید این امر باعث شود که کارفرمای شما به طور کلی در در ارتباط با توسعه‌دهندگان سازنده‌تر و دوستانه‌تر به نظر برسد. -If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software. +اگر در حال حاضر پروژه‌ای متن باز ندارید که بخواهید روی آن کار کنید، اما ترجیح می‌دهید که خروجی کار فعلی شما متن باز باشد، از کارفرمای خود درخواست کنید که برخی از نرم‌افزارهای داخلی خود را متن باز کند. -Many companies are developing open source programs to build their brand and recruit quality talent. +بسیاری از شرکت‌ها برنامه‌هایی متن باز توسعه می‌دهند تا اعتباری برای نام برند خود ایجاد کنند و افرادی با استعداد استخدام کنند. -@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting: +به عنوان مثال، @hueniverse دریافت که دلایلی تجاری برای توجیه [سرمایه‌گذاری والمارت (Walmart)] (https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html)در متن باز وجود دارد. و jamesgpearce@، دریافت که برنامه‌ی متن باز فیس‌بوک، [تفاوت‌هایی را در استخدام ایجاد کرده است](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) -> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues. +> کاملا با فرهنگ خلاقیت‌جویانه‌ی ما و آنچه که سازمان ما با آن شناخته می‌شود، سازگار و همسو است. ما از کارمندان خود پرسیدیم، «آیا از برنامه‌ی نرم‌افزاری متن باز فیس‌بوک آگاهی داشتید؟» دو سوم آن‌ها گفتند «بله» یک دوم آن‌ها گفتند که این برنامه به تصمیم‌شان برای کار کردن در فیس‌بوک تاثیر داشت. اینها اعداد کمی نیستند و امیدواریم که این روند ادامه داشته باشد. -If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location. +اگر شرکت شما این مسیر را طی می‌کند، مهم است که مرزهای بین اجتماع و فعالیت‌های شرکتی را روشن کنید. در آخر، پروژه‌های متن باز از طریق مشارکت‌های مردم در سرتاسر جهان از خود نگهداری می‌کند؛ این پروژه‌ها بزرگ‌تر از هر شرکت یا فضایی هستند. -If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example: +اگر نمی‌توانید کارفرمای کنونی خودتان را متقاعد به اولویت‌بندی کارهای متن باز بکنید، سعی کنید کارفرماهای جدیدی پیدا کنید که کارمندان را تشویق به مشارکت در متن باز می‌کنند. به دنبال شرکت‌هایی بگردید که تعهد صریحی برای کار با پروژه‌های متن باز داشته باشند. به عنوان مثال: + +* برخی شرکت‌ها مانند [Netflix](https://netflix.github.io/) یا [PayPal](https://paypal.github.io/)، وب‌سایت‌هایی دارند که مشارکت آن‌ها در متن باز را برجسته و نمایان می‌کند +* شرکت [Zalando](https://opensource.zalando.com)، «سیاست‌های مشارکت متن باز» خود برای کارمندان را منتشر کرد -* Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source -* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees +پروژه‌هایی که از شرکت‌های بزرگی مانند [Go](https://github.com/golang) یا [React](https://github.com/facebook/react) سرچشمه گرفته‌اند و به آن وصل‌اند نیز احتمالاً افرادی را برای کار با متن باز استخدام خواهند کرد -Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. +بسته به شرایط شخصی خودتان، می‌توانید به طور مستقل برای تأمین هزینه‌های کار متن باز خود، پول جمع کنید. به عنوان مثال: -Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: -* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) -* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) -* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) +* نرم‌افزار متن باز @Homebrew ([و بسیاری از نگهدارندگان و سازمان‌ها](https://github.com/sponsors/community))، کار خودشان را از طریق حامیان مالی [GitHub](https://github.com/sponsors) تأمین می‌کنند +* @gaearon کار خود در [Redux](https://github.com/reactjs/redux) را از طریق کمپین سرمایه‌گذاری جمعی «Patreon» تأمین مالی کرد +* @andrewgodwin از [طریق کمپین Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) کارش در مورد مایگریشن‌های دیتابیس «Django» را تأمین مالی کرد. (Schema Migration) -Finally, sometimes open source projects put bounties on issues that you might consider helping with. +در آخر اینکه گاهی اوقات پروژه‌های متن باز درمورد موضوعاتی که ممکن است در آن بخواهید کمک کنید پاداش‌هایی قرار می‌دهند. -* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/). -* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). +* @ConnorChristie توانست بابت [کمک](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) به @MARKETProtocol در «JavaScript library» (کتابخانه‌ی جاوا اسکریپت) از طریق پاداشی‌ تعیین شده در [gitcoin](https://gitcoin.co/)، دستمزد بگیرد +* @mamiM پس از تأمین اعتبار مربوط به مشکلِ شبکه‌ی Bounties، ترجمه‌ی ژاپنی برای @MetaMask انجام داد. -## Finding funding for your project +## یافتن بودجه برای پروژه‌ -Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. +علاوه‌ بر توافق‌های اولیه با مشارکت‌کنندگان، گاهی اوقات پروژه‌ها از شرکت‌ها، افراد حقیقی یا دیگران برای تأمین بودجه‌ی کارهای جاری پول جمع‌آوری می‌کنند. -Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas. +بودجه‌های سازمانی ممکن است به پرداخت دستمزد مشارکت‌کنندگان، تأمین هزینه‌های اجرای پروژه (مانند هزینه‌های میزبانی) یا سرمایه‌گذاری بر روی ویژگی‌ها یا ایده‌های جدید اختصاص یابد. -As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. +با افزایش محبوبیت ‌متن باز، هنوز هم یافتن بودجه برای پروژه‌ها به صورت تجربی و آزمایشی است، اما چندین گزینه‌ی متداول در دسترس است. -### Raise money for your work through crowdfunding campaigns or sponsorships +### جمع‌آوری سرمایه از طریق کمپین‌های سرمایه‌گذاری جمعی یا حمایت‌های مالی -Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular. -A few examples of sponsored projects include: +اگر از قبل مخاطب یا اعتبار بالایی داشته باشید یا پروژه‌ی شما از محبوبیت بالایی برخوردار باشد، یافتن حمایت‌های مالی امکان‌پذیر است. چند نمونه از پروژه‌های حمایت شده: -* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack) -* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803) -* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects +* پروژه‌ی **[webpack](https://github.com/webpack)** از طریق [OpenCollective](https://opencollective.com/webpack) از شرکت‌ها و اشخاص پول جمع‌آوری می‌کند +* بودجه‌ی **[Vue](https://github.com/vuejs/vue)** از طریق [Patreon](https://github.com/open-source/stories/yyx990803) تأمین می‌شود +* **[Ruby Together](https://rubytogether.org/)،** یک سازمان غیر‌انتفاعی است که هزینه‌های کار در [bundler](https://github.com/bundler/bundler)، [RubyGems](https://github.com/rubygems/rubygems) و سایر پروژه‌های بر پایه‌ی زیرساختی «Ruby» را پرداخت می‌کند -### Create a revenue stream +### ایجاد یک منبع درآمدی -Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include: +بسته به پروژه‌ی خود، ممکن است بتوانید از طریق تبلیغات، گزینه‌های میزبانی شده یا ویژگی‌های اضافی کسب درآمد داشته باشید. چندین مثال در این زمینه: -* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support -* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product -* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service +* **[Sidekiq](https://github.com/mperham/sidekiq)**، نسخه‌هایی پولی به منظور پشتیبانی بیشتر ارائه می‌دهد +* **[Travis CI](https://github.com/travis-ci)**، نسخه‌های پولی محصولات خود را ارائه می‌دهد +* **[Ghost](https://github.com/TryGhost/Ghost)**، یک سازمان غیرانتفاعی است که خدمات مدیریتی پولی ارائه می‌دهد -Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. +بعضی از پروژه‌های محبوب مانند [npm](https://github.com/npm/npm) و [Docker](https://github.com/docker/docker)، برای حمایت از رشد کسب و کار خود، حتی سرمایه‌های مخاطره‌آمیزی را جمع‌آوری می‌کنند -### Apply for grant funding +### برای بودجه، درخواست کمک هزینه (بورسیه) دهید -Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project. +برخی از موسسات و شرکت‌های نرم‌افزاری، کمک‌هزینه‌های مالی برای کارهای متن باز ارائه می‌دهند. گاهی اوقات، بدون ایجاد نهاد قانونی‌ای برای پروژه، کمک‌هزینه‌های مالی به افراد حقیقی پرداخت می‌شود. -* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) -* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) -* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology) -* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work +* **نرم‌افزار [Read the Docs](https://github.com/rtfd/readthedocs.org)**، از پشتیبانی بخش متن باز [Mozilla](https://www.mozilla.org/en-US/grants/)، کمک‌هزینه دریافت کرد +* **بودجه‌ی کار [OpenMRS](https://github.com/openmrs)** توسط [Stripe’s Open Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) تأمین شد +* **[Libraries.io](https://github.com/librariesio)** از موسسه‌ی [Sloan](https://sloan.org/programs/digital-technology) کمک‌هزینه‌ دریافت کرد +* **موسسه‌ی نرم‌افزار پایتون (Python Software Foundation)**، کمک‌های مالی برای کارهای مرتبط با پایتون ارائه می‌دهد -For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you. +برای جزئیات دقیق‌تر و مطالعات موردی، @nayafia راهنمای دریافت دستمزد برای کارهای متن باز را [نوشت](https://github.com/nayafia/lemonade-stand). انواع بودجه‌ها به مهارت‌های مختلفی نیاز دارد، بنابراین نقاط قوت خود را در نظر بگیرید تا گزینه‌ی مناسب برای کار خودتان را دریابید. -## Building a case for financial support +## ایجاد پرونده‌ی موردی (فایل) به منظور دریافت حمایت مالی -Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case. +این که آیا پروژه‌ی شما ایده‌ی جدیدی است یا سال‌هاست که وجود دارد؛ باید برای شناسایی و مشخص کردن سرمایه‌گذار هدف و ایجاد یک پرونده‌‌ی اغواکننده، باید به خوبی راجع به آن فکر کنید. -Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions. +چه بخواهید هزینه‌ی زمانی که صرف می‌کنید را خودتان پرداخت کنید و یا موسسه‌ای هزینه‌ی پروژه‌ی شما را پرداخت کند، باید بتوانید به سوالات زیر پاسخ دهید. -### Impact +### تاثیرگذاری -Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years? +این پروژه به چه دردی می‌خورد؟ برای چه کاربران شما، یا کاربران بالقوه‌ی شما، پروژه‌ را دوست داشته باشند؟ پروژه‌ی خود را در پنج سال آینده چطور می‌بینید؟ -### Traction +### مقبولیت -Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it? +سعی کنید شواهدی را در مورد اهمیت پروژه‌ی خود جمع‌آوری کنید؛ چه بخواهد معیارهای سنجش، تجربه‌های گذشته، یا اظهارنظرهای مثبتی باشد. آیا شرکت‌ها یا افراد قابل ذکری وجود دارند که از پروژه‌ی شما استفاده بکنند؟ اگر نه، آیا شخص برجسته‌ای پروژه‌ی شما را تأیید کرده است؟ -### Value to funder +### ارزش آن برای سرمایه‌گذار -Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit? +سرمایه‌گذاران، چه کارفرمای شما باشد و یا چه یک موسسه‌ی اعطای کمک‌هزینه، اکثرا جذب فرصت‌ها می‌شوند. چرا آن‌ها باید از پروژه‌ی شما در برابر سایر فرصت‌ها حمایت کنند؟ از پروژه‌ی شما چه منفعت شخصی‌ای می‌برند؟ -### Use of funds +### مصارف بودجه -What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary. +با بودجه پیشنهادی، دقیقاً به چه نتیجه‌ای دست خواهید یافت؟ به جای فکر کردن به پرداخت حقوق و دستمزد، روی نقاط عطف یا نتایج پروژه متمرکز شوید. -### How you'll receive the funds +### چگونه بودجه را دریافت خواهید کرد -Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand. +آیا سرمایه‌گذار، الزاماتی در مورد پرداخت هزینه مدنظر دارد؟ به عنوان مثال، ممکن است لازم باشد شما سازمانی غیرانتفاعی باشید یا یک حامی مالی غیرانتفاعی داشته باشید. یا شاید بودجه باید به جای سازمان به یک پیمانکار حقیقی داده شود. هر شخص سرمایه‌گذاری الزامات متفاوتی دارد، بنابراین حتماً از قبل تحقیقات خود را انجام دهید. -## Experiment and don't give up +## آزمایش و تجربه کنید و تسلیم نشوید -Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding. +جمع‌آوری پول آسان نیست، چه پروژه‌ای متن باز باشید، چه یک سازمان غیرانتفاعی و یا یک استارت‌آپ نرم‌افزاری؛ باید در بیشتر موارد با دیدی خلاقانه به موضوع نگاه کنید. با مشخص کردن اینکه چگونه می‌خواهید دستمزد بگیرید، با تحقیقات خود و قرار دادن خود به جای سرمایه‌گذار، به شما کمک می‌کند تا پرونده‌ای قانع‌کننده برای تأمین بودجه بسازید. From 018d345ee9d8172c04594d3d9e609878ca25934c Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 3 May 2021 10:36:32 +0000 Subject: [PATCH 013/629] Bump html-proofer from 3.19.0 to 3.19.1 Bumps [html-proofer](https://github.com/gjtorikian/html-proofer) from 3.19.0 to 3.19.1. - [Release notes](https://github.com/gjtorikian/html-proofer/releases) - [Commits](https://github.com/gjtorikian/html-proofer/compare/v3.19.0...v3.19.1) Signed-off-by: dependabot[bot] --- Gemfile.lock | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Gemfile.lock b/Gemfile.lock index 4086bbc0959..86995d3742f 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -22,7 +22,7 @@ GEM em-websocket (0.5.2) eventmachine (>= 0.12.9) http_parser.rb (~> 0.6.0) - ethon (0.13.0) + ethon (0.14.0) ffi (>= 1.15.0) eventmachine (1.2.7) execjs (2.7.0) @@ -87,7 +87,7 @@ GEM html-pipeline (2.14.0) activesupport (>= 2) nokogiri (>= 1.4) - html-proofer (3.19.0) + html-proofer (3.19.1) addressable (~> 2.3) mercenary (~> 0.3) nokogumbo (~> 2.0) @@ -213,7 +213,7 @@ GEM rb-fsevent (~> 0.10, >= 0.10.3) rb-inotify (~> 0.9, >= 0.9.10) mercenary (0.3.6) - mini_portile2 (2.5.0) + mini_portile2 (2.5.1) minima (2.5.1) jekyll (>= 3.5, < 5.0) jekyll-feed (~> 0.9) From 2cb2fde9a42436ba8e4088c63caf909f7c1e2f4b Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Tue, 4 May 2021 20:21:59 +0430 Subject: [PATCH 014/629] Initial translation done. --- _articles/fa/leadership-and-governance.md | 127 +++++++++++----------- 1 file changed, 61 insertions(+), 66 deletions(-) diff --git a/_articles/fa/leadership-and-governance.md b/_articles/fa/leadership-and-governance.md index b8006c30107..7c105727bc2 100644 --- a/_articles/fa/leadership-and-governance.md +++ b/_articles/fa/leadership-and-governance.md @@ -1,17 +1,8 @@ --- -lang: en -title: Leadership and Governance -description: Growing open source projects can benefit from formal rules for making decisions. +lang: fa +title: مدیریت و نظارت +description: وجود نقش‌های رسمی جهت تصمیم‌گیری، منافع زیادی برای پروژه‌های متن باز در حال رشد به همراه دارد. class: leadership -toc: - understanding-governance-for-your-growing-project: "Understanding governance for your growing project" - what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?" - how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?" - when-should-i-give-someone-commit-access: "When should I give someone commit access?" - what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?" - do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?" - what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?" - do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?" order: 6 image: /assets/images/cards/leadership.png related: @@ -19,147 +10,151 @@ related: - metrics --- -## Understanding governance for your growing project +## نظارت درست بر روی پروژه‌ی در حال رشد -Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers. +پروژه‌ی شما رشد می‌کند، مردم درگیر پروژه‌ی شما می‌شوند، و شما به ادامه دادن این کار متعهد می‌شوید. در این مرحله، ممکن است از خود بپرسید که چگونه می‌توانید مشارکت‌کنندگان پروژه‌ی خود را منسجم و یکپارچه کنید، خواه دادن دسترسی کامیت باشد یا حل و فصل کردن بحث‌ها و گفتگوهای درون اجتماع. اگر سوالاتی دارید، جواب‌ها پیش ماست. -## What are examples of formal roles used in open source projects? +## مثال‌هایی از نقش‌های رسمی مورد استفاده در پروژه های متن باز، چه هستند؟ -Many projects follow a similar structure for contributor roles and recognition. +بسیاری از پروژه‌ها، ساختار مشابهی را در حوزه‌ی نقش‌های مشارکتی و شناختی دنبال می‌کنند. -What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize: +مضمون و معنای این نقش‌ها، در واقع کاملا به شما بستگی دارد. در اینجا، چند نوع نقشی که ممکن است آن‌ها را تشخیص دهید، نام بردیم: -* **Maintainer** -* **Contributor** -* **Committer** +* **نگهدارنده (Maintainer)** +* **مشارکت‌کننده (Contributor)** +* **کامیت کننده (Committer)** -**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers. +**در برخی از پروژه‌ها، نگهدارندگان** تنها افرادی در پروژه هستند که دسترسی کامیت دارند. در برخی دیگر از پروژه‌ها، فقط افرادی دسترسی دارند که در «README» به عنوان نگهدارنده ذکر شده‌اند. -A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it. +نگهدارنده لزوماً کسی نیست که برای پروژه‌ی شما کد می‌نویسد. بلکه می‌تواند کسی باشد که در تبلیغ پروژه‌ی شما کارهای زیادی انجام داده باشد یا مستنداتی را نوشته باشد که پروژه را برای دیگران قابل دسترسی‌تر کرده است. صرف نظر از کاری که آن‌ها در طی روز انجام می‌دهند، نگهدارنده کسی است که نسبت به مسیر و اجرای پروژه احساس مسئولیت می‌کند و متعهد به بهبود بخشیدن آن است. -**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor). +**مشارکت‌کننده می‌تواند هر کسی باشد**: کسی که مسئله یا درخواست «Pull»ی را مطرح می‌کند، یا افرادی باشند که به پروژه ارزش می‌بخشند (خواه این که مسائل مربوط به اولویت‌بندی درخواست‌ها، نوشتن کد یا سازماندهی رویدادها باشد) یا هر کسی باشد که درخواست «pull»ی را ادغام (merge) بکند (جزئی‌ترین تعریف از مشارکت‌کننده) -**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution. +**اصطلاح «کامیت کننده»،** ممکن است برای وجه تمایز دسترسی کامیت، که نوع خاصی از مسئولیت در مقابل سایر اشکال مشارکت است، استفاده شود. -While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill. +در حالی که می‌توانید نقش‌ها را در پروژه‌ی خود به هر روشی که دوست دارید تعریف کنید، استفاده از تعاریف گسترده‌تر را برای تقویت اشکال بیشتری از مشارکت، [مد نظر خود قرار دهید](../how-to-contribute/#what-it-means-to-contribute). شما می‌توانید از نقش‌های مدیریتی برای شناسایی رسمی افرادی که مشارکت برجسته‌ای به پروژه‌ی شما کرده‌اند، صرف نظر از مهارت‌های فنی آن‌ها استفاده کنید -## How do I formalize these leadership roles? +## چگونه به این نقش‌های مدیریتی، رسمیت ببخشیم؟ -Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help. +رسمیت بخشیدن به نقش‌های مدیریتی، باعث می‌شود افراد احساس مالکیت کنند و به اعضای سایر اجتماع‌ها بگویند برای کمک به چه کسانی روی آورند. -For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file. +در پروژه‌های کوچک‌تر، تعیین کردن مدیران می‌تواند به سادگی افزودن نام آن‌ها به فایل‌های «README» یا به یک فایل متنی «CONTRIBUTORS» باشد. -For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor. +برای پروژه‌های بزرگ‌تر، اگر وب‌سایتی دارید، یک صفحه‌ی تیمی ایجاد کنید یا اسامی مدیران پروژه را در آنجا لیست کنید. به عنوان مثال، [Postgres](https://github.com/postgres/postgres/) یک [صفحه‌ی تیمی جامع](https://www.postgresql.org/community/contributors/) و فراگیر با مشخصاتی کوتاه برای هر مشارکت‌کننده دارد. -If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (for example, security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them. +اگر پروژه‌ی شما دارای جامعه‌ی مشارکت‌کننده‌ی بسیار فعالی است، شما می‌توانید یک «تیم اصلی» از نگهدارنده‌ها، یا حتی کمیته‌های فرعی از افرادی که مالکیت حوزه‌های موضوعات مختلف را دارند (به عنوان مثال، امنیت، اولویت‌بندی درخواست‌ها یا هدایت اجتماع) تشکیل دهید. به جای اینکه به هر کسی، وظایف خاصی را محول کنید، بگذارید افراد خودشان، برای نقش‌هایی که بیشتر از همه هیجان زده‌اند سازمان یابند و داوطلب شوند. -Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). +تیم‌های مدیریت، ممکن است بخواهند کانالی مشخص (مانند IRC) ایجاد کنند یا به طور منظم برای بحث درمورد پروژه با هم ملاقات کنند (مانند Gitter یا Google Hangout). حتی می‌توانید آن جلسات را علنی برگزار کنید تا سایر افراد بتوانند گوش دهند. به عنوان مثال، [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby) همچین کاری می‌کند -Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md. +پس از اینکه نقش‌های مدیریتی را ایجاد کردید، ثبت چگونگی نحوه‌ی دسترسی افراد به آن‌ها را فراموش نکنید! فرآیند روشن و واضحی را برای چگونگی کسی که می‌خواهد نگهدارنده شود یا به کمیته‌ای فرعی در پروژه شما بپیوندد، ایجاد کنید و آن را در «GOVERNANCE.md» خود بنویسید. -Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately. +ابزارهایی مانند [Vossibility](https://github.com/icecrime/vossibility-stack)، می‌تواند به شما کمک کند تا به طور عمومی افرادی که در پروژه مشارکت می‌کنند (یا نمی‌کنند) را ردیابی کنید. ثبت این اطلاعات، جلوی این ذهنیت اجتماع که نگهدارندگان گروهی هستند که تصمیمات خود را به صورت خصوصی اتخاذ می‌کنند، می‌گیرد -Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project). +در آخر اینکه اگر پروژه‌ی شما در «GitHub» است، انتقال پروژه‌ی خود را از حساب شخصی خود به یک تشکل و اضافه کردن حداقل یک مدیر پشتیبان را مد نظر خود قرار دهید. [تشکل‌های «GitHub»](https://help.github.com/articles/creating-a-new-organization-account/)، مدیریت دسترسی‌ها و مراکز ذخیره‌سازی متعدد را آسان‌تر می‌کنند و پیشینه‌ی پروژه‌ی شما را از طریق [مالکیت مشترک](../building-community/#share-ownership-of-your-project) محافظت می‌کنند. -## When should I give someone commit access? +## چه موقع باید به کسی اجازه‌ی دسترسی کامیت بدهیم؟ -Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project. +برخی از افراد فکر می‌کنند که شما باید به هر کسی که در پروژه مشارکت می‌کند، دسترسی کامیت بدهید. با انجام این کار، افراد بیشتری ترغیب به داشتن احساس مالکیت نسبت به پروژه‌ی شما، می‌شوند. -On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable! +از طرف دیگر، به خصوص برای پروژه‌های بزرگتر و پیچیده‌تر، ممکن است بخواهید فقط به افرادی که تعهد خود را نشان داده و به اثبات رسانده‌اند، دسترسی کامیت بدهید. هیچ راه درستی برای انجام این کار وجود ندارد - هر جور که راحت‌تر هستید، عمل کنید! -If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances. +اگر پروژه‌ی شما در «GitHub» است، می توانید از شاخه‌های محافظت شده [protected branches](https://help.github.com/articles/about-protected-branches/) برای مدیریت افرادی که می‌توانند تحت شرایط خاصی در شاخه‌ای خاص عمل کنند، استفاده کنید -## What are some of the common governance structures for open source projects? +## برخی از ساختارهای نظارتی متداول برای پروژه‌های متن باز چیست؟ -There are three common governance structures associated with open source projects. +سه ساختار نظارتی متداول در ارتباط با پروژه‌های متن باز وجود دارد. -* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category. -* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](https://www.apache.org/); [all Apache projects](https://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company. +* **BDFL** مخفف «دیکتاتور خیرخواه جاویدان» است ( .(Benevolent Dictator for Lifeتحت این ساختار، یک نفر (معمولاً نویسنده‌ی اولیه‌ی پروژه) در مورد تمام تصمیمات مهم پروژه، حرف آخر را می‌زند. [Python](https://github.com/python)، نمونه‌ای موثق در این مورد است. پروژه‌های کوچک‌تر احتمالاً به طور پیش‌فرض به صورت «BDFL» هستند، زیرا فقط یک یا دو نگهدارنده وجود دارد. پروژه‌هایی که از یک شرکت منشأ گرفته شده باشند نیز ممکن است در طبقه‌بندی «BDFL» قرار گیرند -* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). -Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates: +* **Meritocracy:** (شایسته سالاری) (توجه داشته باشید که اصطلاح شایسته سالاری برای برخی اجتماع‌ها، مفهومی منفی دارد و ساختار آن [دارای پیشینه‌ی پیچیده‌ی اجتماعی و سیاسی ](http://geekfeminism.wikia.com/wiki/Meritocracy).)است.) تحت ساختار «شایسته سالاری»، به مشارکت‌کنندگان فعال پروژه (کسانی که از «شایستگی» نشان می‌دهند) نقش تصمیم‌گیرندگی رسمی داده می‌شود. تصمیم‌‌ها، معمولاً براساس اجماع رای گرفته می‌شوند. مفهوم شایسته سالاری، نخستین بار توسط بنیاد «Apache»، به وجود آمد. تمامی پروژه‌های «Apache» بر اساس شایسته سالاری هستند. مشارکت‌ها فقط توسط افراد حقیقی صورت می‌گیرد؛ نه توسط یک شرکت. + + +* **Liberal contribution:** (مشارکت آزادنه) تحت مدل مشارکت آزادانه، افرادی که بیشترین کار را انجام می‌دهند به عنوان تأثیرگذارترین افراد شناخته می‌شوند، اما این مدل براساس کاری که اکنون انجام می‌دهند است و نه مشارکت‌های که در گذشته داشته‌اند. تصمیمات بزرگ‌ پروژه بر اساس فرآیندی در اجتماع به صورت اجماعی (بحث‌ در مورد مسائل اساسی) به جای رأی‌گیری تنها گرفته می‌شود، و تلاش می‌شود تا آنجا که ممکن است دیدگاه‌های بیشتری از اجتماع را شامل شود. از جمله پروژه‌هایی که از مدل مشارکت آزادانه استفاده کردند، می‌توان [Node.js](https://foundation.nodejs.org/) و [Rust](https://www.rust-lang.org/) را نام برد. + +از کدام مدل بهتر است استفاده کنید؟ به خودتان بستگی دارد! هر مدل، شامل نکات منفی و مثبتی می‌شود. اگرچه ممکن است این مدل‌ها در ابتدا کاملاً متفاوت به نظر برسند؛ اما هر سه مدل، اشتراکات بیشتری از آنچه که به نظر می رسد دارند: * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) * [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) -## Do I need governance docs when I launch my project? +## آیا هنگام راه‌اندازی پروژه‌ی خود به اسناد نظارتی نیاز دارم؟ + +زمان مناسب و دقیقی برای نوشتن اسناد نظارتی پروژه وجود ندارد، اما هنگامی که شرایط اجتماع خود را دیدید و با جو آن آشنا گشتید، به ثبت رساندن اسناد بسیار ساده‌تر می‌شود. بهترین (و سخت‌ترین) بخش در مورد نظارت پروژه‌های متن باز این است که توسط خود اجتماع شکل می‌گیرد! -There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community! +هر چند برخی اسناد اولیه‌ی نظارتی به طور اجتناب ناپذیری در پروژه‌ی شما خواهد بود، ولی شروع به نوشتن آنچه می‌توانید بکنید. به عنوان مثال، شما می‌توانید حتی در زمان راه‌اندازی پروژه‌ی خود، انتظارات واضح و شفاف خودتان از رفتار یا فرآیند‌ مشارکت کاری را تعریف کنید. -Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch. +اگر شما عضوی از شرکتی هستید که پروژه‌ای متن باز راه‌اندازی می‌کند، بد نیست قبل از راه‌اندازی، بحثی درون‌سازمانی درباره نحوه‌ی نگهداری شرکت و تصمیم‌گیری در مورد پیشرفت پروژه داشته باشید. همچنین بهتر است در مورد مسیری که شرکت شما در رابطه با پروژه پیش خواهد گرفت، به صورت علنی صحبت دهید. -If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project. -## What happens if corporate employees start submitting contributions? +## اگر کارمندان شاغل در شرکت شروع به ارائه‌ی خدمات کنند، چه می‌شود؟ -Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering. +پروژه‌های متن باز موفق، توسط بسیاری از افراد و شرکت‌ها مورد استفاده قرار می‌گیرند و در نهایت ممکن است برخی از شرکت‌ها شروع به کسب درآمد از آن پروژه‌ها بکنند. به عنوان مثال، شرکتی ممکن است از کدهای پروژه به عنوان یک بخش سازنده‌ی محصولات خدمات تجاری استفاده کند. -As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project. +هنگامی که استفاده از پروژه بیشتر شود، افراد زیادی خواستار کسانی که در آن پروژه تخصص دارند می‌شوند؛ ممکن است شما یکی از آن‌ها باشید! و گاهی اوقات نیز به خاطر کاری که در پروژه‌ می‌کنید، حقوق دریافت کنید. -It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature. +بسیار مهم است که رفتاری عادی در قبال فعالیت‌های تجاری داشت؛ درست رفتاری مانند فعالیت‌های توسعه‌ای در پروژه‌های دیگر. البته نباید برخورد خاص و رفتار ویژه‌ای با توسعه‌دهندگانی که به آن‌ها پول داده می‌شود در برابر آن‌هایی که بدون دریافت پول به کارشان مشغول هستند، قائل شد. هر یک از مشارکت‌ها باید بر اساس شایستگی‌های فنی ارزیابی شود. با این حال، افرادی که مشغول به فعالیت‌های تجاری هستند، باید احساس راحتی داشته باشند و هنگام بحث و گفتگو در مورد پیشرفت یا ویژگی خاصی، در بیان موارد کاربردی و کارهایی که قبلا داشتند، باید احساس راحتی کنند. -"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.) +پروژه‌های «تجاری» هیچ فرقی با پروژه‌های «متن باز» ندارند. «تجاری» فقط به این معنی است که پول هم در کار است؛ به این معنی که نرم افزاری که در تجارت مورد استفاده قرار می‌گیرد، نرم‌افزاری در پروژه بوده است که در فعالیت تجاری پذیرفته شده است. (هنگامی که از یک نرم‌افزار «متن باز» به عنوان بخشی سازنده از محصولی «غیر متن باز» استفاده می‌شود، محصول نهایی همچنان نرم‌افزاری «دارای حقوق انحصاری» است، هرچند مانند «متن باز» ممکن است برای اهداف تجاری یا غیر تجاری استفاده شود.) -Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions. +مانند هر کس دیگری، توسعه‌دهندگانی که انگیزه‌های تجاری دارند از طریق کیفیت و کمیت مشارکت‌های خودشان است که در پروژه اهمیت می‌یابند و تاثیرگذار می‌شوند. بدیهی است که توسعه‌دهنده‌ای که برای کاری که می‌کند حقوق می‌گیرد، احتمالا بیشتر از شخصی که حقوق نمی‌گیرد، توانایی کار کردن دارد ولی اهمیتی ندارد: پرداخت حقوق فقط یکی از بسیار عامل‌های احتمالی است که می‌تواند بر میزان کاری که شخص می‌کند، تأثیر بگذارد. مشارکت‌ها رو معطوف به بحث‌های مربوط به پروژه بکنید، و نه معطوف به موضوعاتی خارج از پروژه. -## Do I need a legal entity to support my project? +## آیا برای حمایت و پشتیبانی از پروژه‌ی خود به نهاد قانونی نیاز خواهم داشت؟ -You don't need a legal entity to support your open source project unless you're handling money. +شما برای پشتیبانی از پروژه‌ی متن باز خود احتیاج به نهاد قانونی نخواهید داشت، مگر اینکه با پول سر و کار داشته باشید. -For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US). +به عنوان مثال، اگر می‌خواهید کسب و کاری ایجاد کنید، باید از طریق «C Corp» یا «LLC» (اگر در ایالات متحده مستقر هستید) اقدام کنید. اگر فقط کارهای پیمانکاری مربوط به پروژه متن باز خود را انجام می‌دهید، می‌توانید به عنوان یک مالک شخصی پول را بپذیرید یا یک «LLC» (اگر در ایالات متحده مستقر هستید) ایجاد کنید. -If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US). +اگر می‌خواهید کمک‌های مالی برای پروژه‌ی متن باز خود بپذیرید، می‌توانید بستری را برای کمک‌های مالی (مثلاً با استفاده از PayPal یا Stripe) ایجاد کنید، اما این مبلغ مشمول کسر مالیت می‌شود، مگر اینکه به عنوان یک سازمان غیرانتفاعی واجد شرایط باشید (اگر در ایالات متحده مستقر هستید). -Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. +بسیاری از پروژه‌ها مایل به پذیرفتن مشکلات ناشی از ایجاد سازمانی غیرانتفاعی نیستند، بنابراین در عوض یک حامی مالی غیرانتفاعی پیدا می‌کنند. یک حامی مالی، معمولاً در ازای درصدی از کمک مالی، کمک‌های مالی را از طرف شما قبول می‌کند. [Software Freedom Conservancy](https://sfconservancy.org/)،[Apache Foundation](https://www.apache.org/) ،[Eclipse Foundation](https://eclipse.org/org/foundation/) ، [Linux Foundation](https://www.linuxfoundation.org/projects) و [Open Collective](https://opencollective.com/opensource)، نمونه‌هایی از سازمان‌ها هستند که به عنوان حامی‌های مالی در پروژه‌های متن باز فعالیت می‌کنند -If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. +اگر پروژه‌ی شما رابطه‌ی نزدیکی با زبان یا اکوسیستم خاصی داشته باشد، ممکن است پیش‌زمینه‌ی نرم‌افزاری مرتبط با آن وجود داشته باشد که بتوانید با آن کار کنید. به عنوان مثال، [Python Software Foundation](https://www.python.org/psf/) از [PyPI](https://pypi.org/) پشتیبانی می‌کند، [Python package manager](https://www.python.org/psf/) و [Node.js Foundation](https://foundation.nodejs.org/) به [Express.js](https://expressjs.com/)، که مبتنی بر Node است، کمک می‌کند. \ No newline at end of file From 46d5e6a6563bd362f2e5c6505596594004013974 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Wed, 5 May 2021 14:49:31 +0430 Subject: [PATCH 015/629] Initial translation done. --- _articles/fa/starting-a-project.md | 275 ++++++++++++++--------------- 1 file changed, 137 insertions(+), 138 deletions(-) diff --git a/_articles/fa/starting-a-project.md b/_articles/fa/starting-a-project.md index 1ace069082f..bc6c3717201 100644 --- a/_articles/fa/starting-a-project.md +++ b/_articles/fa/starting-a-project.md @@ -1,14 +1,8 @@ --- -lang: en -title: Starting an Open Source Project -description: Learn more about the world of open source and get ready to launch your own project. +lang: fa +title: شروع یک پروژه‌ی متن باز / منبع باز / اوپن سورس +description: در این مقاله چیزهای زیادی درباره‌ی دنیای متن بازها می‌آموزید و آماده‌ی انتشار پروژه‌ی متن باز خودتان می‌شوید. class: beginners -toc: - the-what-and-why-of-open-source: "The what and why of open source" - should-i-launch-my-own-open-source-project: "Should I launch my own open source project?" - launching-your-own-open-source-project: "Launching your own open source project" - naming-and-branding-your-project: "Naming and branding your project" - your-pre-launch-checklist: "Your pre-launch checklist" order: 2 image: /assets/images/cards/beginner.png related: @@ -16,296 +10,300 @@ related: - building --- -## The "what" and "why" of open source +## چیستی و چرایی متن باز -So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it. +اگر در حال فکر کردن این هستید که پروژه‌ی متن باز خودتان را شروع کنید؟ به شما تبریک می‌گوییم! دنیا قدردان کمک و مشارکت شماست. اجازه دهید در ادامه درباره پروژه‌های متن باز بیشتر صحبت کنیم و ببینیم چرا مردم پروژه‌هایشان را متن باز می‌کنند. -### What does "open source" mean? +### متن باز به چه معناست؟ -When a project is open source, that means **anybody is free to use, study, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses). +زمانی که یک پروژه متن باز یا اوپن سورس باشد، **هر کسی می‌تواند و اجازه دارد به صورت رایگان آن را استفاده، مطالعه، ویرایش و برای هر هدفی که می‌خواهد، توزیع کند**. این اجازه‌ها در [لایسنس متن باز](https://opensource.org/licenses) قید شده و قابل اجراست -Open source is powerful because it lowers the barriers to adoption and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions. +پروژه‌های متن باز قدرتمند هستند، چون موانعی که در اختیارات و مشارکت‌ها دیده می‌شود را کاهش و به افراد اجازه می‌دهد پروژه‌های خود را به سرعت گستردش و بهبود دهند. یکی دیگر از دلایل قدرتمند بودن متن بازها این است که پتانسیل کنترل محاسبه را بسته به منابع محدود به کاربران می‌دهد. اگر بخواهیم برای روشن شدن مطلب نمونه‌ای بیاوریم، می‌توانیم به کسب‌وکارهایی اشاره کنیم که به جای تکیه بر منابع محصور و محدود محصولات انحصاری فروشنده‌های نرم‌افزار، از نرم‌افزارهای متن بازی استفاده می‌کنند که به آن‌ها اجازه می‌دهد شخصی را استخدام کنند تا آن نرم‌افزار را برای آن‌ها شخصی‌سازی یا بهینه کند. -_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge). +_نرم‌افزارهای رایگان_ همچنین به پروژه‌های متن باز منسوب می‌شود. گاهی هم ممکن است برنامه‌هایی ببینید که [ترکیبی](https://en.wikipedia.org/wiki/Free_and_open-source_software) از اصلاحات «نرم‌افزار متن باز و رایگان» (FOSS) یا «نرم‌افزار متن باز، آزاد و رایگان» (FLOSS) استفاده می‌کنند. خب، باید بگوییم که کلمه‌ی _Free_ (رایگان) و _libre_ (آزاد / رایگان) هر دو به معنای آزادی در استفاده و دسترسی اطلاق می‌شود، [نه قیمت آن](#does-open-source-mean-free-of-charge) -### Why do people open source their work? +### چرا مردم پروژه‌های‌شان را متن باز می‌کنند؟ -[There are many reasons](https://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include: +[دلایل زیادی وجود دارد](https://ben.balter.com/2015/11/23/why-open-source/) که یک شخص یا سازمان بخواهد پروژه‌های خود را متن باز کند. این دلایل عبارتند از: -* **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors. +* **مشارکت:** هر فردی در دنیا می‌تواند پروژه‌های متن باز را تغییر دهد و در ویرایش آن مشارکت داشته باشد. به عنوان نمونه، Exercism که به عنوان یک پلتفرم متن باز برای تمرین برنامه‌نویسی شناخته می‌شود، با مشارکت افراد مختلف تا به الان بیش از 350 توزیع و ویرایش داشته است. -* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). +* **اقتباس و تغییر مجدد:** هر فردی تقریباً با هر هدفی می‌تواند از پروژه‌های متن باز استفاده کند. افراد حتی می‌توانند از یک پروژه، پروژه‌های دیگری به وجود بیاورند. به عنوان مثال می‌توانیم به [وردپرس](https://github.com/WordPress) اشاره کنیم که از پروژه موجودی به نام [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) منشعب شده است. -* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt). +* **شفافیت:** هرکسی می‌تواند خطاها و تناقض پروژه‌های متن باز را بازرسی کند. از این رو، شفافیت برای دولت‌هایی مانند دولت [بلغارستان](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ایالات متحده آمریکا](https://sourcecode.cio.gov/) و صنایع مقرراتی مانند بانکداری، مراکز بهداشت وُ درمانی و نرم‌افزار امنیتی مانند [Let’s Encrypt](https://github.com/letsencrypt) اهمیت بالایی پیدا می‌کند تا زمان بازرسی خطاها توسط افراد مختلف، دچار مشکل نشوند. -Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source. +ویژگی متن باز فقط مختص به نرم‌افزارها نیست، شما هر چیزی حتی مجموعه‌ای از داده‌های یک کتابخانه را می‌توانید متن باز کنید. اگر می‌خواهید بیشتر بدانید که چه چیزهای دیگری را می‌شود متن باز کرد، می‌توانید به [GitHub Explore](https://github.com/explore) مراجعه کنید. -### Does open source mean "free of charge"? +### آیا پروژ‌های متن باز «مجانی / رایگان» هستند؟ -One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value. +یکی از بزرگ‌ترین جذابیت‌های متن بازها این است که پولی نیستند. هرچند، رایگان بودن، یک محصول جانبی با ارزش کلی یک پروژه‌ی متن باز است. -Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. +به عبارت دیگر، [در لایسنس و گواهینامه‌ی پروژه‌های متن بازها آورده شده است](https://opensource.org/osd-annotated) که هر کسی می‌تواند آن‌ها را استفاده، ویرایش و تقریباً با هر هدفی به اشتراک بگذارد. از این رو، پروژه‌های متن باز به صورت رایگان عرضه می‌شوند و اگر هم استفاده‌ از این پروژه‌ها پولی شود، هر کسی به صورت قانونی می‌تواند از آن کپی بگیرد و درعوض، از نسخه‌ی رایگان آن استفاده کند -As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source. +در نتیجه، بیشتر پروژه‌های متن باز به صورت رایگان ارائه می‌شوند و از طرفی هم «رایگان بودن / مجانی بودن» به عنوان بخشی از تعریف پروژه‌های متن باز به حساب نمی‌آید، یعنی پروژه‌های متن باز هم به صورت رایگان و هم به صورت پولی هستند. البته راههایی سازگار با مجوزهای متن باز مثل ارائه مجوز دوگانه یا محدودکردن ویژگی ها به دو دسته رایگان و پولی برای کسب درآمد غیرمستقیم از پروژه‌های متن باز وجود دارد. -## Should I launch my own open source project? +## آیا پروژه‌ی متن باز خودم را باید منتشر کنم؟ -The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works. +اگر بخواهیم کوتاه جواب بدهیم، بله. چون خروجی پروژه‌ی شما مهم نیست. مهم این است که پروژه‌تان منتشر شود و بهترین راه هم برای یاد گرفتن نحوه‌ی کار پروژه‌های متن باز انتشار آن‌هاست. -If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone! +اگر هیچوقت پروژه‌ی متن بازتان را منتشر نکردید، ممکن است این نگرانی برای‌تان پیش بیاید افراد مختلف چه چیزی درباره‌ی پروژه‌تان می‌گویند یا اصلا به پروژه‌ی شما توجه می‌کنند یا خیر. اگر چنین احساسی دارید، باید بگوییم که تنها نیستید. -Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience. +کار یک پروژه‌ی متن باز مانند هر فعالیت خلاقانه‌ی دیگری مثل نویسندگی و نقاشی است. زمانی که شما به عنوان یک هنرمند اولین اثر خود را با دنیا به اشتراک می‌گذارید، احساس ترس به سراغتان می‌آید. اما این کار را باید انجام دهید، چون تمرین تنها راه بهتر شدن است؛ حتی اگر یک مخاطب هم نداشته باشید. -If you're not yet convinced, take a moment to think about what your goals might be. -### Setting your goals +اگر هنوز هم متقاعد نشدید، به این فکر کنید که اهداف‌تان چه چیزهایی می‌توانند باشند. -Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_ +### اهداف‌تان را مشخص کنید -There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals. +اهداف می‌تواند به شما کمک کند تا متوجه شوید که بر روی چه چیزی کار کنید، به چه چیزی نه بگویید و کجا به کمک دیگران نیاز دارید. با سوال کردن از خودتان شروع کنید. از خودتان بپرسید: _چرا می‌خواهم این پروژه را متن باز کنم؟_ -If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome. +خب، واضح است که هیچ کس جواب درستی برای این سوال ندارد. چون ممکن است چندین هدف برای یک پروژه یا پروژه‌های مختلفی با اهداف متفاوتی وجود داشته باشد. + +اگر نمایش دادن کارتان تنها هدف برای متن باز کردن پروژه‌تان باشد، احتمالاً مشارکت دیگران را نمی‌خواهید و این نخواستن مشارکت را هم در فایل README پروژه‌تان نیز می‌آورید. از طرف دیگر، اگر واقعاً مشارکت دیگران را بخواهید، زمان خود را صرف مرتب کردن اسناد و صرف خوشامدگویی به افرادی می‌کنید که تازه وارد این حوزه شدند. -As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project. +وقتی که پروژه‌ی شما رشد می‌کند، جامعه‌ی مخاطب پروژه‌هایتان احتمالاً بیشتر از یک کد به شما نیاز خواهند داشت. وظایف مهمی که در یک پروژه‌ی متن باز به شما محول می‌شود این است که برای مشکلات پاسخی داشته باشید، کدها را بررسی کنید و مژده‌ی پروژه‌ی متن بازتان را به دیگران بدهید. + +اگرچه مدت زمانی که صرف کارهای غیرکدنویسی می‌کنید، به اندازه و دامنه‌ی پروژه‌یتان بستگی دارد، اما به عنوان یک مسئول‌نگهداری پروژه باید خودتان را آماده کنید آن‌ها را انجام دهید یا حداقل شخصی را پیدا کنید که در کارهای غیرکدنویسی به شما کمک کند. -While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you. -**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community. +**اگر جزئی از یک پروژه‌ی متن باز یک شرکت هستید،** مطمئن شوید پروژه‌یتان منابع لازم داخلی برای پیشرفت را داشته باشد. از این رو، باید بدانید که چه کسی مسئول نگهداری پروژه‌ی متن بازتان است و چگونه می‌خواهید این وظایف را با جامعه‌ی خود به اشتراک بگذارید -If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early. +اگر برای ارتقاء، بهره‌برداری و نگهداری پروژه به بودجه خاص یا کارمند نیاز دارید، می‌توانید این نیازها را در ابتدا اعلام کنید. -### Contributing to other projects +### مشارکت در سایر پروژه‌ها -If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation. +اگر هدف‌تان این باشد که با دیگران در پروژه‌های متن باز همکاری کنید یا می‌خواهید نحوه‌ی عملکرد یک پروژ‌ه‌ی متن باز را درک کنید، همکاری و مشارکت با پروژه‌های موجود را در نظر بگیرید. با پروژه‌ای شروع کنید که قبلا به آن علاقه‌مند بودید و از آن استفاده می‌کردید. مشارکت در یک پروژه‌ی متن باز می‌تواند به سادگی اصلاح یک کد اشتباه یا آپدیت / به‌روزرسانی اسناد باشد. -If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/). +اگر مطمئن نیستید که چگونه می‌توانید در سایر پروژه‌ها مشارکت کنید، به مقاله‌ی [راهنمای نحوه‌ی همکاری در پروژه‌ی متن باز](../how-to-contribute/) مراجعه کنید -## Launching your own open source project +## انتشار پروژه‌ی متن باز خودتان -There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source. +زمان مناسبی برای متن باز کردن پروژه‌تان وجود ندارد. از این رو، می‌توانید یک ایده، کارهایی در دست اقدام یا پروژه‌هایی که بعد از سال‌ها بسته ماندند، را متن باز کنید. -Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work. +به طور کلی، هر زمان که احساس کردید با دیدگاه‌ها و بازخوردهای دیگران راحت هستید، باید پروژه‌یتان را متن باز کنید. -No matter which stage you decide to open source your project, every project should include the following documentation: +مهم نیست در چه مرحله‌ای تصمیم گرفتید پروژه‌تان را متن باز کنید. هر پروژه‌ای باید حاوی اسناد زیر باشد: -* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [لایسنس متن باز](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) * [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) -* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) -* [Code of conduct](../code-of-conduct/) +* [راهنمای مشارکت](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [آیین نامه رفتار](../code-of-conduct/) + +این مؤلفه‌ها به شما به عنوان مسئول‌نگهداری پروژه کمک می‌کند تا انتظارات‌تان را بیان، مشارکت‌ها را مدیریت و از حقوق قانونی خود و دیگران محافظت کنید. این موارد شانس شما را برای داشتن یک تجربه‌ی خوب افزایش می‌دهد. -As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience. +اگر پروژه‌ی شما در GitHub قرار دارد، قرار دادن فایل‌های فوق به همراه نام فایل‌های توصیه‌شده در پوشه ریشه (root) می‌تواند به GitHub کمک کند تا آن‌ها را به صورت خودکار به مخاطبان‌تان شناسایی کند و نمایش دهد. -If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers. +### انتخاب لایسنس یا مجوز -### Choosing a license +لایسنسِ یا مجوز یک پروژه‌ی متن باز به دیگران ضمانت می‌دهد از پروژه‌ی متن باز استفاده، کپی، ویرایش و بدون هیچ عواقبی در آن مشارکت کنند. لایسنس همچنین از شما در برابر موقعیت‌های سخت قانونی محافظت می‌کند. **زمانی که می‌خواهید پروژه‌ی متن بازتان را منتشر کنید، حتما لایسنس آن را هم ضمیمه کنید**. -An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.** +کارهای ادارای و حقوقی برای گرفتن لایسنس هیچ جذابیتی ندارد، اما خبر خوب اینجاست که می‌توانید لایسنس‌های موجود و در دسترس را که از قبل توسط دیگران تدوین شده را در repository (مخزن) خود کپی و پیست کنید. برای محافظت از تلاشی که برای متن باز کردن پروژه‌تان انجام دادید، این کار تنها یک دقیقه وقت شما را می‌گیرد. -Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work. +[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) و [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) جزء محبوب‌ترین لایسنس‌های متن باز هستند. هرچند، لایسنس‌های دیگری هم وجود دارد که می‌توانید از آن‌ها استفاده کنید. -[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from. +زمانی که پروژه‌ی جدیدی در GitHub ایجاد می‌کنید، به شما امکان انتخاب لایسنس داده می‌شود. انتخاب کردن لایسنس باعث می‌شود GitHub پروژه‌ی شما را متن باز نشان دهد. -When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source. +![انتخاب مجوز](/assets/images/starting-a-project/repository-license-picker.png) -![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) +در ادامه‌ی مقاله، سایر سوالات و نگرانی‌هایتان درباره‌ی [جنبه‌های قانونی](../legal/) مدیریت پروژه‌ی متن بازتان را بررسی خواهیم کرد. -If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/). +### نوشتن فایل «README» (فایلی که توضیحات پروژه در آن آورده می‌شود) -### Writing a README +فایل README اطلاعات بیشتری نسبت به این دارد که نحوه‌ی استفاده از پروژه‌تان را به کاربر توضیح دهد. این فایل همچنین توضیح می‌دهد که پروژه‌ی شما چه اهمیتی دارد و کاربران‌تان با این پروژه چه کارهای می‌توانند انجام دهند. -READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it. +سعی کنید در فایل README خودتان به سوالات زیر پاسخ دهید و جواب آن‌ها را در فایل بیاورید: -In your README, try to answer the following questions: +* پروژه‌ی شما چه کاری انجام می‌دهد؟ +* چرا این پروژه مفید است؟ +* چگونه شروع کردم؟ +* در صورت نیاز، از کجا می‌توانم کمک بیشتری دریافت کنم؟ -* What does this project do? -* Why is this project useful? -* How do I get started? -* Where can I get more help, if I need it? -You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down. +شما با فایل README می‌توانید به سایر سوالات نیز پاسخ دهید؛ سوالاتی مانند اینکه چگونه مشارکت‌تان را مدیریت می‌کنید، اهداف پروژه‌تان چیست و اطلاعات لایسنس و اختیارات پروژه‌تان را هم می‌توانید بیاورید. اگر مشارکت کسی را نمی‌خواهید قبول کنید، یا پروژه‌ی شما هنوز برای ارائه آماده نشده باشد، می‌توانید این توضیحات را در فایل README بیاورید -Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one. +بعضی از افراد از نوشتن فایل README خودداری می‌کنند، چون فکر می‌کنند پروژه‌ی آن‌ها هنوز تکمیل نشده یا اینکه نمی‌خواهند کسی مشارکتی داشته باشد. همین‌ها دلایل خیلی خوبی برای نوشتن یک فایل README محسوب می‌شوند. -For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. +برای نوشتن یک فایل README کامل، می‌توانید به مقالات @dguo’s ["Make a README" guide](https://www.makeareadme.com/) یا @PurpleBooth’s [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) مراجعه کنید و از آن‌ها الهام بگیرید -When you include a README file in the root directory, GitHub will automatically display it on the repository homepage. +زمانی که فایل README را در دایرکتوری ریشه خود قرار می‌دهید، GitHub به صورت خودکار آن را در صفحه‌ی اصلی repository (انبار) نشان می‌دهد. -### Writing your contributing guidelines +### نوشتن راهنمای مشارکت -A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on: +فایل CONTRIBUTING (مشارکت) به مخاطبان‌تان می‌گوید که چگونه در پروژه‌ی شما مشارکت کنند. به عنوان مثال، می‌توانید اطلاعات زیر را در آن قید کنید: -* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates)) -* How to suggest a new feature -* How to set up your environment and run tests +* چگونه یک باگ یا مشکل گزارش شود +* چگونه ویژگی جدیدی پیشنهاد دهند +* چگونه محیط پروژه‌تان را تنظیم و آن را برای تست اجرا کنند -In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as: -* The types of contributions you're looking for -* Your roadmap or vision for the project -* How contributors should (or should not) get in touch with you +به علاوه، در فایل CONTRIBUTING می‌توانید جزئیات فنی و انتظارات‌تان را برای مشارکت‌کننده‌ها بیان کنید. به عنوان مثال: -Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. +* نوع مشارکتی که به دنبال آن هستید +* نقشه‌ی راه یا دیدگاهی که به پروژه دارید +* چگونه مشارکت‌کننده‌ها باید (یا نباید) با شما در تماس باشند -For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with: +زمانی که با خونگرمی، حس دوستانه و دادن پیشنهادهای خاص (مانند نوشتن اسناد، یا طراحی وب‌سایت) با مشارکت‌کننده‌هایتان برخورد می‌کنید، بیشتر راه را برای استقبال از تازه‌واردها رفته‌اید و همین کار شما باعث می‌شود آن‌ها برای همکاری با شما هیجان‌زده شوند. -> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. +برای روشن شدن مطلب اجازه دهید نمونه‌ای بیاوریم. به عنوان مثال، [Active Admin](https://github.com/activeadmin/activeadmin/) [راهنمای مشارکت خود](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) به مشارکت‌کننده‌ها را اینگونه شروع می‌کند -In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution. +> در ابتدا، از شما ممنون هستم که می‌خواهید با Active Admin مشارکت کنید. افرادی مثل شما هستند که باعث می‌شوند Active Admin عملکرد خوبی داشته باشد. -Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again. +در ابتدایی‌ترین مرحله‌ی پروژه‌تان، فایل CONTRIBUTING می‌تواند ساده باشد. شما در این فایل همیشه باید نحوه‌ی گزارش دادن باگ‌ها (خطاها) یا مشکلات فایل و هر نیاز فنی مانند تست کردن را برای مشارکت‌کننده‌ها توضیح دهید. -For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). +در طول زمان، ممکن است اطلاعات و سوالات مکرر زیادی به فایل CONTRIBUTING خود اضافه کنید. از این رو، افراد کمتری پیدا می‌شوند که سوالات تکراری از شما بپرسند. -Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. +برای اینکه بدانید چگونه اطلاعات فایل CONTRIBUTING خود را بنویسید، می‌توانید به مقالات @nayafia’s [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) یا @mozilla’s ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) مراجعه کنید -![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg) +[لینک فایل CONTRIBUTING خود را در فایل README قرار دهید](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) تا افرادی که آن را مطالعه می‌کنند این فایل مشارکت را هم ببینند. اگر فایل CONTRIBUTING خود را در repository (انبار) (مخزن) پروژه‌تان قرار داده باشید، زمانی که یک مشارکت‌کننده طرح مشکل یا گزارش یک باگ یا درخواست ادغام کند، GitHub به صورت خودکار او را به لینک فایل CONTRIBUTING هدایت می‌کند -### Establishing a code of conduct +![راهنماهای مشارکت](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### تعیین آیین نامه‌ی رفتاری (Code of Conduct) -Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer. +بالاخره، آیین نامه‌ی رفتاری به ما کمک می‌کند برای رفتارهای مشارکت‌کننده‌های پروژه‌تان قوائدی تعیین کنید. زمانی که بخواهید یک پروژه‌ی متن بازی را برای انجمن یا یک شرکت منتشر کنید، این قوائد می‌تواند ارزشمند باشد. آیین نامه‌ی رفتاری یا (Code of Conduct) این قدرت را به شما می‌دهد تا رفتارهای سازنده و سالم را در بین جامعه کاربران ترویج کنید که در آینده به عنوان یک مسئول‌نگهداری پروژه احساس استرس کمتری داشته باشید. -For more information, check out our [Code of Conduct guide](../code-of-conduct/). +برای اطلاعات بیشتر می‌توانید به [راهنمای آیین نامه‌ی رفتاری](../code-of-conduct/) مراجعه کنید. -In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs. +علاوه بر اینکه یک آیین نامه‌ی رفتاری رفتارهایی که از شرکت‌کنند‌هایتان انتظار دارید را باید به آن‌ها بگوید، این را هم باید تعریف کنید که اجرای این انتظارات به چه کسانی و در چه زمان‌هایی باید انجام می‌شود. آیین نامه‌ی رفتاری همچنین مشخص می‌کند که درصورت بروز تخلف چه کاری باید انجام شود. -Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. +مشابه استفاده از مجوزهایی که از قبل توسط دیگران تدوین شده استانداردهای نوظهوری برای آیین نامه‌ی رفتاری وجود دارد که لازم نیست خودتان آن را بنویسید. (https://contributor-covenant.org/)[Contributor Covenant] یکی از جاهایی است که آیین نامه‌هایی در همین خصوص ارائه می‌کند و حاصل کار آن در [بیش از 40.000 پروژه‌ی متن باز](https://www.contributor-covenant.org/adopters) مانند Kubernetes، Rails و Swift استفاده می‌شود. مهم نیست متن آیین نامه‌ی رفتاری شما چیست، مهم این است که در صورت لزوم باید از آیین نامه‌ی رفتاری خودتان استفاده کنید -Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README. +متن آیین نامه‌ی رفتاری خود را مستقیما در فایل CODE_OF_CONDUCT در repository (مخزن) گیت هاب خودتان کپی و پیست کنید. فایل را در دایرکتوری روت پروژه‌تان ذخیره کنید تا پیدا کردن و لینک دادن آن به فایل README راحت باشد. -## Naming and branding your project +## نام‌گذاری و برندسازی پروژه -Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message. +برندسازی چیزی فراتر از یک لوگوی پُر زرق وُ برق یا یک نام جذاب برای پروژه‌تان است. برندسازی نحوه‌ی صبحت کردن درباره‌ی پروژه و نحوه رساندن پیام به مخاطب‌تان را نشان می‌دهد. -### Choosing the right name +### انتخاب نام درست -Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example: +برای پروژه‌تان از نامی استفاده کنید که یادآوری آن ساده باشد. به طور ایده آل، می‌توانید بعضی از ایده‌ها را از پروژه‌های زیر مشاهده کنید. به عنوان نمونه: -* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting -* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server +* [Sentry](https://github.com/getsentry/sentry) اپ ها را با هدف گزارش خطاهای رخ داده در آنها پایش می کند +* [Thin](https://github.com/macournoyer/thin) یک وب سرور ساده و سریع روبی است -If you're building upon an existing project, using their name as a prefix can help clarify what your project does (for example, [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js). +اگر در حال طراحی پروژه‌تان هستید، به کارگیری نام آن‌ها به عنوان پیشوند می‌تواند به شفاف کردن پروژه‌تان کمک کند. به عنوان نمونه، ([node-fetch](https://github.com/bitinn/node-fetch)، Window.fetch را به Node.js می‌آورد). -Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work! +با در نظر گرفتن توصیه بالا. می‌توان عناوین بامزه یا خوب زیادی ساخت، اما این را به یاد داشته باشید که بعضی از بازی با کلمات و جناس‌ها ممکن است در سایر فرهنگ‌ها یا افرادی که تجربه‌های متفاوتی نسبت به شما دارند، مفهوم یا ترجمه‌ی نادرستی داشته باشد. برخی از کاربران بالقوه شما هم ممکن است کارمندان یک شرکت باشند و حتما نمی‌خواهید زمانی که در حال توضیح دادن نحوه‌ی پروژه‌تان در محل کارشان هستند، احساس نامساعدی داشته باشند. -### Avoiding name conflicts +### از نام‌گذاری‌های دارای منافات خودداری کنید -[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. +اگر پروژه‌ی شما زبان و اکوسیستم یکسانی دارد، می‌توانید نام پروژه‌های مشابه با پروژه‌تان را [بررسی کنید](http://ivantomic.com/projects/ospnc/). اگر نام پروژه‌ی شما با پروژه‌ی دیگری شباهت زیادی داشته باشد، مخاطب شما ممکن است سردرگم شود. -If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet. +اگر با یک وب‌سایت، توئیتر یا دیگر شبکه‌های اجتماعی می‌خواهید پروژه‌تان را نشان دهید، مطمئن شوید همان نامی را انتخاب کنید که می‌خواهید. به طور ایده آل، حتی اگر هنوز نمی‌‌خواهید از آن نام استفاده کنید و برای اینکه خیال‌تان راحت باشد، آن نام را [وارونه کنید](https://instantdomainsearch.com/) -Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk. +مطمئن شوید نام پروژه‌ی شما هیچ برند تجاری را نقض نمی‌کند. اگر چنین باشد، آن شرکت می‌تواند بعدها از شما درخواست کند پروژه‌تان را کنسل کرده یا حتی به صورت قانونی با شما برخورد کند. بنابراین، ارزش این همه ریسک را ندارد و برای جلوگیری از چنین مشکلاتی حتما از نام مناسبی استفاده کنید. -You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/). +برای بررسی تضاد و منافات برندهای تجاری می‌توانید به پایگاه داده برندهای جهانی [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) مراجعه کنید. اگر شما یک شخص حقوقی هستید و در یک شرکت فعالیت می‌کنید، این یکی از چیزهایی است که [تیم حقوقی‌تان می‌تواند](../legal/) به شما کمک کند -Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see? +در نهایت، نام پروژه‌تان را به سرعت در گوگل جستجو کنید. ببینید که افراد به راحتی می‌توانند پروژه‌تان را پیدا کنند؟ در نتایج جستجوی شما چیزی دیگر پیدا می‌شود که نمی‌خواهید کاربران آن را مشاهده کنند؟ -### How you write (and code) affects your brand, too! +### چگونه نوشتن و کدنویسی شما روی برندتان اثر می‌گذارد! -Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists. +در طول عمر پروژه‌تان، در حال نوشتن چیزهای زیادی خواهید بود که می‌توان به نوشتن فایل‌های README، آموزش‌ها، اسناد انجمن، نوشتن پاسخ به مشکلات، حتی شاید نوشتن و پاسخ دادن به خبرنامه و فهرست پستی، اشاره کرد. -Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey. +سبک نویسندگی شما چه در اسناد رسمی و چه در ایمیل‌های محاوره‌ای بخشی از برند پروژه‌تان است. به این فکر کنید چگونه می‌خواهید با مخاطب‌تان برخورد کنید و ببینید این لحن نوشتاری همان چیزی است که می‌خواهید به مخاطب فرستاده شود یا خیر. -Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers. +زمانی که از یک زبان جامع و گرم استفاده می‌کنید و حتی زمانی که با یک فرد صحبت می‌کنید، به جای کلمه‌ی «تو» کلمه‌ی «شما» را به کار می‌برید، کمک زیادی به شما می‌کند تا مشارکت‌کننده‌های جدید از پروژه‌ی شما استقبال کنند. اگر می‌خواهید به زبان انگلیسی بنویسید، سعی کنید ساده باشد. چون زبان بیشتر خواننده‌های شما بومی نیست. -Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. +جدا از کلماتی که در نوشتن اسناد مختلف استفاده می‌کنید، سبک کدنویسی شما هم ممکن است به بخشی از برند پروژه‌تان تبدیل شود. به عنوان مثال می‌توانیم به دو نمونه پروژه به نام‌های [Angular](https://angular.io/guide/styleguide) و [jQuery](https://contribute.jquery.org/style-guide/js/) اشاره کنیم که راهنما و سبک کدنویسی سختی دارند -It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. +در ابتدای کار لازم نیست از راهنمای سبک نویسندگی استفاده کنید. به هر حال، به مرور از ترکیب سبک متفاوت کدنویسی خود در پروژه‌تان لذت خواهید برد. هرچند، این را باید پیش‌بینی کنید که نحوه‌ی نویسندگی و سبک کدنویسی شما ممکن است انواع مختلف افراد را جذب یا دفع کند. در ابتدای‌ترین مرحله‌ی پروژه‌تان فرصت دارید مقدماتی که می‌خواهید مخاطبان ببنند را ارائه دهید. -## Your pre-launch checklist +## مرور (چک لیست / لیست بررسی) قبل از انتشار پروژه‌ی متن باز -Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back. +خب، آماده هستید تا پروژه‌تان را متن باز کنید؟ چک لیست در این مرحله می‌تواند به شما کمک کند. تمام گزینه‌ها و تیک‌ها را بررسی کرده‌اید؟ به محض آماده شدن، روی انتشار [publish](https://help.github.com/articles/making-a-private-repository-public/) کلیک کنید و به خودتان تبریک بگویید. -**Documentation** +**مستندات**
-**Code** +**کد**
@@ -313,50 +311,51 @@ Ready to open source your project? Here's a checklist to help. Check all the box -**People** +**افراد** -If you're an individual: +اگر شما شخص حقیقی هستید:
-If you're a company or organization: +اگر شخص حقوقی هستید و در یک سازمان یا یک شرکت فعالیت می‌کنید:
+ یک شخص برای مدیریت تعاملات اجتماعی (پاسخ به مشکلات، بررسی و درخواست ادغام) که متعهد باشد حضور دارد. +
-## You did it! +## انجامش دادی! -Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow. +اولین پروژه‌ی متن بازتان را تبریک می‌گوییم. بهتر است بدانید که خروجی آن مهم نیست، فقط با این کار تجربه‌ی کار در فضای جامعه را به دست آوردید. با هر کامیت (Commit)، کامنت (Comment) و پاسخ به درخواست ادغام فرصتی برای رشد و یادگیری خود و دیگران ایجاد می‌کنید. From 92fdd15c23425f7b79c453eb6a38103607af882e Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Thu, 6 May 2021 08:52:32 +0000 Subject: [PATCH 016/629] Bump rexml from 3.2.4 to 3.2.5 Bumps [rexml](https://github.com/ruby/rexml) from 3.2.4 to 3.2.5. - [Release notes](https://github.com/ruby/rexml/releases) - [Changelog](https://github.com/ruby/rexml/blob/master/NEWS.md) - [Commits](https://github.com/ruby/rexml/compare/v3.2.4...v3.2.5) Signed-off-by: dependabot[bot] --- Gemfile.lock | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Gemfile.lock b/Gemfile.lock index 86995d3742f..33561394aab 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -238,7 +238,7 @@ GEM rb-fsevent (0.10.4) rb-inotify (0.10.1) ffi (~> 1.0) - rexml (3.2.4) + rexml (3.2.5) rouge (3.26.0) ruby-enum (0.9.0) i18n From b489b3592cf3a35683bef3e356d18e57ad22d95a Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Fri, 7 May 2021 15:31:34 +0430 Subject: [PATCH 017/629] Initial translation done. --- _articles/fa/building-community.md | 228 ++++++++++++++--------------- 1 file changed, 114 insertions(+), 114 deletions(-) diff --git a/_articles/fa/building-community.md b/_articles/fa/building-community.md index a86c8b26c55..906428112c8 100644 --- a/_articles/fa/building-community.md +++ b/_articles/fa/building-community.md @@ -1,12 +1,8 @@ --- -lang: en -title: Building Welcoming Communities -description: Building a community that encourages people to use, contribute to, and evangelize your project. +lang: fa +title: ساخت انجمن های پذیرا +description: ساخت یک انجمن که افراد را به استفاده کردن ، به اشتراک گذاری و تبلیغ کردن پروژه تان ترغیب کند. class: building -toc: - setting-your-project-up-for-success: "Setting your project up for success" - growing-your-community: "Growing your community" - resolving-conflicts: "Resolving conflicts" order: 4 image: /assets/images/cards/building.png related: @@ -14,267 +10,271 @@ related: - coc --- -## Setting your project up for success +## پروژه تان را برای موفقیت راه اندازی کنید -You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around? +وقتی شما پروژه خود را راه اندازی کنید، مطالبی را پخش می کنید و افراد در حال بررسی آنها هستند. حالا سوال اینجا است که چطور باید از آنها بخواهید که در انتظار مطالب‌تان باشند؟ -A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back. +یک انجمن پذیرا ، یک نوع سرمایه گذاری برای شهرت و آینده پروژه تان است. اگر پروژه تان در حال آغاز کسب مشارکتهای اولیه اش است، با اعطای یک تجربه مثبت به مشارکت کننده های اولیه شروع کنید، و برای آنها به عقب برگشتن را ساده سازید -### Make people feel welcome -One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): +### کاری کنید تا افراد احساس پذیرفته شدن داشته باشند + +یک راه برای تفکر درباره انجمن پروژه تان از طریق آنچه مایک مک کویید آن را [قیف مشارکت کننده](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) می نامد میسر است. ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) -As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more. +در حین اینکه شما انجمن خود را می سازید، در نظر بگیرید چطور فردی در بالای قیف( یک کاربر بالقوه) می تواند از لحاظ نظری راهش را به ته قیف ( یک نگهدارنده فعال) هموار سازد. هدف شما این است که ناسازگاری در هر مرحله تجربه مشارکت کننده را کاهش دهید. وقتی افراد، بردهای آسانی دارند، آنها انگیزه بیشتری برای ادامه کار دارند. + +با مستندات خود شروع کنید: -Start with your documentation: +* **برای افراد استفاده از پروژه خود را ساده سازید:** یک مثال از آن کد واضح و [README دوستانه](../starting-a-project/#writing-a-readme) است که راه اندازی پروژه تان را برای هر کسی هموارتر می سازد. +* **بطور واضح توضیح دهید که مشارکت چگونه است،** البته این کار با استفاده از [فایل مشارکت](../starting-a-project/#writing-your-contributing-guidelines) و به روز نگه داشتن موضوعات میسر است. -* **Make it easy for someone to use your project.** [A friendly README](../starting-a-project/#writing-a-readme) and clear code examples will make it easier for anyone who lands on your project to get started. -* **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date. -* **Good first issues**: To help new contributors get started, consider explicitly [labeling issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level. +* **موضوعات اولیه خوب:** برای کمک کردن به اینکه مشارکت کنندگان جدید کار خود را شروع کنند، [برچسب زدن به موضوعاتی که برای موفقیت مبتدی ها به قدر کافی ساده هستند](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels) را بطور آشکار لحاظ کنید. سپس GitHub، این موضوعات را در محل های مختلف روی پلتفورم هموار می سازد، و مشارکت های مفید را افزایش می دهد و سپس ناسازگاری از کاربران مختلف در فائق آمدن بر موضوعاتی که در سطح آنها خیلی دشوار است را کاهش می دهد. -[GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) showed incomplete or confusing documentation is the biggest problem for open source users. Good documentation invites people to interact with your project. Eventually, someone will open an issue or pull request. Use these interactions as opportunities to move them down the funnel. +{نظرسنجی منبع باز( اوپن سورس) 2017 GitHub][GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) که مستندات ناقص و گیچ کننده ای را نشان می داد، بزرگترین مشکل برای کاربران منبع باز می باشد. مستندات خوب، افراد را دعوت می کند که با پروژه‌تان تعامل کنند. در نهایت افراد یک موضوع یا یک درخواست pull( ادغام یا یکپارچگی) را باز خواهند کرد. از این تعاملات به عنوان فرصتهایی برای سوق دادن آنها به پایین قیف استفاده کنید. -* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back. -* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project. -* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help. -* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it. +* **وقتی شخص جدیدی وارد پروژه شما می شود، از وی از روی علاقه تشکر کنید!** این یک تجربه منفی خواهد بود که از فردی بخواهید که از پروژه تان خارج نشود. +* **پاسخگو باشید:** اگر شما به موضوعاتشان در عرض یک ماه پاسخ نمی دهید، شانس اینکه پروژه تان را فراموش کنند بالا می رود. +* **درباره انواع مشارکت هایی که خواهید پذیرفت ، پذیرای عقاید و افکار جدید باشید.** بسیاری از مشارکت کننده ها با یک گزارش باگ یا ترمیم جزئی آغاز می کنند. راه های زیادی برای مشارکت در یک پروژه وجود دارد. به افراد اجازه دهید تا بازگو کنند [چطور می خواهند مساعدت کنند](../how-to-contribute/#what-it-means-to-contribute). +* **اگر یک مشارکتی وجود دارد که شما با آن مخالف هستید،** از آنها به خاطر بیان ایده تشکر کرده و [توضیح دهید](../best-practices/#learning-to-say-no) چرا آن ایده با محدوده پروژه تان تناسب ندارد، و اگر مستندات خوبی دارید رو کنید. -The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute. +اکثریت مشارکت کنندگان منبع باز، مشارکت کنندگان اتفاقی هستند: افرادی که تنها گهگاه در یک پروژه مشارکت می کنند. یک مشارکت کننده اتفاقی شاید زمان کافی برای همگامی با پروژه تان را نداشته باشد، پس کارتان این است که مشارکت را برای او تا حد ممکن ساده تر سازید. -Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself. +ترغیب کردن مشارکت کنندگان دیگر یک سرمایه گذاری روی خودتان می باشد. وقتی شما بزرگترین طرفدارانتان را توانمند می سازید تا با کاری که آنها با انجامش هیجان زده می شوند همگام شوند، فشار کمی برای انجام کامل کار توسط خودتان اعمال می شود. -### Document everything +### مستند کردن همه چیز -When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public. +وقتی شما یک پروژه جدید را آغاز می کنید، شاید احساس طبیعی تان این باشد که کارتان را باید خصوصی ادامه دهید. اما پروژه های منبع باز هنگامی شما را برمی انگیزند که شما پروسه تان را بطور علنی مستند می سازید. -When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed. +وقتی شما کارها را می نویسید، افراد بیشتری می توانند در هر مرحله از رویه ها مشارکت کنند. شما ممکن است درباره چیزی کمک بخواهید چیزی که حتی در حد لزوم هم آن را نمی دانستید. -Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public. +مکتوب کردن چیزها معنایی بیشتر از مستندسازی فنی صرف دارد. هر زمان شما احساس می کنید که مصر هستید تا کاری را مکتوب کنید یا بطور خصوصی پروژه تان را بحث کنید، از خودتان بپرسید که آیا می توانید آنرا علنی کنید یا نه؟ -Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions. +درباره نقشه مسیر پروژه تان ، انواع مشارکت هایی که شما در پی آنها هستید، اینکه چطور مشارکت ها بررسی می شوند یا اینکه چرا تصمیمات خاصی را اتخاذ می کنید ، شفاف سازی کنید. -If you notice multiple users running into the same problem, document the answers in the README. +اگر شما کاربران متعددی را مطلع سازید تا مسئله مشابهی را بررسی کنند، جوابها را در README مستند سازید. -For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you. +برای جلسات، منتشر کردن یادداشت ها و نقشه های مسیر خود در یک موضوع مرتبط را مدنظر قرار دهید. بازخوردی که از این سطح از شفافیت کسب می کنید شاید شما را شگفت زده کند. -Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on. +مستندسازی همه چیزها با کاری که شما انجام می دهید نیز همگام است. اگر شما در حال کار بر روی آپدیت کردن پروژه تان در حجم زیاد هستید، برای آن یک بخش درخواست pull اعمال کنید و آن را به عنوان کاری که در حال پیشرفت است نمره دهید(WIP). از این طریق، افراد دیگر می توانند در پروسه شما اعمال نظر کنند -### Be responsive +### پاسخگو باشید -As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started. +در حین اینکه شما [پروژه تان را ارتقا می دهید](../finding-users)، افراد شاید بازخوردهایی برای شما داشته باشند. آنها ممکن است درباره اینکه چطور موارد کار می کنند سوالاتی داشته باشند، یا برای شروع نیاز به کمک داشته باشند. -Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating. +سعی کنید که هنگامی که شخصی یک موضوع را پیوست می کند، تحویل می دهد یا درخواستی دارد یا درباره پروژه تان سوالی می پرسد پاسخگو باشید. وقتی شما به سرعت پاسخ دهید، افراد احساس خواهند کرد که آنها بخشی از یک گفتگو هستند و درباره مشارکت با شما مشتاق تر خواهند بود. -Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466): +حتی اگر نمی توانید درخواستشان را فوراً بررسی کنید،حداقل از آنها تشکر کنید تا به افزایش مشارکت کمک کرده باشید. اینجا بیان می شود چطور @tdreyno به یک درخواست pull در سایت [Middleman](https://github.com/middleman/middleman/pull/1466) پاسخ داده است: ![Middleman pull request](/assets/images/building-community/middleman_pr.png) -[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution. +[یک مطالعه موزیلا](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) پی برده است که مشارکت کنندگانی که بررسی های کدگونه را در ظرف 48 ساعت دریافت کرده بودند میزان برگشت و تکرار مشارکت خیلی بیشتری داشتند -Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project. +همچنین مکالمات درباره پروژه تان می تواند در محل های د Oیگری در اینترنت مانند Stackverflow ، توییتر، یا Reddit روی دهد. شما می توانید در برخی از این محل ها نوتیفیکیشن هایی را اجرا کنید و بدین طریق هنگامی که شخصی به پروژه تان اشاره می کند، با خبر شوید. -### Give your community a place to congregate +### به انجمن تان یک محلی برای مشارکت کردن اختصاص دهید -There are two reasons to give your community a place to congregate. +دو دلیل برای اعطای یک محل برای مشارکت در انجمن‌تان وجود دارد. -The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate. +اولین دلیل به خاطر مشارکت کنندگان است. به افراد کمک کنید تا همدیگر را بشناسند. افراد دارای منافع مشترک، بطور اجتناب ناپذیری می خواهند که محلی برای گفتگو درباره آن منافع داشته باشند. و وقتی ارتباطات علنی و قابل دسترس باشد، هر کسی می تواند آرشیوهای گذشته را بخواند تا به مشارکت خود شتاب بخشد. -The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel. +دلیل دوم به خاطر خود شما است. اگر شما به افراد محل عمومی برای صحبت درباره پروژه تان ندهید، آنها احتمالاً با شما مستقیماً تماس خواهند گرفت. در شروع، ظاهراً ساده است که به پیامهای خصوصی با موضوع « فقط اینبار»پاسخ دهید. اما در طول زمان مخصوصاً اگر پروژه تان معروف شود، شما کلافه خواهید شد. در برابر وسوسه ارتباط برقرار کردن با افراد درباره پروژه تان بطور خصوصی مقاومت کنید. در عوض آنها را به یک کانال عمومی معین هدایت کنید. -Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above! +ارتباطات عمومی می تواند در حقیقت هدایت کردن مردم برای باز کردن یک موضوع به جای ایمیل مستقیم یا اظهار نظر کردن روی وبلاگ‌تان باشد. همچنین شما می توانید یک لیست مِیلی داشته باشید، یا یک حساب توییتر، Slack یا کانال IRC برای افراد راه بیاندازید تا درباره پروژه تان گفتگو کنند. یا همه موارد بالا را با هم اعمال کنید! -[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members: +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) هر هفته وقت خود را در ساعات اداری به کمک به اعضای انجمن اختصاص می دهد: -> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features. +> همچنین کاپس هر هفته زمانی را برای پیشنهاد دادن کمک و راهنمایی به انجمن اختصاص می دهد. مالکان کاپس با اختصاص زمان اختصاصی برای کار کردن با تازه واردها، کمک به PRs ، و بحث درباره ویژگی های جدید موافقت کرده اند. -Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address. +استثنائات قابل توجهی در مورد ارتباطات عمومی وجود دارد از قبیلِ: موضوعات امنیتی و نقض کدهای رفتاری حساس. شما باید همیشه راهی پیش پای افراد بگذارید تا این موضوعات را بطور خصوصی گزارش کنند. اگر نمی خواهید که از ایمیل شخصی خود استفاده کنید، یک آدرس ایمیل اختصاصی ایجاد کنید. -## Growing your community +## انجمن‌تان را رشد دهید -Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction. +انجمنها بی نهایت قدرتمند هستند. این قدرت می تواند مفید یا مضر باشد که به این بستگی دارد که چطور آن را اعمال می کنید. در حین اینکه انجمن پروژه تان رشد می کند، راه هایی برای کمک به آن وجود دارد تا به جای نیروی مخرب یک نیروی سازنده باشد. -### Don't tolerate bad actors +### بازیگران بد را تحمل نکنید -Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others. +هر پروژه معروفی ناگزیر افرادی که ضرررسان هستند را نیز جذب خواهد کرد. آنها شاید بحثهای غیرضروری را شروع کنند، درباره ویژگی های جزئی خرده گیری کنند یا برای بقیه قلدری کنند. -Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave. +شما به بهترین نحو تلاش کنید تا یک خطی مشی تحمل-صفر نسبت به این نوع افراد اقتباس کنید. اگر افراد منفی را چک نکنید ، افراد دیگر در جامعه تان را نیز ناراحت خواهند ساخت. آنها حتی شاید پروژه تان را ترک کنند. -Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate. +بحثهای دائمی بر روی جنبه های جزئی پروژه تان، افرا دیگر از جمله خود شما را از تمرکز روی کارهای مهم دیگر بازمی دارد. افراد جدیدی که وارد پروژه تان می شوند شاید این مکالمات را ببینند و در نتیجه مشارکت نکنند. -When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations. +وقتی می بینید رفتار منفی‌ای در پروژه تان رخ می دهد، آن را علنی کنید. با لحن قاطع توضیح دهید که چرا رفتارشان قابل قبول نیست. اگر این مسئله دائماً وجود داشت شاید نیاز داشته باشید که از [آنها بخواهید تا پروژه تان را ترک کنند](../code-of-conduct/#enforcing-your-code-of-conduct). [کد رفتاری‌تان](../code-of-conduct/) می تواند یک رهنمود سازنده برای این مکالمات باشد. -### Meet contributors where they're at +### با مشارکت کنندگان تماس بگیرید و در جریان قرار بگیرید که آنها در کجای کار هستند -Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need. +مستندسازی خوب تنها هنگامی مهمتر می شود که انجمن تان رشد می کند. مشارکت کنندگان اتفاقی که ممکن است با پروژه تان آشنا نباشند ، مستنداتتان را می خوانند تا به سرعت متنی که آنها نیاز دارند را بدست آورند. -In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors. +در فایل Contributing خود، بطور آشکار به مشارکت کنندگان جدید بگویید که چگونه کار خود را شروع کنند. شما شاید حتی بخواهید که یک بخش اختصاصی برای این منظور بسازید. برای مثال [Django](https://github.com/django/django) یک صفحه ویژه برای خوشامدگویی به مشارکت کنندگان جدید دارد ![Django new contributors page](/assets/images/building-community/django_new_contributors.png) -In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started. +در صف موضوعتان ، باگهایی که برای انواع مختلف مشارکت کنندگان مناسب هستند، وجود دارد: برای مثال [_تنها اولین دفعه_](https://kentcdodds.com/blog/first-timers-only) ، « اولین موضوع خوب» یا « مستندات» را برچسب بزنید. این برچسب ها برای فرد جدید، بررسی سریع پروژه و شروع به کار بر روی موضوعاتتان را آسان می سازد -Finally, use your documentation to make people feel welcome at every step of the way. +سرانجام از مستندات‌تان استفاده کنید تا افراد را در هر مرحله از این رویه خرسند سازید. -You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration. +شما هرگز با اکثر افرادی که وارد پروژه تان می شوند تعامل نخواهید کرد. شاید مشارکتهایی وجود داشته باشد که آنها را دریافت نکرده اید چون برخی از افراد نمی دانند از کجا باید مشارکت خود را شروع کنند. حتی کلمات کمی وجود دارند که با آن می توان افراد را از ترک کردن پروژه تان به خاطر اشباع شدن بازداشت. -For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): +برای مثال، در اینجا ما [رهنمودهای مشارکت](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) پروژه [روبینیوس]https://github.com/rubinius/rubinius/) را می آوریم: -> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue. +> ما می خواهیم که کار خود را با قدردانی از شما برای استفاده از روبینیوس شروع کنیم. این پروژه یک کار عاشقانه است و ما از همه کاربرانی که باگها را معرفی می کنند، عملکردها را بهبود می دهند و به مستندسازی کمک می کنند، قدردانی می کنیم. هر مشارکتی مهم است پس از شما برای مشارکت سپاسگزاری می کنیم. اینکه گفته می شود اینجا رهنمودهای کمی وجود دارند که ما از شما بخواهیم تا از آنها پیروی کنید، می تواند باعث موفقیت رسیدگی به موضوعتان شود. -### Share ownership of your project +### مالکیت پروژه تان را به اشتراک گذارید -People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around. +افراد با مشارکت در پروژه هایتان هنگام احساس مالکیت بر آن هیجان زده می شوند. این بدان معنی نیست که شما باید چشم انداز پروژه تان را تغییر دهید یا مشارکتهایی که شما نمی خواهید را بپذیرید. اما هرچه به دیگران اعتبار بیشتری ببخشید، آنها بیشتر انتظار آن را می کشند. -See if you can find ways to share ownership with your community as much as possible. Here are some ideas: +ببینید آیا می توانید تا آنجا که ممکن است راه هایی را برای تسهیم مالکیت با انجمن تان بیابید. در اینجا بعضی ایده ها در این باره ارائه می شوند: + +* **در برابر رفع باگ های ( غیرسرنوشت ساز) ساده مقاومت کنید:** در عوض از آنها به عنوان فرصتهایی برای پذیرش مشارکت کنندگان جدید استفاده کنید، یا شخصی که تمایل به مشارکت دارد، را راهنمایی کنید. شاید در اول غیرطبیعی به نظر برسد، اما سرمایه گذاری‌تان در طول زمان بازدهی‌اش را به تدریج بدست خواهد داد. برای مثال، @michaeljoseph از یک مشارکت کننده خواست تا درخواست Pull خود را درباره موضوع [Cookiecutter](https://github.com/audreyr/cookiecutter) به جای تعمیر آن توسط خودش ارائه دهد. -* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself. ![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) -* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does. +* **یک فایل مشارکت کننده یا مولف در پروژه تان را شروع کنید** تا همه افرادی که به پروژه تان کمک می کردند مانند [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) را لیست کنید. -* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples. +* **اگر شما یک انجمن بزرگ دارید، یک خبرنامه منتشر کنید یا یک پست وبلاگی بنویسید** که قدردان مشارکت کنندگان هستید. خبرنامه های [This Week in Rust](https://this-week-in-rust.org/) و [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) هودی دو نمونه خوب از این موارد هستند. -* **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](https://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile. +* **به همه مشارکت کنندگان دسترسی Commit کردن بدهید.** @fleixge پی برد که این کار، [افراد را وادار می کند](https://felixge.de/2013/03/11/the-pull-request-hack.html) تا با هیجان بیشتری patch هایشان را اصلاح کنند و حتی باعث می شود اعضای جدید برای پروژه هایی بیابید که روی آنها سرمایه گذاری نکرده بودید. -* If your project is on GitHub, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators. +* اگر پروژه تان روی گیت هاب است، **آن را از حساب شخصی خود به یک [سازمان](https://help.github.com/articles/creating-a-new-organization-account/) انتقال دهید** و حداقل یک ادمین پشتیبان به آن بیافزایید. سازمان ها کار کردن روی پروژه هایی با همکاران خارجی را آسانتر می سازند. -The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help. +واقعیت این است که [اکثر پروژه ها](https://peerj.com/preprints/1233.pdf) تنها دارای یک یا دو عضو هستند کسانی که اکثر کار را انجام می دهند. هرچه پروژه تان بزرگتر باشد، و هرچه انجمن تان بزرگتر باشد، دستیابی به کمک ساده تر خواهد بود. -While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help. +در حالی که شاید همیشه شخصی را برای جواب دادن به تماس ها نیابید، اما فرستادن سیگنالهایی به آنجا شانسی که افراد دیگر در پروژه همکاری بکنند را افزایش خواهد داد. و اینکه هرچه زودتر اقدام کنید، افراد زودتر می توانند به شما کمک کنند. -## Resolving conflicts +## حل و فصل تضادها -In the early stages of your project, making major decisions is easy. When you want to do something, you just do it. +در مراحل اولیۀ پروژه تان، اتخاذ کردن تصمیمات بزرگ ساده است. وقتی می خواهید که کاری را انجام دهید، شما فقط مشغول انجام آن شوید. -As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own. +در حین اینکه پروژه تان معروف تر می شود، مردم بیشتری از تصمیماتی که شما اتخاذ می کنید سود می برند. حتی اگر انجمن بزرگی از مشارکت کنندگان را ندارید، و اگر پروژه تان دارای کاربران زیادی نیست، شما افرادی را خواهید یافت که تصمیمات را می سنجند و موضوعاتی مرتبط با خودشان را مطرح می کنند. -For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address. +برای اکثر بخش ها، اگر شما یک انجمن محترم و صمیمی را پرورش می دهید و پروسه تان را علنی مستندسازی کنید، انجمن تان باید قادر باشد تا راه حل را پیدا کند. اما گاهی اوقات شما موضوعی را مطرح می کنید که پرداختن به آن یک کمی دشوارتر است. -### Set the bar for kindness +### قالبی برای نوع دوستی تعیین کنید -When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you. +وقتی انجمن تان با یک موضوع خاص مواجه است، مجرب ها ممکن است داوطلب شوند. افراد ممکن است عصبی شوند یا اشباع شوند و آن وظیفه را به شما یا دیگری محول کنند. -Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive. +کارتان به عنوان یک نگاهدارنده آن است که از وخیم تر شدن شرایط جلوگیری کنید. حتی اگر شما عقیده قوی‌ای به این موضوع دارید، سعی کنید که جایگاه یک میانجی یا تسهیل کننده را داشته باشید به جای اینکه به نبرد با دیدگاه تان وارد شوید. اگر شخصی در حال بی مهر شدن است یا دارد مکالمات را انحصاری می سازد، [فوراً اقدام کنید](../building-community/#dont-tolerate-bad-actors) تا مباحثات را مدنی و سودمند نگه دارید. -Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly. +افراد دیگر به رهنمودهای شما نگاه می کنند. یک نمونه خوب را تعیین کنید، شما هنوز می توانید ناامیدی، ناراحتی یا نگرانی را اظهار کنید اما آرامش خود را کاملاً حفظ کنید. -Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you. +خونسرد بودن آسان نیست، اما نشان دادن رهبری ، سلامت انجمن تان را بهبود می بخشد. اینترنت از شما تشکر می کند. -### Treat your README as a constitution +### فایل README خود را به عنوان یک قانون اساسی در نظر بگیرید -Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion. +فایل README تان [بیشتر از یک مجموعه رهنمودها است](../starting-a-project/#writing-a-readme)، همچنین یک محلی برای گفتگو درباره اهداف، دیدگاه و نقشه مسیرتان است. اگر افراد آشکارا روی بحث درباره ارزش یک ویژگی خاص تمرکز می کنند، این کار به تجدیدنظر درباره README تان و صحبت درباره دیدگاه بهتر درباره پروژه تان کمک می کند. تمرکز روی README تان همچنین این مکالمات را غیرمحرمانه می سازد، بنابراین شما می توانید یک بحث سازنده را دنبال کنید. -### Focus on the journey, not the destination +### تمرکز روی سفر نه مقصد -Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns. +برخی پروژه ها از یک فرایند رای گیری استفاده می کنند تا تصمیمات بزرگی را اتخاذ کنند. در حالی که در نگاه اول معقول به نظر می رسد، اما رای گیری به جای گوش دادن و پرداختن به نگرانی های همدیگر روی دستیابی به یک جواب تاکید می کند. -Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place. +رای گیری می تواند سیاسی باشد، که در آن اعضای انجمن برای انجام منافع همدیگر یا رای دادن در یک راه خاص احساس تحت فشار قرار داشتن کنند. البته همه رای نمی دهند، چه [اکثریت انجمن تان سکوت پیشه کنند](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) چه کاربران فعلی که از رای آگاهی ندارند در حال جایگزین شدن باشند. -Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus. +گاهی اوقات، رای گیری یک رهگشای ضروری است. هرچه شما بیشتر توانمند باشید به جای خودِ اجماع بیشتر روی « اجماع‌جویی» تاکید می کنید. -Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion. +تحت یک فرایند اجماع جویی ، اعضای انجمن، نگرانی های بزرگ خود را بحث می کنند تا آنها احساس کنند که حرفهایشان شنیده می شود. وقتی تنها نگرانی های کوچک باقی می ماند، انجمن روی به جلو حرکت می کند.« اجماع جویی مهر تاییدی بر این مطلب است که یک انجمن شاید قادر نباشد که به یک جواب جامع دست یابد. در عوض، آن به گوش سپاری و مباحثه اولویت می دهد. -Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions. +حتی اگر شما در عمل به عنوان یک نگهدارنده پروژه یک فرایند اجماع‌جویی را اقتباس کنید، مهم است که بدانید چه افرادی در حال گوش دادن هستند. وادار کنید دیگر افراد احساس کنند که شنیده می شوند و متعهد شوید که نگرانی هایشان را حل می کنید، و راه طولانی انتشار شرایط حساس را طی می کنید. سپس حرفهایتان را با اقداماتتان مقایسه کنید. + +با به خاطر داشتن یک راه حل به یک تصمیم متمایل نشوید. مطمئن شوید که همه افراد احساس شنیده شدن می کنند و اینکه همه اطلاعات قبل از حرکت به سوی راه حل علنی شده اند. -Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution. +### مکالمه را بطور متمرکز روی کار عملی حفظ کرده و پیش ببرید -### Keep the conversation focused on action +مباحثه مهم است اما یک تفاوت بین مکالمات سودمند و غیرمفید وجود دارد. -Discussion is important, but there is a difference between productive and unproductive conversations. +مباحثات مادامی که فعالانه به سوی راه حل سوق می یابند را تشویق کنید. اگر واضح است که مکالمه بی فروغ شده یا به خارج از موضوع هدایت شده، گفتگوها دارد شخصی می شود یا افراد وارد بحثهای جزئی و حاشیه ای می شوند، زمان آن فرا رسیده که به مباحثات خاتمه دهید. -Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down. -Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues. +اجازه دادن به این مکالمات که همچنان ادامه یابد نه تنها برای موضوع تحت بررسی بد است بلکه برای سلامت انجمن تان نیز بد است. این کار پیامی می فرستد مبنی بر اینکه این نوع مکالمات مجاز هستند یا حتی انجام آنها مورد تشویق قرار می گیرد و در نتیجه می تواند روحیه افراد را از مطرح کردن و حل کردن موضوعات آتی تضعیف کند. -With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_ +با ذکر هر نکته توسط دیگران یا خودتان، از خود بپرسید که _«چطور این نکته ما را به راه حل نزدیکتر می کند؟»_ -If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation. +اگر مکالمه به سوی حل شدن سوق یافته است از گروه بپرسید که در مرحله بعد باید _چه گامهایی را انتخاب کنید؟_ تا دوباره روی مکالمه متمرکز شوید. -If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it. +اگر یک مکالمه بطور واضح هیچ روزنه ای به سوی راه حل نیافته یا هیچ اقدام واضحی برای عملیاتی شدن وجود ندارد یا اقدام مناسب قبلا اتخاذ شده، موضوع را ببندید و توضیح دهید چرا شما آن را بسته اید. -### Pick your battles wisely +### نبردهایتان را عاقلانه سازید -Context is important. Consider who is involved in the discussion and how they represent the rest of the community. +متن مهم است، در نظر بگیرید چه کسانی در بحث درگیر می شوند و چطور آنها بقیه انجمن را تحت تاثیر قرار می دهند. -Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices. +آیا همه افراد در انجمن در این باره ناراحت هستند یا حتی درگیر این موضوع هستند؟ یا آیا یک دردسرساز منحصر به فرد وجود دارد؟ فراموش نکنید که فقط صداهای فعال را در نظر نگیرید و اعضای ساکت جامعه تان را نیز لحاظ کنید. -If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread. +اگر موضوع ، نیازهای گسترده تر انجمن تان را متجلی نمی سازد، شما شاید نیاز به تایید نگرانی های افراد کمی از انجمن تان داشته باشید. اگر این یک موضوع تکرار شونده بدون یک راه حل واضح باشد، آنها را به مباحثات قبلی درباره این موضوع ارجاع دهید و موضوع را ببندید. -### Identify a community tiebreaker +### راهگشای انجمن تان را شناسایی کنید -With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker. +با یک نگرش خوب و ارتباطات واضح، اکثر شرایط دشوار قابل حل هستند. البته حتی در مکالمه سودمند، می تواند یک تفاوت در عقیده درباره چگونگی پیشرفت رویه ها وجود داشته باشد. در این موارد، یک فرد یا گروه از افرادی را شناسایی کنید که می توانند به عنوان رهگشا عمل کنند. -A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it. +یک رهگشا می تواند نگه دارنده اولیه پروژه باشد یا می تواند یک گروه کوچک از کسانی باشند که مبتنی بر رای گیری تصمیم می گیرند. بطور ایده آل شما یک رهگشا و یک فرایند مرتبط در یک فایل GOVERNANCE را شناسایی کرده اید قبل از اینکه ملزم باشید که از آن استفاده کنید. -Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible. +رهگشایتان، باید یک تصمیم گیرنده نهایی باشد. موضوعات نفاق انگیز فرصتی برای انجمن تان است تا درس بگیرد و تکامل یابد. در آغوش کشیدن این فرصتها و استفاده از یک فرایند همکارانه برای حرکت به سوی یک راه حل هرجایی شدنی است. -## Community is the ❤️ of open source +## اجتماع ها و انجمن ها ❤️ متن باز هستند -Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience. +انجمنهای سالم اما کوشا هزاران ساعت را برای منبع باز در هر هفته اختصاص می دهند. خیلی از مشارکت کنندگان به افراد دیگر به عنوان دلیلی برای کار کردن یا نکردن روی منبع باز اشاره می کنند. با یادگیری اینکه چطور از قدرت بطور سازنده بهره برداری کنید شما باید به افراد خارج از آنجا کمک کنید تا از یک تجربه منبع باز فراموش نشدنی برخوردار شوند. From faabd571cb77a8557540f150236fed9cbaa4f9a9 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Sat, 8 May 2021 02:20:05 +0430 Subject: [PATCH 018/629] Initial translation done. --- _articles/fa/code-of-conduct.md | 111 ++++++++++++++++---------------- 1 file changed, 54 insertions(+), 57 deletions(-) diff --git a/_articles/fa/code-of-conduct.md b/_articles/fa/code-of-conduct.md index 0b21e42d458..563ad07cbd4 100644 --- a/_articles/fa/code-of-conduct.md +++ b/_articles/fa/code-of-conduct.md @@ -1,14 +1,8 @@ --- -lang: en -title: Your Code of Conduct -description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. +lang: fa +title: منشور اخلاقی +description: با تصویب و اجرای منشور اخلاقی، رفتار سالم و سازنده را در انجمن (community) خود تسهیل کنید. class: coc -toc: - why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?" - establishing-a-code-of-conduct: "Establishing a code of conduct" - deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct" - enforcing-your-code-of-conduct: "Enforcing your code of conduct" - your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer" order: 8 image: /assets/images/cards/coc.png related: @@ -16,105 +10,108 @@ related: - leadership --- -## Why do I need a code of conduct? +## چرا به منشور اخلاقی نیاز داریم؟ -A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community. +منشور اخلاقی سندی است که انتظارات مربوط به رفتار را برای شرکت‌کنندگان پروژه تعیین می‌کند. تصویب و اجرای منشور اخلاقی می‌تواند به ایجاد جو اجتماعی مثبت و سازنده برای انجمن شما کمک کند. -Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time. +منشور اخلاقی نه تنها از شرکت‌کنندگان پروژه بلکه از شما هم محافظت می‌کند. اگر شما از پروژه‌ای نگهداری می‌کنید، ممکن است متوجه شده باشید که نگرش‌های مخرب از طرف دیگر شرکت‌کنندگان باعث می‌شود در طول کار از کار خود خسته یا ناراضی شوید. -A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with. +منشور اخلاقی این امکان را به شما می‌دهد تا رفتاری سالم و سازنده را در جامعه تسهیل کنید. داشتن نگرشی پیشگیرانه، احتمال اینکه شما یا دیگران از پروژه خسته شوید را کاهش می‌دهد و این امکان را برای شما فراهم می‌سازد تا وقتی کسی کاری را اشتباه انجام داد بتوانید با آن مقابله و جلوی آن را بگیرید. -## Establishing a code of conduct +## ایجاد منشور اخلاقی -Try to establish a code of conduct as early as possible: ideally, when you first create your project. +سعی کنید هر چه زودتر منشور اخلاق را ایجاد کنید: در حالت ایده‌آل، هنگامی که پروژۀ خود را شروع می‌کنید. -In addition to communicating your expectations, a code of conduct describes the following: +علاوه بر ابلاغ انتظاراتی که دارید، منشور اخلاقی موارد زیر را شرح می‌دهد: -* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_ -* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_ -* What happens if someone violates the code of conduct -* How someone can report violations +* منشور اخلاقی در چه جاهایی اعمال می‌شود _(فقط در مورد مشکلات و درخواست‌های pull، یا دیگر فعالیت‌های انجمن مانند رویدادها؟)_ +* منشور اخلاقی برای چه کسانی اعمال می‌شود _(اعضای انجمن و نگه‌دارندگان، در مورد حامیان مالی چطور؟)_ +* اگر کسی منشور اخلاقی را نقض کند چه اتفاقی می‌افتد؟ +* چگونه می‌توان تخلفات را گزارش داد؟ -Wherever you can, use prior art. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. +در هر جا که می‌توانید، از دانش پیشین خود استفاده کنید. [عهدنامۀ مشارکت‌کنندگان](https://contributor-covenant.org/) نوعی منشور اخلاقی جا افتاده و مقبول است که بیش از 40،000 پروژۀ متن باز از جمله «Kubernetes»، « «Rails و «Swift» از آن استفاده می‌کنند. -The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples. +[منشور اخلاقی Django](https://www.djangoproject.com/conduct/) و [منشور اخلاقی Citizen](http://citizencodeofconduct.org/) نیز دو نمونۀ خوب دیگر هستند. -Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file. +فایل «منشور اخلاقی» را در فهرست اصلی پروژه قرار دهید و با لینک کردن آن با فایل‌های CONTRIBUTING یا README، آن را در دیدگاه انجمن خود قرار دهید. -## Deciding how you'll enforce your code of conduct +## تصمیم‌گیری در مورد نحوۀ پیش بردن منشور اخلاقی -You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so: +شما باید **قبل از وقوع** هر گونه تخلفی ابتدا توضیح دهید که منشور اخلاقی شما چگونه عملیاتی می‌شود. چندین دلیل برای اینکار وجود دارد: -* It demonstrates that you are serious about taking action when it's needed. +* نشان می‌دهد که شما جدی هستید و در صورت لزوم اقدام می‌کنید. -* Your community will feel more reassured that complaints actually get reviewed. +* انجمن‌تان نسبت به بررسی شدن شکایات، اطمینان بیشتری پیدا می‌کند. -* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation. +* به انجمن خود در صورت مرتکب شدن به تخلفی اطمینان خواهید داد که روند بازبینی منصفانه و شفاف خواهد بود. -You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group. +شما باید روشی ویژه‌ای (مانند آدرس ایمیل) برای مردم فراهم آورید تا بتوانند تخلفات ناشی از منشور اخلاقی را گزارش دهند و توضیح دهند که چه کسی مرتکب تخلفات شده است. می‌تواند یک نگهدارنده، گروهی از نگهدارنده‌ها یا یک کارگروه ویژۀ منشور اخلاقی باشد. -Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +فراموش نکنید که ممکن است کسی بخواهد در مورد شخصی که این گزارشات را دریافت می‌کند تخلفی را گزارش دهد. در این صورت، برای آن‌ها گزینه‌ای تعبیه کنید تا بتوانند تخلفات را به شخص دیگری گزارش دهند. به عنوان مثال، @ctb و @mr-c در مورد [پروژۀ خود «khmer»](https://github.com/dib-lab/khmer) می‌گویند: -> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.* +> مواردی از سوءرفتار، آزار و اذیت و رفتارهای غیر‌قابل‌قبول را می توان با ایمیل زدن به **khmer project@idyll.org** گزارش داد که فقط «C. Titus Brown» و Michael R. Crusoe» به آن دسترسی دارند. برای گزارش مسئله‌ای در رابطه با هر کدام از آن‌ها، لطفاً به **Judi Brown Clarke** دکترای مدیریت در مرکز «BEACON» برای مطالعۀ تکامل در عمل، مرکز علوم و فناوری «NSF» ایمیل بزنید. -For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project). +برای ایده گرفتن، به [کتابچۀ راهنمای اجرای](https://www.djangoproject.com/conduct/enforcement-manual/) «Django» مراجعه کنید (اگرچه ممکن است بنا به اندازه پروژۀ خود، نیازی به چنین کتابچۀ جامعی نداشته باشید). -## Enforcing your code of conduct +## عملیاتی کردن منشور اخلاقی -Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up. +گاهی اوقات علی‌رغم تلاشی که می‌کنید، شخصی کاری خلاف منشور اخلاقی انجام می‌دهد. روش‌های مختلفی برای پرداختن و عکس‌العمل نشان دادن به رفتار منفی و مضر در هنگام بروز آن وجود دارد. -### Gather information about the situation +### جمع‌آوری اطلاعات در مورد وضعیت -Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment. +با هر یک از اعضای انجمن خود، رفتاری یکسان داشته باشید. اگر گزارشی منوط بر نقص منشور اخلاقی دریافت کردید، آن را جدی بگیرید و موضوع را بررسی کنید، حتی اگر با آن شخص رابطه‌ای نزدیک دارید. با این کار به انجمن خود نشان می‌دهید که برای دیدگاه آن‌ها ارزش قائل هستید و به قضاوت آن‌ها اعتماد دارید. -The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context. +آن عضو خطاکار انجمن ممکن است اولین بار نباشد که مرتکب به خطایی شده و به طور مداوم دیگران را ناراحت می‌کند، یا ممکن است اولین بار آن‌ها باشد. بسته به خطایی که مرتکب می‌شوند، اقدامات لازمی باید اجرا شود. + +قبل از عکس‌العمل نشان دادن، زمان کافی را برای فهمیدن کامل ماجرا صرف کنید. نظرات و گفتگوهای مربوط به گذشتۀ شخص را بررسی کنید تا آن‌ها را بهتر بشناسید و متوجه شوید چرا ممکن است چنین رفتاری از آن‌ها سر بزند. سعی کنید دیدگاه‌های دیگری را غیر از دیدگاه‌های خودتان دربارۀ این فرد و رفتار او جمع‌آوری کنید. -Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior. -### Take appropriate action +### اقداماتی مناسب به کار ببرید + +پس از جمع آوری و بررسی اطلاعات کافی، باید تصمیم بگیرید که چه کاری انجام دهید. همانطور که به قدم بعدی می‌اندیشید، به یاد داشته باشید که هدف شما به عنوان ناظر، ایجاد محیطی امن، محترم و فضایی مشارکتی است. در نظر داشته باشید که تنها مسئلۀ چگونگی برخورد در آن موقعیت مهم نیست، بلکه چگونگی پاسخ و عکس‌العمل شما در آینده‌ی رفتار و انتظارات افراد حاضر در انجمن شما تأثیر می‌گذارد. + +وقتی کسی گزارشی منوط بر تخلف در منشور اخلاقی می‌دهد، رسیدگی به آن وظیفۀ شماست و نه خود او. گاهی اوقات، فرد گزارش‌دهنده با افشای این اطلاعات، آیندۀ شغلی، اعتبار یا ایمنی خود را ممکن است در معرض خطر بزرگی قرار دهد. وادار کردن آن‌ها به مقابله کردن با فرد مزاحم و خاطی می‌تواند فرد گزارش‌دهنده را در موقعیتی مخاطره‌آمیز قرار دهد. شما باید شخصا ارتباط مستقیم با فرد خاطی مورد نظر را مدیریت کنید، مگر اینکه فرد گزارش‌دهنده صریحاً خلاف آن را درخواست کند. -After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward. -When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise. +چند روش وجود دارد که شما می‌توانید با استفاده از آن‌ها با موارد نقض منشور اخلاقی برخورد کنید: -There are a few ways you might respond to a code of conduct violation: +* **به شخص مورد نظر ترجیحاً به طور مشخص‌ و واضح اخطار عمومی دهید** و توضیح دهید که چگونه رفتار او بر دیگران تأثیر منفی می‌گذارد. اخطار به صورت عمومی به بقیۀ افراد انجمن این پیام را می‌رساند که منشور اخلاقی را جدی می‌گیرید. در مکالمه‌های خود خوش‌برخود باشید ولی جدی بمانید. -* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication. +* **به طور خصوصی با شخص مورد نظر صحبت بکنید** تا توضیح دهید که چگونه رفتار او بر دیگران تأثیر منفی می‌گذارد. اگر موقعیت طوری باشد که اطلاعات حساس شخصی فرد در میان باشد، بهتر است از کانال‌های ارتباطی خصوصی استفاده کنید. اگر با شخص به طور خصوصی صحبت می‌کنید، بهتر است کسانی را که برای اولین بار وضعیت را گزارش کرده‌اند مطلع کنید تا بدانند که اقدام کرده‌اید. قبل از پیگیری کردن گزارش مربوطه، از شخص گزارش‌دهنده رضایت بگیرید. -* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them. +گاهی اوقات، نمی‌توان به نتیجه‌ای قطعی رسید. فرد مورد نظر ممکن است در مواجهه با او پرخاشگر یا خصمانه برخورد کند یا تغییری در رفتار خود ایجاد نکند. در این شرایط، ممکن است بخواهید اقدامات جدی‌تری را در نظر بگیرید. مثلا: -Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example: +* **فرد مورد نظر را از ادامۀ همکاری در پروژه تعلیق کنید**، که از طریق منع موقت یا شرکت در هر جنبه‌ای از پروژه اعمال می‌شود -* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project +* **فرد مورد نظر را به طور دائمی** از ادامۀ همکاری در پروژه تعلیق کنید -* **Permanently ban** the person from the project +منع کردن اعضا نباید امری ساده تلقی شود و باید نشان‌دهندۀ اختلاف دائمی در دیدگاه و آشتی‌ناپذیری تلقی شود. این اقدامات را فقط باید در مواقعی پیش بگیرید که مشخص باشد امکان دستیابی به نتیجه‌ای قطعی وجود ندارد. -Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached. +## وظایف شما به عنوان یک نگهدارنده -## Your responsibilities as a maintainer +منشور اخلاقی آیین‌نامه‌ای نیست که به صورت خودسرانه اجرا شود. شما مجری منشور اخلاقی هستید و مسئولیت پیروی از قوانین تعیین شده به وسیله‌ی منشور اخلاقی از وظایف شماست. -A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes. +شما به عنوان نگهدارنده، دستورالعمل‌هایی را برای انجمن خود تعیین می‌کنید و آن دستورالعمل‌ها را مطابق با قوانین مندرج در منشور اخلاقی اجرا می‌کنید. این به معنای جدی گرفتن هر گونه گزارش مربوطی به نقض منشور اخلاقی است. گزارش فرد گزارش‌دهنده باید کاملا جامع و منصفانه بررسی شود. اگر تشخیص دادید رفتاری که آن‌ها گزارش داده‌اند، نقض منشور اخلاقی نیست، این مسئله را به وضوح با آن‌ها در میان بگذارید و توضیح دهید که چرا در این زمینه اقدامی نمی‌کنید. عکس‌العملی که نشان می‌دهند به خودشان مربوط است: باید رفتاری که آن‌ها با آن روبرو بوده‌اند را تحمل کنند یا مشارکت‌شان در انجمن را متوقف سازند. -As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community. +گزارش رفتاری که در واقع منشور اخلاقی شما را نقض نمی‌کند، همچنان نشان‌دهندۀ مشکلی در انجمن شما است و شما باید این مشکل بالقوه را بررسی کرده و چاره‌ای برای آن پیدا کنید. که این ممکن است شامل بازنگری در منشور اخلاقی برای روشن ساختن رفتار قابل‌قبول یا صحبت با شخصی باشد که رفتار وی گزارش شده است و شما باید به فرد بگویید که اگرچه منشور اخلاقی را نقض نکرده‌اند، اما دارند در لبۀ آنچه که از آن‌ها انتظار می‌رود راه می‌روند و موجب ناراحتی در برخی از شرکت‌کنندگان شده‌اند. -A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable. +موضوع مهم این است که شما به عنوان یک نگهدارنده، باید استانداردهای رفتار قابل‌قبول را تعیین و عملیاتی کنید. شما توانایی شکل دادن به ارزش‌های اجتماعی پروژه را دارید و شرکت‌کنندگان انتظار دارند که شما این ارزش‌ها را به صورت منصفانه و یکسان اجرا کنید. -In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way. -## Encourage the behavior you want to see in the world 🌎 +## ترغیب‌کنندۀ رفتاری باشید که می‌خواهید در دنیا آن را مشاهده کنید 🌎 -When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow. +هنگامی که یک پروژه خصمانه یا ناخوشایند به نظر می‌رسد، حتی اگر فقط یک نفر باشد که رفتار او غیرقابل‌تحمل باشد، ممکن است مشارکت‌کنندگان بیشتری را از دست بدهید که حتی ممکن است بعضی از آن‌ها را هرگز ملاقات نکرده باشید. اتخاذ یا اجرای منشور اخلاقی همیشه ساده نیست، اما ایجاد فضایی دوستانه به رشد انجمن شما کمک می کند. From e6bac70d8a1ff4e68979cacbaa27ca90244a974e Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Sun, 9 May 2021 20:05:55 +0430 Subject: [PATCH 019/629] Initial translation done. --- _articles/fa/metrics.md | 123 +++++++++++++++++++--------------------- 1 file changed, 59 insertions(+), 64 deletions(-) diff --git a/_articles/fa/metrics.md b/_articles/fa/metrics.md index 080b3eea9d4..d7274ce79b5 100644 --- a/_articles/fa/metrics.md +++ b/_articles/fa/metrics.md @@ -1,14 +1,8 @@ --- lang: en -title: Open Source Metrics -description: Make informed decisions to help your open source project thrive by measuring and tracking its success. +title: سنجه‌های پروژه‌های متن باز +description: آگاهانه تصمیم‌گیری کنید تا با ارزیابی و پیگیری موفقیت، به پیشرفت پروژۀ متن باز خود کمک کنید. class: metrics -toc: - why-measure-anything: "Why measure anything?" - discovery: "Discovery" - usage: "Usage" - retention: "Retention" - maintainer-activity: "Maintainer activity" order: 9 image: /assets/images/cards/metrics.png related: @@ -16,117 +10,118 @@ related: - best-practices --- -## Why measure anything? +## چرا چیزی را ارزیابی کنیم؟ -Data, when used wisely, can help you make better decisions as an open source maintainer. +هنگامی که داده‌ها هوشمندانه استفاده شوند، به شما کمک می‌کنند تا به عنوان یک نگهدارندۀ متن باز تصمیمات بهتری بگیرید. -With more information, you can: +با اطلاعات بیشتر، می‌توانید: -* Understand how users respond to a new feature -* Figure out where new users come from -* Identify, and decide whether to support, an outlier use case or functionality -* Quantify your project's popularity -* Understand how your project is used -* Raise money through sponsorships and grants +* درک بهتری از واکنش کاربران به ویژگی‌های جدید داشته باشید +* بفهمید کاربران جدید از کجا آمده‌اند +* موارد کاربردی برجسته و قابلیت‌ها را شناسایی کنید و تصمیم بگیرید که آیا به پشتیبانی از آن‌ها ادامه می‌دهید یا خیر +* محبوبیت پروژۀ خود را بسنجید +* جنبه‌های کاربردی پروژه را درک کنید +* از طریق اسپانسرها و کمک‌هزینه‌ها، پول جمع‌آوری کنید -For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work: +به عنوان مثال، پروژۀ متن باز [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) دریافت که «Google Analytics» به آن‌ها در اولویت‌بندی کارها کمک می‌کند. -> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew. +> «Homebrew» بصورت رایگان در اختیار کاربران قرار می‌گیرد و توسط داوطلبان در اوقات فراغت‌شان اداره می‌شود. در نتیجه، ما منابع لازم برای انجام مطالعات دقیق دربارۀ کاربران «Homebrew» را نداریم تا در مورد چگونگی بهترین طراحی برای ‌آینده و اولویت‌بندی کارهای فعلی تصمیم بگیریم. تجزیه و تحلیل کلی و ناشناس در رابطه با کاربران به ما امکان می‌دهد اصلاحات و ویژگی‌ها را بر اساس شیوه، مکان و زمان استفادۀ کاربران از «Homebrew» اولویت‌بندی کنیم. -Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you. +محبوبیت، همه چیز نیست. دلایل متفاوت زیادی برای ورود افراد در پروژه‌های متن باز وجود دارد. اگر هدف شما به عنوان نگهدارندۀ متن باز این است که کار خود را در معرض نمایش بگذارید، پس همینطور برخورد کنید یا فقط از آن لذت ببرید؛ معیارها برای شما آنچنان مهم نیستند. -If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity. +اگر _می‌خواهید_ به سطح درک عمیق‌تری دربارۀ پروژۀ خودتان برسید، روش‌های تجزیه و تحلیل فعالیت‌های پروژه خود را بدانید. -## Discovery -Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_ +## کشف و پیدا کردن + +قبل از اینکه کسی بتواند از پروژۀ شما استفاده کند یا در آن مشارکت داشته باشد، باید بداند که همچین پروژه‌ای وجود دارد. از خودتان بپرسید: _آیا مردم می‌توانند این پروژه را پیدا کنند؟_ ![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) -If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Insights", then "Traffic". On this page, you can see: +اگر پروژۀ شما در «GitHub» قرار دارد، [می‌توانید ببینید](https://help.github.com/articles/about-repository-graphs/#traffic) افرادی که در پروژۀ شما هستند از کجا آمده‌اند؟ در صفحه پروژۀ خود، روی «Insights» و سپس «Traffic» کلیک کنید. در این صفحه، این موارد را می‌توانید ببینید: -* **Total page views:** Tells you how many times your project was viewed +* **تعداد بازدیدها از صفحه:** به شما می‌گوید پروژه چند بار دیده شده است -* **Total unique visitors:** Tells you how many people viewed your project +* **تعداد بازدیدکنندگان منحصر به فرد:** به شما می‌گوید چند نفر پروژه را دیده‌اند -* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working. +* **سایت‌های ارجاع دهنده یا معرفی‌کننده:** به شما می‌گوید، بازدیدکنندگان از کجا آمده‌اند. این معیار به شما کمک می‌کند تا بفهمید در کجا می‌توانید به مخاطب خود دسترسی پیدا کنید و آیا تلاش‌های تبلیغاتی شما موثر واقع شده است یا خیر. -* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors. +* **محتوای محبوب:** به شما می‌گوید، بازدیدکنندگان به کدام بخش پروژۀ شما می‌روند و شمار بازدیدهای صفحه و بازدیدکنندگان منحصر به فرد را نشان می‌دهد. -[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work. +قسمت [GitHub stars](https://help.github.com/articles/about-stars/) هم می‌تواند به صورت معیاری برای محبوبیت عمل کند.اگرچه «GitHub stars» لزوماً با تعداد دانلودها و استفاده از محتوا ارتباط مستقیمی ندارد، اما این قسمت می‌تواند به شما بگوید که چه تعدادی از آدم‌ها متوجه پروژۀ شما شده‌اند.. -You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites. +همچنین شاید بخواهید قابلیت کشف شدن (شناخته‌ شدن) را در [بخش‌های مشخصی ردیابی کنید](https://opensource.com/business/16/6/pirate-metrics): به عنوان مثال، «Google PageRank»، ترافیک رجوعی به وب‌سایت پروژۀ شما، یا مراجعات از سایر پروژه‌های متنباز یا سایر وب‌سایت‌ها. -## Usage +## استفاده -People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_ +مردم پروژۀ شما را در این دنیای عجیب‌غریبی که اینترنت می‌نامیم، پیدا می‌کنند. در بهترین حالت، وقتی پروژۀ شما را ببینند، به آن مشتاق می‌شوند و می‌خواهند کاری انجام دهند. دومین سوالی که باید از خود بپرسید این است که: _آیا مردم از این پروژه استفاده می‌کنند؟_ -If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads. +اگر از یک برنامۀ مدیریت پکیج (package manager) مانند «npm» یا «RubyGems.org» برای انتشار پروژۀ خود استفاده می‌کنید، می‌توانید دانلودهای مربوط به پروژه را ردیابی کنید. -Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers. +هر برنامۀ مدیریت پکیجی ممکن است تعریف متفاوتی از دانلود داشته باشد و دانلود لزوماً با نصب یا استفاده ارتباط داشته باشد، اما مبنایی را برای مقایسه فراهم می‌کند. برای پیگیری آمارهای مختلف می‌توانید در میان بسیاری از مدیریت‌های محبوب پیکیج، از [Libraries.io](https://libraries.io/) استفاده کنید. -If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners. +اگر پروژۀ شما در «GitHub» است، دوباره به صفحۀ «Traffic» بروید. می‌توانید از نمودار کلون [clone graph](https://github.com/blog/1873-clone-graphs) استفاده کنید تا ببینید چند بار پروژۀ شما در یک روز مشخص کپی شده است، که این نمودار براساس کل کلون‌ها (کپی‌ها) و کپی‌های منحصر به فرد مشخص شده است. ![Clone graph](/assets/images/metrics/clone_graph.png) -If usage is low compared to the number of people discovering your project, there are two issues to consider. Either: +اگر میزان استفاده در مقایسه با تعداد افرادی که پروژۀ شما را پیدا می‌کنند کم است، دو مسئله وجود دارد که باید در نظر بگیرید: + +* مخاطبان به طور موفقیت‌آمیز با پروژۀ شما ارتباط نمی‌گیرند +* یا مخاطبان اشتباهی را جذب کرده‌اید -* Your project isn't successfully converting your audience, or -* You're attracting the wrong audience +به عنوان مثال، اگر پروژۀ شما در صفحۀ اول «Hacker News» قرار گیرد، احتمالاً جهشی در میزان کشف (ترافیک) اما با نرخ گرایش پایینی را مشاهده خواهید کرد؛ زیرا در Hacker News، افراد زیادی پروژۀ شما را پیدا می‌کنند. اگر پروژۀ «Ruby» شما در یک مجمع «Ruby» ارائه شده باشد، به احتمال زیاد نرخ گرایش بالایی از مخاطبان هدف را شاهد خواهید بود. -For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience. +سعی کنید بفهمید مخاطبان شما از کجا می‌آیند و از نظرات دیگران در مورد صفحۀ پروژۀ خود بهره ببرید تا متوجه شوید با کدام یک از این دو مسئله روبرو هستید. -Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing. +وقتی با مخاطبان و افرادی که از پروژۀ شما استفاده می‌کنند آشنا شدید، بهتر است بفهمید که آن‌ها چه استفاده‌ای از پروژه می‌کنند. آیا آن‌ها با فورک کردن کد شما و افزودن ویژگی‌های مختلف، بر روی آن کار می‌کنند؟ آیا آن‌ها از آن برای مصارف علمی یا تجاری استفاده می‌کنند؟ -Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business? -## Retention +## استمرار و نگهداری -People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_ +مردم پروژۀ شما را پیدا می‌کنند و از آن استفاده می‌کنند. سوالی که باید از خودتان بپرسید این است که: _آیا مردم در آن مشارکت هم می‌کنند یا خیر؟_ -It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand). +هیچ‌وقت برای فکر کردن به مشارکت‌کنندگان دیر نیست. اگر پروژۀ شما محبوب باشد (بسیاری از از آن استفاده کنند) و سایر افراد دست به کار نشوند و از آن _پشتیبانی نکنند_ خود را در موقعیتی ناسالم قرار می‌دهید (به اندازۀ کافی نگهدارنده نداشته باشید). -Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things. +نگهداری، مستلزم [ورود مشارکت‌کنندگان جدید](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) است، زیرا مشارکت‌کنندگان فعال قبلی در نهایت به سراغ کارهای دیگر می‌روند. -Examples of community metrics that you may want to regularly track include: +نمونه‌هایی از معیارهای انجمن که باید مرتباً آن‌ها را بررسی کنید، شامل این موارد می‌شود: -* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Insights" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository. +* **تعداد کل مشارکت‌کنندگان و تعداد تعهدات هر مشارکت‌کننده:** به شما می‌گوید چه تعداد مشارکت‌کننده دارید و چه کسانی کم و بیش فعال هستند. این بخش را می‌توانید در «GitHub» در قسمت «Insights -> Contributors» مشاهده کنید. در حال حاضر، این نمودار فقط مشارکت‌کنندگانی که متعهد به شاخۀ پیش‌فرض مرکز ذخیره‌سازی شده‌اند را مشخص می‌کند. ![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) -* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant. +* **مشارکت‌کنندگان تازه‌کار، عادی، همیشگی:** کمک می‌کند تا پیگیری کنید که آیا مشارکت‌کنندگان جدیدی دریافت می‌کنید یا خیر. (مشارکت‌کنندگان عادی، مشارکت‌کنندگانی با تعهدات کم هستند که البته تعریف «تعهدات کم» به خود شما بستگی دارد و می‌تواند یک یا پنج یا کمتر باشد) بدون مشارکت‌کنندگان جدید، انجمن پروژه راکد و کم‌رونق می‌شود. -* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews. +* **تعداد مسائل در جریان و درخواست‌های باز pull:** اگر بیش از حد زیاد شوند، ممکن است در اولویت‌بندی مسائل و بررسی کدها به کمک نیاز داشته باشید. -* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project. +* **تعداد مسائل باز شده (open issued) و درخواست های باز شدۀ pull:** مسائل باز شده، یعنی کسی به اندازه کافی به پروژۀ شما اهمیت بدهد تا مسئله‌ای را باز کند. اگر این تعداد با گذشت زمان افزایش یابد، نشان‌دهندۀ این است که مردم به پروژۀ شما علاقه‌مند هستند. -* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue. +* **انواع مشارکت‌ها:** به عنوان مثال، نوع تعهدها، رفع اشتباهات یا اشکالات یا اظهار نظر در مورد یک موضوع. -## Maintainer activity +## فعالیت‌های شخص نگهدارنده -Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_ +نگهدارنده‌هایی که پاسخگو نیستند به نقطۀ ضعف پروژه‌های متن باز تبدیل می‌شوند. اگر کسی مشارکتی از خود به جای بگذارد اما هرگز از یک نگهدارنده پاسخی دریافت نکند، ممکن است احساس دلسردی کرده و آنجا را ترک کند. -Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave. +[تحقیقات که در Mozilla شکل گرفت](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) نشان می‌دهد که پاسخگو بودن نگهدارنده عاملی حیاتی در تشویق به مشارکت‌های بیشتر است. -[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions. +در نظر بگیرید که چه مدت طول می‌کشد تا شما (یا نگهدارنده‌ای دیگر) به مشارکت‌ها پاسخ دهید، خواه مسئله‌ای باشد یا درخواست pull. پاسخگو بودن نیاز به اقدام خاصی ندارد. می‌تواند به این سادگی باشد: _«ممنون از درخواست شما! در عرض یک هفته آن را بررسی می‌کنم.»_ -Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_ +همچنین می‌توانید مدت زمانی که برای تکمیل مراحل مختلف فرآیند مشارکت لازم است را اندازه بگیرید، همچون: -You could also measure the time it takes to move between stages in the contribution process, such as: +* متوسط زمان باز ماندن مسئله +* بسته شدن مسئله توسط روابط عمومی (PR) +* بسته شدن مسائل قدیمی +* متوسط زمان ادغام کردن درخواست‌های pull -* Average time an issue remains open -* Whether issues get closed by PRs -* Whether stale issues get closed -* Average time to merge a pull request -## Use 📊 to learn about people +## از آمار 📊 برای درک مردم استفاده کنید -Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive. +درک معیارها (استانداردها) به شما کمک می‌کند تا پروژۀ متن باز فعال و رو به‌ رشدی داشته باشید. حتی اگر هم تمامی معیارها را پیگیری نمی‌کنید، از چارچوب بالا استفاده کنید تا توجه خود را به نوع رفتاری که به پیشرفت پروژه کمک می‌کند متمرکز کنید. From c9a3449e79b25502be76af0a5d232ed5673188ca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Sun, 9 May 2021 23:54:41 +0000 Subject: [PATCH 020/629] Translate how-to-contribute.md via GitLocalize --- _articles/tr/how-to-contribute.md | 244 +++++++++++++----------------- 1 file changed, 101 insertions(+), 143 deletions(-) diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index 142b1f03e22..0f79a454a87 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -10,22 +10,16 @@ toc: finding-a-project-to-contribute-to: Katkıda bulunacak bir proje bulma how-to-submit-a-contribution: Katkı nasıl gönderilir? what-happens-after-you-submit-a-contribution: Bir katkı gönderdikten sonra ne olur? -order: 1 -image: /assets/images/cards/contribute.png +order: '1' +image: "/assets/images/cards/contribute.png" related: -- beginners -- building + - beginners + - building --- ## Açık kaynağa neden katkıda bulunmalıyım? - + Açık kaynağa katkıda bulunmak, hayal edebileceğiniz herhangi bir konuyu öğrenmek, öğretmek ve deneyim geliştirmek için faydalı bir yol olabilir. @@ -67,79 +61,61 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol ### Kod yazarak katkıda bulunmak zorunda değilsin -Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye _büyük bir_ iyilik yapacaksınız! +Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız! - + Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir. - + ### Etkinlik planlamayı sever misiniz? -* [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin -* Projenin konferansını düzenleyin (eğer varsa) -* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun +- [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin +- Projenin konferansını düzenleyin (eğer varsa) +- Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun ### Tasarlamayı sever misiniz? -* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın -* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın -* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın -* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın +- Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın +- [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın +- Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın +- [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın ### Yazmayı sever misin? -* Proje dokümantasyonunu yazın ve geliştirin -* Projenin nasıl kullanıldığını gösteren örnekler oluşturun -* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın -* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın -* Projenin dokümantasyonu için çeviri yapın +- Proje dokümantasyonunu yazın ve geliştirin +- Projenin nasıl kullanıldığını gösteren örnekler oluşturun +- Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın +- [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın +- Projenin dokümantasyonu için çeviri yapın - + ### Organize etmeyi sever misiniz? -* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin -* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) -* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. +- Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin +- Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) +- Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. ### Kod yazmayı sever misiniz? -* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun -* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun -* Proje kurulumunu otomatikleştirin -* Araçları ve testleri geliştirin +- [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun +- Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun +- Proje kurulumunu otomatikleştirin +- Araçları ve testleri geliştirin ### İnsanlara yardım etmeyi sever misiniz? -* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te -* İnsanlar için açık konulardaki soruları cevaplayın -* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun +- Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te +- İnsanlar için açık konulardaki soruları cevaplayın +- Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun ### Başkalarına kod yazarken yardım etmeyi sever misiniz? -* Diğer kişilerin gönderimlerindeki kodu inceleyin -* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın -* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) +- Diğer kişilerin gönderimlerindeki kodu inceleyin +- Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın +- Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) ### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz! @@ -147,21 +123,15 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d Örneğin: -* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) -* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor -* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) +- @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) +- @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor +- @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır. ## Kendinizi yeni bir projeye yönlendirmek - + Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. @@ -177,34 +147,34 @@ Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapıların Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir: -* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) -* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) -* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) -* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes -* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. +- **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) +- **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) +- **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) +- **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes +- **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın. Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir. -* **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. -* **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. -* **CONTRIBUTING:** README dosyaları projeyi insanların _kullanmalarına_ yardımcı olurken, CONTRIBUTING dökümanları insanların projeye _katkıda_ bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. -* **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. -* **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. +- **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. +- **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. +- **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. +- **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. +- **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir. -* **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. -* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. -* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine _"Nasıl ...?"_ veya _"Ne düşünüyorsunuz ...?" gibi_). Diğerleri, tüm konuşmalar için sorun listesini kullanır. -* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. +- **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. +- **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. +- **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. +- **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. ## Katkıda bulunacak bir proje bulma Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı! -Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, _"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"_ diyen ABD Başkanı John F. Kennedy'yi örnek alın. +Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi örnek alın. Açık kaynağa katkıda bulunmak, farklı projelerde her seviyede gerçekleşir. İlk katkınızın tam olarak ne olacağını veya nasıl görüneceğini düşünmeniz gerekmez. @@ -222,15 +192,15 @@ Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz: -* [GitHub Explore](https://github.com/explore/) -* [Open Source Friday](https://opensourcefriday.com) -* [First Timers Only](https://www.firsttimersonly.com/) -* [CodeTriage](https://www.codetriage.com/) -* [24 Pull Requests](https://24pullrequests.com/) -* [Up For Grabs](https://up-for-grabs.net/) -* [Contributor-ninja](https://contributor.ninja) -* [First Contributions](https://firstcontributions.github.io) -* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +- [GitHub Explore](https://github.com/explore/) +- [Open Source Friday](https://opensourcefriday.com) +- [First Timers Only](https://www.firsttimersonly.com/) +- [CodeTriage](https://www.codetriage.com/) +- [24 Pull Requests](https://24pullrequests.com/) +- [Up For Grabs](https://up-for-grabs.net/) +- [Contributor-ninja](https://contributor.ninja) +- [First Contributions](https://firstcontributions.github.io) +- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi @@ -342,13 +312,7 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac - + ## Nasıl katkı yapılır? @@ -358,45 +322,45 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir. - + Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun. **Bağlam ver.** Başkalarının sizi anlamada hızlanmalarına yardımcı olun. Bir hatayla karşılaşıyorsanız, ne yapmaya çalıştığınızı ve nasıl tekrarlanabileceğini açıklayın. Yeni bir fikir önerecekseniz, neden projeye faydalı olacağını düşündüğünüzü açıklayın (sadece sizin için değil!). -> 😇 _"Y yaptığımda X olmuyor"_ -> X _"X çalışmıyor! Lütfen düzeltin."_ +> 😇 *"Y yaptığımda X olmuyor"* +> +> 😢 *"X çalışmıyor! Lütfen düzeltin."* **Ödevini önceden yap.** Bir şeyleri bilmemek normaldir, ama denediğini göster. Yardım istemeden önce, bir projenin README'sini, belgelerini, sorun listesini (açık veya kapalı), e-posta listesini kontrol ettiğinizden ve bir cevap için interneti aradığınızdan emin olun. Öğrenmeye çalıştığını gösterdiğin zaman insanlar takdir edeceklerdir. -> X _"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."_ -> 😢 _"X nasıl yapılır?"_ +> 😇 *"X'in nasıl uygulanacağından emin değilim. Yardım belgelerini kontrol ettim ve herhangi bir yerde bulamadım."* +> +> 😢 "X nasıl yapılır?" **İstekleri kısa ve öz tutun.** Bir e-posta göndermek gibi, ne kadar basit veya yararlı olursa olsun, her katkı başkasının incelemesini gerektirir. Birçok projenin, yardım için uygunların yapabileceklerinden daha fazla gelen talebi olur. Basit olun. Birinin size yardım edebilme şansını artıracaksınız. -> 😇 _"Bir API öğretici belgesi yazmak istiyorum."_ -> 😢 _"Geçen gün otoyoldan aşağı iniyordum ve benzin için durdum ve sonra aklıma yapmamız gereken bir şey için inanılmaz bir fikir geldi, ama bunu açıklamadan önce sana göstereyim ..."_ +> 😇 *"Bir API öğretici belgesi yazmak istiyorum."* +> +> 😢 *"Geçen gün otoyoldan aşağı iniyordum ve benzin için durdum ve sonra aklıma yapmamız gereken bir şey için inanılmaz bir fikir geldi, ama bunu açıklamadan önce sana göstereyim ..."* **Tüm iletişimi herkese açık tutun.** Her ne kadar cazip olsa da, hassas bilgileri (güvenlik sorunu veya ciddi davranış ihlali gibi) paylaşmanız gerekmedikçe, geliştiricilere özel olarak ulaşmayın. Sohbeti herkese açık tuttuğunuzda, daha fazla kişi alış verişinizden öğrenebilir ve bundan faydalanabilir. Tartışmalar da kendi başlarına katkı sayılabilir. -> 😇 _(yorum olarak) "@-maintainer Merhabalar! Bu PR'a nasıl devam edelim?"_ -> 😢 _(bir e-posta olarak) "Hey, e-posta yüzünden sizi rahatsız ettiğim için özür dilerim, ancak PR'mi gözden geçirme şansınız olup olmadığını merak ediyordum"_ +> 😇 *(yorum olarak) "@-maintainer Merhabalar! Bu PR'a nasıl devam edelim?"* +> +> 😢 *(bir e-posta olarak) "Hey, e-posta yüzünden sizi rahatsız ettiğim için özür dilerim, ancak PR'mi gözden geçirme şansınız olup olmadığını merak ediyordum"* **Soru sormak sorun değil (ama sabırlı olun!).** Herkes bir zamanlar projede yeniydi ve deneyimli katılımcıların bile yeni bir projeye bakarken hız kazanmaları gerekiyor. Aynı şekilde, uzun süredir devam edenler bile, projenin her bölümüne aşina değildir. Onlara size göstermelerini istediğiniz sabrı gösterin. -> 😇 _"Bu hatayı incelediğiniz için teşekkür ederiz. Önerilerinizi takip ettim. İşte sonuç."_ -> 😢 _"Neden sorunumu çözemiyorsun? Bu senin projen değil mi?"_ +> 😇 *"Bu hatayı incelediğiniz için teşekkür ederiz. Önerilerinizi takip ettim. İşte sonuç."* +> +> 😢 *"Neden sorunumu çözemiyorsun? Bu senin projen değil mi?"* **Topluluk kararlarına saygı gösterin.** Fikirleriniz, toplumun öncelikleri veya vizyonundan farklı olabilir. Geri bildirim sunabilir veya fikrinizi sürdürmemeye karar verebilirler. Tartışmanız ve uzlaşı aramanız gerekirken, geliştiriciler kararınızla sizden daha uzun yaşamak zorundadır. Düşüncelerine katılmıyorsanız, her zaman kendi çatalınızla çalışabilir veya kendi projenizi başlatabilirsiniz. -> 😇 _"Fikrimi destekleyemediğiniz için hayal kırıklığına uğradım, ancak bunun sadece kullanıcıların küçük bir bölümünü etkilediğini açıkladığınızdan, nedenini anlıyorum. Dinlediğiniz için teşekkürler."_ -> 😢 _"Neden fikrimi desteklemiyorsun? Bu kabul edilemez!"_ +> 😇 *"Fikrimi destekleyemediğiniz için hayal kırıklığına uğradım, ancak bunun sadece kullanıcıların küçük bir bölümünü etkilediğini açıkladığınızdan, nedenini anlıyorum. Dinlediğiniz için teşekkürler."* +> +> 😢 *"Neden fikrimi desteklemiyorsun? Bu kabul edilemez!"* **Her şeyden önce, zarif olun.** Açık kaynak dünyanın her yerinden ortak çalışanlardan oluşur. Bağlam diller, kültürler, coğrafyalar ve zaman dilimleri arasında kaybolur. Ek olarak, yazılı iletişim bir ton veya ruh halini iletmeyi zorlaştırır. Bu konuşmaların niyetlerinin iyi olduğunu düşünün. Bir fikre kibarca geri dönmek, daha fazla içerik istemek veya konumunuzu daha da netleştirmek iyi bir şey. İnterneti bulduğunuzdan daha iyi bir yer bırakmaya çalışın. @@ -406,53 +370,47 @@ Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığ Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız: -* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir -* **PR** bir çözüm üzerinde çalışmaya başlamak içindir -* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. +- **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir +- **PR** bir çözüm üzerinde çalışmaya başlamak içindir +- **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. Bir sorun açmadan veya talepte bulunmadan önce, belirli bir şey eklemeniz gerekip gerekmediğini görmek için projenin katkıda bulunma belgelerini (genellikle CONTRIBUTING veya README dosyaları) kontrol edin. Örneğin, bir şablon izlemenizi istenebilir veya test ortamı kullanmanız gerekebilir. Önemli bir katkı yapmak istiyorsanız, üzerinde çalışmadan önce sormanız gereken bir sorun açın. Projeyi bir süre izlemeniz yararlı olacaktır (GitHub'da, tüm konuşmalar size bildirilmek için ["İzle"yi tıklayabilirsiniz](https://help.github.com/articles/watching-repositories/)) ve kabul edilmeyebilecek bir işe başlamadan önce topluluk üyelerini tanıyın. - + ### Bir istek/sorun açmak Genellikle aşağıdaki durumlarda bir sorun açmalısınız: -* Çözemediğiniz bir hatayı bildirmek için -* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) -* Yeni bir özellik veya başka bir proje fikri önermek için +- Çözemediğiniz bir hatayı bildirmek için +- Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) +- Yeni bir özellik veya başka bir proje fikri önermek için Sorunlar üzerinde iletişim kurmak için ipuçları: -* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. -* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. -* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. +- **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. +- **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. +- **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. ### PR açma Genellikle aşağıdaki durumlarda bir PR açmalısınız: -* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) -* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda +- Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) +- Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz. Proje GitHub'taysa, PR nasıl gönderilir: -* **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) -* Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . -* **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") -* Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. -* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. -* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. +- **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) +- Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . +- **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") +- Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. +- **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. +- **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz. @@ -464,7 +422,7 @@ Katkınızı gönderdikten sonra, aşağıdakilerden biri olacaktır: ### 😭 Hiç bir cevap almazsınız. -Umarım bir katkı yapmadan önce [projeyi faaliyet belirtileri açısından kontrol](#katkıda-bulunmadan-önce-üzerinden-geçilebilecek-bir-kontrol-listesi) ettiniz. Ancak aktif bir projede bile, katkınızın yanıt alamaması olası. +Umarım bir katkı yapmadan önce [projeyi faaliyet belirtileri açısından kontrol](#katk%C4%B1da-bulunmadan-%C3%B6nce-%C3%BCzerinden-ge%C3%A7ilebilecek-bir-kontrol-listesi) ettiniz. Ancak aktif bir projede bile, katkınızın yanıt alamaması olası. Bir haftadan uzun bir süredir yanıt alamadıysanız, aynı konuya kibarca yorum yazmak, birinden inceleme istemek doğru olur. Katkınızı gözden geçirecek doğru kişinin adını biliyorsanız, bunları o konuya ekleyebilirsiniz (@). From 1969f16cf07f1a3ac3c7b9bb47e9c11491124399 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Sun, 9 May 2021 23:56:02 +0000 Subject: [PATCH 021/629] Translate code-of-conduct.md via GitLocalize --- _articles/tr/code-of-conduct.md | 46 +++++++++++++-------------------- 1 file changed, 18 insertions(+), 28 deletions(-) diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md index afc8f06f843..9ba8ff26e3b 100644 --- a/_articles/tr/code-of-conduct.md +++ b/_articles/tr/code-of-conduct.md @@ -7,9 +7,9 @@ toc: why-do-i-need-a-code-of-conduct: Neden bir davranış kural listesine ihtiyacım var? establishing-a-code-of-conduct: Davranış kuralları oluşturmak deciding-how-youll-enforce-your-code-of-conduct: Davranış kurallarınızı nasıl uygulayacağınıza karar verme - enforcing-your-code-of-conduct: Davranış kurallarınızı güçlendirmek + enforcing-your-code-of-conduct: Davranış kurallarınızı uygulama your-responsibilities-as-a-maintainer: Bir koruyucu olarak sorumluluklarınız -order: 8 +order: '8' image: "/assets/images/cards/coc.png" related: - building @@ -30,10 +30,10 @@ Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar: -* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_? -* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_? -* Birisi davranış kurallarını ihlal ederse ne olur? -* İhlaller nasıl rapor edilebilir? +- Davranış kuralları nerede yürürlüğe girer *(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)*? +- Davranış kuralları kimin için geçerlidir *(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)*? +- Birisi davranış kurallarını ihlal ederse ne olur? +- İhlaller nasıl rapor edilebilir? Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir. @@ -43,20 +43,15 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN ## Davranış kurallarınızı nasıl uygulayacağınıza karar verme - + -Bir ihlal meydana _gelmeden önce_ davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var: +Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var: -* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. +- İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. -* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. +- Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. -* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. +- Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir. @@ -66,7 +61,7 @@ Birisinin, bu raporları alan bir kişi hakkındaki ihlali bildirmek isteyebilec İlham almak için Django'nun [uygulama kılavuzunu inceleyin](https://www.djangoproject.com/conduct/enforcement-manual/) (ancak projenizin büyüklüğüne bağlı olarak bu kadar kapsamlı bir şeye ihtiyacınız olmayabilir). -## Davranış kural listesini güçlendirmek +## Davranış kurallarınızı güçlendirmek Bazen, en iyi çabalarınıza rağmen, birileri bu kodu ihlal eden bir şey yapabilir. Olay ortaya çıktığında olumsuz ya da zararlı davranışları ele almanın birkaç yolu vardır. @@ -78,12 +73,7 @@ Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesi Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın. - + ### Uygun işlemi yapın @@ -93,15 +83,15 @@ Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır: -* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. +- **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. -* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. +- Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin: -* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** +- Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** -* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** +- Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız. @@ -111,7 +101,7 @@ Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kur Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler. -_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. +*Teknik* olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler. From 49fbda6b00bfbffed71b9465b23e6986373b0953 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Sun, 9 May 2021 23:57:36 +0000 Subject: [PATCH 022/629] Translate finding-users.md via GitLocalize --- _articles/tr/finding-users.md | 79 +++++++---------------------------- 1 file changed, 16 insertions(+), 63 deletions(-) diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md index a3753a58406..914ee05a185 100644 --- a/_articles/tr/finding-users.md +++ b/_articles/tr/finding-users.md @@ -10,7 +10,7 @@ toc: go-where-your-projects-audience-is-online: Projenizin izleyicisinin (çevrimiçi) olduğu yere gidin go-where-your-projects-audience-is-offline: Projenizin kitlesinin (çevrimdışı) olduğu yere gidin build-a-reputation: Bir itibar oluşturun -order: 3 +order: '3' image: "/assets/images/cards/finding.png" related: - beginners @@ -27,7 +27,7 @@ Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığ Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır. -İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. +İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, *kullanıcıların ve katkıda bulunanların* ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır: @@ -37,12 +37,7 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa ## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun - + İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun. @@ -50,17 +45,11 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun. - + **Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin. -Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_. +Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin *"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi*. Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) . @@ -68,31 +57,25 @@ Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHu Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için kolay bir yolu olsun, haydi çıkıp izleyicilerinizle konuşun! -## Projenizin izleyicisinin (çevrimiçi) olduğu yere gidin +## Projenizin hedef kitlesinin olduğu yere gidin (çevrimiçi olarak) Çevrimiçi sosyal yardım, mesajınızı hızla paylaşmanın ve yaymanın harika bir yoludur. Çevrimiçi kanalları kullanarak, çok geniş bir kitleye ulaşma potansiyeline sahip olursunuz. Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun. - + Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın: -* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. -* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. -* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: _"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum_ ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. +- **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. +- **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. +- **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın. İlk duyurularınız hiç kimsesin dikkatini çekmiyorsa veya kimse cevap vermiyorsa, cesaretini kırmayın! Çoğu proje lansmanı aylar veya yıllar alabilen yinelemeli bir süreçtir. İlk kez bir yanıt alamazsanız, farklı bir taktik deneyin veya başkalarının çalışmalarına ilk olarak değer katmanın yollarını arayın. Projenizi tanıtmak ve başlatmak zaman ve özveri gerektirir. -## Projenizin kitlesinin (çevrimdışı) olduğu yere gidin +## Projenizin hedef kitlesinin olduğu yere gidin (çevrimdışı) ![Public speaking](/assets/images/finding-users/public_speaking.jpg) @@ -100,37 +83,19 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları [Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın. - + Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar. Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin. - + Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir. Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz. - + ## Bir itibar oluşturun @@ -138,25 +103,13 @@ Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir. - + İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin. Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir. - + ## Devam et! From a1a39d7ee96ac9136dc68ecce7a28f4cb5e033c4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Mon, 10 May 2021 00:06:28 +0000 Subject: [PATCH 023/629] Translate starting-a-project.md via GitLocalize --- _articles/tr/starting-a-project.md | 184 ++++++++++------------------- 1 file changed, 62 insertions(+), 122 deletions(-) diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index a466eb48bd2..b5d1598305a 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -9,11 +9,11 @@ toc: launching-your-own-open-source-project: Kendi açık kaynak projenizi başlatmak naming-and-branding-your-project: Projenizi isimlendirme ve markalama your-pre-launch-checklist: Lansman öncesi kontrol listeniz -order: 2 -image: /assets/images/cards/beginner.png +order: '2' +image: "/assets/images/cards/beginner.png" related: -- finding -- building + - finding + - building --- ## Açık kaynağın "nedir"i ve "neden"i @@ -26,25 +26,19 @@ Bir proje açık kaynak olduğunda, **herhangi biri herhangi bir amaç için pro Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek, benimseme engellerini azaltır. Ayrıca, kullanıcılara kapalı kaynağa göre kendi bilgisayarlarını ve bilgisayarlarında çalışan işlemleri kontrol etme imkanı da verir. Örneğin, açık kaynak yazılım kullanan bir işletme, yalnızca kapalı kaynak satıcısının ürün kararlarına güvenmek yerine, bir kişiyi yazılımda özel iyileştirmeler yapması için işe alma seçeneğine sahiptir. -_Özgür yazılım_ , _açık kaynak ile_ aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. _Free_ ve _Libre_ özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor). +*Özgür yazılım* , *açık kaynak ile* aynı proje grubunu ifade eder. Bazen [bu terimleri](https://en.wikipedia.org/wiki/Free_and_open-source_software) "ücretsiz ve açık kaynak yazılım" (FOSS) veya "ücretsiz, özgür ve açık kaynak yazılım" (FLOSS) olarak birleştirilir. *Free* ve *Libre* özgürlüğe atıfta bulunur [fiyata değil](#a%C3%A7%C4%B1k-kaynak-%C3%BCcretsiz-anlam%C4%B1na-m%C4%B1-geliyor). ### İnsanlar neden işlerini açık kaynak olarak sunarlar? - + Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler: -* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. +- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. -* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. +- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. -* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir. +- **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir. Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın. @@ -68,19 +62,13 @@ Henüz ikna olmadıysanız, hedeflerinizin ne olabileceğini düşünmek için b ### Hedeflerinizi belirlemek -Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, _neden bu projeye kaynak açıyorum?_ +Hedefler, neyin üzerinde çalışacağınızı, neye hayır diyeceğinizi ve başkalarından nereden yardıma ihtiyacınız olduğunu anlamanıza yardımcı olabilir. Kendinize şunu sorarak başlayın, *neden bu projeye kaynak açıyorum?* Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahip farklı projeler için birden fazla hedefiniz olabilir. Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız. - + Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir. @@ -90,13 +78,7 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın. - + ### Diğer projelere katkıda bulunmak @@ -112,24 +94,24 @@ Genel olarak konuşursak, başkalarının işinizi görmesini ve işiniz hakkın Projenizi hangi aşamada açmaya karar verirseniz verin, her proje aşağıdaki belgeleri içermelidir: -* [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) -* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) -* [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) -* [Davranış kuralları](../code-of-conduct/) +- [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +- [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +- [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +- [Davranış kuralları](../code-of-conduct/) Bir geliştirici olarak, bu bileşenler beklentileri iletmenize, katkıları yönetmenize ve herkesin yasal haklarını (kendi haklarınız dahil) korumanıza yardımcı olur. Olumlu bir deneyim yaşama şansınızı önemli ölçüde artırırlar. -Projeniz GitHub'taysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak GitHub'ın onları okuyucularınıza tanıtmasına ve otomatik olarak göstermesine yardımcı olacaktır. +Projeniz GitHub'daysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak, GitHub'ın bunları tanımasına ve okuyucularınız için otomatik olarak ortaya çıkarmasına yardımcı olur. ### Bir lisans seçimi -Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.** +Projeniz GitHub'taysa, bu dosyaları önerilen dosya adlarıyla kök dizininize koymak GitHub'ın onları okuyucularınıza tanıtmasına ve otomatik olarak göstermesine yardımcı olacaktır. Açık kaynaklı lisans, başkalarının projenize yanıt vermeden kullanabileceğini, kopyalayabileceğini, değiştirebileceğini ve katkıda bulunabileceğini garanti eder. Aynı zamanda sizi kötü yasal durumlardan korur. **Açık kaynak kodlu bir proje başlatırken projenize bir lisans eklemelisiniz.** -[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ve [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) en popüler açık kaynaklı lisanslardır, ancak seçilebilecek [başka seçenekler](https://choosealicense.com) de vardır. +[MIT](https://choosealicense.com/licenses/mit/) , [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ve [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) en popüler açık kaynak lisanslarıdır, ancak [aralarından seçim yapabileceğiniz başka seçenekler](https://choosealicense.com) de vardır. -GitHub'da yeni bir proje oluşturduğunuzda, size bir lisans seçme seçeneği sunulur. Açık kaynak lisansı eklemek GitHub projenizi açık kaynak yapar. +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) ve [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) en popüler açık kaynaklı lisanslardır, ancak seçilebilecek [başka seçenekler](https://choosealicense.com) de vardır. ![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) @@ -137,28 +119,22 @@ Açık kaynak kodlu bir projeyi yönetmenin yasal yönleri hakkında başka soru ### README Yazma -README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar. +README'ler, projenizi nasıl kullanılacağını açıklamadan fazlasını yapar. Ayrıca projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini açıklarlar. README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar. -* Bu proje ne yapıyor? -* Bu proje neden faydalıdır? -* Kullanmaya nasıl başlarım? -* İhtiyacım olursa nereden daha fazla yardım alabilirim? +- Bu proje ne yapıyor? +- Bu proje neden faydalıdır? +- Kullanmaya nasıl başlarım? +- İhtiyacım olursa nereden daha fazla yardım alabilirim? README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin. - + -Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler. +README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin. -Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make a README" kılavuzunu](https://www.makeareadme.com/) veya @PurpleBooth'ın [README şablonunu](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kullanmayı deneyin. +Bazen, insanlar bir README yazmaktan kaçınırlar çünkü proje bitmemiş gibi hissederler veya katkı kabul etmek istemezler. Bunların hepsi yazmak için çok iyi nedenler. Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make a README" kılavuzunu](https://www.makeareadme.com/) veya @PurpleBooth'ın [README şablonunu](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) kullanmayı deneyin. @@ -166,27 +142,27 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler. -* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) -* Yeni bir özellik nasıl önerilir -* Proje ortamı nasıl kurulur ve testler nasıl yapılır +- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) +- Yeni bir özellik nasıl önerilir +- Proje ortamı nasıl kurulur ve testler nasıl yapılır Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: -* Aradığınız katkı türleri -* Proje için yol haritanız veya vizyonunuz -* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) +- Aradığınız katkı türleri +- Proje için yol haritanız veya vizyonunuz +- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) -Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir. +Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: -Örneğin, [Active Admin](https://github.com/activeadmin/activeadmin/) [katkıda bulunan rehberine](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) şu şekilde başlar: +Sıcak, arkadaşça bir ton kullanmak ve katkılar için özel önerilerde bulunmak (örneğin, dokümantasyon yazmak veya bir web sitesi yapmak gibi) yeni gelenlerin kendilerini memnun ve istekli hissetmelerini sağlama konusunda yardımcı olabilir. > Öncelikle, Active Admin’e katkıda bulunduğunuz için teşekkür ederiz. Active Admin'i harika bir araç yapan sizin gibi insanlar. Projenizin ilk aşamalarında, CONTRIBUTING dosyanız basit olabilir. Hataların veya dosya sorunlarının nasıl bildirileceğini ve katkı sağlamak için teknik gereksinimleri (testler gibi) her zaman açıklamalısınız. -Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsiniz. Bu bilgileri yazmak, daha az kişinin size aynı soruları tekrar soracağı anlamına gelir. +Projenizin ilk aşamalarında, CONTRIBUTING dosyanız basit olabilir. Hataların veya dosya sorunlarının nasıl bildirileceğini ve katkı sağlamak için teknik gereksinimleri (testler gibi) her zaman açıklamalısınız. -CONTRIBUTING dosyanızı yazarken daha fazla yardım için @nayafia'nın [katkıda bulunma rehber şablonuna](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz. +Zamanla, CONTRIBUTING dosyanıza sıkça sorulan diğer soruları ekleyebilirsiniz. Bu bilgileri yazmak, daha az kişinin size aynı soruları tekrar soracağı anlamına gelir. CONTRIBUTING dosyanızı yazarken daha fazla yardım için @nayafia'nın [katkıda bulunma rehber şablonuna](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) veya @mozilla'nın ["Bir CONTRIBUTING.md Nasıl Oluşturulur"](https://mozillascience.github.io/working-open-workshop/contributing/) makalesine bakabilirsiniz. @@ -194,23 +170,17 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan ### Davranış kural listesi oluşturmak - + Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. -Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın. +Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. -Katılımcıların _nasıl_ davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir. +Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir. Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız. -Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosyayı projenizin kök dizininde tutun, böylece README'nizden kolayca bulabilir ve linkleyebilirsiniz. +Açık kaynaklı lisanslara benzer şekilde, davranış kuralları için de yeni ortaya çıkan standartlar vardır, bu yüzden kendiniz yazmak zorunda değilsiniz. [Contributor Covenant](https://contributor-covenant.org/), Kubernet, Rails ve Swift dahil olmak üzere [40.000'den fazla açık kaynaklı proje](https://www.contributor-covenant.org/adopters) tarafından kullanılan bir davranış kural listesi şablonudur. Hangi metni kullanırsanız kullanın, gerektiğinde davranış kurallarınızı uygulamak için hazırlıklı olmalısınız. ## Projenizi isimlendirme ve markalama @@ -220,44 +190,38 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir. -* [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler -* [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur +- [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler +- [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir). -Her şeyden önce netlik düşünün. Püf noktaları eğlencelidir, ancak bazı şakaların diğer kültürlere veya sizden farklı deneyimlere sahip insanlara tercüme edilemeyebileceğini unutmayın. Potansiyel kullanıcılarınızdan bazıları şirket çalışanları olabilir: projenizi işte açıklamak zorunda kaldıklarında onları rahatsız etmek istemezsiniz! +Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir). ### Benzersiz isim bulmak +Her şeyden önce netlik düşünün. Püf noktaları eğlencelidir, ancak bazı şakaların diğer kültürlere veya sizden farklı deneyimlere sahip insanlara tercüme edilemeyebileceğini unutmayın. Potansiyel kullanıcılarınızdan bazıları şirket çalışanları olabilir: projenizi işte açıklamak zorunda kaldıklarında onları rahatsız etmek istemezsiniz! + Özellikle aynı dili veya ekosistemi paylaşıyorsanız, [benzer bir adla açık kaynaklı projeleri kontrol edin](http://ivantomic.com/projects/ospnc/). İsminiz popüler bir projeyle örtüşüyorsa, takipçilerinizin kafaları karışabilir. Bir web sitesi, Twitter hesabı veya projenizi temsil eden diğer özellikleri istiyorsanız, istediğiniz adları aldığınızdan emin olun. İdeal olarak, [bu isimleri](https://instantdomainsearch.com/) henüz kullanmak istemediğiniz zamanlarda bile, rahat etmek için şimdiden alın. Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez. -Projenizin adının herhangi bir ticari markayı ihlal etmediğinden emin olun. Bir şirket sizden projenizi kapatmanızı isteyebilir veya hatta aleyhinize yasal işlem başlatabilir. Bu riske değmez. - [WIPO Global Marka Veritabanını](http://www.wipo.int/branddb/en/) ticari marka çakışmaları için kontrol edebilirsiniz. Eğer bir şirketteyseniz, bu [hukuk ekibinizin size yardımcı olabileceği](../legal/) şeylerden biridir. ### Nasıl yazdığın (ve kodladığın) markanı da etkiler! -Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. +Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. - + Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün. Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin markasının bir parçası olabilir. [Angular](https://angular.io/guide/styleguide) ve [jQuery](https://contribute.jquery.org/style-guide/js/) titiz kodlama stilleri ve yönergeleri olan projelere iki örnektir. -Yeni başladığınızda, projeniz için bir stil rehberi yazmak gerekli değildir ve yine de projenize farklı kodlama stilleri eklemekten zevk aldığınızı fark edebilirsiniz. Ancak, yazma ve kodlama stilinizin farklı insanları nasıl çekebileceğini veya caydıracağını tahmin etmelisiniz. Projenizin ilk aşamaları, görmek istediğiniz emsali belirleme fırsatınızdır. +Kelimeleri nasıl yazdığınızın ötesinde, kodlama stiliniz de projenizin markasının bir parçası olabilir. [Angular](https://angular.io/guide/styleguide) ve [jQuery](https://contribute.jquery.org/style-guide/js/) titiz kodlama stilleri ve yönergeleri olan projelere iki örnektir. ## Lansman öncesi kontrol listeniz @@ -267,53 +231,39 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
- +
- +
- +
- +
**Kod**
- +
- +
- +
**İnsanlar** @@ -322,39 +272,29 @@ Bireyseniz:
- +
Bir şirket veya kuruluşsanız:
- +
- +
- +
- +
## Başardınız! From 20d86932785458cd1c687f0d3cfde1b376107408 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Mon, 10 May 2021 00:10:48 +0000 Subject: [PATCH 024/629] Translate starting-a-project.md via GitLocalize --- _articles/tr/starting-a-project.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index b5d1598305a..c0dd38a4479 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -174,7 +174,7 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. -Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. +Daha fazla bilgi için [Davranış Kuralları kılavuzumuza](../code-of-conduct/) göz atın. Katılımcıların *nasıl* davranmasını beklediğinizi iletmenin yanı sıra, bir davranış kural listesi de bu beklentilerin kimlere, ne zaman başvuruda bulunduklarına ve bir ihlal meydana geldiğinde ne yapılması gerektiğini açıklamaya meyillidir. From 9547d757b56c58232bb3d42dcdfe624a7415263d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Mon, 10 May 2021 00:13:36 +0000 Subject: [PATCH 025/629] Translate starting-a-project.md via GitLocalize --- _articles/tr/starting-a-project.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index c0dd38a4479..7c8076466bc 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -128,7 +128,7 @@ README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını - Kullanmaya nasıl başlarım? - İhtiyacım olursa nereden daha fazla yardım alabilirim? -README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin. +README'nizi, katkıları nasıl ele aldığınız, projenin hedeflerinin ne olduğu ve lisanslar ve atıfla ilgili bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkıları kabul etmek istemiyorsanız veya projeniz henüz üretime hazır değilse, bu bilgileri not edin. From f505bc844147675fd9769709c9a376dc083093df Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Mon, 10 May 2021 03:57:26 +0300 Subject: [PATCH 026/629] Fix formating errors created by Gitlocalize --- _articles/tr/code-of-conduct.md | 38 ++-- _articles/tr/finding-users.md | 73 ++++++-- _articles/tr/how-to-contribute.md | 274 +++++++++++++++++++---------- _articles/tr/starting-a-project.md | 134 ++++++++++---- 4 files changed, 360 insertions(+), 159 deletions(-) diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md index 9ba8ff26e3b..886e0c91a85 100644 --- a/_articles/tr/code-of-conduct.md +++ b/_articles/tr/code-of-conduct.md @@ -30,10 +30,10 @@ Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar: -- Davranış kuralları nerede yürürlüğe girer *(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)*? -- Davranış kuralları kimin için geçerlidir *(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)*? -- Birisi davranış kurallarını ihlal ederse ne olur? -- İhlaller nasıl rapor edilebilir? +* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_? +* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_? +* Birisi davranış kurallarını ihlal ederse ne olur? +* İhlaller nasıl rapor edilebilir? Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir. @@ -43,15 +43,20 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN ## Davranış kurallarınızı nasıl uygulayacağınıza karar verme - + Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var: -- İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. +* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. -- Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. +* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. -- Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. +* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir. @@ -73,7 +78,12 @@ Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesi Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın. - + ### Uygun işlemi yapın @@ -83,15 +93,15 @@ Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır: -- **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. +* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. -- Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. +* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin: -- Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** +* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** -- Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** +* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız. @@ -101,7 +111,7 @@ Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kur Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler. -*Teknik* olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. +_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler. diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md index 914ee05a185..20d8e3c976e 100644 --- a/_articles/tr/finding-users.md +++ b/_articles/tr/finding-users.md @@ -27,7 +27,7 @@ Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığ Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır. -İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, *kullanıcıların ve katkıda bulunanların* ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. +İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır: @@ -37,7 +37,12 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa ## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun - + İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun. @@ -45,11 +50,17 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun. - + **Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin. -Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin *"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi*. +Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_. Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) . @@ -63,13 +74,19 @@ Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun. - + Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın: -- **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. -- **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. -- **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. +* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. +* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. +* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın. @@ -83,19 +100,37 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları [Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın. - + Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar. Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin. - + Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir. Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz. - + ## Bir itibar oluşturun @@ -103,13 +138,25 @@ Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir. - + İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin. Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir. - + ## Devam et! diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index 0f79a454a87..487e228f428 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -19,7 +19,13 @@ related: ## Açık kaynağa neden katkıda bulunmalıyım? - + Açık kaynağa katkıda bulunmak, hayal edebileceğiniz herhangi bir konuyu öğrenmek, öğretmek ve deneyim geliştirmek için faydalı bir yol olabilir. @@ -63,59 +69,77 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız! - + Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir. - + ### Etkinlik planlamayı sever misiniz? -- [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin -- Projenin konferansını düzenleyin (eğer varsa) -- Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun +* [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin +* Projenin konferansını düzenleyin (eğer varsa) +* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun ### Tasarlamayı sever misiniz? -- Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın -- [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın -- Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın -- [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın +* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın +* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın +* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın +* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın ### Yazmayı sever misin? -- Proje dokümantasyonunu yazın ve geliştirin -- Projenin nasıl kullanıldığını gösteren örnekler oluşturun -- Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın -- [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın -- Projenin dokümantasyonu için çeviri yapın +* Proje dokümantasyonunu yazın ve geliştirin +* Projenin nasıl kullanıldığını gösteren örnekler oluşturun +* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın +* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın +* Projenin dokümantasyonu için çeviri yapın - + ### Organize etmeyi sever misiniz? -- Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin -- Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) -- Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. +* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin +* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) +* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. ### Kod yazmayı sever misiniz? -- [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun -- Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun -- Proje kurulumunu otomatikleştirin -- Araçları ve testleri geliştirin +* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun +* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun +* Proje kurulumunu otomatikleştirin +* Araçları ve testleri geliştirin ### İnsanlara yardım etmeyi sever misiniz? -- Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te -- İnsanlar için açık konulardaki soruları cevaplayın -- Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun +* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te +* İnsanlar için açık konulardaki soruları cevaplayın +* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun ### Başkalarına kod yazarken yardım etmeyi sever misiniz? -- Diğer kişilerin gönderimlerindeki kodu inceleyin -- Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın -- Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) +* Diğer kişilerin gönderimlerindeki kodu inceleyin +* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın +* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) ### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz! @@ -123,15 +147,21 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d Örneğin: -- @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) -- @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor -- @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) +* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) +* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor +* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır. ## Kendinizi yeni bir projeye yönlendirmek - + Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. @@ -147,34 +177,34 @@ Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapıların Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir: -- **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) -- **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) -- **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) -- **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes -- **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. +* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) +* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) +* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) +* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes +* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın. Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir. -- **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. -- **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. -- **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. -- **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. -- **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. +* **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. +* **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. +* **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. +* **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. +* **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir. -- **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. -- **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. -- **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. -- **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. +* **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. +* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. +* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. +* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. ## Katkıda bulunacak bir proje bulma Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı! -Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi örnek alın. +Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil * ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi örnek alın. Açık kaynağa katkıda bulunmak, farklı projelerde her seviyede gerçekleşir. İlk katkınızın tam olarak ne olacağını veya nasıl görüneceğini düşünmeniz gerekmez. @@ -192,15 +222,15 @@ Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz: -- [GitHub Explore](https://github.com/explore/) -- [Open Source Friday](https://opensourcefriday.com) -- [First Timers Only](https://www.firsttimersonly.com/) -- [CodeTriage](https://www.codetriage.com/) -- [24 Pull Requests](https://24pullrequests.com/) -- [Up For Grabs](https://up-for-grabs.net/) -- [Contributor-ninja](https://contributor.ninja) -- [First Contributions](https://firstcontributions.github.io) -- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi @@ -212,7 +242,9 @@ Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kab
- +
**Proje aktif olarak katkı kabul ediyor** @@ -221,71 +253,97 @@ Ana daldaki geliştirici faaliyetine bakın. GitHub'da, bu bilgiyi bir kütüpha
- +
- +
- +
Ardından, projenin sorun listesine bakın.
- +
- +
- +
- +
- +
Şimdi aynısını projenin PR listesi için yapın.
- +
- +
- +
- +
- +
**Proje katkı bekliyor mu?** @@ -294,25 +352,39 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac
- +
- +
- +
- +
- + ## Nasıl katkı yapılır? @@ -322,7 +394,13 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir. - + Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun. @@ -370,47 +448,53 @@ Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığ Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız: -- **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir -- **PR** bir çözüm üzerinde çalışmaya başlamak içindir -- **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. +* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir +* **PR** bir çözüm üzerinde çalışmaya başlamak içindir +* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. Bir sorun açmadan veya talepte bulunmadan önce, belirli bir şey eklemeniz gerekip gerekmediğini görmek için projenin katkıda bulunma belgelerini (genellikle CONTRIBUTING veya README dosyaları) kontrol edin. Örneğin, bir şablon izlemenizi istenebilir veya test ortamı kullanmanız gerekebilir. Önemli bir katkı yapmak istiyorsanız, üzerinde çalışmadan önce sormanız gereken bir sorun açın. Projeyi bir süre izlemeniz yararlı olacaktır (GitHub'da, tüm konuşmalar size bildirilmek için ["İzle"yi tıklayabilirsiniz](https://help.github.com/articles/watching-repositories/)) ve kabul edilmeyebilecek bir işe başlamadan önce topluluk üyelerini tanıyın. - + ### Bir istek/sorun açmak Genellikle aşağıdaki durumlarda bir sorun açmalısınız: -- Çözemediğiniz bir hatayı bildirmek için -- Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) -- Yeni bir özellik veya başka bir proje fikri önermek için +* Çözemediğiniz bir hatayı bildirmek için +* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) +* Yeni bir özellik veya başka bir proje fikri önermek için Sorunlar üzerinde iletişim kurmak için ipuçları: -- **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. -- **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. -- **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. +* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. +* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. +* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. ### PR açma Genellikle aşağıdaki durumlarda bir PR açmalısınız: -- Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) -- Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda +* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) +* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz. Proje GitHub'taysa, PR nasıl gönderilir: -- **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) -- Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . -- **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") -- Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. -- **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. -- **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. +* **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) +* Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . +* **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") +* Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. +* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. +* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz. diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index 7c8076466bc..e577a4289a3 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -30,15 +30,21 @@ Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek ### İnsanlar neden işlerini açık kaynak olarak sunarlar? - + Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler: -- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. +* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. -- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. +* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. -- **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir. +* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir. Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın. @@ -68,7 +74,13 @@ Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahi Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız. - + Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir. @@ -78,7 +90,13 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın. - + ### Diğer projelere katkıda bulunmak @@ -94,10 +112,10 @@ Genel olarak konuşursak, başkalarının işinizi görmesini ve işiniz hakkın Projenizi hangi aşamada açmaya karar verirseniz verin, her proje aşağıdaki belgeleri içermelidir: -- [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) -- [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) -- [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) -- [Davranış kuralları](../code-of-conduct/) +* [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Davranış kuralları](../code-of-conduct/) Bir geliştirici olarak, bu bileşenler beklentileri iletmenize, katkıları yönetmenize ve herkesin yasal haklarını (kendi haklarınız dahil) korumanıza yardımcı olur. Olumlu bir deneyim yaşama şansınızı önemli ölçüde artırırlar. @@ -123,14 +141,20 @@ README'ler, projenizi nasıl kullanılacağını açıklamadan fazlasını yapar README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar. -- Bu proje ne yapıyor? -- Bu proje neden faydalıdır? -- Kullanmaya nasıl başlarım? -- İhtiyacım olursa nereden daha fazla yardım alabilirim? +* Bu proje ne yapıyor? +* Bu proje neden faydalıdır? +* Kullanmaya nasıl başlarım? +* İhtiyacım olursa nereden daha fazla yardım alabilirim? README'nizi, katkıları nasıl ele aldığınız, projenin hedeflerinin ne olduğu ve lisanslar ve atıfla ilgili bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkıları kabul etmek istemiyorsanız veya projeniz henüz üretime hazır değilse, bu bilgileri not edin. - + README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin. @@ -142,15 +166,15 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler. -- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) -- Yeni bir özellik nasıl önerilir -- Proje ortamı nasıl kurulur ve testler nasıl yapılır +* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) +* Yeni bir özellik nasıl önerilir +* Proje ortamı nasıl kurulur ve testler nasıl yapılır Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: -- Aradığınız katkı türleri -- Proje için yol haritanız veya vizyonunuz -- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) +* Aradığınız katkı türleri +* Proje için yol haritanız veya vizyonunuz +* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: @@ -170,7 +194,13 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan ### Davranış kural listesi oluşturmak - + Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. @@ -190,8 +220,8 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir. -- [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler -- [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur +* [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler +* [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir). @@ -215,7 +245,13 @@ Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici b Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. - + Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün. @@ -231,39 +267,53 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
- +
- +
- +
- +
**Kod**
- +
- +
- +
**İnsanlar** @@ -272,29 +322,39 @@ Bireyseniz:
- +
Bir şirket veya kuruluşsanız:
- +
- +
- +
- +
## Başardınız! From 06c7506fdee312aa1816e1d22ca659449fcef07e Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Wed, 12 May 2021 08:07:42 +0000 Subject: [PATCH 027/629] Bump actions/setup-ruby from 1 to 1.1.3 Bumps [actions/setup-ruby](https://github.com/actions/setup-ruby) from 1 to 1.1.3. - [Release notes](https://github.com/actions/setup-ruby/releases) - [Commits](https://github.com/actions/setup-ruby/compare/v1...v1.1.3) Signed-off-by: dependabot[bot] --- .github/workflows/tests.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 27f8a14d6a8..0eb22ebf388 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -11,7 +11,7 @@ jobs: uses: actions/checkout@v2.3.4 - name: Set up Ruby - uses: actions/setup-ruby@v1 + uses: actions/setup-ruby@v1.1.3 - name: Set up Node uses: actions/setup-node@v2.1.5 From 5470c2f44c3d8d8c01c66d9f7c6b019b4baa8b5b Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Fri, 14 May 2021 16:20:21 +0430 Subject: [PATCH 028/629] Initial translation done. --- _articles/fa/legal.md | 152 +++++++++++++++++++++--------------------- 1 file changed, 76 insertions(+), 76 deletions(-) diff --git a/_articles/fa/legal.md b/_articles/fa/legal.md index ed6cf093fd5..fe8c35ec5f4 100644 --- a/_articles/fa/legal.md +++ b/_articles/fa/legal.md @@ -1,16 +1,8 @@ --- -lang: en -title: The Legal Side of Open Source -description: Everything you've ever wondered about the legal side of open source, and a few things you didn't. +lang: fa +title: جنبه‌های حقوقی پروژه‌های متن باز +description: تمامی چیزهایی که در مورد جنبه‌های حقوقی متن باز برای شما سوال شده و چیزهایی که سوال نشده. class: legal -toc: - why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?" - are-public-github-projects-open-source: "Are public GitHub projects open source?" - just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project" - which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?" - what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?" - does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?" - what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?" order: 10 image: /assets/images/cards/legal.png related: @@ -18,149 +10,157 @@ related: - leadership --- -## Understanding the legal implications of open source +## درک پیامدهای حقوقی پروژه‌های منبع آزاد -Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).) +اشتراک گذاشتن کارهای خلاقانه با جهانیان می‌تواند تجربه‌ای هیجان‌انگیز و ارزشمند باشد. همچنین می‌تواند به معنای درگیر شدن با یک سری موارد حقوقی باشد در رابطه با آن‌ها چیزی نمی‌دانید. خوشبختانه، نیازی نیست از ابتدا شروع کنید. ما نیازهای حقوقی شما را برآورده کرده و پوشش داده‌ایم. (قبل از شروع، حتماً متن [سلب مسئولیت](/notices/) ما را بخوانید.) -## Why do people care so much about the legal side of open source? +## چرا مردم اینقدر به جنبه‌های حقوقی متن آزاد اهمیت می‌دهند؟ -Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it. +به طور کلی، به این معنی است که هیچ کس دیگری نمی‌تواند از اثر شما استفاده کند، کپی کند، پخش کند یا اصلاحاتی روی آن انجام دهد؛ بدون اینکه در معرض ریسک دعوی قضایی و پیگیری قرار بگیرد. -In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. +هرچند پروژه‌های متن باز شرایطی غیرمعمول دارند، زیرا خالق اثر انتظار دارد که دیگران از اثر استفاده کنند و آن را اصلاح نمایند و به اشتراک بگذارند. اما از آنجا که پیش‌فرض قانونی همچنان شامل حقق نشر می‌شود، شما به مجوزی نیاز دارید که صریحاً این دسترسی‌ها را میسر سازد. -Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions. +اگر مجوز (لایسنس) مربوط به پروژه‌های متن باز را اعمال نکنید، همه کسانی که در پروژۀ شما مشارکت می‌کنند نیز به عنوان دارندۀ حق نشر برای کارهای منحصر به فرد خود شناخته می‌شوند. این بدان معناست که هیچ کس نمی‌تواند از مشارکت‌های خود استفاده یا کپی کند و آن را توزیع یا اصلاح نماید و این «هیچ کس» شامل شما هم می‌شود. -If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you. +در آخر اینکه ممکن است پروژۀ شما وابستگی‌هایی با ملزومات مجوز داشته باشد که از آن‌ها اطلاع نداشته باشید. انجمن (community) پروژه یا سیاست‌های کارفرمایی شما نیز ممکن است پروژه را ملزم به استفاده از مجوز‌های متن باز خاصی بکند. در زیر دربارۀ آن توضیح می‌دهیم. -Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. -## Are public GitHub projects open source? +## آیا پروژه‌های عمومی «GitHub» متن باز محسوب می‌شوند؟ -When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**. +هنگام ایجاد [پروژه‌ای جدید](https://help.github.com/articles/creating-a-new-repository/) در «GitHub»، این انتخاب را دارید که منبع را **خصوصی** یا **عمومی** مشخص کنید ![Create repository](/assets/images/legal/repo-create-name.png) -**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. +**عمومی کردن پروژه‌تان در «GitHub» به منزلۀ مجوزدار کردن پروژه نیست.** پروژه‌های عمومی‌ای که [تحت شرایط خدمات «GitHub»](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants) قرار می‌گیرند این امکان را برای افراد میسر می‌سازد که پروژه شما را مشاهده کنند و آن را فورک (fork) کنند، اما در غیر این افراد همچین اجازه‌ای ندارند. -If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. +اگر می‌خواهید دیگران از پروژۀ شما استفاده کنند، آن را توزیع دهند یا اصلاح نمایند و در آن مشارکت کنند، باید پروانۀ مخصوص پروژه‌های متن باز داشته باشید. به عنوان مثال، کسی قانونا نمی‌تواند از هر بخشی از پروژۀ «GitHub» شما در کد خود استفاده کند، حتی اگر عمومی باشد؛ مگر اینکه صریحاً به او اجازۀ چنین کاری را بدهید. -## Just give me the TL;DR on what I need to protect my project. +## به من توضیحات تکمیلی را در مورد چگونگی مراقبت از پروژه بدهید -You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project. +امروزه کار خیلی ساده‌تر شده است زیرا مجوز‌های پروژه‌های متن باز استاندارد شده و استفاده از آن‌ها آسان است. می‌توانید مجوزهای (پروانه‌های) موجود را مستقیماً در پروژۀ خود کپی کنید. -[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). +[MIT](https://choosealicense.com/licenses/mit/) ، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) و [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) معروف‌ترین مجوزهای متن باز هستند، اما گزینه‌های دیگری نیز برای انتخاب وجود دارد. می‌توانید متن کامل این مجوزها و دستورالعمل‌های مربوط به نحوۀ استفاده از آن‌ها را در سایت [choosealicense.com] پیدا کنید. -When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). +وقتی پروژۀ جدیدی را در «GitHub» ایجاد می‌کنید، [از شما خواسته می‌شود مجوزی را انتخاب کرده و به پروژه اضافه کنید](https://help.github.com/articles/open-source-licensing/). -## Which open source license is appropriate for my project? +## چه مجوز متن بازی برای پروژۀ من مناسب است؟ -If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. +اگر تازه‌کار هستید، [مجوز MIT](https://choosealicense.com/licenses/mit/) به درد شما می‌خورد. کوتاه است، درک آن بسیار آسان می‌باشد و به هر کسی اجازه می‌دهد هر کاری انجام دهد تا زمانی که کپی مجوز، از جمله اخطار حق نشر شما را نگه دارند. در صورت نیاز، می‌توانید پروژه را تحت هر مجوز دیگری انتشار دهید. -Otherwise, picking the right open source license for your project depends on your objectives. +در غیر این صورت، انتخاب مجوز متن باز مناسب برای پروژۀ شما به اهداف‌تان بستگی دارد. -Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. +پروژۀ شما به احتمال زیاد **وابستگی‌ها** و مولفه‌های فراوانی داشته باشد (یا خواهد داشت). به عنوان مثال، اگر در پروژۀ متن باز خود از «Node.js» استفاده می‌کنید، احتمالاً از کتابخانه‌های Node Package Manager (npm) (مدیریت پکیج Node) استفاده خواهید کرد. هر کدام از این کتابخانه‌هایی که به آن‌ها وابسته هستید، مجوز (لایسنس، پروانه) متن باز مخصوص به خود را دارند. اگر هر یک از مجوزهای آن‌ها «اختیاری» باشد (بدون هیچ گونه شرطی برای فعالیت‌های آینده، اجازۀ استفاده، اصلاح، تغییر و اشتراک‌گذاری را به عموم مردم می‌دهد)، می‌توانید از هر مجوزی که می‌خواهید استفاده کنید. مجوزهای اختیاری متداول شامل «MIT»، «Apache 2.0»، «ISC» و «BSD» می‌شوند. -On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. +از طرف دیگر، اگر هر یک از مجوزهای وابستگی شما، «کپی‌لفت قوی» باشند (مشروط به استفاده از همان مجوز در آینده، مجوزهای عمومی مشابهی را می‌دهد)، در این صورت پروژۀ شما باید از همان مجوز استفاده کند. مجوزهای متداول کپی‌لفت ((Copyleft (تعریف: کپی‌لفت نوعی بازی با کلمهٔ کپی‌رایت است. کپی‌لفت عملی را توصیف می‌کند که در آن تضمین می‌شود که اجازهٔ نسخه‌برداری و ویرایش یک اثر برای همگان محفوظ می‌مانَد و هیچ شخصی اجازه ندارد حق ویرایش و نسخه‌برداری را از دیگر افراد سلب کند.) قوی شامل «GPLv2»، «GPLv3» و «AGPLv3» می‌شوند. -You may also want to consider the **communities** you hope will use and contribute to your project: +همچنین ممکن است بخواهید **انجمن‌هایی** را در نظر بگیرید که امیدوار هستید از پروژۀ شما استفاده کنند و در آن مشارکت کنند: -* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). -* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. -* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. +* **آیا می‌خواهید پروژۀ شما به عنوان وابستگی توسط سایر پروژه‌ها مورد استفاده قرار گیرد؟** بهتر است محبوب‌ترین نوع مجوز را در انجمن‌تان استفاده کنید. به عنوان مثال، [MIT](https://choosealicense.com/licenses/mit/) محبوب‌ترین مجوز برای [کتابخانه‌های npm](https://libraries.io/search?platforms=NPM) است. -Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know). +* **آیا می‌خواهید پروژۀ شما مورد توجه کسب و کارهای بزرگ قرار بگیرد؟** کسب‌وکارهای بزرگ احتمالاً سریعا مجوز ثبت اختراع را از تمامی مشارکت‌کنندگان می‌خواهند. در این صورت، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) به درد شما و آن‌ها می‌خورد. -When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). +* **آیا می‌خواهید پروژه شما مورد توجه مشارکت‌کنندگانی قرار بگیرد که نمی‌خواهند مشارکت‌های آن‌ها در نرم‌افزارهای متن بسته مورد استفاده قرار بگیرد؟** [GPLv3] یا (همچنین اگر آن‌ها تمایلی به مشارکت در خدمات متن بسته ندارند) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) به درد خواهد خورد. -## What if I want to change the license of my project? +ممکن است **شرکت** شما در پروژه‌های متن باز، شرایط خاصی برای مجوزها داشته باشد. به عنوان مثال، ممکن است به مجوز اختیاری نیاز داشته باشد تا شرکت بتواند از پروژۀ شما در محصول متن بستۀ خود استفاده کند. یا ممکن است شرکت شما به یک مجوز کپی‌لفت قوی و یک توافق‌نامۀ همکاری اضافی نیاز داشته باشد (به زیر مراجعه کنید) تا فقط منحصرا شرکت شما بتواند از پروژه در نرم‌افزارهای متن بسته استفاده کند. یا ممکن است شرکت شما نیازها و شرایط خاصی در رابطه با استانداردها، مسئولیت‌های اجتماعی یا شفافیت داشته باشد، که هر یک از آن‌ها ممکن است به یک استراتژی خاص دیگری در ارتباط با مجوز نیاز داشته باشد. با [بخش حقوقی شرکت] خود در رابطه با این موارد صحبت کنید. -Most projects never need to change licenses. But occasionally circumstances change. +هنگام ایجاد پروژه جدید در «GitHub»، به شما امکان انتخاب نوع مجوز داده می‌شود. انتخاب یکی از مجوزهایی که در بالا ذکر شد، پروژۀ «GitHub» شما را متن باز می‌کند. اگر مایل به دیدن گزینه‌های دیگه‌ای هستید، [choosealicense.com](https://choosealicense.com) را بررسی کنید تا مجوز مناسب‌تان را پیدا کنید حتی اگر برای [نرم‌افزار](https://choosealicense.com/non-software/) نباشد. -For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license: +## اگر بخواهم مجوز پروژۀ خود را تغییر دهم چه کاری باید بکنم؟ -**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! +اکثر پروژه‌ها به تغییر دادن مجوز خود، نیازی پیدا نمی‌کنند. ولی گاهی اوقات شرایط فرق می‌کند. -**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. +به عنوان مثال، با رشد پروژۀ شما، وابستگی‌ها یا کاربران آن اضافه می‌شود یا شرکت شما استراتژی‌های خود را تغییر می‌دهد که هرکدام از آن‌ها نیاز به مجوز دیگری دارند. همچنین، اگر از ابتدا مجوزی برای پروژۀ خود انتخاب نکردید، افزودن مجوز در واقع تفاوتی با تغییر مجوز ندارد. هنگام افزودن یا تغییر مجوز پروژه، سه نکتۀ اساسی باید در نظر گرفته شود: -**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. +**کاری پیچیده است.** تعیین سازگاری و انطباق مجوز و حق نشر می تواند خیلی زود پیچیده و گیج‌کننده شود. تغییر مجوز به مجوزی جدید و سازگار برای نسخه‌های جدید و مشارکت‌ها با تغییر مجوز تمامی مشارکت‌های موجود، تفاوت‌هایی دارد. در اولین قدم، در صورت تمایل به تغییر مجوزها، تیم حقوقی شما درگیر می‌شود. حتی اگر برای تغییر مجوز از دارندگان حق نشر پروژه خود اجازه دارید یا می‌توانید از آن‌ها اجازه بگیرید، تأثیر این تغییر را بر سایر کاربران و مشارکت‌کنندگان پروژۀ خود در نظر داشته باشید. تغییر مجوز را به صورت یک «رویداد مدیریتی» برای پروژۀ خود تصور کنید که به احتمال زیاد با برقراری ارتباط صریح و مشورت با ذی‌نفعان پروژه، هموارتر پیش خواهد رفت. بنابراین بهتر است از بدو تأسیس، مجوزی مناسب را برای پروژۀ خودتان انتخاب کنید! -Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. +**مجوز موجود و فعلی پروژه‌تان.** در صورتی که مجوز کنونی پروژۀ شما با مجوزی که می‌خواهید به آن تغییر دهید سازگار باشد، می‌توانید از مجوز جدید استفاده کنید. به این دلیل که اگر مجوز A با مجوز B سازگار باشد، در حالی که با شرایط B مطابقت دارید، با شرایط A نیز منطبق خواهید بود (اما لزوما برعکس آن درست نیست). بنابراین اگر در حال حاضر از مجوزی اختیاری استفاده می‌کنید (به عنوان مثال، «MIT»)، می‌توانید به مجوزی با شرایط بیشتری تغییر مجوز دهید، به شرطی که نسخه‌ای از مجوز «MIT» و هرگونه شرط حق نشر دیگۀ مربوط به آن را حفظ کنید (یعنی همچنان با حداقل شرایط مجوز «MIT» سازگار باشید). اما اگر مجوز فعلی شما اختیاری نباشد (به عنوان مثال کپی‌لفت باشد یا مجوزی نداشته باشید) و تنها دارندۀ حق نشر نیستید، نمی‌توانید مجوز پروژۀ خود را به «MIT» تغییر دهید. اساساً، صاحبان حق نشر پروژه با داشتن مجوز اختیاری از قبل اجازۀ تغییر مجوزها را داده‌اند. -## Does my project need an additional contributor agreement? +**صاحبان کنونی حق‌نشر پروژه‌تان.** اگر تنها مشارکت‌کننده در پروژه‌تان هستید، شما یا شرکت شما تنها صاحبان حق‌نشر این پروژه خواهید بود. خودتان یا شرکت می‌توانید، مجوز را تغییر دهید یا مجوز جدیدی اضافه کنید. در غیر این صورت ممکن است باید قبل از تغییر مجوز، با دیگر صاحبان حق‌نشر به توافق برسید. آن‌ها چه کسانی هستند؟ افرادی که در متعهد به پروژه هستند، نفطۀ خوبی برای شروع است. اما در برخی موارد حق‌نشر توسط افراد بالادستی این افراد حفظ می‌شود. در برخی موارد افراد مشارکت کم و حداقلی داشته‌اند، اما هیچ قانون سخت و جدی وجود ندارد که بگوید افرادی که مشارکتی در برخی از خطوط کد داشته‌اند مشمول حق‌نشر نباشد. چه کار باید کرد؟ بستگی دارد. برای پروژه‌ای نسبتاً کوچک و تازه‌شکل گرفته، ممکن است امکان‌پذیر باشد که همۀ مشارکت‌کنندگان موجود با تغییر مجوز در طرح مسئله‌ای یا در درخواست pullی موافقت کنند. برای پروژه‌های بزرگ و قدیمی، ممکن است برای مثلا تغییر مجوز مجبور شوید به جستجوی بسیاری از مشارکت‌کنندگان و حتی ورثه‌های آن‌ها مشغول شوید. موزیلا سال‌ها به طول انجامید (2001 تا 2006) تا مجوز «Firefox»، «Thunderbird» و دیگر نرم‌افزارهای مربوطه را تغییر دهد. -Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). +همچنین می‌توانید موافقت مشارکت‌کنندگان را از قبل جلب کنید (از طریق توافق‌نامه‌های مشارکتی اضافی - به زیر مراجعه کنید) تا بتوانید کارتان را در مورد برخی از تغییرات مجوز تحت شرایط خاصی را فراتر از شرایط مجاز مجوز متن باز موجود پیش ببرید. این موضوع پیچیدگی تغییر مجوزها را کمی تغییر می‌دهد. برای اینکار به کمک وکلای خود بیشتر احتیاج خواهید داشت و هنوز هم باید در هنگام اجرای تغییر مجوز، به طور واضح با ذی‌نفعان پروژۀ خود صحبت کنید. -An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. +## آیا پروژۀ من به توافق‌نامه‌های همکاری (مشارکتی) اضافی نیاز دارد؟ + +به احتمال زیاد نه. برای اکثریت قریب به اتفاق پروژه‌های متن باز، یک مجوز متن آزاد به طور ضمنی به عنوان مجوز درونی (برای مشارکت‌کنندگان) و مجوز خارجی (برای سایر مشارکت‌کنندگان و کاربران) عمل می‌کند. اگر پروژۀ شما در «GitHub» میزبانی می‌شود، شرایط خدمات‌دهی «GitHub»، «مجوزهای درونی و مجوزهای خروجی را [صریحا پیش‌فرض](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license) درنظر می‌گیرد. + +توافق‌نامه‌های همکاری اضافی - که اغلب به آن توافق‌نامه مجوز مشارکت‌کننده (CLA) گفته می‌شود - برای نگهدارندگان پروژه می‌تواند کارهای مدیریتی ایجاد کند. اینکه توافق‌نامه چه مقدار کار اضافه می‌کند به پروژه و نحوۀ اجرای آن بستگی دارد. یک توافق‌نامه‌ی ساده ممکن است نیاز داشته باشد که مشارکت‌کنندگان با یک کلیک تأیید کنند که از حقوق لازم برای مشارکت در مجوز پروژه متن باز برخوردار هستند. یک توافق‌نامه‌ی پیچیده‌تر ممکن است نیاز به بررسی قانونی داشته باشد و مربوط به کارفرمایان مشارکت‌کنندگان شود. + +همچنین، با افزودن «تشریفات اداری» که به عقیدۀ برخی غیرضروری می‌باشد و فهم آن سخت یا ناعادلانه است (وقتی که ذی‌نفعان توافق‌نامه حقوق و مزایای بیشتری از مشارکت‌کنندگان یا عموم مردمی که کارهایی در پروژه‌ی متن باز انجام می‌دهند، به دست می‌آورند)؛ به همین خاطر ممکن است یک توافق‌نامه‌ی همکاری اضافی غیرمنصفانه نسبت به انجمن پروژه تلقی شود. -Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community. -Some situations where you may want to consider an additional contributor agreement for your project include: +برخی از شرایطی که ممکن است بخواهید یک توافق‌نامه‌ی همکاری اضافی را برای پروژۀ خود در نظر بگیرید، شامل این موارد می‌شود: + +* وکلای شما می‌خواهند که تمامی مشارکت‌کنندگان به طور صریح شرایط مشارکت (آنلاین یا آفلاین) را بپذیرند، شاید به این دلیل که فکر می‌کنند مجوز متن باز به خودی خود کافی نیست (با اینکه هست!). اگر این تنها نگرانی است، توافق‌نامه‌ی مشارکت‌کننده که مجوز پروژۀ متن باز را تأیید می‌کند باید کافی باشد. [توافق‌نامۀ مجوز مشارکت‌کنند‌ۀ حقیقی jQuery] نمونۀ خوبی از توافق‌نامۀ همکاری اضافی خفیف است. + +* شما یا وکیل‌هاتان بخواهید توسعه‌دهندگان نشان دهند که هر تعهدی که روی آن کار می‌کنند مجاز است. الزام [گواهی مبدا توسعه‌دهنده](https://developercertificate.org/) برای این است که چه تعداد پروژه به این صورت هستند. به عنوان مثال، انجمن «Node.js» به جای «توافق‌نامۀ مجوز مشارکت‌کننده» قبلی خود از «گواهی مبدا توسعه‌دهنده» استفاده می کند. راهکار ساده برای اجرای خودکار «گواهی مبدا توسعه‌دهنده» در منبع (repository) شما، «ربات گواهی مبدا توسعه‌دهنده» است. -* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. -* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). -* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. -* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. -* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. +* پروژۀ شما از یک مجوز متن باز استفاده بکند که شامل امتیاز ثبت اختراع (مانند MIT) نباشد و شما به داشتن سریع امتیاز ثبت اختراع مشارکت‌کنندگان نیاز داشته باشید؛ برخی از آن‌ها ممکن است در شرکت‌هایی با مجموعه‌های بزرگ حق ثبت اختراع کار کنند که می‌تواند شما یا سایر مشارکت‌کنندگان و کاربران پروژه را مورد هدف قرار دهد. [توافق‌نامۀ مجوز مشارکت‌کنندگان حقیقی Apache]https://www.apache.org/licenses/icla.pdf)، یک توافق‌نامۀ همکاری اضافی است که معمولاً مورد استفاده قرار می‌گیرد و شامل امتیاز ثبت اختراع است که همانند آنچه در مجوز «Apache 2.0» یافت می‌شود، است. -If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. +* پروژۀ شما تحت مجوز کپی‌لفت باشد ، اما شما همچنین باید نسخه‌ای اختصاصی از پروژه را توزیع و پخش کنید. هر مشارکت‌کننده باید به شما حق نشر اختصاص دهد یا به شما (اما نه به عموم) مجوز اختیاری بدهد. [توافق‌نامۀ همکاری MongoDB](https://www.mongodb.com/legal/contributor-agreement) نمونه‌ای از این نوع توافق‌نامه است. -## What does my company's legal team need to know? +* ممکن باشد پروژۀ شما در طول عمر خود مجوزهایش را تغییر بدهد و بخواهید مشارکت‌کنندگان از قبل با چنین تغییراتی موافقت کنند. -If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project. +اگر در پروژۀ خود نیازی به استفاده از توافق‌نامه‌های همکاری اضافی داشته باشید، استفاده از توافق‌نامه‌های یکپارچه‌سازی مانند [توافق‌نامۀ مجوز مشارکت‌کننده](https://github.com/cla-assistant/cla-assistant) را برای به حداقل رساندن حواس‌پرتی مشارکت‌کنندگان در نظر بگیرید. -For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company. +## تیم حقوقی شرکت من چه چیزهایی را باید بداند؟ -**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: +اگر به عنوان کارمند شرکت پروژه‌ای متن باز را منتشر می‌کنید، ابتدا تیم حقوقی باید بداند که شما در حال تهیۀ پروژه‌ای متن باز هستید. -* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. +حتما این موضوع را به آن‌ها بگویید حتی اگر این پروژه‌ای شخصی باشد. شما احتمالاً با شرکت خود «توافق‌نامۀ کارمندی» دارید که به آن‌ها تا حدودی کنترلی بر روی پروژه های شما می‌دهد، به خصوص اگر مربوط به شرکت باشند یا از منابع شرکت برای توسعۀ پروژه استفاده کرده باشید. شرکت شما _باید_ به شما اجازه دهد و ممکن است از قبل از طریق توافق‌نامه‌ی کارمندی یا سایر سیاست‌های شرکت مجوز داشته باشد. در غیر این صورت، می‌توانید مذاکره کنید (به عنوان مثال، توضیح دهید که پروژۀ شما اهداف یادگیری و توسعۀ حرفه‌ای شرکت را دنبال می‌کند)، یا تا زمانی که شرکت بهتری پیدا نکردید از کار بر روی پروژۀ خودتان خودداری کنید.. -* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. +**اگر در جستجوی پروژه‌ای برای شرکت هستید،** قطعاً آن‌ها را در جریان بگذارید. تیم حقوقی شما احتمالاً قبلاً سیاست‌هایی را برای استفاده از مجوزهای متن باز (و شاید توافق‌نامه‌های همکاری اضافی) برای استفاده بر اساس الزامات تجاری و تخصصی شرکت در مورد اطمینان از مطابقت پروژۀ شما با مجوزهای وابستگی شرکت، در نظر گرفته است. اگر نه، به نفع هم شما و هم شرکت است! تیم حقوقی شما باید مشتاق همکاری با شما برای مشخص کردن این موارد باشد. چند مسئلۀ مهم: -* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). +* **نهادهای واسط** آیا پروژه شما وابستگی‌هایی به کار دیگران دارد یا در غیر این صورت کد دیگران را شامل می شود یا از آن‌ها استفاده می‌کند؟ اگر پروژه متن باز باشد، باید پروژۀ شما با مجوزهای متن باز مطابقت داشته باشد. این کار با انتخاب مجوز شروع می‌شود که مربوط به مجوزهای متن باز واسط می‌شود (نگاه کنید به بالا). اگر پروژۀ شما پروژه‌های متن باز واسط دیگر را اصلاح یا توزیع می‌کند، تیم حقوقی شما همچنین می‌خواهد بداند که شما سایر شرایط‌های مجوزهای متن باز واسط مانند حفظ اخطارهای حق نشر را رعایت می‌کنید یا خیر. اگر پروژۀ شما از کدهای دیگران استفاده می‌کند که فاقد مجوز متن باز هستند، احتمالاً باید از نگهدارندگان واسط بخواهید که [مجوز متن باز را اضافه کنند](https://choosealicense.com/no-license/#for-users) و اگر نمی‌توانید مجوز را دریافت کنید، استفاده از کد دیگران را در پروژۀ خوتان متوقف کنید. -* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. +* **اسرار کاری:** به این توجه داشته باشید که آیا چیزی در پروژه وجود دارد که شرکت نخواهد آن را در دسترس عموم قرار دهد. در این صورت، پس از مشخص کردن مطالبی که می‌خواهید خصوصی نگه دارید، می‌توانید بقیۀ پروژۀ خود را با متن باز کنید. -* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. +* **حق ثبت اختراع:** آیا شرکت شما متقاضی ثبت اختراعی است که متن باز آن پروژه در [دسترس عموم](https://en.wikipedia.org/wiki/Public_disclosure) است؟ متأسفانه، ممکن است از شما خواسته شود صبر کنید (یا شاید این شرکت در دیدگاه خود تجدید نظر کند). اگر انتظار دارید که کارمندان شرکت‌های بزرگی که دارای حق ثبت اختراع هستند، به پروژۀ شما کمک کنند و در آن مشارکت داشته باشند، ممکن است تیم حقوقی از شما بخواهد از یک مجوز با امتیاز ثبت اختراع سریع (از جمله Apache 2.0 یا GPLv3) یا توافق‌نامۀ همکاری اضافی استفاده کنید ( به بالا نگاه کنید). -If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). +* **نشان تجاری:** بررسی کنید تا نام پروژۀ شما با [هیچ نشان تجاری موجودی مغایرت نداشته باشد](../starting-a-project/#avoiding-name-conflicts). اگر از نشان‌های تجاری شرکت خود در پروژه استفاده می‌کنید، بررسی کنید تا هیچ مشکلی ایجاد نکند. [FOSSmarks](http://fossmarks.org/) یک راهنمای جامع برای شناخت نشان‌های تجاری در زمینه‌ی پروژه‌های متن باز و رایگان است. -Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: +* **حریم خصوصی:** آیا پروژۀ شما اطلاعات مربوط به کاربران را جمع‌آوری می‌کند؟ سرورهای شرکت، مکالمات را ضبط می‌کند؟ تیم حقوقی می‌تواند به شما در زمینه‌ی پیروی از سیاست‌های شرکت و آیین‌نامه‌های خارجی کمک کند. -* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). +اگر دارید اولین پروژه متن باز شرکت خود را منتشر می‌کنید، رعایت موارد فوق کافی است (اما نگران نباشید، اکثر پروژه‌ها نگرانی‌های اساسی خاصی نباید ایجاد کنند). + +در بلند مدت، تیم حقوقی می‌تواند کمک بیشتری به شرکت کند تا از مشارکت خود در پروژه‌های متن باز بهره‌ی بیشتری ببرد و در امان بماند: + +* سیاست های مربوط به مشارکت کارمندان سیاست‌هایی را تدوین کنید که مشخص سازد کارمندان شما در پروژه‌های متن باز چه نوع مشارکتی داشته باشند. داشتن سیاست‌های مشخص و واضح باعث کاهش سردرگمی در بین کارمندان و کمک به آن‌ها در مشارکت هرچه بهتر در پروژه‌های متن باز شرکت می‌شود؛ چه به عنوان بخشی از شغل آنها و چه به صورت فعالیت در اوقات فراغت‌شان. یک مثال خوب، [مدل‌های استاندارد و سیاست‌های همکاری در پروژه‌های متن باز](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) «Rackspace» است. -* **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts. -* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. +* **چه چیزهایی را منتشر کنیم:** [(تقریبا) همه چیز؟](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) اگر تیم حقوقی شما استراتژی متن باز شرکت شما را درک کرده و در آن سرمایه‌گذاری کرده باشد، به جای جلوگیری از تلاش‌هایتان، به بهترین وجه به شما کمک می‌کند. + +* **سازگاری:** حتی اگر شرکت شما هیچ پروژۀ متن بازی را منتشر نکند، از دیگر نرم‌افزارهای متن باز استفاده می‌کند. [داشتن آگاهی از روند کار](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) می‌تواند از بروز مشکلات بی‌جا، تأخیر در محصول و شکایات جلوگیری کند. -* **Patents:** Your company may wish to join the [Open Invention Network](https://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). -* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project). +* **امتیاز ثبت اختراع:** ممکن است شرکت شما مایل باشد به شبکۀ [Open Invention Network](https://www.openinventionnetwork.com/)، که یک مجموعۀ ثبت اختراع مشترک برای محافظت از اعضا و استفادۀ آن‌ها از از پروژه‌های بزرگ متن باز یا جستجوی سایر [مجوزهای اختراع ثبت جایگزین](https://www.eff.org/document/hacking-patent-system-2016) است، بپیوندد. + +* **نظارت:** مخصوصاً زمانی منطقی است که پروژه‌ای را به یک [شخص حقوقی خارج از شرکت](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project) منتقل کنید. \ No newline at end of file From 6d1e0aa720aa1b876d0836df366826d3df5401f9 Mon Sep 17 00:00:00 2001 From: Hamed Takmil Date: Fri, 14 May 2021 16:41:14 +0430 Subject: [PATCH 029/629] Language abbreviation updated. --- _data/locales/fa.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_data/locales/fa.yml b/_data/locales/fa.yml index dd41c8e0717..9a17d1650ef 100644 --- a/_data/locales/fa.yml +++ b/_data/locales/fa.yml @@ -1,4 +1,4 @@ -en: +fa: locale_name: Farsi nav: about: درباره From ec476224d3874771bf1284f8e48f69a5246c4ebd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Wed, 19 May 2021 02:18:00 +0300 Subject: [PATCH 030/629] Fix formating errors created by Gitlocalize (#35) --- _articles/tr/code-of-conduct.md | 38 ++-- _articles/tr/finding-users.md | 73 ++++++-- _articles/tr/how-to-contribute.md | 274 +++++++++++++++++++---------- _articles/tr/starting-a-project.md | 134 ++++++++++---- 4 files changed, 360 insertions(+), 159 deletions(-) diff --git a/_articles/tr/code-of-conduct.md b/_articles/tr/code-of-conduct.md index 9ba8ff26e3b..886e0c91a85 100644 --- a/_articles/tr/code-of-conduct.md +++ b/_articles/tr/code-of-conduct.md @@ -30,10 +30,10 @@ Mümkün olduğunca en erken zamanda bir davranış kural listesi oluşturmaya Beklentilerinizi iletmenin yanı sıra, bir davranış kural listesi aşağıdakileri de açıklar: -- Davranış kuralları nerede yürürlüğe girer *(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)*? -- Davranış kuralları kimin için geçerlidir *(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)*? -- Birisi davranış kurallarını ihlal ederse ne olur? -- İhlaller nasıl rapor edilebilir? +* Davranış kuralları nerede yürürlüğe girer _(sadece sorunlar ve talepler üzerine mi yoksa toplantılar gibi topluluk etkinliklerinde mi?)_? +* Davranış kuralları kimin için geçerlidir _(topluluk üyeleri ve bakıcıları, peki ya sponsorlar?)_? +* Birisi davranış kurallarını ihlal ederse ne olur? +* İhlaller nasıl rapor edilebilir? Nerede olursanız olun, geçmiş tecrübelerden faydalanın. [Katkıda Bulunanlar Sözleşmesi (Contributor Covenant)](https://contributor-covenant.org/) Kubernet, Rails ve Swift dahil olmak üzere 40.000'den fazla açık kaynaklı proje tarafından kullanılan ortak bir davranış kural listesidir. @@ -43,15 +43,20 @@ CODE_OF_CONDUCT dosyasını projenizin kök dizinine yerleştirin ve CONTRIBUTIN ## Davranış kurallarınızı nasıl uygulayacağınıza karar verme - + Bir ihlal meydana *gelmeden önce* davranış kurallarınızın nasıl uygulanacağını açıklamalısınız. Bunu yapmak için birkaç neden var: -- İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. +* İhtiyaç duyulduğunda harekete geçme konusunda ciddi olduğunuzu gösterir. -- Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. +* Topluluğunuz şikayetlerin gerçekten gözden geçirildiği konusunda daha güvende hissedecektir. -- Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. +* Topluluğunuza, inceleme sürecinin adil ve şeffaf olduğunu, kendilerini bir ihlal için araştırıldıklarında güvence altında olduklarını hissettirirsiniz. İnsanlara davranış kuralları ihlalini bildirebilmeleri için özel bir yol (e-posta adresi gibi) vermelisiniz ve bu raporun kimlere ulaştığını açıklamalısınız. Bu bir kurucu, bir geliştirme grubu veya bir davranış kuralları çalışma grubu olabilir. @@ -73,7 +78,12 @@ Söz konusu topluluk üyesi, sürekli olarak başkalarını rahatsız hissetmesi Cevap vermeden önce, neler olduğunu anlamak için biraz zaman harcayın. Kim olduklarını ve neden böyle davrandıklarını daha iyi anlamak için, kişi ya da kişilerin geçmiş yorumlarını ve konuşmalarını okuyun. Bu kişi ve davranışları hakkındaki kendi görüşleriniz dışında başka bakış açıları da toplamaya çalışın. - + ### Uygun işlemi yapın @@ -83,15 +93,15 @@ Birisi bir davranış kuralları ihlali bildirdiğinde, bu durumla yüzleşmesi Bir davranış kural ihlaline yanıt vermenin birkaç yolu vardır: -- **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. +* **Söz konusu kişiye genel bir uyarı verin** ve davranışlarının diğerlerini, nasıl olumsuz etkilediğini tercihen meydana geldiği kanalda açıklayın. Mümkün olan diğer yerlerde de, genel iletişim kanalarında da, davranış kurallarını ciddiye aldığınız toplumun geri kalanına iletir. Kibar olun, ancak iletişiminizde sağlam olun. -- Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. +* Davranışlarının diğerlerini nasıl olumsuz yönde etkilediğini açıklamak **için ilgili kişiye özel olarak ulaşın**. Durum hassas kişisel bilgiler içeriyorsa, özel bir iletişim kanalı kullanmak isteyebilirsiniz. Biriyle özel olarak iletişim kurarsanız, durumu ilk ihbar eden kişileri CC ile bilgilendirmek iyi bir fikirdir, bu sayede harekete geçtiğinizi bilmiş olurlar. CC'ye eklemeden önce ihbar den kişiden onay isteyin. Bazen bir çözüme ulaşılamaz. Söz konusu kişi karşı karşıya geldiğinde saldırgan veya düşmanca olabilir veya davranışlarını değiştirmez. Bu durumda, daha güçlü bir işlem yapmayı düşünebilirsiniz. Örneğin: -- Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** +* Söz konusu kişiyi projedeki herhangi bir şeye katılamayacak şekilde **gecici olarak engelleyebilirsiniz** -- Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** +* Kişiyi projeden **kalıcı olarak yasaklayabilirsiniz** Kalıcı olarak yasaklama üyeleri kolayca alınmamalı ve kalıcı uzlaşmaz bir bakış açısı farklılığını temsil etmelidir. Bu önlemleri yalnızca bir çözüme ulaşılamayacağı açıksa almalısınız. @@ -101,7 +111,7 @@ Davranış kuralları, keyfi olarak uygulanan bir yasa değildir. Davranış kur Proje sahibi olarak, topluluğunuz için kılavuz ilkeler belirler ve bu ilkeleri davranış kurallarınızda belirtilen kurallara uygun olarak uygularsınız. Bu, herhangi bir davranış kuralları ihlali raporunu ciddiye almak anlamına gelir. İhbar eden şikayeti hakkında kapsamlı ve adil bir inceleme yapılmasını hak eder. Bildirdikleri davranışların bir ihlal olmadığını belirlerseniz, bunu açıkça belirtin ve neden bu konuda harekete geçmeyeceğinizi açıklayın. Bununla ne yapacakları onlara bağlı: Sorunlu olduğunu düşündükleri davranışlara hoşgörü gösterirler veya topluluktan ayrılabilirler. -*Teknik* olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. +_Teknik_ olarak davranış kurallarını ihlal etmeyen bir davranış raporu, toplumunuzda bir sorun olduğunu gösterebilir ve bu olası sorunu araştırmanız ve buna göre davranmanız gerekir. Bu, kabul edilebilir davranışı netleştirmek için davranış kurallarınızı gözden geçirmeyi ve/veya davranışları rapor edilen kişiyle konuşmayı ve davranış kurallarını ihlal etmemelerine rağmen, diğer katılımcıları rahatsız etiğini bildirmeniz gerekebilir. Sonunda, bir proje sahibi olarak, kabul edilebilir davranış için standartları belirler ve uygularsınız. Projenin topluluk değerlerini şekillendirme yetkiniz var ve katılımcılar bu değerleri adil ve eşit bir şekilde uygulamanızı beklerler. diff --git a/_articles/tr/finding-users.md b/_articles/tr/finding-users.md index 914ee05a185..20d8e3c976e 100644 --- a/_articles/tr/finding-users.md +++ b/_articles/tr/finding-users.md @@ -27,7 +27,7 @@ Projenizi tanıtmaya yönelik asıl çalışmaya başlamadan önce, ne yaptığ Projenizi farklı veya ilginç kılan nedir? Neden yarattınız? Bu soruları kendiniz cevaplamak, projenizin önemini bildirmenize yardımcı olacaktır. -İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, *kullanıcıların ve katkıda bulunanların* ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. +İnsanların kullanıcı olarak dahil olduklarını ve sonunda katkıda bulunduğunu unutmayın, çünkü projeniz onlar için bir problemi çözüyor. Projenizin mesajını ve değerini düşündüğünüzde, _kullanıcıların ve katkıda bulunanların_ ne isteyebileceğini onların gözünden bakmaya çalışarak görmeye çalışın. Örneğin, @robb, projesi olan [Cartography'nin](https://github.com/robb/Cartography) neden faydalı olduğunu açıkça belirtmek için kod örnekleri kullanır: @@ -37,7 +37,12 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa ## İnsanların projenizi bulmasına ve takip etmesine yardımcı olun - + İnsanların projenizi tek bir alana işaret ederek bulup hatırlamalarına yardımcı olun. @@ -45,11 +50,17 @@ Mesajlaşmaya daha derin bir dalış yapmak için Mozilla'nın ["Personas and Pa Henüz projeniz için iletişim noktaları kurmak istemiyorsanız, yaptığınız her şeyde kendi Twitter veya GitHub hesabınızı tanıtın. Twitter veya GitHub hesabınızı tanıtmak, insanların sizinle nasıl iletişim kurabileceklerini veya işlerinizi takip etmelerini sağlayacaktır. Bir buluşma veya etkinlikte konuşuyorsanız, iletişim bilgilerinizin biyo veya slaytlarınıza eklendiğinden emin olun. - + **Projeniz için bir web sitesi oluşturmayı düşünün.** Bir web sitesi, projenizi daha net hale getirir ve özellikle açık belgeler ve eğitimlerle desteklendiğinde gezinmeyi kolaylaştırır. Bir web sitesine sahip olmak, projenizin aktif olduğunu ve bu sayede hedef kitlenizin kendisini daha rahat hissetmesini sağlayacaktır. İnsanlara projenizi nasıl kullanacakları hakkında fikir vermek için örnekler verin. -Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin *"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi*. +Django'nun yaratıcısı [@adrianholovaty](https://news.ycombinator.com/item?id=7531689) , bir web sitesinin _"ilk günlerde Django için yaptıkları en iyi şey" olduğunu söyledi_. Projeniz GitHub'da barındırıyorsanız, kolayca web sitesi yapmak için [GitHub Pages](https://pages.github.com/) kullanabilirsiniz. [Yeoman](http://yeoman.io/) , [Vagrant](https://www.vagrantup.com/) ve [Middleman](https://middlemanapp.com/) mükemmel, kapsamlı web sitelerine [birkaç örnektir](https://github.com/showcases/github-pages-examples) . @@ -63,13 +74,19 @@ Artık projeniz için bir mesajınız ve insanların projenizi bulmaları için Hedef kitlenize ulaşmak için mevcut çevrimiçi topluluklardan ve platformlardan yararlanın. Açık kaynaklı projeniz bir yazılım projesiyse, kitlenizi [Stack Overflow](https://stackoverflow.com/) , [Reddit](https://www.reddit.com) , [Hacker News](https://news.ycombinator.com/) veya [Quora](https://www.quora.com/)'da bulabilirsiniz. İnsanların işinizden en çok faydalanabileceğini veya heyecanlanacağını düşündüğünüz kanalları bulun. - + Projenizi ilgili kanallarda paylaşmanın yollarını bulabilecek misiniz bir bakın: -- **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. -- **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. -- **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. +* **İlgili açık kaynaklı projeleri ve toplulukları tanıyın.** Bazen projenizi doğrudan tanıtmanız gerekmez. Projeniz Python'u kullanan veri bilimcileri için mükemmelse, Python veri bilimi topluluğunu tanıyın. İnsanlar sizi tanıdıkça, hakkında konuşmak ve çalışmalarınızı paylaşmak için doğal fırsatlar ortaya çıkacaktır. +* **Projenizin çözdüğü sorunu yaşayan insanları bulun.** Projenizin hedef kitlesine giren kişileri ilgili forumlarda arayın. Projenizi bir çözüm olarak önermek için sorularına cevap verin ve uygun olduğunda temkinli bir yol bulun. +* **Geri bildirim isteyin.** Kendinizi ve işinizi ilgili ve ilgi çekici bulabilecek bir kitleye tanıtın. Projenizden kimin faydalanacağını düşündüğünüz konusunda net olun. Cümleyi bitirmeye çalışın: *"Projemin gerçekten Y'yi yapmaya çalışan X'e yardım edeceğini düşünüyorum* ." Çalışmanızı tanıtmak yerine, başkalarının geri bildirimlerini dinleyin ve bunlara yanıt verin. Genel olarak konuşursak, karşılığında bir şey istemeden önce başkalarına yardım etmeye odaklanın. Herkes bir projeyi çevrimiçi olarak kolayca tanıtabildiğinden, çok fazla gürültü çıkacaktır. Kalabalıktan sıyrılmak için, insanlara sadece ne istediğinizi değil, kim olduğunuzu anlatmaya çalışın. @@ -83,19 +100,37 @@ Genel olarak konuşursak, karşılığında bir şey istemeden önce başkaları [Topluluk karşısında konuşma konusunda](https://speaking.io/) yeniyseniz, projenizin dili veya ekosistemiyle ilgili yerel bir buluşma bularak başlayın. - + Daha önce topluluk önünde konuşmadıysanız, gergin hissetmek tamamen normaldir! İzleyicilerinizin sizin için orada olduğunu unutmayın, çünkü işinizi gerçekten duymak istiyorlar. Konuşmanızı yazarken, izleyicilerinizin ilginç bulacağı ve değer kazanacağı şeylere odaklanın. Dilinizi arkadaşça ve ulaşılabilir tutun. Gülümseyin, nefes alın ve eğlenin. - + Hazır olduğunuzda, projenizi tanıtmak için bir konferansta konuşmayı düşünün. Konferanslar, bazen dünyanın her yerinden daha fazla insana ulaşmanıza yardımcı olabilir. Dilinize veya ekosisteminize özgü konferansları arayın. Konuşmanızı göndermeden önce, konuşmanızı katılımcılar için uyarlamak ve konferansta konuşma kabul etme şansınızı artırmak için konferansı araştırın. Konferansın konuşmacılarına bakarak, izleyicilerinizi daha kolay anlayabilirsiniz. - + ## Bir itibar oluşturun @@ -103,13 +138,25 @@ Yukarıda belirtilen stratejilere ek olarak, insanları projenizi paylaşmaya ve Yeni gelenlere yardım etmek, kaynakları paylaşmak ve başkalarının projelerine anlamlı katkılar yapmak olumlu bir itibara kavuşmanıza yardımcı olacaktır. Açık kaynak topluluğunda aktif bir üye olmak, insanların çalışmanız için bağlam oluşturmasına yardımcı olacak ve projenize dikkat etme ve paylaşma olasılıkları artacaktır. Diğer açık kaynaklı projelerle ilişkilerin geliştirilmesi resmi ortaklıklara yol açabilir. - + İtibarınızı oluşturmak için asla çok erken veya geç değildir. Kendi projenizi daha önce başlatmış olsanız bile, başkalarına yardım etmenin yollarını aramaya devam edin. Kitle oluşturmak için bir gecede çözüm yoktur. Başkalarının güvenini ve saygısını kazanmak zaman alır ve itibarınızı geliştirmek hiç tamamlanmayan bir iştir. - + ## Devam et! diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md index 0f79a454a87..487e228f428 100644 --- a/_articles/tr/how-to-contribute.md +++ b/_articles/tr/how-to-contribute.md @@ -19,7 +19,13 @@ related: ## Açık kaynağa neden katkıda bulunmalıyım? - + Açık kaynağa katkıda bulunmak, hayal edebileceğiniz herhangi bir konuyu öğrenmek, öğretmek ve deneyim geliştirmek için faydalı bir yol olabilir. @@ -63,59 +69,77 @@ Endişe etmeyin! Açık kaynak kodlu bir projeye dahil olmanın çok farklı yol Açık kaynağa katkıda bulunma konusunda yaygın bir yanılgı, kod yazarak katkıda bulunmanız gerektiğidir. Aslında, genellikle [en çok ihmal edilen veya göz ardı edilen](https://github.com/blog/2195-the-shape-of-open-source) projenin diğer kısımlarıdır. Bu tür katkılara katılmayı teklif ederek projeye *büyük bir* iyilik yapacaksınız! - + Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve diğer topluluk üyeleriyle tanışmak için harika bir yoldur. Bu ilişkileri kurmak size projenin diğer bölümlerinde de çalışma fırsatı verecektir. - + ### Etkinlik planlamayı sever misiniz? -- [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin -- Projenin konferansını düzenleyin (eğer varsa) -- Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun +* [NodeSchool için @fzamperin yaptığı gibi](https://github.com/nodeschool/organizers/issues/406), proje hakkında atölye çalışmaları veya buluşmalar düzenleyin +* Projenin konferansını düzenleyin (eğer varsa) +* Topluluk üyelerinin doğru konferansları bulmasına ve konuşma için öneriler sunmasına yardımcı olun ### Tasarlamayı sever misiniz? -- Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın -- [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın -- Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın -- [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın +* Projenin kullanılabilirliğini geliştirmek için şablonları yeniden yapılandırın +* [Drupal'ın önerdiği gibi](https://www.drupal.org/community-initiatives/drupal-core/usability), projenin navigasyonunu veya menülerini yeniden düzenleyin ve bunu yapmak için hassas kullanıcı araştırması yapın +* Projenin tutarlı bir görsel tasarıma sahip olması için bir stil rehberi hazırlayın +* [Hapi.js’in katılımcılarının yaptığı gibi](https://github.com/hapijs/contrib/issues/68) t-shirtler veya yeni bir logo tasarlayın ### Yazmayı sever misin? -- Proje dokümantasyonunu yazın ve geliştirin -- Projenin nasıl kullanıldığını gösteren örnekler oluşturun -- Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın -- [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın -- Projenin dokümantasyonu için çeviri yapın +* Proje dokümantasyonunu yazın ve geliştirin +* Projenin nasıl kullanıldığını gösteren örnekler oluşturun +* Proje için bir bülten başlatın veya posta listesinden önemli noktaları açığa çıkarın +* [PyPA'nın katılımcılarının yaptığı gibi](https://github.com/pypa/python-packaging-user-guide/issues/194) proje için dersler yazın +* Projenin dokümantasyonu için çeviri yapın - + ### Organize etmeyi sever misiniz? -- Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin -- Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) -- Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. +* Projeyi daha organize hale getirmek için benzer sorunları bağlantılayın ve yeni sorun etiketleri önerin +* Açık sorunların üzerinden geçin ve eskileri kapatmayı önerin, [@nzakas'ın ESLint için yaptığı gibi](https://github.com/eslint/eslint/issues/6765) +* Tartışmayı ileriye taşımak için açılan konular hakkında açıklayıcı sorular sorun. ### Kod yazmayı sever misiniz? -- [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun -- Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun -- Proje kurulumunu otomatikleştirin -- Araçları ve testleri geliştirin +* [@Dianjin'in Leaflet için yaptığı gibi](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) çözülmesi gereken açık bir konu bulun +* Yeni bir özellik yazmak için yardımcı olabilir misiniz diye sorun +* Proje kurulumunu otomatikleştirin +* Araçları ve testleri geliştirin ### İnsanlara yardım etmeyi sever misiniz? -- Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te -- İnsanlar için açık konulardaki soruları cevaplayın -- Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun +* Proje hakkında soruları yanıtlayın. Örneğin, Stack Overflow'da ([bu Postgres örneğinde olduğu gibi](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) veya Reddit'te +* İnsanlar için açık konulardaki soruları cevaplayın +* Tartışma panolarını veya konuşma kanallarını yönetmeye yardımcı olun ### Başkalarına kod yazarken yardım etmeyi sever misiniz? -- Diğer kişilerin gönderimlerindeki kodu inceleyin -- Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın -- Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) +* Diğer kişilerin gönderimlerindeki kodu inceleyin +* Bir projenin nasıl kullanılabileceğini öğretici yazılar yazın +* Başka bir katılımcıya mentor olmaya çalışın, [@ereichert Rust projesinde @bronzdoc için yaptığı gibi](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) ### Sadece yazılım projeleri üzerinde çalışmak zorunda değilsiniz! @@ -123,15 +147,21 @@ Kod yazmayı sevseniz bile, diğer katkı türleri de bir projeye katılmak ve d Örneğin: -- @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) -- @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor -- @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) +* @sindresorhus ["harika" listelerin bir listesini oluşturuyor](https://github.com/sindresorhus/awesome) +* @h5bp ön yüz geliştirici adayları için [olası mülakat sorularının bir listesini](https://github.com/h5bp/Front-end-Developer-Interview-Questions) oluşturuyor +* @stuartlynn ve @nicole-a-tesla [martılar hakkında eğlenceli bilgiler topladı](https://github.com/stuartlynn/puffin_facts) Bir yazılım geliştiricisi olsanız bile, bir dokümantasyon projesi üzerinde çalışmak açık kaynak kodla başlamanıza yardımcı olabilir. Kod içermeyen projeler üzerinde çalışmak genellikle daha az korkutucu olur ve işbirliği süreci sizin güven ve deneyiminizi artırır. ## Kendinizi yeni bir projeye yönlendirmek - + Bir yazım hatasının düzeltilmesinden daha fazla olarak, açık kaynağa katkıda bulunmak, partideki bir grup yabancıyla konuşmaya çalışmak gibidir. Lamalar hakkında konuşmaya başlarsanız, akvaryum balığı ile ilgili derin bir tartışma yapıyorlarsa, muhtemelen size biraz garip bakarlar. @@ -147,34 +177,34 @@ Bununla birlikte, birçok açık kaynak projenin benzer organizasyon yapıların Tipik bir açık kaynak projesi aşağıdaki insan türlerine sahiptir: -- **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) -- **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) -- **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) -- **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes -- **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. +* **Yazar:** Projeyi yaratan kişi(ler)/kurum(lar) +* **Sahip:** Kurum veya depo üzerinde yönetim hakkına sahip kişi/kişiler (her zaman orijinal yazarla aynı olmayabilir) +* **Geliştiriciler:** Vizyonu yönlendirmekten ve projenin organizasyonel yönlerini yönetmekten sorumlu olanlar ve katkıda bulunanlar (Projenin yazarları veya sahipleri de olabilirler) +* **Katkıda Bulunanlar:** Projeye katkıda bulunan herkes +* **Topluluk Üyeleri:** Projeyi kullanan insanlar. Sohbetlerde aktif olabilirler veya projenin yönü ile ilgili görüşlerini ifade edebilirler. Daha büyük projeler ayrıca araç yönetimi, öncelik yönetimi, topluluk yönetimi ve etkinlik organizasyonu gibi farklı görevlere odaklanmış alt komitelere veya çalışma gruplarına sahip olabilir. Bu bilgileri bulmak için bir projenin "ekip" sayfasına veya yönetim dokümantasyon deposuna bakın. Projelerin belgeleri de vardır. Bu dosyalar genellikle bir kütüphanenin dizin yapısının en üst seviyelerinde listelenir. -- **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. -- **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. -- **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. -- **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. -- **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. +* **LICENCE:** Tanım gereği her açık kaynak projenin [bir açık kaynak lisansa](https://choosealicense.com) sahip olması gerekir. Projenin lisansı yoksa açık kaynak değildir. +* **README:** README, projeye yeni topluluk üyelerini karşılayan kullanım kılavuzudur. Projenin neden yararlı olduğunu ve nasıl başlayacaklarını açıklar. +* **CONTRIBUTING:** README dosyaları projeyi insanların *kullanmalarına* yardımcı olurken, CONTRIBUTING dökümanları insanların projeye *katkıda* bulunmalarına yardımcı olur. Hangi tür katkıların gerekli olduğunu ve sürecin nasıl çalıştığını açıklar. Her projenin bir CONTRIBUTING dosyası olmasa da, varlığı bunun katkı bekleyen bir proje olduğunu işaret eder. +* **CODE_OF_CONDUCT:** Davranış kuralları, katılımcıların davranışlarıyla ilgili temel kuralları belirler ve arkadaşça ve misafirperver bir ortamı oluşturmaya yardımcı olur. Her projenin bir CODE_OF_CONDUCT dosyası olmasa da, varlığı bu konuya dikkate edilen bir proje olduğunu gösterir. +* **Diğer belgeler:** Özellikle büyük projelerde öğretici belgeler, izlenecek yollar veya yönetim politikaları gibi ek belgeler olabilir. Son olarak, açık kaynak projeler tartışmaları yönetmek için aşağıdaki araçları kullanır. Arşivleri okumak, topluluğun nasıl düşündüğü ve çalıştığı hakkında size iyi bir fikir verecektir. -- **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. -- **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. -- **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. -- **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. +* **Sorun listesi:** İnsanların projeyle ilgili sorunları tartıştıkları yerler. +* **PR (Değişiklik istekleri):** İnsanların devam etmekte olan değişiklikleri tartıştıkları ve inceledikleri yerler. +* **Tartışma forumları veya e-posta listeleri:** Bazı projeler, tartışma konuları için bu kanalları kullanabilir (örneğin, hata raporları veya özellik istekleri yerine *"Nasıl ...?"* veya *"Ne düşünüyorsunuz ...?" gibi*). Diğerleri, tüm konuşmalar için sorun listesini kullanır. +* **Anlık sohbet kanalları:** Bazı projelerde gündelik konuşmalar, işbirlikleri ve hızlı fikir alışverişleri için sohbet kanalları (Slack veya IRC gibi) kullanılır. ## Katkıda bulunacak bir proje bulma Açık kaynak projelerin nasıl çalıştığını çözdüğünüze göre, katkıda bulunacak bir proje bulma zamanı! -Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil - ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi örnek alın. +Daha önce hiç bir açık kaynak projeye katkıda bulunmadıysanız, *"Ülkenizin sizin için neler yapabileceğini değil * ülkeniz için neler yapabileceğinizi sorun"* diyen ABD Başkanı John F. Kennedy'yi örnek alın. Açık kaynağa katkıda bulunmak, farklı projelerde her seviyede gerçekleşir. İlk katkınızın tam olarak ne olacağını veya nasıl görüneceğini düşünmeniz gerekmez. @@ -192,15 +222,15 @@ Düzeltebileceğiniz açık sorunları arıyorsanız, her açık kaynak projenin Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aşağıdaki kaynaklardan birini de kullanabilirsiniz: -- [GitHub Explore](https://github.com/explore/) -- [Open Source Friday](https://opensourcefriday.com) -- [First Timers Only](https://www.firsttimersonly.com/) -- [CodeTriage](https://www.codetriage.com/) -- [24 Pull Requests](https://24pullrequests.com/) -- [Up For Grabs](https://up-for-grabs.net/) -- [Contributor-ninja](https://contributor.ninja) -- [First Contributions](https://firstcontributions.github.io) -- [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) ### Katkıda bulunmadan önce üzerinden geçilebilecek bir kontrol listesi @@ -212,7 +242,9 @@ Katkıda bulunmak istediğiniz bir proje bulduğunuzda, projenin katkıları kab
- +
**Proje aktif olarak katkı kabul ediyor** @@ -221,71 +253,97 @@ Ana daldaki geliştirici faaliyetine bakın. GitHub'da, bu bilgiyi bir kütüpha
- +
- +
- +
Ardından, projenin sorun listesine bakın.
- +
- +
- +
- +
- +
Şimdi aynısını projenin PR listesi için yapın.
- +
- +
- +
- +
- +
**Proje katkı bekliyor mu?** @@ -294,25 +352,39 @@ Arkadaş canlısı ve misafirperver bir proje, yeni katılımcılara açık olac
- +
- +
- +
- +
- + ## Nasıl katkı yapılır? @@ -322,7 +394,13 @@ Hoşunuza giden bir proje buldunuz ve katkıda bulunmaya hazırsınız. En sonun İster bir kerelik bir katkı yapan, ister bir topluluğa katılmaya çalışan biri olun, başkalarıyla çalışmak açık kaynak dünyasında geliştireceğiniz en önemli becerilerden biridir. - + Bir sorunu açmadan veya bir PR oluşturmadan ya da sohbette bir soru sormadan önce, fikirlerinizi etkili bir şekilde ortaya çıkarmak için bu noktaları aklınızda bulundurun. @@ -370,47 +448,53 @@ Herhangi bir şey yapmadan önce, fikrinizin başka bir yerde tartışılmadığ Fikrinizi başka bir yerde bulamazsanız, harekete geçmeye hazırsınız. Proje GitHub'taysa, muhtemelen bir sorun açarak veya PR oluşturarak iletişim kurarsınız: -- **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir -- **PR** bir çözüm üzerinde çalışmaya başlamak içindir -- **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. +* **Sorunlar** bir konuşma veya tartışma başlatmak için iyi yerdir +* **PR** bir çözüm üzerinde çalışmaya başlamak içindir +* **Daha hafif bir iletişim** için açıklayıcı veya nasıl yapılır sorusu gibi, eğer varsa projenin Stack Overflow, IRC, Slack veya diğer sohbet kanallarından sormayı deneyin. Bir sorun açmadan veya talepte bulunmadan önce, belirli bir şey eklemeniz gerekip gerekmediğini görmek için projenin katkıda bulunma belgelerini (genellikle CONTRIBUTING veya README dosyaları) kontrol edin. Örneğin, bir şablon izlemenizi istenebilir veya test ortamı kullanmanız gerekebilir. Önemli bir katkı yapmak istiyorsanız, üzerinde çalışmadan önce sormanız gereken bir sorun açın. Projeyi bir süre izlemeniz yararlı olacaktır (GitHub'da, tüm konuşmalar size bildirilmek için ["İzle"yi tıklayabilirsiniz](https://help.github.com/articles/watching-repositories/)) ve kabul edilmeyebilecek bir işe başlamadan önce topluluk üyelerini tanıyın. - + ### Bir istek/sorun açmak Genellikle aşağıdaki durumlarda bir sorun açmalısınız: -- Çözemediğiniz bir hatayı bildirmek için -- Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) -- Yeni bir özellik veya başka bir proje fikri önermek için +* Çözemediğiniz bir hatayı bildirmek için +* Üst düzey bir konuyu veya fikri tartışmak için (örneğin, topluluk, vizyon veya politikalar) +* Yeni bir özellik veya başka bir proje fikri önermek için Sorunlar üzerinde iletişim kurmak için ipuçları: -- **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. -- **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. -- **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. +* **Başa çıkmak istediğiniz açık bir sorun görürseniz**, konuyla ilgili insanlara çalıştığınızı bildirmek için yorum yapın. Bu şekilde, insanların aynı konu üzerinde gereksiz yere çalışması daha az olasıdır. +* **Eğer bir sorun bir süre önce açılmışsa**, başka bir yerde ele alınması ya da zaten çözülmüş olması olasıdır, bu nedenle çalışmaya başlamadan önce durum hakkında onay almak için yorum yapın. +* **Bir sorunu açtıysanız ancak cevabı daha sonra kendi başınıza çözdüyseniz**, durumu bildirmek için soruna yorum yapın, sonra sorunu kapatın. Bu sonucun belgelenmesi bile projeye bir katkıdır. ### PR açma Genellikle aşağıdaki durumlarda bir PR açmalısınız: -- Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) -- Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda +* Önemsiz düzeltmeleri göndermek için (örneğin bir yazım hatası, bozuk bir bağlantı veya açık bir hata) +* Bir konuda önceden sorulmuş veya daha önce konuşmuş olduğunuz bir katkı için çalışmaya başladığınızda Bir PR, bitmiş işi temsil etmek zorunda değildir. PR'ı erkenden açmak genellikle daha iyidir, bu nedenle diğerleri ilerlemeniz hakkında fikir sahibi olabilir veya geribildirimde bulunabilir. Sadece konu satırında bir "WIP" (Çalışmakta Olan Çalışma) etiketi ile işaretlemeniz yeterlidir. Daha sonra her zaman daha fazla geliştirme ekleyebilirsiniz. Proje GitHub'taysa, PR nasıl gönderilir: -- **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) -- Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . -- **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") -- Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. -- **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. -- **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. +* **[Depoyu çatallayın](https://guides.github.com/activities/forking/)** ve yerel olarak klonlayın. Kendi yerelinize ana depoyu "upstream" olarak bağlayın. Sık sık "upstream" den yapılan değişiklikleri çekin, böylece güncel kalırsınız ve çekme isteğinizi gönderdiğinizde, birleştirme çakışmalarının olasılığı daha düşük olur. ([Burada](https://help.github.com/articles/syncing-a-fork/) daha ayrıntılı talimatlara bakın.) +* Düzenlemeleriniz için **[bir dal oluşturun](https://guides.github.com/introduction/flow/)** . +* **PR'nızda ilgili sorunlara** veya destekleyici belgelere atıfta bulunun (örneğin, "Closes #37") +* Değişiklikleriniz HTML/CSS"de farklılıklar içeriyorsa **önceki ve sonraki ekran görüntülerini ekleyin**. Görüntüleri PR gövdesine sürükleyip bırakarak yükleyebilirsiniz. +* **Değişikliklerinizi test edin!** Varsa, testleriniz varsa test edin ve gerektiğinde yenilerini oluşturun. Testlerin olup olmadığı, değişikliklerin mevcut projeyi bozmadığından emin olun. +* **Projenin tarzına uygun şekilde** katkıda bulunun. Bu koddaki girintileri, noktalı virgülleri veya yorumları kendi deponuzda olduğundan farklı bir şekilde kullanmak anlamına gelebilir, ancak bakıcının birleştirmesini, başkalarının gelecekte anlamasını ve sürdürmesini kolaylaştırır. Bu ilk PR ise, @kentcdodds'ın bir örnek video eğitimi olarak oluşturduğu [Bir PR Yap](http://makeapullrequest.com/)'ı izleyin. Ayrıca, @Roshanjossey tarafından oluşturulan [First Contributions](https://github.com/Roshanjossey/first-contributions) deposunda çekme isteği yapmayı da deneyebilirsiniz. diff --git a/_articles/tr/starting-a-project.md b/_articles/tr/starting-a-project.md index 7c8076466bc..e577a4289a3 100644 --- a/_articles/tr/starting-a-project.md +++ b/_articles/tr/starting-a-project.md @@ -30,15 +30,21 @@ Açık kaynak güçlüdür çünkü fikirlerin hızla yayılmasına izin vererek ### İnsanlar neden işlerini açık kaynak olarak sunarlar? - + Bir kişinin veya örgütün bir projeyi açmak istemesinin [birçok nedeni](https://ben.balter.com/2015/11/23/why-open-source/) vardır . Bazı örnekler: -- **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. +* **İşbirliği:** Açık kaynak projeler, dünyadaki herhangi birinden değişiklikleri kabul edebilir. Örneğin, [Exercism](https://github.com/exercism/) 350'den fazla katkıda bulunana sahip bir programlama egzersiz platformudur. -- **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. +* **Adapte etme ve yeniden tanımlama:** Açık kaynaklı projeler herkes tarafından herhangi bir amaç için kullanılabilir. İnsanlar başka şeyler yapmak için bile kullanabilirler. Örneğin [WordPress](https://github.com/WordPress), [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md) adı verilen mevcut bir projenin alt dalı olarak başladı. -- **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir. +* **Şeffaflık:** Açık kaynaklı bir projeyi herkes hata veya tutarsızlık açısından inceleyebilir. Şeffaflık, [Bulgaristan](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) veya [ABD](https://sourcecode.cio.gov/) gibi develetler, bankacılık veya sağlık gibi sıkı kurallara bağlı endüstriler ve [Let's Encrypt](https://github.com/letsencrypt) gibi güvenlik yazılımları için önemlidir. Açık kaynak sadece yazılım için değil. Veri kümelerinden kitaplara kadar her şeyi açık kaynak koduyla açabilirsiniz. Açık kaynak başka neler yapabileceğiniz hakkında fikir edinmek için [GitHub Explore](https://github.com/explore)'a göz atın. @@ -68,7 +74,13 @@ Bu sorunun tek bir doğru cevabı yok. Tek bir proje veya farklı hedeflere sahi Tek amacınız işinizi göstermekse, katkı bile istemeyebilir ve hatta bunu README'nizde bile söyleyebilirsiniz. Öte yandan, katkıda bulunanlar istiyorsanız, açık belgelere ve yeni gelenlerin hoş karşılanmasına zaman ayıracaksınız. - + Projeniz büyüdükçe, topluluğunuzun sizden sadece kod yazmaktan daha fazlasına ihtiyacı olabilir. Sorunlara cevap vermek, kodu gözden geçirmek ve projenizi geliştirmek, açık kaynaklı bir projedeki önemli görevlerdir. @@ -78,7 +90,13 @@ Kodlama yapmayan görevler için harcadığınız zaman, projenizin boyutuna ve Tanıtım, operasyonlar ve projenin bakımı için özel bir bütçeye veya personele ihtiyacınız varsa, bu görüşmeleri erkenden başlatın. - + ### Diğer projelere katkıda bulunmak @@ -94,10 +112,10 @@ Genel olarak konuşursak, başkalarının işinizi görmesini ve işiniz hakkın Projenizi hangi aşamada açmaya karar verirseniz verin, her proje aşağıdaki belgeleri içermelidir: -- [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) -- [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) -- [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) -- [Davranış kuralları](../code-of-conduct/) +* [Açık kaynak lisansı](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Katkıda bulunma kuralları](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Davranış kuralları](../code-of-conduct/) Bir geliştirici olarak, bu bileşenler beklentileri iletmenize, katkıları yönetmenize ve herkesin yasal haklarını (kendi haklarınız dahil) korumanıza yardımcı olur. Olumlu bir deneyim yaşama şansınızı önemli ölçüde artırırlar. @@ -123,14 +141,20 @@ README'ler, projenizi nasıl kullanılacağını açıklamadan fazlasını yapar README'ler projenizi nasıl kullanacağınızı açıklamaktan daha fazlasını yapar. Ayrıca, projenizin neden önemli olduğunu ve kullanıcılarınızın bununla neler yapabileceğini de açıklar. -- Bu proje ne yapıyor? -- Bu proje neden faydalıdır? -- Kullanmaya nasıl başlarım? -- İhtiyacım olursa nereden daha fazla yardım alabilirim? +* Bu proje ne yapıyor? +* Bu proje neden faydalıdır? +* Kullanmaya nasıl başlarım? +* İhtiyacım olursa nereden daha fazla yardım alabilirim? README'nizi, katkıları nasıl ele aldığınız, projenin hedeflerinin ne olduğu ve lisanslar ve atıfla ilgili bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkıları kabul etmek istemiyorsanız veya projeniz henüz üretime hazır değilse, bu bilgileri not edin. - + README'nizi, katkıları nasıl ele aldığınız, projenin amaçlarının ne olduğu ve lisanslar ve atıflar hakkında bilgiler gibi diğer soruları yanıtlamak için kullanabilirsiniz. Katkı kabul etmek istemiyorsanız veya projeniz henüz olgun değilse, bunu mutlaka belirtin. @@ -142,15 +166,15 @@ Daha fazla ilham almak için, eksiksiz bir README yazmak için @dguo'nun ["Make Kök dizinine bir README dosyası eklediğinizde, GitHub otomatik olarak depo ana sayfasında görüntüler. -- Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) -- Yeni bir özellik nasıl önerilir -- Proje ortamı nasıl kurulur ve testler nasıl yapılır +* Hata raporu nasıl gönderilir ([sorun ve istek şablonlarını](https://github.com/blog/2111-issue-and-pull-request-templates) kullanmayı deneyin) +* Yeni bir özellik nasıl önerilir +* Proje ortamı nasıl kurulur ve testler nasıl yapılır Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: -- Aradığınız katkı türleri -- Proje için yol haritanız veya vizyonunuz -- Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) +* Aradığınız katkı türleri +* Proje için yol haritanız veya vizyonunuz +* Katkıda bulunanlar sizinle nasıl temasa geçmeli (veya geçmemeli) Teknik ayrıntılara ek olarak, bir CONTRIBUTING dosyası, aşağıdakiler gibi katkılar için beklentilerinizi iletme fırsatıdır: @@ -170,7 +194,13 @@ README'nizden CONTRIBUTING dosyanıza bağlantı verin, böylece daha çok insan ### Davranış kural listesi oluşturmak - + Son olarak, bir davranış kural listesi projenizin katılımcı davranışları için temel kurallar koymanıza yardımcı olur. Bir topluluk veya şirket için açık kaynak kodlu bir proje başlatıyorsanız, bu özellikle değerlidir. Davranış kuralları, sağlıklı ve yapıcı topluluk davranışını kolaylaştırmanıza yardımcı olur ve bu da geliştirici olarak stresinizi azaltacaktır. @@ -190,8 +220,8 @@ Metni doğrudan projenizdeki bir CODE_OF_CONDUCT dosyasına yapıştırın. Dosy Marka, gösterişli bir logo veya çekici bir proje adından daha fazlasıdır. Projeniz hakkında nasıl konuştuğunuzla ve mesajınızla kime ulaştığınızla ilgilidir. -- [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler -- [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur +* [Sentry](https://github.com/getsentry/sentry) çöküş raporlaması için uygulamaları izler +* [Thin](https://github.com/macournoyer/thin) hızlı ve basit bir Ruby web sunucusudur Mevcut bir projenin üzerine inşa ediyorsanız, adlarını ön ek olarak kullanmak projenizin ne yaptığını netleştirmeye yardımcı olabilir (örneğin, [node-fetch](https://github.com/bitinn/node-fetch) `window.fetch` komutunu getirir). @@ -215,7 +245,13 @@ Projenizin ömrü boyunca birçok yazı yazacaksınız; README'ler, öğretici b Projenizin ömrü boyunca birçok yazı yazacaksınız: README'ler, öğretici belgeler, topluluk belgeleri, sorulara cevaplar, belki de haber bültenleri ve posta listeleri. - + Resmi bir belge veya geçici bir e-posta olsun, yazma stiliniz projenizin markasının bir parçasıdır. Hedef kitlenize nasıl sesleneceğinizi ve bunun iletmek istediğiniz ton olup olmadığını düşünün. @@ -231,39 +267,53 @@ Projenizi açmaya hazır mısınız? İşte size yardımcı olacak bir kontrol l
- +
- +
- +
- +
**Kod**
- +
- +
- +
**İnsanlar** @@ -272,29 +322,39 @@ Bireyseniz:
- +
Bir şirket veya kuruluşsanız:
- +
- +
- +
- +
## Başardınız! From 95b66da2f678846e87bde4772b0254c555bc8190 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Umut=20I=C5=9F=C4=B1k?= Date: Wed, 19 May 2021 02:26:17 +0300 Subject: [PATCH 031/629] Fetch From Upstream (#36) * Bump actions/setup-ruby from 1 to 1.1.3 Bumps [actions/setup-ruby](https://github.com/actions/setup-ruby) from 1 to 1.1.3. - [Release notes](https://github.com/actions/setup-ruby/releases) - [Commits](https://github.com/actions/setup-ruby/compare/v1...v1.1.3) Signed-off-by: dependabot[bot] * Fix formating errors created by Gitlocalize (#35) Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Blake Williams --- .github/workflows/tests.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 27f8a14d6a8..0eb22ebf388 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -11,7 +11,7 @@ jobs: uses: actions/checkout@v2.3.4 - name: Set up Ruby - uses: actions/setup-ruby@v1 + uses: actions/setup-ruby@v1.1.3 - name: Set up Node uses: actions/setup-node@v2.1.5 From 5fd0351050ac5b3dbe070f5c4e56033b8791db54 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Wed, 19 May 2021 07:26:51 +0000 Subject: [PATCH 032/629] Bump nokogiri from 1.11.3 to 1.11.4 Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.11.3 to 1.11.4. - [Release notes](https://github.com/sparklemotion/nokogiri/releases) - [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md) - [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.11.3...v1.11.4) Signed-off-by: dependabot[bot] --- Gemfile.lock | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Gemfile.lock b/Gemfile.lock index 33561394aab..3029fa9f9cc 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -220,7 +220,7 @@ GEM jekyll-seo-tag (~> 2.1) minitest (5.14.4) multipart-post (2.1.1) - nokogiri (1.11.3) + nokogiri (1.11.4) mini_portile2 (~> 2.5.0) racc (~> 1.4) nokogumbo (2.0.5) From 10a1bdbd7166982df5e2ced14ebddf2b1c4d7d60 Mon Sep 17 00:00:00 2001 From: Bart Date: Thu, 20 May 2021 12:05:44 +0800 Subject: [PATCH 033/629] Modify 2 incorrect words MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Modify 2 incorrect words' translation, function and variable always stand for 函数 and 变量 --- _articles/zh-hans/starting-a-project.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md index 897a26d9232..3a8113891a5 100644 --- a/_articles/zh-hans/starting-a-project.md +++ b/_articles/zh-hans/starting-a-project.md @@ -300,7 +300,7 @@ redirect_from: /zh-cn/starting-a-project/
From a2c53e912d2aa0cfeef243ada78b7d9a7f5e0b3a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=AB=AB=E6=B3=93?= Date: Thu, 27 May 2021 11:46:49 +0800 Subject: [PATCH 034/629] Fix typo in article "how to contribute" --- _articles/zh-hant/how-to-contribute.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md index c6eb5d96d90..c29fd8b182e 100644 --- a/_articles/zh-hant/how-to-contribute.md +++ b/_articles/zh-hant/how-to-contribute.md @@ -57,7 +57,7 @@ redirect_from: /zh-tw/how-to-contribute/ ### **你不一定要會寫程式才能貢獻** -對開源做出貢獻常見的誤解之一就是：要寫程式纔算貢獻。其實專案裡不需編碼的工作也是[經常被忽視](https://github.com/blog/2195-the-shape-of-open-source)的部分。你對專案所做的非程式類貢獻，其實是對專案來說莫大的幫助！ +對開源做出貢獻常見的誤解之一就是：要寫程式才算貢獻。其實專案裡不需編碼的工作也是[經常被忽視](https://github.com/blog/2195-the-shape-of-open-source)的部分。你對專案所做的非程式類貢獻，其實是對專案來說莫大的幫助！