From 69935819dd07c1c0d6a38e90053a98864f2acee0 Mon Sep 17 00:00:00 2001 From: Aseel Ahmed Date: Tue, 7 Oct 2025 19:18:01 +0300 Subject: [PATCH 1/9] Add Arabic translation for Open Source Guides --- Gemfile.lock | 4 + _articles/ar/best-practices.md | 280 ++++++++++ _articles/ar/building-community.md | 276 +++++++++ _articles/ar/code-of-conduct.md | 114 ++++ _articles/ar/finding-users.md | 148 +++++ _articles/ar/getting-paid.md | 177 ++++++ _articles/ar/how-to-contribute.md | 527 ++++++++++++++++++ _articles/ar/index.html | 6 + _articles/ar/leadership-and-governance.md | 156 ++++++ _articles/ar/legal.md | 166 ++++++ ...ing-balance-for-open-source-maintainers.md | 219 ++++++++ _articles/ar/metrics.md | 128 +++++ ...ecurity-best-practices-for-your-project.md | 84 +++ _articles/ar/starting-a-project.md | 356 ++++++++++++ _data/locales/ar.yml | 27 + assets/css/translate.scss | 1 + 16 files changed, 2669 insertions(+) create mode 100644 _articles/ar/best-practices.md create mode 100644 _articles/ar/building-community.md create mode 100644 _articles/ar/code-of-conduct.md create mode 100644 _articles/ar/finding-users.md create mode 100644 _articles/ar/getting-paid.md create mode 100644 _articles/ar/how-to-contribute.md create mode 100644 _articles/ar/index.html create mode 100644 _articles/ar/leadership-and-governance.md create mode 100644 _articles/ar/legal.md create mode 100644 _articles/ar/maintaining-balance-for-open-source-maintainers.md create mode 100644 _articles/ar/metrics.md create mode 100644 _articles/ar/security-best-practices-for-your-project.md create mode 100644 _articles/ar/starting-a-project.md create mode 100644 _data/locales/ar.yml diff --git a/Gemfile.lock b/Gemfile.lock index cbd4e9fd317..d8cc74fc83f 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -58,6 +58,7 @@ GEM ffi (1.17.1-arm-linux-gnu) ffi (1.17.1-arm-linux-musl) ffi (1.17.1-arm64-darwin) + ffi (1.17.1-x64-mingw-ucrt) ffi (1.17.1-x86-linux-gnu) ffi (1.17.1-x86-linux-musl) ffi (1.17.1-x86_64-darwin) @@ -281,6 +282,8 @@ GEM racc (~> 1.4) nokogiri (1.18.10-arm64-darwin) racc (~> 1.4) + nokogiri (1.18.10-x64-mingw-ucrt) + racc (~> 1.4) nokogiri (1.18.10-x86_64-darwin) racc (~> 1.4) nokogiri (1.18.10-x86_64-linux-gnu) @@ -342,6 +345,7 @@ PLATFORMS arm-linux-gnu arm-linux-musl arm64-darwin + x64-mingw-ucrt x86-linux x86-linux-gnu x86-linux-musl diff --git a/_articles/ar/best-practices.md b/_articles/ar/best-practices.md new file mode 100644 index 00000000000..aac362fa281 --- /dev/null +++ b/_articles/ar/best-practices.md @@ -0,0 +1,280 @@ +--- +lang: en +title: Best Practices for Maintainers +description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community. +class: best-practices +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 an 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 them. + +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](https://github.com/dependabot) 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/ar/building-community.md b/_articles/ar/building-community.md new file mode 100644 index 00000000000..90d73dd6eda --- /dev/null +++ b/_articles/ar/building-community.md @@ -0,0 +1,276 @@ +--- +lang: en +title: Building Welcoming Communities +description: Building a community that encourages people to use, contribute to, and evangelize your project. +class: building +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 a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help. +* **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/) 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/ar/code-of-conduct.md b/_articles/ar/code-of-conduct.md new file mode 100644 index 00000000000..3c3d187ae79 --- /dev/null +++ b/_articles/ar/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: en +title: Your Code of Conduct +description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. +class: coc +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](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. + +## 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/ar/finding-users.md b/_articles/ar/finding-users.md new file mode 100644 index 00000000000..3fa494ec3c9 --- /dev/null +++ b/_articles/ar/finding-users.md @@ -0,0 +1,148 @@ +--- +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 +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/ar/getting-paid.md b/_articles/ar/getting-paid.md new file mode 100644 index 00000000000..772ab932e29 --- /dev/null +++ b/_articles/ar/getting-paid.md @@ -0,0 +1,177 @@ +--- +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 +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Why some people seek financial support + +Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. + + + +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/), have websites that highlight their involvement in open source + +Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. + +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 in new features or ideas. + +As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. + +### 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) +* **[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/cli) 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/ar/how-to-contribute.md b/_articles/ar/how-to-contribute.md new file mode 100644 index 00000000000..47be4d64d21 --- /dev/null +++ b/_articles/ar/how-to-contribute.md @@ -0,0 +1,527 @@ +--- +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 veterans. +class: contribute +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, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151) +* Curate a folder of examples showing how the project is used +* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/) +* Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/) +* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) + + + +### 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. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide). +* **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 like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). + +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/Merge requests:** Where people discuss and review changes that are in progress, whether it's to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews. +* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/) +* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/). + +## 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! + +> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation. + +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/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) +* [GitLab Explore](https://gitlab.com/explore/projects/starred) + +### 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 main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) + +
+ + +
+ +
+ + +
+ +
+ + +
+ +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 it when you demonstrate that you're trying to learn. + +> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ +> +> 😢 _"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 doing the following: + +* **Raising an Issue:** These are like starting a conversation or discussion +* **Pull requests** are for starting work on a solution. +* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution. + +Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. + +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 small fixes such as a typo, a broken link or an obvious error. +* Start work on a contribution that was already asked for, or that you've already discussed, in an issue. + +A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later. + +If the project is on GitHub, here's how to submit a pull request: + +* **[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. It's important to make sure your changes don't break the existing project. +* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. + +If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. + +## What happens after you submit your contribution + +Before we start celebrating, one of the following will happen after you submit your contribution: + +### 😭 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 give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. + +### 🚧 Someone requests changes to your contribution + +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. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). + +If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). + +### 👎 Your contribution doesn't get accepted + +Your contribution 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/ar/index.html b/_articles/ar/index.html new file mode 100644 index 00000000000..009f753ca55 --- /dev/null +++ b/_articles/ar/index.html @@ -0,0 +1,6 @@ +--- +layout: index +lang: ar +title: إرشادات المشاريع مفتوحة المصدر +permalink: /ar/ +--- diff --git a/_articles/ar/leadership-and-governance.md b/_articles/ar/leadership-and-governance.md new file mode 100644 index 00000000000..b726ea4d825 --- /dev/null +++ b/_articles/ar/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: en +title: Leadership and Governance +description: Growing open source projects can benefit from formal rules for making decisions. +class: leadership +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://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. + + + +If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. diff --git a/_articles/ar/legal.md b/_articles/ar/legal.md new file mode 100644 index 00000000000..a7468b5e5cb --- /dev/null +++ b/_articles/ar/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 +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, with this guide you don't have to start from scratch. (Before you dig in, be sure to read our [disclaimer](/notices/).) + +## Why do people care so much about the legal side of open source? + +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 to explicitly give these permissions with a license. + +These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions. + +Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. + +## 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://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. + +If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. + +## 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 [popular open source licenses](https://innovationgraph.github.com/global-metrics/licenses), but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). + +When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). + + + +## Which open source license is appropriate for my project? + +It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. + +Otherwise, picking the right open source license for your project depends on your objectives. + +Your project very likely has (or will have) **dependencies**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). + +Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want. + +Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify. + +Dependencies with **source-available licenses**, such as the Business Source License [BSL](https://spdx.org/licenses/BUSL-1.1.html) or the Server Side Public License [SSPL](https://en.wikipedia.org/wiki/Server_Side_Public_License), may appear to be under open source licenses but come with usage and business model restrictions. These restrictions may prevent your project from being considered Open Source as defined by the [Open Source Initiative (OSI)](https://opensource.org/). + +Projects often rely on **non-source code content**, such as images, icons, videos, fonts, data files, or other materials, which are governed by their own licenses. As with traditional software dependencies, the licenses these materials range from Commercial to permissive to Copyleft. The [Creative Commons](https://creativecommons.org/share-your-work/cclicenses/), a non-profit organization, created a series of licenses popular for non-source content. Creative Commons licenses range from very permissive [CC0](https://creativecommons.org/publicdomain/zero/1.0/deed.en) to Permissive [CC-BY](https://creativecommons.org/licenses/by/4.0/deed.en) to copyleft [CC-SA](https://creativecommons.org/licenses/by-sa/2.0/deed.en). They also can sometime restrict commercial use by adding a non-commercial (NC) option to these licenses. +You may also want to consider the **communities** you hope will use and contribute to your project: + +* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). +* **Do you want your project to appeal to large businesses?** A large business may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. +* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. + +Your **company** may have policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance. + +When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). + +## 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](https://github.com/thehale/git-authorship) is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. + +Alternatively, you can have contributors pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. + +## Does my project need an additional contributor agreement? + +Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/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://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. +* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). +* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. +* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. +* 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](#which-open-source-license-is-appropriate-for-my-project)). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. + +* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. + +* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement ([see above](#which-open-source-license-is-appropriate-for-my-project)). + +* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. + +* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. + +* **AI** As AI models and functionality become integral to software, it is crucial to understand licensing agreements and relevant legislation controlling their use. Even when a model or service claims to be under a standard open source license, additional terms may impose restrictions, such as preventing abuse or fraud. New legislation is also putting restrictions on the types of systems or actions that can be performed by AI-based software. +* **Software Bill of Materials** A Software Bill of Materials (SBOM) is a comprehensive list of third-party dependencies, versions, associated licenses, and other metadata. SBOMs are legally mandated in certain countries, industries, or due to contractual obligations. A request for a SBOM often starts the license compliance journey for an organization. + +If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). + +Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: + +* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/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/blog/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/ar/maintaining-balance-for-open-source-maintainers.md b/_articles/ar/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..71207686f49 --- /dev/null +++ b/_articles/ar/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,219 @@ +--- +lang: en +untranslated: true +title: Maintaining Balance for Open Source Maintainers +description: Tips for self-care and avoiding burnout as a maintainer. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. + +To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play. + +So, what is personal ecology? As described by the Rockwood Leadership Institute, it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse/2025-01/foundation/en#129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with. + + + +By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work. + +## Tips for Self-Care and Avoiding Burnout as a Maintainer: + +### Identify your motivations for working in open source + +Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus. + +### Reflect on what causes you to get out of balance and stressed out + +It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers: + +* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference. + + + +* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations. + + + +* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person. + + + +* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project. + + + +* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community. + + + +### Watch out for signs of burnout + +Can you keep up your pace for 10 weeks? 10 months? 10 years? + +There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress). + + + +### What would you need to continue sustaining yourself and your community? + +This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard: + +* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. + + You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work. + +* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/). + + + +* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions. + + + +* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term. + + If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day. + + + +* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time. + + + +Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about. + + + + + +Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run. + +## Additional Resources + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://mikemcquaid.com/saying-no/) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://foundation.mozilla.org/en/blog/its-a-wrap-movement-building-from-home/) series + +## Contributors + +Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/ar/metrics.md b/_articles/ar/metrics.md new file mode 100644 index 00000000000..145dd18119b --- /dev/null +++ b/_articles/ar/metrics.md @@ -0,0 +1,128 @@ +--- +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 +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](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), 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. + +[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health. diff --git a/_articles/ar/security-best-practices-for-your-project.md b/_articles/ar/security-best-practices-for-your-project.md new file mode 100644 index 00000000000..2848d1863fa --- /dev/null +++ b/_articles/ar/security-best-practices-for-your-project.md @@ -0,0 +1,84 @@ +--- +lang: en +untranslated: true +title: Security Best Practices for your Project +description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting. +class: security-best-practices +order: -1 +image: /assets/images/cards/security-best-practices.png +--- + +Bugs and new features aside, a project's longevity hinges not only on its usefulness but also on the trust it earns from its users. Strong security measures are important to keep this trust alive. Here are some important actions you can take to significantly improve your project's security. + +## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA) + +### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages. + +Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services. + +MFA provides an additional layer of security against account takeover. Once enabled, you have to log in with your username and password and provide another form of authentication that only you know or have access to. + +## Secure your code as part of your development workflow + +### Security vulnerabilities in your code are cheaper to fix when detected early in the process than later, when they are used in production. + +Use a Static Application Security Testing (SAST) tool to detect security vulnerabilities in your code. These tools are operating at code level and don't need an executing environment, and therefore can be executed early in the process, and can be seamlessly integrated in your usual development workflow, during the build or during the code review phases. + +It's like having a skilled expert look over your code repository, helping you find common security vulnerabilities that could be hiding in plain sight as you code. + +How to choose your SAST tool? +Check the license: Some tools are free for open source projects. For example GitHub CodeQL or SemGrep. +Check the coverage for your language(s) + +* Select one that easily integrates with the tools you already use, with your existing process. For example, it's better if the alerts are available as part of your existing code review process and tool, rather than going to another tool to see them. +* Beware of False Positives! You don't want the tool to slow you down for no reason! +* Check the features: some tools are very powerful and can do taint tracking (example: GitHub CodeQL), some propose AI-generated fix suggestions, some make it easier to write custom queries (example: SemGrep). + +## Don't share your secrets + +### Sensitive data, such as API keys, tokens, and passwords, can sometimes accidentally get committed to your repository. + +Imagine this scenario: You are the maintainer of a popular open-source project with contributions from developers worldwide. One day, a contributor unknowingly commits to the repository some API keys of a third-party service. Days later, someone finds these keys and uses them to get into the service without permission. The service is compromised, users of your project experience downtime, and your project's reputation takes a hit. As the maintainer, you're now faced with the daunting tasks of revoking compromised secrets, investigating what malicious actions the attacker could have performed with this secret, notifying affected users, and implementing fixes. + +To prevent such incidents, "secret scanning" solutions exist to help you detect those secrets in your code. Some tools like GitHub Secret Scanning, and Trufflehog by Truffle Security can prevent you from pushing them to remote branches in the first place, and some tools will automatically revoke some secrets for you. + +## Check and update your dependencies + +### Dependencies in your project can have vulnerabilities that compromise the security of your project. Manually keeping dependencies up to date can be a time-consuming task. + +Picture this: a project built on the sturdy foundation of a widely-used library. The library later finds a big security problem, but the people who built the application using it don't know about it. Sensitive user data is left exposed when an attacker takes advantage of this weakness, swooping in to grab it. This is not a theoretical case. This is exactly what happened to Equifax in 2017: They failed to update their Apache Struts dependency after the notification that a severe vulnerability was detected. It was exploited, and the infamous Equifax breach affected 144 million users' data. + +To prevent such scenarios, Software Composition Analysis (SCA) tools such as Dependabot and Renovate automatically check your dependencies for known vulnerabilities published in public databases such as the NVD or the GitHub Advisory Database, and then creates pull requests to update them to safe versions. Staying up-to-date with the latest safe dependency versions safeguards your project from potential risks. + +## Avoid unwanted changes with protected branches + +### Unrestricted access to your main branches can lead to accidental or malicious changes that may introduce vulnerabilities or disrupt the stability of your project. + +A new contributor gets write access to the main branch and accidentally pushes changes that have not been tested. A dire security flaw is then uncovered, courtesy of the latest changes. To prevent such issues, branch protection rules ensure that changes cannot be pushed or merged into important branches without first undergoing reviews and passing specified status checks. You're safer and better off with this extra measure in place, guaranteeing top-notch quality every time. + +## Set up an intake mechanism for vulnerability reporting + +### It's a good practice to make it easy for your users to report bugs, but the big question is: when this bug has a security impact, how can they safely report them to you without putting a target on you for malicious hackers? + +Picture this: A security researcher discovers a vulnerability in your project but finds no clear or secure way to report it. Without a designated process, they might create a public issue or discuss it openly on social media. Even if they are well-intentioned and offer a fix, if they do it with a public pull request, others will see it before it's merged! This public disclosure will expose the vulnerability to malicious actors before you have a chance to address it, potentially leading to a zero-day exploit, attacking your project and its users. + +### Security Policy + +To avoid this, publish a security policy. A security policy, defined in a `SECURITY.md` file, details the steps for reporting security concerns, creating a transparent process for coordinated disclosure, and establishing the project team's responsibilities for addressing reported issues. This security policy can be as simple as "Please don't publish details in a public issue or PR, send us a private email at security@example.com", but can also contain other details such as when they should expect to receive an answer from you. Anything that can help the effectiveness and the efficiency of the disclosure process. + +### Private Vulnerability Reporting + +On some platforms, you can streamline and strengthen your vulnerability management process, from intake to broadcast, with private issues. On GitLab, this can be done with private issues. On GitHub, this is called private vulnerability reporting (PVR). PVR enables maintainers to receive and address vulnerability reports, all within the GitHub platform. GitHub will automatically create a private fork to write the fixes, and a draft security advisory. All of this remains confidential until you decide to disclose the issues and release the fixes. To close the loop, security advisories will be published, and will inform and protect all your users through their SCA tool. + +## Conclusion: A few steps for you, a huge improvement for your users + +These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues. + +## Contributors + +### Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) with contributions from: + +[@JLLeitschuh](https://github.com/JLLeitschuh) +[@intrigus-lgtm](https://github.com/intrigus-lgtm) + many others! diff --git a/_articles/ar/starting-a-project.md b/_articles/ar/starting-a-project.md new file mode 100644 index 00000000000..f4282add76d --- /dev/null +++ b/_articles/ar/starting-a-project.md @@ -0,0 +1,356 @@ +--- +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 +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://www.cio.gov/2016/08/11/peoples-code.html), 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/definition-annotated/) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. + +As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source. + +## 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](https://namechecker.vercel.app/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. + +If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet. + +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. diff --git a/_data/locales/ar.yml b/_data/locales/ar.yml new file mode 100644 index 00000000000..3b90db7cc08 --- /dev/null +++ b/_data/locales/ar.yml @@ -0,0 +1,27 @@ +ar: + locale_name: العربية + nav: + about: عن المشروع + contribute: ساهِم + index: + lead: "البرمجيات مفتوحة المصدر يصنعها أشخاص مثلك تمامًا، تعلّم كيف تطلِق مشروعَك وتُنمّيه" + opensourcefriday: "إنه يوم الجمعة! خصّص بضع ساعات للمساهمة في البرمجيات التي تستخدمها وتحبها" + article: + table_of_contents: جدول المحتويات + back_to_all_guides: رجوع للأدلة + related_guides: أدلة ذات صلة + footer: + contribute: + heading: ساهِم + description: "هل تريد تقديم اقتراح؟ هذا المحتوى مفتوح المصدر. ساعدنا على تحسينه" + button: ساهِم + subscribe: + heading: ابقَ على تواصل + description: "GitHubكُن أول من يطّلِع على أحدث نصائح وموارد" + label: البريد الإلكتروني + button: اشترِك + byline: + format: "[code] بـِ [love] بواسطة [github] و [friends]" + code_label: code + love_label: love + friends_label: المساهمون diff --git a/assets/css/translate.scss b/assets/css/translate.scss index 566205b4f49..6d80177d0cf 100644 --- a/assets/css/translate.scss +++ b/assets/css/translate.scss @@ -29,6 +29,7 @@ $section_translation: ( "zh-hans": "章节", "pcm": "Portion", "sw": "Sehemu ya", + "ar" : "قسم" ); @each $locale, $translation in $section_translation { From 4bd64eeb0ac62c73518e1ff63fed1ed8a1801ada Mon Sep 17 00:00:00 2001 From: Aseel Ahmed Date: Wed, 15 Oct 2025 19:57:32 +0300 Subject: [PATCH 2/9] Fix: update Arabic articles lang and permalinks --- _articles/ar/best-practices.md | 2 +- _articles/ar/building-community.md | 2 +- _articles/ar/code-of-conduct.md | 2 +- _articles/ar/finding-users.md | 2 +- _articles/ar/getting-paid.md | 2 +- _articles/ar/how-to-contribute.md | 2 +- _articles/ar/leadership-and-governance.md | 2 +- _articles/ar/legal.md | 2 +- _articles/ar/maintaining-balance-for-open-source-maintainers.md | 2 +- _articles/ar/metrics.md | 2 +- _articles/ar/security-best-practices-for-your-project.md | 2 +- _articles/ar/starting-a-project.md | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-) diff --git a/_articles/ar/best-practices.md b/_articles/ar/best-practices.md index aac362fa281..6774e795a1d 100644 --- a/_articles/ar/best-practices.md +++ b/_articles/ar/best-practices.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar title: Best Practices for Maintainers description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community. class: best-practices diff --git a/_articles/ar/building-community.md b/_articles/ar/building-community.md index 90d73dd6eda..cf9eee8bd6f 100644 --- a/_articles/ar/building-community.md +++ b/_articles/ar/building-community.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar title: Building Welcoming Communities description: Building a community that encourages people to use, contribute to, and evangelize your project. class: building diff --git a/_articles/ar/code-of-conduct.md b/_articles/ar/code-of-conduct.md index 3c3d187ae79..6a08e69b266 100644 --- a/_articles/ar/code-of-conduct.md +++ b/_articles/ar/code-of-conduct.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar title: Your Code of Conduct description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. class: coc diff --git a/_articles/ar/finding-users.md b/_articles/ar/finding-users.md index 3fa494ec3c9..1d6b8ce7885 100644 --- a/_articles/ar/finding-users.md +++ b/_articles/ar/finding-users.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar title: Finding Users for Your Project description: Help your open source project grow by getting it in the hands of happy users. class: finding diff --git a/_articles/ar/getting-paid.md b/_articles/ar/getting-paid.md index 772ab932e29..aa2bd691dc2 100644 --- a/_articles/ar/getting-paid.md +++ b/_articles/ar/getting-paid.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar 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 diff --git a/_articles/ar/how-to-contribute.md b/_articles/ar/how-to-contribute.md index 47be4d64d21..2374a496375 100644 --- a/_articles/ar/how-to-contribute.md +++ b/_articles/ar/how-to-contribute.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar 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 veterans. class: contribute diff --git a/_articles/ar/leadership-and-governance.md b/_articles/ar/leadership-and-governance.md index b726ea4d825..a685a704a6e 100644 --- a/_articles/ar/leadership-and-governance.md +++ b/_articles/ar/leadership-and-governance.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar title: Leadership and Governance description: Growing open source projects can benefit from formal rules for making decisions. class: leadership diff --git a/_articles/ar/legal.md b/_articles/ar/legal.md index a7468b5e5cb..8f868afa049 100644 --- a/_articles/ar/legal.md +++ b/_articles/ar/legal.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar 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 diff --git a/_articles/ar/maintaining-balance-for-open-source-maintainers.md b/_articles/ar/maintaining-balance-for-open-source-maintainers.md index 71207686f49..a9afe2cb0c0 100644 --- a/_articles/ar/maintaining-balance-for-open-source-maintainers.md +++ b/_articles/ar/maintaining-balance-for-open-source-maintainers.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar untranslated: true title: Maintaining Balance for Open Source Maintainers description: Tips for self-care and avoiding burnout as a maintainer. diff --git a/_articles/ar/metrics.md b/_articles/ar/metrics.md index 145dd18119b..90557df1fdf 100644 --- a/_articles/ar/metrics.md +++ b/_articles/ar/metrics.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar title: Open Source Metrics description: Make informed decisions to help your open source project thrive by measuring and tracking its success. class: metrics diff --git a/_articles/ar/security-best-practices-for-your-project.md b/_articles/ar/security-best-practices-for-your-project.md index 2848d1863fa..aaf05db6cff 100644 --- a/_articles/ar/security-best-practices-for-your-project.md +++ b/_articles/ar/security-best-practices-for-your-project.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar untranslated: true title: Security Best Practices for your Project description: Strengthen your project's future by building trust through essential security practices — from MFA and code scanning to safe dependency management and private vulnerability reporting. diff --git a/_articles/ar/starting-a-project.md b/_articles/ar/starting-a-project.md index f4282add76d..9f590d9c370 100644 --- a/_articles/ar/starting-a-project.md +++ b/_articles/ar/starting-a-project.md @@ -1,5 +1,5 @@ --- -lang: en +lang: ar 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 From 739c84d251f8d49378ad090919c74301378c8760 Mon Sep 17 00:00:00 2001 From: mohammedabusamra04 Date: Wed, 22 Oct 2025 10:22:08 +0300 Subject: [PATCH 3/9] Add files via upload --- code-of-conduct (2).md | 114 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 code-of-conduct (2).md diff --git a/code-of-conduct (2).md b/code-of-conduct (2).md new file mode 100644 index 00000000000..b0a43958209 --- /dev/null +++ b/code-of-conduct (2).md @@ -0,0 +1,114 @@ +--- +lang: ar +title: مدونة السلوك الخاصة بمشروعك +description: عزِّز السلوك الإيجابي والبنّاء في مجتمعك من خلال اعتماد وتطبيق مدونة سلوك. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## لماذا تحتاج إلى مدونة سلوك ؟ _( Code Of Conduct )_ + +تُعدّ مدونة السلوك وثيقة تُحدّد التوقعات والمعايير السلوكية للمشاركين في مشروعك. إن اعتماد مدونة سلوك وتطبيقها يُسهم في خلق بيئة اجتماعية إيجابية داخل مجتمع المشروع. + +تساعد مدونات السلوك في حماية جميع المشاركين — وليس المشاركين فقط، بل أيضًا أنت كمشرف أو مطوّر للمشروع. فبمرور الوقت، قد تؤدي المواقف غير البنّاءة من بعض الأعضاء إلى شعورك بالإرهاق أو فقدان الحافز تجاه العمل. + +تمنحك مدونة السلوك القدرة على تعزيز سلوك مجتمعي صحي وبنّاء، كما أن اتخاذ مواقف استباقية يقلل من احتمال شعورك أنت أو غيرك بالإجهاد من المشروع، ويساعدك على اتخاذ الإجراء المناسب عندما يتصرف أحد الأعضاء بطريقة غير لائقة أو غير متوافقة مع قيم المشروع. + +## وضع مدونة سلوك + +من الأفضل أن تقوم بوضع مدونة سلوك في أقرب وقت ممكن، ويفضل أن يكون ذلك عند إنشاء مشروعك لأول مرة. + +إلى جانب توضيح التوقعات الخاصة بك، تساعد مدونة السلوك على تحديد الأمور التالية: + +* نطاق تطبيق مدونة السلوك _( هل تنطبق فقط على القضايا والطلبات ، أم تشمل الأنشطة المجتمعية مثل الفعاليات ؟)_ +* الأشخاص الذين ينطبق عليهم السلوك _( أعضاء المجتمع والمشرفون ، وماذا عن الرعاة ؟)_ +* الإجراءات المتخذة في حال خرق أحدهم مدونة السلوك +* الطريقة التي يمكن من خلالها الإبلاغ عن الانتهاكات + +كلما أمكن، اعتمد على نماذج موجودة مسبقًا بدل أن تصنع كل شيء من الصفر. على سبيل المثال، [اتفاقية المساهمين](https://contributor-covenant.org/) هي مدونة سلوك جاهزة يمكن دمجها مباشرة في مشروعك، وقد تبناها آلاف المشاريع المفتوحة المصدر مثل Kubernetes وRails وSwift. + + [مدونة سلوك Django](https://www.djangoproject.com/conduct/) و [مدونة السلوك للمواطنين](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) كما تعتبر هاتان المدونتان مثالين جيدين على مدونات السلوك يمكن الاعتماد عليهما. + +## تحديد كيفية تطبيق مدونة السلوك الخاصة بك + + + +ينبغي أن توضح كيف سيتم تطبيق مدونة السلوك الخاصة بك، بحيث يعرف الجميع الإجراءات المتخذة عند حدوث أي انتهاك وكيفية التعامل معه عند حدوث أي انتهاك. هناك عدة أسباب تجعل من المهم توضيح ذلك: + +* يُظهر هذا أنك تتعامل بجدية مع أي تجاوزات تحدث عند الحاجة، + +* كما يمنح أفراد مجتمعك شعورًا بالثقة بأن أي شكوى يتم أخذها بعين الاعتبار فعلًا. + +* ويُطمئن الجميع بأن عملية المراجعة تتم بشفافية وعدالة، في حال تم التحقيق مع أحدهم بسبب مخالفة محتملة. + +يجب أن توفّر وسيلة خاصة للأشخاص للإبلاغ عن أي انتهاك لمدونة السلوك، مثل بريد إلكتروني مخصص، وتوضح من يستقبل هذا الإبلاغ. يمكن أن يكون شخصًا مشرفًا، أو مجموعة من المشرفين، أو فريق خاص بإدارة مدونة السلوك. + +تذكر أن هناك احتمال أن يرغب شخص بالإبلاغ عن انتهاك يرتبط بشخص يستقبل هذه التقارير. في هذه الحالة، يجب أن توفّر لهم خيارًا للإبلاغ إلى شخص آخر. على سبيل المثال، يمكن تحديد مشرفين بديلين مثل @ctb و @mr-c. [اشرح ذلك في مشروعهم](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> يمكن الإبلاغ عن أي سلوك مسيء أو تحرشي أو غير مقبول عبر إرسال بريد إلكتروني إلى: **khmer-project@idyll.org** والذي يذهب فقط إلى C. Titus Brown وMichael R. Crusoe. للإبلاغ عن أي مشكلة تتعلق بأحدهما، يرجى إرسال البريد الإلكتروني إلى: **Judi Brown Clarke, Ph.D.** إلى مدير التنوع في مركز BEACON لدراسة التطور في الفعل، وهو مركز تابع للصندوق الوطني للعلوم (NSF) للعلوم والتكنولوجيا. + +للحصول على مصدر إلهام، يمكنك الاطلاع على مدونة سلوك Django.[دليل تطبيق القواعد](https://www.djangoproject.com/conduct/enforcement-manual/) +(قد لا يكون من الضروري أن يكون لديك دليل شامل بهذا الشكل، فهذا يعتمد على حجم مشروعك). + +## تطبيق مدونة السلوك الخاصة بك + +في بعض الأحيان، رغم كل جهودك، قد يقوم شخص ما بفعل يخالف مدونة السلوك. هناك عدة طرق للتعامل مع السلوك السلبي أو الضار عند حدوثه. + +### اجمع المعلومات المتعلقة بالموقف + +عامل كل عضو في المجتمع كما لو كانت صوته مهم بقدر صوتك. إذا وصلتك بلاغات عن شخص انتهك مدونة السلوك، خذ الأمر بجدية وحقق فيه، حتى لو لم تتوافق مع تجربتك الشخصية معه. هذا يُظهر لأعضاء المجتمع أنك تقدر وجهات نظرهم وتثق في حكمهم. + +قد يكون العضو المعني متكرّر الانتهاك ويجعل الآخرين يشعرون بعدم الارتياح بشكل مستمر، أو قد يكون تصرف مرة واحدة فقط. في كلتا الحالتين، يمكن أن يكون هناك سبب لاتخاذ إجراء، حسب السياق. + +قبل أن ترد، امنح نفسك وقتًا لفهم ما حدث. راجع تعليقات الشخص ومحادثاته السابقة لتفهم شخصيته وأسباب تصرفه بهذه الطريقة. حاول أيضًا جمع آراء غير رأيك الشخصي حول هذا الشخص وسلوكه. + + + +### اتخذ الإجراء المناسب + +بعد أن تجمع وتعالج معلومات كافية، ستحتاج لتقرير ما هو الإجراء المناسب. أثناء تفكيرك في خطواتك التالية، تذكّر أن هدفك كمسؤول أو مشرف هو خلق بيئة آمنة، محترمة، ومتعاونة. ركّز ليس فقط على كيفية التعامل مع الموقف نفسه، بل أيضًا على كيف سيؤثر ردك على سلوك المجتمع وتوقعاته في المستقبل. + +عندما يبلغ أحدهم عن انتهاك لمدونة السلوك، فإن مسؤوليتك أنت، لا هم، في التعامل مع الأمر. أحيانًا يكون المبلغ يشارك معلومات معرّضة مخاطر كبيرة على مسيرته المهنية، سمعته، أو سلامته الشخصية. إجباره على مواجهة من أساء له قد يضعه في موقف صعب. لذلك، يجب أن تتولى أنت التواصل المباشر مع الشخص المعني، إلا إذا طلب المبلغ خلاف ذلك صراحة. + +هناك عدة طرق يمكن من خلالها الرد على انتهاك مدونة السلوك: + +* **وجّه تحذيرًا علنيًا للشخص المعني** واشرح كيف أثّر سلوكهم سلبًا على الآخرين، ويفضّل أن يكون ذلك في القناة التي وقع فيها السلوك. التواصل العلني، حينما يكون ممكنًا، يُظهر لبقية المجتمع أنك تأخذ مدونة السلوك على محمل الجد. كن لطيفًا في حديثك، لكن حازمًا في موقفك. + +* **تواصل مع الشخص المعني بشكل خاص** لتوضيح كيف أثّر سلوكهم سلبًا على الآخرين. قد ترغب في استخدام وسيلة تواصل خاصة إذا كان الموقف يتضمن معلومات شخصية حساسة. إذا تواصلت مع الشخص على انفراد، فمن الجيد إشراك (CC) من أبلغوا عن الموقف أولًا، ليعرفوا أنك اتخذت إجراءً. استأذن المبلغ قبل إضافته في الـ CC. + +أحيانًا، لا يمكن التوصل إلى حل. قد يصبح الشخص المعني عدائيًا أو عدوانيًا عند مواجهته، أو قد لا يغيّر سلوكه. في هذه الحالة، قد تحتاج إلى التفكير في اتخاذ إجراءات أشد. على سبيل المثال: + +* **أوقف الشخص عن المشاركة مؤقتًا** من المشروع، ويتم تطبيق ذلك عبر حظر مؤقت يمنعهم من المشاركة في أي جزء من أنشطة المشروع. + +* **منع الشخص نهائيًا من المشاركة** في المشروع. + +حظر الأعضاء ليس أمرًا يُتخذ باستخفاف، فهو يمثل اختلافًا دائمًا ولا يمكن التوفيق بين وجهات النظر فيه. يجب اتخاذ مثل هذه الإجراءات فقط عندما يكون واضحًا أن الحل لا يمكن الوصول إليه. + +## مسؤولياتك كصاحب المشروع أو المشرف + +مدونة السلوك ليست قانونًا يُطبق بشكل تعسفي. أنت المسؤول عن تطبيق مدونة السلوك، ومن مسؤوليتك الالتزام بالقواعد التي تحددها المدونة. + +كصاحب المشروع أو المشرف، أنت من يضع الإرشادات لمجتمعك ويطبّقها وفق القواعد الواردة في مدونة السلوك. هذا يعني أن أي تقرير عن انتهاك يجب أخذه على محمل الجد. المبلغ عن الانتهاك يستحق مراجعة عادلة وشاملة لشكواه. إذا وجدت أن السلوك المبلغ عنه لا يشكل انتهاكًا، فاخبره بذلك بوضوح واشرح سبب عدم اتخاذ أي إجراء. وما يفعله بعد ذلك يعود له: سواء تقبل السلوك أو قرر التوقف عن المشاركة في المجتمع. + +حتى التقرير عن سلوك لا يُعتبر تقنيًا انتهاكًا، قد يشير إلى وجود مشكلة ضمن مجتمعك، ويجب عليك التحقيق في هذه المشكلة المحتملة واتخاذ الإجراء المناسب. قد يشمل ذلك تعديل مدونة السلوك لتوضيح السلوك المقبول، أو التحدث مع الشخص المعني وإخباره أنه لم ينتهك المدونة، لكنه يقترب من حدود ما هو متوقع ويجعل بعض المشاركين يشعرون بعدم الارتياح. + +في النهاية، بصفتك المشرف أو صاحب المشروع، أنت من يحدد ويطبّق المعايير للسلوك المقبول. لديك القدرة على تشكيل قيم المجتمع الخاص بالمشروع، ويتوقع المشاركون منك تطبيق هذه القيم بطريقة عادلة ومتوازنة. + +## شجّع السلوك الذي ترغب في رؤيته في مجتمعك 🌎 + +عندما يبدو المشروع عدائيًا أو غير مرحب، حتى لو كان هناك شخص واحد فقط يُسمح له بسلوك سيء، فإنك تخاطر بخسارة العديد من المساهمين الآخرين، قد يكون بعضهم لم تلتقِ بهم من قبل. قد لا يكون من السهل دائمًا تبني أو تطبيق مدونة السلوك، لكن خلق بيئة مرحبة سيساعد مجتمعك على النمو والتطور. \ No newline at end of file From febe3277f72be7c3e03ce188925dd1843062fff6 Mon Sep 17 00:00:00 2001 From: Aseel Ahmed Date: Wed, 22 Oct 2025 16:44:59 +0300 Subject: [PATCH 4/9] Add Arabic translation for 'How to Contribute' --- _articles/ar/how-to-contribute.md | 174 +++++++++++++++--------------- _data/locales/ar.yml | 4 +- 2 files changed, 89 insertions(+), 89 deletions(-) diff --git a/_articles/ar/how-to-contribute.md b/_articles/ar/how-to-contribute.md index 2374a496375..7ad6b59b27d 100644 --- a/_articles/ar/how-to-contribute.md +++ b/_articles/ar/how-to-contribute.md @@ -1,7 +1,7 @@ --- lang: ar -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 veterans. +title: كيف تساهم في مشروع مفتوح المصدر ؟ +description: هل تريد أن تساهم في مشاريع مفتوحة المصدر؟ دليل للمبتدئين والمحترفين حول كيفية المشاركة فيها class: contribute order: 1 image: /assets/images/cards/contribute.png @@ -10,135 +10,134 @@ 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. +### التعرف على أشخاص مهتمين في أشياء متشابهة +المشاريع مفتوحة المصدر التي تمتلك مجتمعات لطيفة ومرّحبة تجذب الناس للاستمرار لسنوات. كثير من الأشخاص كوّنوا صداقات قويّة من خلال مشاركتهم في هذه المشاريع، سواء بلقائهم في المؤتمرات أو عبر محادثاتهم الليلية على الإنترنت. -### 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? +حتى لو كنت تحب كتابة الكود، فأنواع المساهمات الأخرى تُعد طريقة ممتازة للمشاركة في المشروع والتعرف على أعضاء المجتمع الآخرين. بناء هذه العلاقات سيفتح أمامك فرصًا للعمل على أجزاء أخرى من المشروع. +### هل تحب تنظيم الأحداث (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 did for 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) +* أعِد هيكلة التصاميم لتحسين قابلية استخدام المشروع +* نفّذ أبحاث تجربة المستخدم (user research) لإعادة تصميم هيكل التنقّل(navigation structure) والقوائم، [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability) +* أنشئ Style Guide لمساعدة المشروع على الحفاظ على تصميم بصري متّسق +* صمّم رسومات للt-shirts أو شعارًا جديدًا للمشروع، [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) -### Do you like to write? +### هل تحب الكتابة؟ -* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151) -* Curate a folder of examples showing how the project is used -* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/) -* Write tutorials for the project, [like PyPA's contributors did](https://packaging.python.org/) -* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) +* اكتُب وطوّر توثيق المشروع, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151) +* نظّم مجلدًا يحتوي على أمثلة توضح كيفية استخدام المشروع +* أطلِق نشرة إخبارية للمشروع، أو نظّم أبرز المحتويات من قائمة البريد الإلكتروني, [like @opensauced did for their product](https://news.opensauced.pizza/about/) +* اكتب شروحات (Tutorials) للمشروع, [like PyPA's contributors did](https://packaging.python.org/) +* اكتب ترجمة لتوثيق المشروع, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) -### 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? +* اربط المشاكل المكررة واقترح تسميات جديدة للمشاكل (Issue Labels)، للحفاظ على تنظيم المشروع +* راجع المشاكل المفتوحة (Open Issues)، واقترح إغلاق المشاكل القديمة, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) +* اطرح أسئلة توضيحية على المشاكل التي فُتحت مؤخرًا لدفع النقاش قدمًا. -* 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? +* ابحث عن مشكلة مفتوحة لتعمل عليها, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* اسأل إذا كان بإمكانك المساعدة في كتابة ميزة جديدة +* أتمتة إعداد المشروع(Project Setup) +* تحسين الأدوات أو الاختبارات (Tooling and Testing) -* 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? +* أجب عن الأسئلة المتعلقة بالمشروع، على سبيل المثال: Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) أوReddit +* أجب على أسئلة الأشخاص المتعلقة بالمشاكل المفتوحة +* ساعد في إدارة ومراقبة قنوات التواصل والمجتمعات التقنية -* 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! +* اجع الكود في مساهمات الآخرين +* اكتب شروحات حول كيفية استخدام المشروع +* اعرض الإشراف أو التوجيه على مساهم آخر, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) -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: +رغم أن مصطلح (Open Source) غالبًا ما يشير إلى البرمجيات، إلا أنه يمكنك المساهمة في أي شيء تقريبًا. هناك كتب، وصفات، قوائم، ودروس يتم تطويرها كمشاريع مفتوحة المصدر. +على سبيل المثال : * @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) * @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates * @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) -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 +## التعرف على مشروع جديد -## 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. @@ -436,7 +435,7 @@ Before you open an issue or pull request, or ask a question in chat, keep these **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. @@ -458,7 +457,7 @@ If you want to make a substantial contribution, open an issue to ask before work

-### Opening an issue +### (issue) الإبلاغ عن مشكلة You should usually open an issue in the following situations: @@ -472,7 +471,7 @@ Tips for communicating on issues: * **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 +### (pull request) فتح طلب دمج You should usually open a pull request in the following situations: @@ -492,11 +491,11 @@ If the project is on GitHub, here's how to submit a pull request: 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 your contribution +## ماذا يحدث بعد تقديم مساهمتك؟ Before we start celebrating, one of the following will happen after you submit your contribution: -### 😭 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. @@ -506,7 +505,7 @@ If you haven't gotten a response in over a week, it's fair to politely respond i If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. -### 🚧 Someone requests changes to your contribution +### 🚧 أحدهم يطلب إجراء تعديلات على مساهمتك 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. @@ -514,14 +513,15 @@ When someone requests changes, be responsive. They've taken the time to review y If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). -### 👎 Your contribution doesn't get accepted +### 👎 لم تُقبَل مساهمَتَك Your contribution 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/_data/locales/ar.yml b/_data/locales/ar.yml index 3b90db7cc08..7c562651504 100644 --- a/_data/locales/ar.yml +++ b/_data/locales/ar.yml @@ -4,8 +4,8 @@ ar: about: عن المشروع contribute: ساهِم index: - lead: "البرمجيات مفتوحة المصدر يصنعها أشخاص مثلك تمامًا، تعلّم كيف تطلِق مشروعَك وتُنمّيه" - opensourcefriday: "إنه يوم الجمعة! خصّص بضع ساعات للمساهمة في البرمجيات التي تستخدمها وتحبها" + lead: "البرمجيات مفتوحة المصدر يطورها أشخاص مثلك تمامًا، تعلّم كيف تطلِق مشروعَك وتُنمّيه" + opensourcefriday: "إنه يوم الجمعة، خصّص بضع ساعات للمساهمة في البرمجيات التي تستخدمها وتحبها" article: table_of_contents: جدول المحتويات back_to_all_guides: رجوع للأدلة From a3a713afe2b85b2a7384a07513728d9b5dcab524 Mon Sep 17 00:00:00 2001 From: afnan Date: Thu, 23 Oct 2025 15:29:57 +0300 Subject: [PATCH 5/9] Add a arabic translation to best-practices --- _articles/ar/best-practices.md | 270 +++++++++++++++++---------------- 1 file changed, 141 insertions(+), 129 deletions(-) diff --git a/_articles/ar/best-practices.md b/_articles/ar/best-practices.md index 6774e795a1d..4a8858d2f5c 100644 --- a/_articles/ar/best-practices.md +++ b/_articles/ar/best-practices.md @@ -1,7 +1,7 @@ --- lang: ar -title: Best Practices for Maintainers -description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community. +title: أفضل الممارسات للمحافظين +description: تسهيل حياتك كمحافظ على مشروع مفتوح المصدر، من توثيق العمليات إلى الاستفادة من مجتمعك. class: best-practices order: 5 image: /assets/images/cards/best-practices.png @@ -10,271 +10,283 @@ 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. +## ما معنى أن تكون Maintainer (مسؤول عن مشروع) ؟ -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. + إذا كنت مسؤولًا عن مشروع open source يستخدمه عدد كبير من الناس، فمن المؤكد أنك لاحظت أنك أصبحت تقوم بـ coding أقل، وتقضي وقتًا أكثر في الرد على issues المشاكل والبلاغات . -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. +في بدايات المشروع، تكون لا تزال تجرب أفكارًا جديدة وتتخذ قرارات بناءً على ما ترغب فيه. ومع نمو المشروع وزيادة شعبيته، ستجد نفسك تعمل أكثر مع users و contributors -## Documenting your processes +إن الحفاظ على مشروع بطريقة صحيحة يتطلب منك أكثر من مجرد code. غالبًا ما تكون هذه ال tasks غير متوقعة، لكنها مهمة جدًا لنمو المشروع، تمامًا مثل الكود. -Writing things down is one of the most important things you can do as a maintainer. +لقد جمعنا لك هنا بعض الأمور التي تساعدك على تسهيل حياتك، بدءًا من توثيق العمليات documenting processes وصولًا إلى كيفية الاستفادة بشكل صحيح من community المحيط بمشروعك. -Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask. +## دوّن (وثّق) الإجراءات الخاصة بك +إن تدوين الأمور يعد واحدًا من أهم الأشياء التي يمكنك القيام بها كـ +maintainer. -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. +الـ Documentation ليس فقط لتوضيح أفكارك لنفسك، بل يساعد أيضًا الآخرين على فهم ما تحتاجه أو تتوقعه منهم، حتى قبل أن يسألوا. -Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all. +عندما تكون الأمور مكتوبة، يصبح من الأسهل عليك قول "لا" عندما لا تناسب مسألة معينة الـ scope الخاص بك. وفي الوقت نفسه، يصبح من الأسهل على الآخرين الدخول والمساعدة. فأنت لا تعرف من قد يقرأ أو يستخدم مشروعك. -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. +حتى لو لم تكتب فقرات كاملة، فإن تدوينها كنقاط سريعة bullet points أفضل من عدم كتابة أي شيء على الإطلاق. -### Write down your project's vision +وتذكّر دائمًا أن تحافظ على الـ documentation محدثًا up-to-date. وإذا لم تتمكن من القيام بذلك دائمًا، فاحذف التوثيق القديم أو وضح أنه قديم outdated، حتى يعرف الـ contributors أن التحديثات مرحّب بها. -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. +### اكتب رؤية (Vision) مشروعك +ابدأ بكتابة أهداف مشروعك. أضفها في ملف الـ README، أو أنشئ ملفًا منفصلًا وسمّه VISION. إذا كانت هناك أي عناصر أخرى قد تساعد، مثل "خارطة طريق" للمشروع project roadmap، اجعلها public أيضًا. -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). +عندما تمتلك رؤية واضحة ومكتوبة، فإن ذلك يجعلك مركّزًا ويساعدك على تجنّب ما يُعرف بـ +"scope creep" الزحف بالنطاق الذي يحدث نتيجة مساهمات الآخرين. + + +كمثال، اكتشف @lord أن وجود رؤية للمشروع ساعده على تحديد أي الطلبات تستحق أن يقضي وقتَه عليها. وكـ maintainer جديد، ندم على عدم التزامه بـ scope مشروعه عندما تعامل مع أول feature request لمشروع [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. +### وضّح توقعاتك Expectations -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. +كتابة القوانين Rules أمر مرهق أحيانًا. قد تشعر أحيانًا وكأنك "شرطي" يراقب تصرفات الآخرين أو أنك تفسد الجو المرح. +لكن الحقيقة أن القوانين الجيدة، عندما تُكتب وتُطبق بعدل، تمنح الـ maintainers القوة. فهي تمنعك من الانجرار للقيام بأمور لا ترغب فيها. -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. +إذا كانت إدارتك للمشروع part-time أو مجرد تطوع كامل volunteered، كن صريحًا بشأن مقدار الوقت المتاح لديك. هذا لا يعني الوقت الذي تعتقد أن المشروع يحتاجه، ولا الوقت الذي يريدك الآخرون أن تقضيه فيه. -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"_) +* كيفية مراجعة المساهمات contribution وقبولها:( هل تحتاج إلى tests ؟ هل يجب تعبئة issue template نموذج بلاغ ؟ ) +* أنواع المساهمات التي تقبلها:( هل تريد المساعدة في جزء معين من كود المشروع فقط؟ ) +* متى يكون من المقبول متابعتك أو تذكيرك:( مثلًا، "يمكن توقع رد من مسؤول المشروع خلال 7 أيام. إذا لم تسمع شيئًا بعد هذا الوقت، من المقبول تمامًا إرسال ping في النقاش." ) +* مقدار الوقت الذي تخصصه للمشروع:( مثلًا، "نخصص حوالي 5 ساعات في الأسبوع لهذا المشروع." ) -[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), 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. +ومن الأمثلة للمشاريع التي لها قواعد أساسية للمحافظين والمساهمين :[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) -### Keep communication public +### اجعل التواصل 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. +لا تنسَ أن تعمل document لتفاعلاتك أيضًا. قدر ما تستطيع، اجعل التواصل الذي يخص مشروعك public. إذا حاول أحدهم التواصل معك على الخاص لمناقشة feature request أو احتاج support، فبكل أدب وجّهه إلى قناة تواصل علنية، مثل mailing list (قائمة بريدية) أو 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. +إذا جلست مع maintainers آخرين، أو اتخذتم قرارًا كبيرًا على الخاص، فقُم بتوثيق هذه النقاشات بشكل public، حتى ولو فقط بنشر notes الخاصة بك. -That way, anybody who joins your community will have access to the same information as someone who's been there for years. +بهذه الطريقة، أي شخص جديد ينضم إلى الـ community الخاص بك سيحصل على نفس المعلومات التي يمتلكها الشخص الموجود منذ سنوات. -## 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. +أحد أهم الأماكن التي ستتدرب فيها على قول لا هو قائمة القضايا issue وطلبات السحب pull request. كمحافظ على المشروع، ستتلقى حتماً اقتراحات قد لا ترغب في قبولها. -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. +لا تترك مساهمة لا ترغب بها مفتوحة فقط لأنك تشعر بالذنب أو بدافع اللطف. مع مرور الوقت، تراكم issues و PRs غير المردود عليها سيجعل العمل على مشروعك أكثر توترًا ويخلق شعورًا بالرهبة. -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). +من الأفضل أن تقوم بإغلاق المساهمات التي تعلم مسبقًا أنك لن تقبلها، وبشكل فوري. وإذا كان مشروعك يعاني بالفعل من backlog كبير، فإن @steveklabnik يقدّم نصائح ممتازة حول [كيفية إجراء triage للـ issues بطريقة فعّالة](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! +أيضًا، تجاهل المساهمات يرسل إشارة سلبية إلى الـ community. المشاركة في مشروع مفتوح المصدر قد تكون خطوة مخيفة، خصوصًا إذا كانت هذه أول تجربة للشخص. حتى إن لم تقبل المساهمة، فمن المهم الاعتراف بجهد صاحبها وشكره على اهتمامه، فمجرد مشاركته هو بمثابة مجاملة كبيرة للمشروع! -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** +* **اشكرهم** على مساهمتهم. +* **اشرح لهم سبب عدم توافقها** مع نطاق المشروع **scope**، وقدّم اقتراحات واضحة للتحسين إن أمكن. كن لطيفًا، لكن حازمًا. +* **ضع رابطًا إلى التوثيق** المناسب **documentation** إن كان متوفرًا. إذا لاحظت وصول طلبات متكررة لأمور لا ترغب في قبولها، أضفها إلى التوثيق لتجنّب تكرار الشرح. +* **قم بإغلاق الطلب**. -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](https://github.com/celery/celery/) عن خطأ متعلق بـ Windows، قام **@berkerpeksag** بالرد بطريقة واضحة: -![Celery screenshot](/assets/images/best-practices/celery.png) +![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/): +إذا شعرت بأن فكرة قول "**لا**" **terrifies**، فأنت لست وحدك. كما قالت **@jessfraz**: -> 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. +> "لقد تحدثت مع **maintainers** من عدة مشاريع **open source** مثل Mesos, Kubernetes, Chromium، واتفقوا جميعًا على أن من أصعب المهام كونك **maintainer** هو قول ’لا‘ على **patches** لا ترغب بها." -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. +لا تشعر بالذنب إن لم ترغب في قبول مساهمة شخص ما. أول قاعدة في الـ **open source**، وفقًا لما ذكره **@shykes**: +_"الـ 'No' مؤقتة، أما الـ 'Yes' فهي للأبد."_ من الطبيعي أن تتعاطف مع حماس الآخرين، لكن رفض المساهمة **contribution** لا يعني رفض الشخص الذي قدمها. -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. +في النهاية إذا لم تكن المساهمة بالجودة المطلوبة، فأنت **غير ملزم under no obligation** بقبولها. كن لطيفًا و **responsive** مع كل من يساهم في مشروعك، لكن لا تقبل إلا ال**changes** التي تؤمن حقًا بأنها ستجعل مشروعك أفضل. كلما مارست قول "**لا**" أكثر، أصبح الأمر أسهل. **Promise.** -### Be proactive +### كن 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. +لتقليل كمية المساهمات غير المرغوب فيها من البداية، قم بشرح process مشروعك لتقديم وقبول المساهمات في ملف contributing guide دليل المساهمة. -If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example: +إذا لاحظت وصول مساهمات low-quality بشكل متكرر، اجعل من الضروري أن يقوم contributors ببعض الخطوات المسبقة، مثل: -* Fill out an issue or PR template/checklist -* Open an issue before submitting a PR +* تعبئة template للـ issue أو الـ PR، أو استخدام قائمة تدقيق. +* فتح issue (بلاغ) قبل تقديم PR (طلب دمج). -If they don't follow your rules, close the issue immediately and point to your documentation. +إذا لم يلتزموا بالقواعد، قم بإغلاق الـ issue فورًا ووجّههم إلى الـ 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. +رغم أن هذه الطريقة قد تبدو unkind في البداية، إلا أن كونك proactive مفيد للطرفين. فهو يقلل من احتمال أن يضع شخص ما ساعات طويلة من العمل الضائع على pull request لن يتم قبوله، ويسهّل إدارة ضغط العمل الخاص بك. -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. +أحيانًا، عندما تقول "لا"، قد يغضب المساهم المحتمل أو ينتقد قرارك. إذا أصبح سلوكه عدائيًا hostile، [اتخذ خطوات لتهدئة الوضع](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) أو حتى قم بإزالته من الـ community الخاص بك، إذا لم يكن راغبًا في التعاون بشكل بنّاء constructively. -### Embrace mentorship +### تبنَّ نهج الـ 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. +قد يقوم أحد الأعضاء في الـ community بتقديم contributions متكررة لا تتماشى مع standards المشروع. هذا قد يكون محبطًا للطرفين بسبب تكرار حالات الرفض. -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. +إذا لاحظت أن هذا الشخص متحمّس للمشروع ولكنه يحتاج إلى مزيد من polish، فتحلَّ بالصبر. اشرح له بوضوح في كل مرة سبب عدم توافق مساهمته مع expectations المشروع. حاول توجيهه نحو task أسهل أو أقل غموضًا، مثل issue تحمل وسم "good first issue" ليبدأ بالتدرّج. وإن كان لديك وقت، فكّر في منحه mentoring خلال أول مساهمة له، أو اطلب من أحد أعضاء الـ community مساعدته في ذلك. -## Leverage your community +## استفد من قوة الـ 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. +لست مضطرًا للقيام بكل شيء بنفسك. وُجدت الـ community من أجل دعم المشروع! حتى لو لم يكن لديك مساهمون نشطون بعد، لكن لديك عدد كبير من users، فيمكن توجيههم للمساعدة. -### Share the workload +### شارك الـ 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. +إحدى الطرق لجذب contributors جدد هي تحديد issues بسيطة مناسبة للمبتدئين عبر وضع label واضح عليها. عندها سيقوم GitHub بإبراز هذه issues في أماكن مختلفة، مما يزيد من 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. +عندما تلاحظ contributors جدد يقدمون مساهمات متكررة، قدّر جهودهم من خلال منحهم responsibility أكبر. ولا تنسَ توثيق كيفية التطور داخل المشروع والوصول إلى leadership roles لمن يرغب بذلك. -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). +تشجيع الآخرين على مشاركة ownership في المشروع يمكن أن يقلّل من workload عنك بشكل كبير، كما حدث مع المشروع p5.js الخاص بـ @lmccart. -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! +إذا احتجت إلى الابتعاد عن مشروعك أو اضطررت إلى step away عن مشروعك، سواء لفترة hiatus مؤقتة أو بشكل permanently دائم، فلا يوجد أي شعور بالـ shame في أن تطلب من شخص آخر أن take over تولّي المسؤولية بدلاً منك. -@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: +إذا كان هناك من هو متحمّس لـ direction المشروع، يمكنك منحه commit access أو تسليم الـ control الإداري رسميًا لشخص آخر. وإذا قام أحدهم بعمل fork للمشروع ويقوم بـ maintaining نشط له في مكان آخر، فمن الجيد أن تضع link لهذا الـ fork من مشروعك الأصلي. من الرائع أن هناك أشخاصًا يريدون لمشروعك أن يبقى live on! -> 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 اكتشف أن توثيق الـ vision لمشروعه Dokku ساعد في استمرار تحقيق الأهداف حتى بعد ابتعاده عن المشروع: -### Let others build the solutions they need +> "كتبت صفحة wiki أوضّح فيها ما أريد ولماذا. ولدهشتي، بدأ الـ maintainers بتحريك المشروع في هذا الاتجاه! هل حدث تمامًا كما كنت سأفعله؟ ليس دائمًا. لكنه قرّب المشروع أكثر نحو الرؤية التي وضعتها." -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. +إذا كان لدى مساهم محتمل رأي مختلف حول ما ينبغي أن يقوم به مشروعك، يمكنك "encourage" تشجيعه بلطف للعمل على fork خاص به. + +الـ Forking ليس أمرًا سيئًا. القدرة على copy وmodify المشاريع هي واحدة من أقوى مزايا open source. تشجيع أعضاء الـ community على العمل في fork خاص بهم يمكن أن يوفر لهم creative outlet يحتاجونه، دون أن يتعارض مع vision مشروعك. +نفس الأمر ينطبق على المستخدم الذي يحتاج حلًا لا تتوفر لديك الموارد الكافية لبنائه. تقديم APIs وcustomization hooks يمكن أن يساعد الآخرين على تلبية احتياجاتهم بأنفسهم دون تعديل المصدر مباشرة. @orta وجد أن تشجيع plugins لـ CocoaPods أدى إلى بعض من أكثر الأفكار إثارة: -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 +### طلب tests وفحوصات أخرى لتحسين جودة الكود -One of the most important ways you can automate your project is by adding tests. +إحدى أهم طرق أتمتة مشروعك هي إضافة 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. +تساعد tests المساهمين على الشعور بالثقة بعدم كسر أي شيء، كما تسهل عليك مراجعة وقبول المساهمات بسرعة. كلما كنت أكثر استجابة، كان مجتمعك أكثر تفاعلًا. -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. +قم بإعداد automatic tests لتعمل على جميع المساهمات الواردة، وتأكد من أنه يمكن تشغيلها محليًا بسهولة من قبل المساهمين. اجعل كل مساهمة تمر عبر tests قبل تقديمها، لتضع معيارًا أدنى للجودة. تساعد required status checks على GitHub في ضمان عدم دمج أي تغيير دون اجتياز tests. -If you add tests, make sure to explain how they work in your CONTRIBUTING file. +إذا أضفت tests، تأكد من شرح كيفية عملها في ملف 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 them. +الأمر الجيد في إدارة مشروع مشهور هو أن مسؤولين آخرين ربما واجهوا مشاكل مشابهة ووجدوا لها حلولًا. -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: +هناك [variety of tools](https://github.com/showcases/tools-for-open-source) متاحة لمساعدتك على أتمتة بعض جوانب عمل الصيانة. بعض الأمثلة: -* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases -* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests -* [Danger](https://github.com/danger/danger) helps automate code review -* [no-response](https://github.com/probot/no-response) closes issues where the author hasn't responded to a request for more information -* [dependabot](https://github.com/dependabot) checks your dependency files every day for outdated requirements and opens individual pull requests for any it finds +* [semantic-release](https://github.com/semantic-release/semantic-release) لأتمتة الإصدارات +* [mention-bot](https://github.com/facebook/mention-bot) لذكر المراجعين المحتملين في pull requests +* [Danger](https://github.com/danger/danger) يساعد في أتمتة مراجعة الكود +* [no-response](https://github.com/probot/no-response) يغلق القضايا التي لم يرد فيها المؤلف على طلب معلومات إضافية +* [dependabot](https://github.com/dependabot) يتحقق يوميًا من ملفات الاعتماديات ويفتح pull requests لأي تحديثات قديمة -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. +بالنسبة لتقارير الأخطاء والمساهمات الشائعة، لدى GitHub [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates) يمكنك إعدادها لتسهيل التواصل معك. @TalAter أنشأ [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) لمساعدتك في كتابة هذه القوالب. -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. +لإدارة إشعارات البريد الإلكتروني، يمكنك إعداد [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) لتنظيمها حسب الأولوية. -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. +إذا أردت التقدم أكثر، يمكن لدلائل الأسلوب وlinters توحيد مساهمات المشروع وجعل مراجعتها وقبولها أسهل. -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. +إذا لم تكن متأكدًا من الأدوات المناسبة، انظر إلى ما يفعله المشاريع الشهيرة الأخرى، خصوصًا في نفس النظام البيئي الخاص بك. على سبيل المثال، كيف تبدو عملية المساهمة في وحدات Node الأخرى؟ استخدام أدوات مماثلة سيجعل عملية المساهمة أكثر ألفة للمساهمين المستهدفين. -## 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. +ربما كان العمل في open source مصدرًا للمتعة بالنسبة لك. ربما بدأ الآن يثير شعورًا بالتجنب أو الذنب. -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. +قد تشعر بالإرهاق أو بالخوف عند التفكير في مشاريعك، وفي الوقت نفسه تتراكم القضايا وpull requests. -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. +الإرهاق burnout قضية حقيقية وشائعة في العمل المفتوح المصدر، خاصة بين المسؤولين. كمحافظ على المشروع، سعادتك شرط أساسي لاستمرار أي مشروع open source. -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. +وبالرغم من أن هذا بديهي، خذ استراحة! لا تنتظر حتى تشعر بالإرهاق لتأخذ عطلة. @brettcannon، مطور أساسي في Python، قرر أخذ [month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) بعد 14 سنة من العمل التطوعي في OSS. -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. +أحيانًا يكون من الصعب أخذ استراحة من العمل في open source عندما تشعر أن الجميع يحتاج إليك. قد يحاول البعض حتى جعلك تشعر بالذنب إذا ابتعدت قليلًا. -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. +أخذ الاستراحات لا يقتصر على الإجازات فقط. إذا كنت لا ترغب في العمل على open source في عطلات نهاية الأسبوع أو خلال ساعات عملك، ضع هذه التوقعات بوضوح للآخرين حتى يعرفوا عدم إزعاجك. -## 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. +إدارة مشروع مشهور تتطلب مهارات مختلفة عن مراحل النمو الأولى، لكنها ليست أقل مكافأة. كمحافظ على المشروع، ستكتسب خبرة في القيادة والمهارات الشخصية على مستوى نادر أن يحصل عليه معظم الناس. ورغم أن الأمر قد يكون صعبًا أحيانًا، فإن وضع حدود واضحة وأخذ فقط ما تستطيع تحمله سيساعدك على البقاء سعيدًا، متجدد النشاط، ومنتجًا. +
\ No newline at end of file From 7c5e990e5d97789e8c90d89ee28f410290936dda Mon Sep 17 00:00:00 2001 From: mohammedabusamra04 Date: Fri, 24 Oct 2025 14:43:39 +0300 Subject: [PATCH 6/9] Mohammed Work --- _articles/ar/code-of-conduct.md | 106 +++++++-------- _articles/ar/leadership-and-governance.md | 149 +++++++++++++--------- 2 files changed, 140 insertions(+), 115 deletions(-) diff --git a/_articles/ar/code-of-conduct.md b/_articles/ar/code-of-conduct.md index 6a08e69b266..b0a43958209 100644 --- a/_articles/ar/code-of-conduct.md +++ b/_articles/ar/code-of-conduct.md @@ -1,7 +1,7 @@ --- lang: ar -title: Your Code of Conduct -description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. +title: مدونة السلوك الخاصة بمشروعك +description: عزِّز السلوك الإيجابي والبنّاء في مجتمعك من خلال اعتماد وتطبيق مدونة سلوك. class: coc order: 8 image: /assets/images/cards/coc.png @@ -10,105 +10,105 @@ related: - leadership --- -## Why do I need a code of conduct? +## لماذا تحتاج إلى مدونة سلوك ؟ _( 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. +كلما أمكن، اعتمد على نماذج موجودة مسبقًا بدل أن تصنع كل شيء من الصفر. على سبيل المثال، [اتفاقية المساهمين](https://contributor-covenant.org/) هي مدونة سلوك جاهزة يمكن دمجها مباشرة في مشروعك، وقد تبناها آلاف المشاريع المفتوحة المصدر مثل Kubernetes وRails وSwift. -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. + [مدونة سلوك Django](https://www.djangoproject.com/conduct/) و [مدونة السلوك للمواطنين](https://web.archive.org/web/20200330154000/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. - -## 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. [اشرح ذلك في مشروعهم](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.* +> يمكن الإبلاغ عن أي سلوك مسيء أو تحرشي أو غير مقبول عبر إرسال بريد إلكتروني إلى: **khmer-project@idyll.org** والذي يذهب فقط إلى C. Titus Brown وMichael R. Crusoe. للإبلاغ عن أي مشكلة تتعلق بأحدهما، يرجى إرسال البريد الإلكتروني إلى: **Judi Brown Clarke, Ph.D.** إلى مدير التنوع في مركز 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). +للحصول على مصدر إلهام، يمكنك الاطلاع على مدونة سلوك Django.[دليل تطبيق القواعد](https://www.djangoproject.com/conduct/enforcement-manual/) +(قد لا يكون من الضروري أن يكون لديك دليل شامل بهذا الشكل، فهذا يعتمد على حجم مشروعك). -## 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. +* **تواصل مع الشخص المعني بشكل خاص** لتوضيح كيف أثّر سلوكهم سلبًا على الآخرين. قد ترغب في استخدام وسيلة تواصل خاصة إذا كان الموقف يتضمن معلومات شخصية حساسة. إذا تواصلت مع الشخص على انفراد، فمن الجيد إشراك (CC) من أبلغوا عن الموقف أولًا، ليعرفوا أنك اتخذت إجراءً. استأذن المبلغ قبل إضافته في الـ CC. -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. +عندما يبدو المشروع عدائيًا أو غير مرحب، حتى لو كان هناك شخص واحد فقط يُسمح له بسلوك سيء، فإنك تخاطر بخسارة العديد من المساهمين الآخرين، قد يكون بعضهم لم تلتقِ بهم من قبل. قد لا يكون من السهل دائمًا تبني أو تطبيق مدونة السلوك، لكن خلق بيئة مرحبة سيساعد مجتمعك على النمو والتطور. \ No newline at end of file diff --git a/_articles/ar/leadership-and-governance.md b/_articles/ar/leadership-and-governance.md index a685a704a6e..c3c2264da33 100644 --- a/_articles/ar/leadership-and-governance.md +++ b/_articles/ar/leadership-and-governance.md @@ -1,7 +1,7 @@ --- lang: ar -title: Leadership and Governance -description: Growing open source projects can benefit from formal rules for making decisions. +title: القيادة والحوكمة +description: المشاريع مفتوحة المصدر التي تتوسع مع الوقت قد تستفيد كثيرًا من وجود قواعد واضحة ومنظمة تساعدها في اتخاذ القرارات. class: leadership order: 6 image: /assets/images/cards/leadership.png @@ -10,147 +10,172 @@ 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** +* **المشرف _( القائم على المشروع )_** +* **المساهم** +* **المصرّح له بالتحديث** -**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 Request)، أو أي فرد يضيف قيمة حقيقية للمشروع — سواء من خلال فرز المشكلات وتنظيمها، أو كتابة الأكواد، أو حتى تنظيم الفعاليات الخاصة بالمجتمع. +وفي بعض المشاريع، يُعتبر المساهم ببساطة أي شخص تم قبول إحدى مساهماته ودمجها في المستودع، وهي ربما أضيق تعريف ممكن للمساهم. -**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), على سبيل المثال, [يستضيف ساعات مكتبية أسبوعية](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. +بمجرد أن تحدد أدوار القيادة، لا تنسَ توثيق كيفية الوصول إليها! ضع عملية واضحة لكيفية أن يصبح الشخص مشرفًا (maintainer) أو ينضم إلى لجنة فرعية (subcommittee) في مشروعك، واكتب ذلك في ملف 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، فكر في نقل المشروع من حسابك الشخصي إلى منظمة (Organization) وإضافة على الأقل مشرف احتياطي واحد. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) تجعل إدارة الصلاحيات والمستودعات المتعددة أسهل، وتحمي إرث مشروعك من خلال [الملكية المشتركة](../building-community/#share-ownership-of-your-project). -## When should I give someone commit access? +## متى يجب أن أمنح شخصًا صلاحية التعديل (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، يمكنك استخدام [الفروع المحمية](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. +* **BDFL:** BDFL اختصار لعبارة "المستبد الخيّر مدى الحياة". في هذا الهيكل، يكون لشخص واحد (عادة مؤلف المشروع الأصلي) الكلمة الأخيرة في جميع القرارات الكبرى للمشروع. [بايثون](https://github.com/python) يُعد مثال Python كلاسيكيًا على هذا الهيكل. +غالبًا ما تكون المشاريع الصغيرة BDFL بشكل افتراضي، نظرًا لوجود مشرف واحد أو مشرفين فقط. +كما أن المشروع الذي نشأ داخل شركة قد يندرج أيضًا تحت فئة BDFL. -* **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. +* **الحوكمة على أساس الجدارة:** **(ملاحظة: مصطلح "meritocracy" يحمل دلالات سلبية لدى بعض المجتمعات وله [تاريخ اجتماعي وسياسي معقد](http://geekfeminism.wikia.com/wiki/Meritocracy).)** في هيكل الحوكمة على أساس الجدارة (Meritocracy)، يُمنح المساهمون النشطون في المشروع (أي الذين يظهرون "جدارتهم") دورًا رسميًا في اتخاذ القرارات. +عادةً ما تُتخذ القرارات بناءً على إجماع التصويت البحت. +تم تطوير مفهوم الحوكمة على أساس الجدارة بواسطة[مؤسسة Apache](https://www.apache.org/); [جميع مشاريع Apache](https://www.apache.org/index.html#projects-list) تتبع نموذج الحوكمة على أساس الجدارة. ويمكن تقديم المساهمات فقط من قبل أفراد يمثلون أنفسهم، وليس من قبل أي شركة. -* **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: +* **Liberal contribution:** في نموذج Liberal contribution، يُعترف بالأشخاص الذين يقومون بأكبر قدر من العمل على أنهم الأكثر تأثيرًا، لكن هذا الاعتراف يعتمد على العمل الحالي وليس على المساهمات التاريخية. +تُتخذ القرارات الكبرى في المشروع بناءً على عملية البحث عن التوافق (مناقشة القضايا الكبرى) بدلاً من التصويت البحت، مع السعي لإشراك أكبر عدد ممكن من وجهات نظر المجتمع. +من الأمثلة الشهيرة على المشاريع التي تستخدم نموذج Liberal contribution: [Node.js](https://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). + +أي نموذج يجب أن تستخدمه؟ القرار يعود إليك! كل نموذج له مميزاته وتحدياته. +وعلى الرغم من أن هذه النماذج قد تبدو مختلفة تمامًا في البداية، إلا أن كلها تشترك في كثير من النقاط أكثر مما يبدو. +إذا كنت مهتمًا بتبني أحد هذه النماذج، يمكنك الاطلاع على هذه القوالب: * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) * [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) -## 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، على سبيل المثال)، لكن هذه الأموال لن تكون قابلة للخصم الضريبي إلا إذا كنت منظمة غير ربحية مؤهلة (مثل 501c3 إذا كنت في الولايات المتحدة). -Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://www.eclipse.org/org/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. +كثير من المشاريع لا ترغب في تحمل عناء إنشاء منظمة غير ربحية، لذلك يلجأون إلى راعي مالي غير ربحي بدلاً من ذلك. يقوم الراعي المالي بقبول التبرعات نيابة عنك، وعادةً مقابل نسبة معينة من قيمة التبرع. [مؤسسة المحافظة على حرية البرمجيات](https://sfconservancy.org/), [مؤسسة Apache](https://www.apache.org/), [مؤسسة Eclipse](https://www.eclipse.org/org/), [مؤسسة Linux](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 للبرمجيات](https://www.python.org/psf/) يساعد في دعم [PyPI](https://pypi.org/), مدير الحزم الخاص بـ Python، و [Node.js Foundation](https://foundation.nodejs.org/) يساعد في دعم [Express.js](https://expressjs.com/), إطار عمل قائم على Node +Footer From 6fcf8792ce085d96356b6d2d10a32b0d6c4867f1 Mon Sep 17 00:00:00 2001 From: lenovo Date: Fri, 24 Oct 2025 17:32:35 +0300 Subject: [PATCH 7/9] Maha Work --- _articles/ar/finding-users.md | 122 ++++++++++++++------------ _articles/ar/getting-paid.md | 161 +++++++++++++++++----------------- 2 files changed, 147 insertions(+), 136 deletions(-) diff --git a/_articles/ar/finding-users.md b/_articles/ar/finding-users.md index 1d6b8ce7885..2e23b74b30b 100644 --- a/_articles/ar/finding-users.md +++ b/_articles/ar/finding-users.md @@ -1,7 +1,7 @@ --- lang: ar -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 order: 3 image: /assets/images/cards/finding.png @@ -10,139 +10,147 @@ 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: +تذكر أن الأشخاص ينخرطون كمستخدمين، ويصبحون في النهاية مساهمين، لأن مشروعك يحل مشكلة لهم. +عندما تفكر في رسالة مشروعك وقيمته، حاول أن تنظر إليهما من منظور ما قد يرغب فيه المستخدمون والمساهمون. + +على سبيل المثال، يستخدم @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. +للتعمق أكثر في الرسائل، راجع تمرين Mozilla ["الشخصيات والمسارات"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) لتطوير شخصيات المستخدمين. -## 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. +**امتلك حساب واضح للترويج لعملك.** يعد حساب Twitter أو عنوان GitHub URL أو قناة 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"_. +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), قال أحد مؤسسي Django، إن إنشاء موقع ويب كان _"أفضل شيء فعلناه مع Django في الأيام الأولى"_. -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. +إذا كان مشروعك مستضافًا على GitHub، فيمكنك استخدام [GitHub Pages](https://pages.github.com/) لإنشاء موقع ويب بسهولة. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), و [Middleman](https://middlemanapp.com/) هي [بعض الأمثلة](https://github.com/showcases/github-pages-examples) على مواقع ويب ممتازة وشاملة. -![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) +![الصفحة الرئيسية لـ Vagrant](/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/), [Reddit](https://www.reddit.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: +انظر إذا كان بإمكانك العثور على طرق لمشاركة مشروعك بالطرق : -* **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. +- **تعرف على المشاريع والمجتمعات مفتوحة المصدر ذات الصلة.** في بعض الأحيان، لا يتعين عليك الترويج لمشروعك بشكل مباشر. إذا كان مشروعك مثاليًا لعلماء البيانات الذين يستخدمونPython، فتعرف على مجتمع علوم بيانات Python. عندما يتعرف الناس عليك، ستنشأ فرص طبيعية للحديث عن عملك ومشاركته. +- **ابحث عن الأشخاص الذين يعانون من المشكلة التي يحلها مشروعك.** ابحث في المنتديات ذات الصلة عن الأشخاص الذين يندرجون ضمن الجمهور المستهدف لمشروعك. أجب عن سؤالهم وابحث عن طريقة لبقة، عندما يكون ذلك مناسبًا، لاقتراح مشروعك كحل. +- **اطلب التعليقات.** قدم نفسك وعملك لجمهور قد يجده مهماً ومثيراً للاهتمام. كن محدداً بشأن من تعتقد أنه سيستفيد من مشروعك. حاول إكمال الجملة التالية: ”أعتقد أن مشروعي سيساعد حقاً X، الذين يحاولون القيام بـ Y“. استمع إلى تعليقات الآخرين ورد عليها، بدلاً من مجرد الترويج لعملك. -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) +![الخطابة](/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. +
diff --git a/_articles/ar/getting-paid.md b/_articles/ar/getting-paid.md index aa2bd691dc2..16a0eea37ed 100644 --- a/_articles/ar/getting-paid.md +++ b/_articles/ar/getting-paid.md @@ -1,7 +1,7 @@ --- lang: ar -title: Getting Paid for Open Source Work -description: Sustain your work in open source by getting financial support for your time or your project. +title: الحصول على أجر مقابل العمل مفتوح المصدر +description: استمر على عملك في المصدر المفتوح من خلال الحصول على الدعم المالي مقابل وقتك أو مشروعك. class: getting-paid order: 7 image: /assets/images/cards/getting-paid.png @@ -10,168 +10,171 @@ related: - leadership --- -## Why some people seek financial support +
-Much of the work of open source is voluntary. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. +## لماذا يسعى بعض الأشخاص للحصول على الدعم المالي + +معظم الأعمال مفتوحة المصدر هي أعمال تطوعية. على سبيل المثال، قد يصادف شخص ما خطأً في مشروع يستخدمه ويقدم حلاً سريعاً له، أو قد يستمتع بالتلاعب بمشروع مفتوح المصدر في أوقات فراغه. -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. +يمكن أن يكون الحفاظ على المشاريع الشهيرة مسؤولية كبيرة، حيث يستغرق 10 أو 20 ساعة في الأسبوع بدلاً من بضع ساعات في الشهر. -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), نظرًا لأن العمل المنجز يميل لصالح أولئك الذين يتمتعون بالفعل بمزايا في الحياة، والذين يكتسبون مزايا إضافية بناءً على مساهماتهم التطوعية، في حين أن الآخرين غير القادرين على التطوع لا يحصلون على فرص لاحقًا، مما يعزز النقص الحالي في التنوع في مجتمع المصادر المفتوحة. -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. +من الأسهل الدفاع عن العمل مفتوح المصدر إذا كان صاحب العمل يستخدم المشروع بالفعل، ولكن كن مبدعًا في عرضك. ربما لا يستخدم صاحب العمل المشروع، ولكنه يستخدم Python، وتساعد صيانة مشروع Python شهير في جذب مطوري Python جدد. ربما يجعل ذلك صاحب العمل يبدو أكثر ملاءمة للمطورين بشكل عام. -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 وجدت أن برنامج المصدر المفتوح ل Facebook [أحدث فرقًا](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. +> إنه يتوافق بشكل وثيق مع ثقافة القراصنة لدينا، وكيف كان يُنظر إلى مؤسستنا. سألنا موظفينا: ”هل كنتم على علم ببرنامج البرمجيات مفتوحة المصدر في Facebook؟“. أجاب ثلثاهم بـ”نعم“. وقال نصفهم إن البرنامج ساهم بشكل إيجابي في قرارهم العمل لدينا. هذه أرقام ليست هامشية، وآمل أن يستمر هذا الاتجاه. -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/), have websites that highlight their involvement in open source +- بعض الشركات، مثل [Netflix](https://netflix.github.io/), لديهم مواقع ويب تسلط الضوء على مشاركتهم في المصادر المفتوحة -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. +المشاريع التي نشأت في شركة كبيرة، مثل [Go](https://github.com/golang) أو [React](https://github.com/facebook/react), من المرجح أيضًا أن توظف أشخاصًا للعمل على المصادر المفتوحة. -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 Sponsors](https://github.com/sponsors) +- @gaearon مول عمله في [Redux](https://github.com/reactjs/redux) من خلال [حملة التمويل الجماعي على Patreon](https://redux.js.org/) +- @andrewgodwin تمويل العمل على ترحيل مخطط Django [من خلال حملة Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) -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 الخاصة بهم [من خلال مكافأة على gitcoin](https://gitcoin.co/). +- @mamiM قامت بترجمة @MetaMask إلى اللغة اليابانية بعد [تم تمويل هذه المشكلة على شبكة 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 in new features or ideas. +قد يوجه التمويل التنظيمي إلى دفع رواتب المساهمين الحاليين، أو تغطية تكاليف تشغيل المشروع (مثل رسوم الاستضافة)، أو الاستثمار في ميزات أو أفكار جديدة. -As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. +مع تزايد شهرة المصادر المفتوحة، لا يزال العثور على تمويل للمشاريع أمراً تجريبياً، ولكن هناك بعض الخيارات الشائعة المتاحة. -### 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) -* **[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) +- **[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/cli) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. +بعض المشاريع الشهيرة، مثل [npm](https://github.com/npm/cli) و [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 Open Source Support](https://www.mozilla.org/en-US/grants/) +- **[OpenMRS](https://github.com/openmrs)** تم تمويل العمل من قبل [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +- **[Libraries.io](https://github.com/librariesio)** حصل على منحة من [مؤسسة Sloan](https://sloan.org/programs/digital-technology) +- **[مؤسسة برمجيات Python](https://www.python.org/psf/grants/)** تقدم منحًا للأعمال المتعلقة بلغة Python -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 571e882f832081e03908ada8a978647a7b08c9aa Mon Sep 17 00:00:00 2001 From: Aseel Ahmed Date: Mon, 27 Oct 2025 13:40:48 +0200 Subject: [PATCH 8/9] Added Arabic translation for some articles --- _articles/ar/best-practices.md | 2 +- _articles/ar/code-of-conduct.md | 10 +- _articles/ar/how-to-contribute.md | 293 ++++++++++++---------- _articles/ar/leadership-and-governance.md | 5 +- _data/locales/ar.yml | 2 +- 5 files changed, 170 insertions(+), 142 deletions(-) diff --git a/_articles/ar/best-practices.md b/_articles/ar/best-practices.md index 4a8858d2f5c..f07e00e133b 100644 --- a/_articles/ar/best-practices.md +++ b/_articles/ar/best-practices.md @@ -1,7 +1,7 @@ --- lang: ar title: أفضل الممارسات للمحافظين -description: تسهيل حياتك كمحافظ على مشروع مفتوح المصدر، من توثيق العمليات إلى الاستفادة من مجتمعك. +description: تسهيل حياتك كمحافظ على مشروع مفتوح المصدر، من توثيق العمليات إلى الاستفادة من مجتمعك class: best-practices order: 5 image: /assets/images/cards/best-practices.png diff --git a/_articles/ar/code-of-conduct.md b/_articles/ar/code-of-conduct.md index b0a43958209..1cbe92fe50c 100644 --- a/_articles/ar/code-of-conduct.md +++ b/_articles/ar/code-of-conduct.md @@ -1,7 +1,7 @@ --- lang: ar title: مدونة السلوك الخاصة بمشروعك -description: عزِّز السلوك الإيجابي والبنّاء في مجتمعك من خلال اعتماد وتطبيق مدونة سلوك. +description: عزِّز السلوك الإيجابي والبنّاء في مجتمعك من خلال اعتماد وتطبيق مدونة سلوك class: coc order: 8 image: /assets/images/cards/coc.png @@ -10,7 +10,9 @@ related: - leadership --- -## لماذا تحتاج إلى مدونة سلوك ؟ _( Code Of Conduct )_ +
+ +## لماذا تحتاج إلى مدونة سلوك (Code of Conduct) ؟ تُعدّ مدونة السلوك وثيقة تُحدّد التوقعات والمعايير السلوكية للمشاركين في مشروعك. إن اعتماد مدونة سلوك وتطبيقها يُسهم في خلق بيئة اجتماعية إيجابية داخل مجتمع المشروع. @@ -111,4 +113,6 @@ related: ## شجّع السلوك الذي ترغب في رؤيته في مجتمعك 🌎 -عندما يبدو المشروع عدائيًا أو غير مرحب، حتى لو كان هناك شخص واحد فقط يُسمح له بسلوك سيء، فإنك تخاطر بخسارة العديد من المساهمين الآخرين، قد يكون بعضهم لم تلتقِ بهم من قبل. قد لا يكون من السهل دائمًا تبني أو تطبيق مدونة السلوك، لكن خلق بيئة مرحبة سيساعد مجتمعك على النمو والتطور. \ No newline at end of file +عندما يبدو المشروع عدائيًا أو غير مرحب، حتى لو كان هناك شخص واحد فقط يُسمح له بسلوك سيء، فإنك تخاطر بخسارة العديد من المساهمين الآخرين، قد يكون بعضهم لم تلتقِ بهم من قبل. قد لا يكون من السهل دائمًا تبني أو تطبيق مدونة السلوك، لكن خلق بيئة مرحبة سيساعد مجتمعك على النمو والتطور. + +
\ No newline at end of file diff --git a/_articles/ar/how-to-contribute.md b/_articles/ar/how-to-contribute.md index 7ad6b59b27d..a0d6c4c2d97 100644 --- a/_articles/ar/how-to-contribute.md +++ b/_articles/ar/how-to-contribute.md @@ -1,7 +1,7 @@ --- lang: ar title: كيف تساهم في مشروع مفتوح المصدر ؟ -description: هل تريد أن تساهم في مشاريع مفتوحة المصدر؟ دليل للمبتدئين والمحترفين حول كيفية المشاركة فيها +description: هل تريد أن تساهم في مشاريع مفتوحة المصدر؟ دليل للمبتدئين والمحترفين حول كيفية المساهمة فيها class: contribute order: 1 image: /assets/images/cards/contribute.png @@ -10,6 +10,7 @@ related: - building --- +
## لماذا تساهم في مشروع مفتوح المصدر؟ @@ -141,54 +142,64 @@ related: -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. +بالنسبة لأي مساهمة تتعدى مجرد تصحيح خطأ مطبعي، فإن المساهمة في المشاريع مفتوحة المصدر تشبه الاقتراب من مجموعة غرباء في حفلة. إذا بدأت بالحديث عن حيوان اللاما بينما هم منغمسون في مناقشة حول أسماك الزينة، فغالبًا سينظرون إليك بنظرة محيرة بعض الشيء. + +قبل أن تندفع بتقديم اقتراحاتك بشكل عشوائي، ابدأ أولاً بتعلّم "قراءة الجو العام" للمناقشة. فعل ذلك يزيد من فرص أن تُلاحَظ أفكارك ويُصغَى لها +. ### مكونات المشروع مفتوح المصدر -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. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide). -* **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 like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). -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. +قد تحتوي المشاريع الأكبر أيضًا على لجان فرعية أو مجموعات عمل تركز على مهام مختلفة، مثل أدوات التطوير، وفرز المشكلات، وإدارة المجتمع، وتنظيم الفعاليات. ابحث في موقع المشروع عن صفحة الفريق (Team) +أو في المستودع عن وثائق إدارة المشروع(governance documentation) لمعرفة هذه المعلومات. -* **Issue tracker:** Where people discuss issues related to the project. -* **Pull/Merge requests:** Where people discuss and review changes that are in progress, whether it's to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml), use certain GitHub Action flows to automate and quicken their code reviews. -* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/) -* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/). +يحتوي المشروع أيضًا على وثائق. +تكون هذه الملفات عادةً موجودة في المستوى الأعلى من المستودع (أي في المجلد الرئيسي) +. +* **LICENSE:** الترخيص؛ كل مشروع مفتوح المصدر يجب أن يكون له [ترخيص مفتوح المصدر](https://choosealicense.com).إذا لم يكن للمشروع ترخيص، فهو ليس مفتوح المصدر. +* **README:** ملف الترحيب؛ هو دليل التعليمات الذي يرحب بأعضاء المجتمع الجدد ويشرح لماذا المشروع مفيد وكيفية البدء به. +* **CONTRIBUTING:** دليل المساهمة؛ بينما تساعد ملفات الREADME الناس على استخدام المشروع، فإن ملفات الCONTRIBUTING تساعد الناس على المساهمة في المشروع. يشرح أنواع المساهمات المطلوبة وكيفية سير العملية. وجود هذا الملف يشير إلى أن المشروع مُرحّب بالمساهمين الجدد. مثال جيد لدليل المساهمة الفعّال الموجود في [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide). +* **CODE_OF_CONDUCT:** قواعد السلوك؛ تحدد قواعد السلوك الأساسية لسلوك المشاركين وتساعد على خلق بيئة ودية. على الرغم من أن ليس كل مشروع يحتوي على هذا الملف، إلا أن وجوده يشير إلى أن المشروع مُرحّب بالمساهمين الجدد. +* **Other documentation:** قد تكون هناك وثائق إضافية، مثل الدروس التعليمية، الشروحات خطوة بخطوة، أو سياسات إدارة المشروع ، خصوصًا في المشاريع الكبيرة مثل : [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). + +أخيرًا، تستخدم المشاريع مفتوحة المصدر الأدوات التالية لتنظيم النقاشات. +قراءة الأرشيفات ستمنحك فكرة جيدة عن كيفية تفكير المجتمع وطريقة عمله + +* **Issue tracker:** المكان الذي يناقش فيه الناس المشاكل المتعلقة بالمشروع. +* **Pull/Merge requests:** المكان الذي يناقش فيه الناس التغييرات الجاري العمل عليها ويستعرضونها، سواء كان ذلك لتحسين سطر كود لمساهم، أو استخدام القواعد اللغوية، أو الصور، وغيرها. بعض المشاريع، مثل [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint.yml)، تستخدم بعض GitHub Action لتسريع وأتمتة مراجعات الكود. +* **Discussion forums or mailing lists:** قد تستخدم بعض المشاريع هذه القنوات للمواضيع الحوارية (على سبيل المثال، _"كيف أفعل..."_ أو _"ما رأيك في..."_ بدلاً من تقارير الأخطاء أو طلبات المزايا). بينما يستخدم البعض الآخر الـ Issue tracker لجميع المحادثات. مثال جيد على ذلك هو [CHAOSS' weekly Newsletter](https://chaoss.community/news/). +* **Synchronous chat channel:** تستخدم بعض المشاريع قنوات الدردشة (مثل Slack أو IRC) للمحادثات غير الرسمية، والتعاون، والتبادل السريع للأفكار. مثال جيد على ذلك هو [EddieHub's Discord community](http://discord.eddiehub.org/). ## إيجاد مشروع للمساهمة فيه -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 وتجد رابطًا معطلًا أو خطأً مطبعيًا. أو ربما تكون مستخدمًا جديدًا ولاحظت شيئًا لا يعمل، أو مشكلة تعتقد أنها يجب أن تكون موثقة. بدلًا من تجاهلها والمضي قدمًا، أو طلب مساعدة شخص آخر لإصلاحها، تحقق مما إذا كان بإمكانك المساهمة بالمساعدة. هذا هو جوهر مشاريع البرمجيات مفتوحة المصدر! -> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation. +> وفقًا لدراسة أجراها Igor Steinmacher وباحثون آخرون في علوم الحاسوب، فإن [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` التي تبرز الـ beginner-friendly issues التي يمكنك البدء بها. انتقل إلى الصفحة الرئيسية للمستودع على 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) @@ -227,153 +238,153 @@ You can also use one of the following resources to help you discover and contrib ### قائمة تحقّق قبل أن تساهم -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 main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) +اطلع على نشاط الـ commit على الفرع الرئيسي. على GitHub، يمكنك رؤية هذه المعلومات في تبويب Insights على الصفحة الرئيسية للمستودع، مثل [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
-Next, look at the project's issues. +بعد ذلك، اطلع على الـ issues الخاصة بالمشروع.
-Now do the same for the project's pull requests. +الآن افعل الشيء نفسه بالنسبة للـ pull requests الخاصة بالمشروع.
-**Project is welcoming** +**المشروع مرحّب بالمساهمين** -A project that is friendly and welcoming signals that they will be receptive to new contributors. +المشروع الذي يكون ودودًا ومرحّبًا يشير إلى أنه سيكون متقبلًا للمساهمين الجدد.
+ هل يشكر القائمون على المشروع الأشخاص على مساهماتهم؟ +
\ No newline at end of file diff --git a/_articles/ar/leadership-and-governance.md b/_articles/ar/leadership-and-governance.md index c3c2264da33..92d65beca97 100644 --- a/_articles/ar/leadership-and-governance.md +++ b/_articles/ar/leadership-and-governance.md @@ -1,7 +1,7 @@ --- lang: ar title: القيادة والحوكمة -description: المشاريع مفتوحة المصدر التي تتوسع مع الوقت قد تستفيد كثيرًا من وجود قواعد واضحة ومنظمة تساعدها في اتخاذ القرارات. +description: المشاريع مفتوحة المصدر التي تتوسع مع الوقت قد تستفيد كثيرًا من وجود قواعد واضحة ومنظمة تساعدها في اتخاذ القرارات class: leadership order: 6 image: /assets/images/cards/leadership.png @@ -9,6 +9,7 @@ related: - best-practices - metrics --- +
## فهم آلية الحوكمة في مشروعك المتنامي @@ -179,3 +180,5 @@ related: إذا كان مشروعك مرتبطًا ارتباطًا وثيقًا بلغة برمجة معينة أو بيئة معينة، فقد يكون هناك أيضًا مؤسسة برمجيات ذات صلة يمكنك العمل معها. على سبيل المثال، الـ [مؤسسة Python للبرمجيات](https://www.python.org/psf/) يساعد في دعم [PyPI](https://pypi.org/), مدير الحزم الخاص بـ Python، و [Node.js Foundation](https://foundation.nodejs.org/) يساعد في دعم [Express.js](https://expressjs.com/), إطار عمل قائم على Node Footer + +
\ No newline at end of file diff --git a/_data/locales/ar.yml b/_data/locales/ar.yml index 7c562651504..812379b6ca5 100644 --- a/_data/locales/ar.yml +++ b/_data/locales/ar.yml @@ -7,7 +7,7 @@ ar: lead: "البرمجيات مفتوحة المصدر يطورها أشخاص مثلك تمامًا، تعلّم كيف تطلِق مشروعَك وتُنمّيه" opensourcefriday: "إنه يوم الجمعة، خصّص بضع ساعات للمساهمة في البرمجيات التي تستخدمها وتحبها" article: - table_of_contents: جدول المحتويات + table_of_contents: قائمة المحتويات back_to_all_guides: رجوع للأدلة related_guides: أدلة ذات صلة footer: From f66e75c2132262885be2b743744b1567dfcf1951 Mon Sep 17 00:00:00 2001 From: Aseel Ahmed Date: Mon, 27 Oct 2025 13:51:20 +0200 Subject: [PATCH 9/9] Translation for some articles --- _articles/ar/finding-users.md | 2 +- _articles/ar/getting-paid.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/_articles/ar/finding-users.md b/_articles/ar/finding-users.md index 2e23b74b30b..26f36dee46c 100644 --- a/_articles/ar/finding-users.md +++ b/_articles/ar/finding-users.md @@ -1,7 +1,7 @@ --- lang: ar title: العثور على مستخدمين لمشروعك -description: ساعد مشروعك مفتوح المصدر على النمو من خلال إتاحته للمستخدمين السعداء. +description: ساعد مشروعك مفتوح المصدر على النمو من خلال إتاحته للمستخدمين السعداء class: finding order: 3 image: /assets/images/cards/finding.png diff --git a/_articles/ar/getting-paid.md b/_articles/ar/getting-paid.md index 16a0eea37ed..dd2d3e2bc19 100644 --- a/_articles/ar/getting-paid.md +++ b/_articles/ar/getting-paid.md @@ -1,7 +1,7 @@ --- lang: ar title: الحصول على أجر مقابل العمل مفتوح المصدر -description: استمر على عملك في المصدر المفتوح من خلال الحصول على الدعم المالي مقابل وقتك أو مشروعك. +description: استمر على عملك في المصدر المفتوح من خلال الحصول على الدعم المالي مقابل وقتك أو مشروعك class: getting-paid order: 7 image: /assets/images/cards/getting-paid.png