@@ -431,11 +439,11 @@ Before you open an issue or pull request, or ask a question in chat, keep these
Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way.
-If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request:
+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:
-* **Issues** are like starting a conversation or discussion
-* **Pull requests** are for starting work on a solution
-* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one
+* **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.
@@ -467,10 +475,10 @@ Tips for communicating on issues:
You should usually open a pull request in the following situations:
-* Submit trivial fixes (for example, a typo, a broken link or an obvious error)
-* Start work on a contribution that was already asked for, or that you've already discussed, in an issue
+* 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. You can always add more commits later.
+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:
@@ -478,43 +486,41 @@ If the project is on GitHub, here's how to submit a pull request:
* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.
* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.")
* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
-* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
+* **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 a contribution
-
-You did it! Congratulations on becoming an open source contributor. We hope it's the first of many.
+## What happens after you submit your contribution
-After you submit a contribution, one of the following will happen:
+Before we start celebrating, one of the following will happen after you submit your contribution:
-### 😭 You don't get a response.
+### 😭 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.
+**Don't reach out to that person privately**; remember that public communication is vital to open source projects.
-If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.
+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.
+### 🚧 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.
+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 (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over.
+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 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.
+### 🎉 Your contribution gets accepted
Hooray! You've successfully made an open source contribution!
-## You did it!
+## 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/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md
index e7be38930e1..0b8e185cef2 100644
--- a/_articles/hu/how-to-contribute.md
+++ b/_articles/hu/how-to-contribute.md
@@ -209,7 +209,6 @@ Az alábbiakban találsz néhány oldalt, amelyek segítenek abban, hogy felfede
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/hu/legal.md b/_articles/hu/legal.md
index 8edd7d79069..2762bf09b2d 100644
--- a/_articles/hu/legal.md
+++ b/_articles/hu/legal.md
@@ -134,13 +134,13 @@ Ha a céged első nyílt forráskódú projektjének publikálásán dolgozol, a
Hosszabb távon a jogi csapat többet tehet azért, hogy segítsen a vállalatnak profitálni a nyílt forráskódból és közben biztonságban tudhassa magát:
-* **Munkavállalói hozzájárulás szabályozása:** Fontold meg olyan vállalati irányelv kidolgozását, amely meghatározza, hogy a munkavállalók hogyan járulnak hozzá a nyílt forráskódú projektekhez. Az egyértelmű szabályozás csökkenti a zavart az alkalmazottak körében, és segít abban, hogy a vállalat érdekeinek megfelelően járuljanak hozzá a nyílt forráskódú projektekhez, akár munkájuk részeként, akár szabadidejükben. Jó példa erre a Rackspace féle [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Munkavállalói hozzájárulás szabályozása:** Fontold meg olyan vállalati irányelv kidolgozását, amely meghatározza, hogy a munkavállalók hogyan járulnak hozzá a nyílt forráskódú projektekhez. Az egyértelmű szabályozás csökkenti a zavart az alkalmazottak körében, és segít abban, hogy a vállalat érdekeinek megfelelően járuljanak hozzá a nyílt forráskódú projektekhez, akár munkájuk részeként, akár szabadidejükben. Jó példa erre a Rackspace féle [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
A (nyílt forráskódú) javítások (patch-ek) szellemi tulajdonának elengedése építi a munkavállaló tudásbázisát és hírnevét. Ez azt mutatja, hogy a vállalat befektet a munkavállaló fejlődésébe, valamint erősíti az önállóság és autonómia érzését. Mindezek magasabb morálhoz és a jobb munkavállalók megtartáshoz is vezetnek.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/hu/maintaining-balance-for-open-source-maintainers.md b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..b7825099585
--- /dev/null
+++ b/_articles/hu/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: hu
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the
Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As
described by the Rockwood Leadership Institute , it involves "
maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md
index b3d2cb2c763..6e25291ca99 100644
--- a/_articles/id/how-to-contribute.md
+++ b/_articles/id/how-to-contribute.md
@@ -207,7 +207,6 @@ Anda juga bisa menggunakan salah satu dari beberapa sumber daya berikut untuk me
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/id/legal.md b/_articles/id/legal.md
index a65220e36f4..d688d4cefc3 100644
--- a/_articles/id/legal.md
+++ b/_articles/id/legal.md
@@ -133,13 +133,13 @@ Jika Anda merilis proyek open source perusahaan Anda pertama kalinya, informasi
Dalam jangka panjang, tim hukum Anda bisa melakukan lebih banyak lagi dengan membantu perusahaan untuk mendapatkan lebih banyak dari keterlibatannya pada open source:
-* **Kebijakan kontribusi karyawan:** Pertimbangkan untuk mengembangkan kebijakan perusahaan yang menentukan bagaimana karyawan berkontribusi pada proyek open source. Sebuah kebijakan yang jelas akan mengurangi kebingungan pada karyawan Anda dan membantu mereka untuk berkontribusi pada proyek open source yang penting bagi perusahaan, baik sebagai bagian dari pekerjaan mereka atau dimasa senggang mereka. Sebuah contoh bagus adalah [Model IP dan Kebijakan Kontribusi Open Source](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) milik Rackspace.
+* **Kebijakan kontribusi karyawan:** Pertimbangkan untuk mengembangkan kebijakan perusahaan yang menentukan bagaimana karyawan berkontribusi pada proyek open source. Sebuah kebijakan yang jelas akan mengurangi kebingungan pada karyawan Anda dan membantu mereka untuk berkontribusi pada proyek open source yang penting bagi perusahaan, baik sebagai bagian dari pekerjaan mereka atau dimasa senggang mereka. Sebuah contoh bagus adalah [Model IP dan Kebijakan Kontribusi Open Source](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) milik Rackspace.
Membiarkan IP yang terkait dengan patch membangun basis pengetahuan dan reputasi karyawan. Ini menunjukkan bahwa perusahaan menekankan pengembangan karyawan dan menciptakan rasa pemberdayaan dan otonomi. Semua manfaat ini juga menyebabkan semangat kerja lebih tinggi dan retensi karyawan yang lebih baik.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/id/maintaining-balance-for-open-source-maintainers.md b/_articles/id/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..081eaa3069a
--- /dev/null
+++ b/_articles/id/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: id
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the
Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As
described by the Rockwood Leadership Institute , it involves "
maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md
index b97a1f92d74..25b7e93c18e 100644
--- a/_articles/ja/code-of-conduct.md
+++ b/_articles/ja/code-of-conduct.md
@@ -111,4 +111,4 @@ _厳密には_ 行動規範を違反していない行動に対して報告が
## あなたが世界中で見たいと望む行動を推奨しましょう 🌎
-プロジェクトが有効的でなく歓迎的でもない場合、皆が我慢している人物がたった一人しかいなかったとしても、コントリビューターの多くを失うリスクを抱えているのです。そのうちの何人かは一度も会ったことがないかもしれません。行動規範を採用して遵守させるのは必ずしも簡単なことではありません。しかし、歓迎的な環境を育てていくことはコミュニティを成長させる役に立つでしょう。
+プロジェクトが友好的でなく歓迎的でもない場合、皆が我慢している人物がたった一人しかいなかったとしても、コントリビューターの多くを失うリスクを抱えているのです。そのうちの何人かは一度も会ったことがないかもしれません。行動規範を採用して遵守させるのは必ずしも簡単なことではありません。しかし、歓迎的な環境を育てていくことはコミュニティを成長させる役に立つでしょう。
diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md
index dfecc9a1157..3b95817e956 100644
--- a/_articles/ja/how-to-contribute.md
+++ b/_articles/ja/how-to-contribute.md
@@ -207,7 +207,6 @@ README を読んで、壊れたリンクやタイポを見つけるかもしれ
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md
index 9e150ad769a..707b71ae1a1 100644
--- a/_articles/ja/legal.md
+++ b/_articles/ja/legal.md
@@ -92,7 +92,7 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
追加のコントリビューターアグリーメントはしばしば Contributor License Agreement (CLA) と呼ばれます。これを作ることで、プロジェクトのメンテナーは運用上の手間が必要になってきます。どのくらいの手間がかかるかはプロジェクトとやり方によります。簡単な同意であれば、コントリビューターに対してプロジェクトのオープンソースライセンスに従ってコントリビュートする権利があるとクリックひとつで同意できる様になるでしょう。より複雑な同意になると、法務のレビューとコントリビューターの雇用主の署名が必要になるかもしれません。
-加えて、「書類作業」が必要になることによって、中にはその作業が不必要、理解しがたい、公正ではない(プロジェクトのオープンソースライセンスによって、同意を受ける人や一般の人がコントリビューターより多くの権利を得る場合)と感じる人が出てくるかもしれません。このような状況では、追加のコントリビューターアグリーメントはプロジェクトのコミュニティからは有効的でないと受け取られるかもしれません。
+加えて、「書類作業」が必要になることによって、中にはその作業が不必要、理解しがたい、公正ではない(プロジェクトのオープンソースライセンスによって、同意を受ける人や一般の人がコントリビューターより多くの権利を得る場合)と感じる人が出てくるかもしれません。このような状況では、追加のコントリビューターアグリーメントはプロジェクトのコミュニティからは友好的でないと受け取られるかもしれません。
@@ -134,13 +134,13 @@ GitHub 上で新しいプロジェクトを作ると、ライセンスの選択
長期的には、法務部門は企業がオープンソースに関わることでより多くのことを安全に獲得する助けとなります:
-* **従業員のコントリビュートポリシー:** 従業員がどのようにオープンソースにコントリビュートするかを定めた社内規約を作ることを検討しましょう。明確な規約を作ることで従業員同士の混乱も減りますし、従業員に対して企業が最も関心のあるオープンソースプロジェクトに業務の一環であれ空き時間でコントリビュートする手助けにもなります。 Rackspace の [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) が良い例です。
+* **従業員のコントリビュートポリシー:** 従業員がどのようにオープンソースにコントリビュートするかを定めた社内規約を作ることを検討しましょう。明確な規約を作ることで従業員同士の混乱も減りますし、従業員に対して企業が最も関心のあるオープンソースプロジェクトに業務の一環であれ空き時間でコントリビュートする手助けにもなります。 Rackspace の [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) が良い例です。
- パッチに関連した知的財産を手放すことで従業員の知識ベースと名声を築く事ができます。そうすることで、その企業は従業員の能力を高め、自律的に働くことに投資していることを示すことができます。こういったメリットは、モラルの向上や従業員の維持にも繋がります。
+ パッチに関連した知的財産を手放すことで従業員の知識ベースと名声を築く事ができます。そうすることで、その企業は従業員の能力を高め、自律的に働くことに投資していることを示すことができます。こういったメリットは、士気の向上や従業員の維持にも繋がります。
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..228f6021f2a
--- /dev/null
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,220 @@
+---
+lang: ja
+title: オープンソースメンテナーのバランス維持
+description: メンテナンス担当者としてのセルフケアと燃え尽き症候群を避けるためのヒント。
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+人気のあるオープンソースプロジェクトが成長するにつれて、バランスを保ち、長期的にリフレッシュし、生産性を維持するために明確な境界線を設定することが必要になります。
+
+メンテナーの経験とバランスを取るための戦略を知るために、私たちは 40 人の maintainer community のメンバーとワークショップを行い、彼らのオープンソースでの燃え尽き症候群に対する第一線での経験と、バランスを保つための実践を学ぶことができました。ここで「パーソナルエコロジー」という概念が登場します。
+
+「パーソナルエコロジー」とはなんでしょうか?described by the Rockwood Leadership Institute によると、「生涯にわたってエネルギーを維持するために、バランス、ペース、効率を維持すること 」を意味します。これにより、私たちの会話のフレームワークを作り、メンテナーが自分の行動や貢献を、時間とともに進化する大きな生態系の一部であると認識する助けとなりました。燃え尽き症候群は、[WHO によって定義されるように](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281) 、慢性的な職場でのストレスから生じる症候群であり、メンテナーの間では珍しくありません。これは、モチベーションの喪失、集中力の欠如、および共同作業者やコミュニティとの共感の欠如に繋がります。
+
+
+
+ 私は仕事を始めることや集中することができませんでした。ユーザーに対して共感の欠如がありました。
+
+— @gabek , Owncast ライブストリーミングサーバーのメンタナー、燃え尽き症候群がオープンソースの仕事に与える影響について語る
+
+
+
+パーソナルエコロジーの概念を取り入れることで、燃え尽き症候群を積極的に回避し、セルフケアを優先し、最高の仕事をするためのバランスを維持することができます。
+
+## メンテナーとしてのセルフケアと燃え尽き症候群を回避するためのヒント
+
+### オープンソースで働く動機を明確にする
+
+オープンソースのメンテナンスのどの部分にあなたの活力が湧いてくるか、じっくり考えてみましょう。あなたのモチベーション理解することで、新しい課題に取り組む準備ができ、仕事に優先順位をつけることができます。ユーザーからの好意的なフィードバックであれ、コミュニティとの協力や交流の喜び、コードに没頭する満足感など、あなたのモチベーションを認識することで、集中力を高める指針になります。
+
+### バランスを崩し、ストレスを感じる原因を振り返る
+
+燃え尽きてしまう原因を理解することは重要です。オープンソースのメンテナーの間で見られるいくつかの共通のテーマは以下の通りです。
+
+* **肯定的なフィードバックの欠如:** ユーザーは苦情があるときに接触する可能性が高いです。全てが順調に進んでいる場合、ユーザーは黙っている傾向があります。あなたの貢献がどのような変化をもたらしているかを示すポジティブなフィードバックがないまま、問題のリストが増えていくのを見るのは、がっかりするでしょう。
+
+
+
+ まるで虚空に叫ぶようなもので、フィードバックが本当に活力を与えてくれます。私たちには、幸せだけど静かなユーザーがたくさんいます。
+
+— @thisisnic , Apache Arrow のメンテナー
+
+
+
+* **「No」と言わない:** オープンソースプロジェクトでは、必要以上の責任を負うことは簡単です。それがユーザーであれ、貢献者であれ、他のメンテナーであれ、彼らの期待に答えられるとは限りません。
+
+
+
+ 私は、自分が一人で行うべきこと以上のことを引き受けて、多くの人々の仕事をしなければならないことに気がつきました。これは FOSS でよく行われています。
+
+— @agnostic-apollo , Termux のメンテナー
+
+
+
+* **一人での作業:** メンテナーであることは非常に孤独です。例え同じメンテナーのグループで働いていたとしても、ここ数年、分散チームを直接集めるのは難しくなっています。
+
+
+
+ 特に COVID 以降、自宅で仕事をするようになってからは、誰とも会わず、誰とも話さない方が難しいです。
+
+— @gabek , Owncast ライブストリーミングサーバーのメンタナー、燃え尽き症候群がオープンソースの仕事に与える影響について語る
+
+
+
+* **時間やリソースの不足:** これは特にプロジェクトに取り組むために自分の自由な時間を犠牲にしなければならないボランティアのメンテナーにとって特に当てはまります。
+
+
+私はもっと経済的なサポートが欲しいのです。そうすれば、私の貯金を使い果たすことなくオープンソースの仕事に専念でき、後に多くの契約業務を行って補わなければならないというプレッシャーも感じずに済みます。
+
+— オープンソースのメンテナー
+
+
+
+* **矛盾する要求:** オープンソースは様々な動機を持ったグループで溢れており、その間を行き来するのは難しいことがあります。オープンソースの仕事で給料をもらっている場合、雇用主の利益はコミュニティの利益と対立することがあります。
+
+
+ 有料のオープンソースでは、雇用主が重視するものとコミュニティにとっての最善のものとの間に葛藤が生じます。
+
+— オープンソースのメンテナー
+
+
+
+### 燃え尽きの兆候に注意
+
+あなたは 10 週間、10 ヶ月、10 年とこのペースを続けることができますか?
+
+[@shaunagm](https://github.com/shaunagm) による [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) や Mozilla の[自己評価キット](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw)のようなツールがあり、自分の現在のペースを振り返り、調整できる点があるかどうかを確認することができます。一部のメンテナーは、睡眠の質や心拍数変動 (両方ともストレスに関連している) のような指標を追跡するためにウェアラブル技術も利用しています。
+
+
+ 私は良質なウェアラブル技術を強く信じています。その背後にある科学的根拠によって、どのように改善的できたかや、目指す状態を最適にする方法を理解することができます。
+
+— オープンソースのメンテナー
+
+
+
+### 自分自身とコミュニティを維持し続けるためには何が必要だろうか?
+
+これは各メンテナーによって異なり、生活の段階や外部要因によって変わるでしょう。しかし、以下は私たちが耳にしたいくつかのテーマです:
+
+* **コミュニティに頼る:** 仕事の委譲や貢献者の探し方は、仕事の負担を軽減できます。プロジェクトの連絡窓口を複数持つことで、心配することなく休憩を取ることができます。[Maintainer Community](http://maintainers.github.com/) のようなグループで他のメンテナーや広いコミュニティと繋がることができます。これは、相互支援や学びのための素晴らしいリソースとなるでしょう。
+
+ ユーザーコミュニティとの交流方法も探して、定期的にフィードバックを受け取り、オープンソースの作業の影響を理解することができます。
+
+* **資金調達をさぐる:** ピザのお金を探しているのか、フルタイムのオープンソースを探しているのか、サポートするリソースはたくさんあります!最初のステップとして、[GitHub Sponsors](https://github.com/sponsors)を有効にして、他の人があなたのオープンソースの作業をスポンサーすることを許可します。フルタイムに移行することを考えている場合は、次回の [GitHub Accelerator](http://accelerator.github.com/) に応募してみて下さい。
+
+
+
+ 少し前にポッドキャストに出演し、オープンソースの維持と持続性について話していました。GitHubで私の作業をサポートしてくれる少数の人々がいるだけで、ゲームの前に座るのではなく、オープンソースでちょっとしたことをする決断をすぐに下す助けとなることに気づきました。
+
+— @mansona , EmberJS のメンテナー
+
+
+
+* **ツールを使う:** [GitHub Copilot](https://github.com/features/copilot/) や [GitHub Actions](https://github.com/features/actions) のようなツールを使って、退屈な作業を自動化し、より意味のある貢献のために時間を確保しましょう。
+
+
+ 退屈な時に [Copilot](http://github.com/features/copilot/) を使って、楽しいことをしましょう。
+
+— オープンソースメンテナー
+
+
+
+* **休息と充電:** オープンソース以外の趣味や興味の時間を作りましょう。週末は休んでリフレッシュし、[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) に反映させましょう!一晩ぐっすり眠れるかどうかで、長期的な努力を継続できるかどうかが大きく変わってきます。
+
+ プロジェクトのある側面が特に楽しいと感じるのであれば、その楽しさを 1 日を通して体験できるように仕事を構成してみましょう。
+
+
+
+ 夜にリラックスするよりも、日中に「創造的なひととき」を取り入れる機会が増えてきていると感じています。
+
+— @danielroe , Nuxt のメンテナー
+
+
+
+* **境界線を設ける:** 全ての要求に「 Yes 」と言うわけにはいきません。これは、「今すぐそれに対応することはできませんし、将来的にも考えていません」とシンプルに伝えることや、READMEに自分が取り組みたいことや取り組みたくないことを明記することも含みます。例として、「明確な理由が示されたPRだけをマージする」とか、「隔週の木曜日の18時から19時にだけ問題をレビューする」といったことを伝えることができます。これにより、他の人たちに対する期待値を明確にし、また、あなたの時間に求められることに対して柔軟に対応するための基準を提供することができます。
+
+
+
+これらの点で他者を真に信頼するためには、全ての要求に「 Yes 」と答えるような人であってはいけません。そうすることで、プロフェッショナルにもプライベートにも境界線を持たなくなり、信頼性のある同僚としての立場も失ってしまいます。
+
+ — @mikemcquaid , Homebrew のメンテナー、 [Saying No](https://mikemcquaid.com/saying-no/) にて
+
+
+
+ 不利益な行動や否定的な交流を断ち切る毅然とした態度を身につけましょう。どうでもいいことにはエネルギーを使わなくても大丈夫です。
+
+
+
+私のソフトウェアは無料で提供していますが、私の時間やエネルギーは無料ではありません。
+
+— @IvanSanchez , Leaflet のメンテナー
+
+
+
+
+
+オープンソースのメンテナンスに暗い面があるのは、誰もが知っていることです。その中には、ありがたみを感じない人や、過度な権利を主張する人、あるいは明らかにトラブルを起こす人との接触が含まれます。プロジェクトが人気を集めるにつれて、このようなやり取りが増え、メンテナの負担が増大し、その結果、燃え尽きるリスクが高まることが考えられます。
+
+— @foosel , Octoprint のメンテナー、 [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs) にて
+
+
+
+忘れないでください、パーソナルエコロジーは継続的な実践であり、オープンソースの旅を進める中で進化していきます。自分自身のケアを優先し、バランスを保つことで、効果的かつ持続可能にオープンソースコミュニティに貢献できます。これにより、あなた自身の幸福とプロジェクトの長期的な成功の両方を確保することができます。
+
+## その他のリソース
+
+* [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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## 貢献者
+
+このガイドのために経験やヒントを提供してくれた全てのメンテナーに感謝します!
+
+このガイドブックは、[@abbycabs](https://github.com/abbycabs) によって作成されました。:
+
+[@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/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md
index 44a441e8e9b..d775b1dbb66 100644
--- a/_articles/ko/how-to-contribute.md
+++ b/_articles/ko/how-to-contribute.md
@@ -185,7 +185,9 @@ related:
오픈소스 프로젝트가 어떻게 작동하는지 알았으니, 이제 기여할 프로젝트를 찾아야 합니다!
-이전에 오픈소스에 기여한 적이 없다면, 케네디 미국 전 대통령으로부터 조언을 구하세요. _"Ask not what your country can do for you - ask what you can do for your country."_
+이전에 오픈 소스에 기여한 적이 없다면, 미국 존 케네디 대통령의 명언을 떠올려보세요.
+_"Ask not what your country can do for you - ask what you can do for your country."_
+_"국가가 나를 위해 무엇을 해줄 것을 바라기에 앞서, 내가 국가를 위해 무엇을 할 것인가를 생각해야 한다."_
오픈소스에 기여하는 것은 프로젝트 전반에 걸쳐 모든 수준에서 발생합니다. 여러분의 첫 번째 기여가 정확히 무엇이고 어떻게 보일지 생각할 필요가 없습니다.
@@ -207,7 +209,6 @@ README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md
index e23bab5555a..37bc21b9f71 100644
--- a/_articles/ko/legal.md
+++ b/_articles/ko/legal.md
@@ -133,13 +133,13 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는
장기적으로, 법률팀은 오픈소스에 대한 참여를 통해 더 많은 것을 얻고, 안전을 유지할 수 있도록 더 많은 일을 할 수 있습니다:
-* **직원 기여 정책:** 직원이 오픈소스 프로젝트에 기여하는 방법을 지정하는 기업 정책을 개발하는 것을 고려하십시오. 분명한 정책은 직원들 사이의 혼란을 줄이고 작업의 일부 또는 자유 시간에 상관없이, 회사의 이익을 최대한 활용하여 오픈소스 프로젝트에 기여할 수 있도록 지원합니다. 좋은 예시는 Rackspace의 [모델 IP 및 오픈소스 기여 정책](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)입니다.
+* **직원 기여 정책:** 직원이 오픈소스 프로젝트에 기여하는 방법을 지정하는 기업 정책을 개발하는 것을 고려하십시오. 분명한 정책은 직원들 사이의 혼란을 줄이고 작업의 일부 또는 자유 시간에 상관없이, 회사의 이익을 최대한 활용하여 오픈소스 프로젝트에 기여할 수 있도록 지원합니다. 좋은 예시는 Rackspace의 [모델 IP 및 오픈소스 기여 정책](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)입니다.
Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
-— @vanl, ["모델 IP 및 공개 소스 기여 정책"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["모델 IP 및 공개 소스 기여 정책"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/ko/maintaining-balance-for-open-source-maintainers.md b/_articles/ko/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..1e9216a51ac
--- /dev/null
+++ b/_articles/ko/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ko
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/legal.md b/_articles/legal.md
index 312c51dfa1a..b124e1e4477 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -12,7 +12,7 @@ related:
## Understanding the legal implications of open source
-Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](/notices/).)
+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?
@@ -20,9 +20,9 @@ Glad you asked! When you make a creative work (such as writing, graphics, or cod
In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation.
-Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions.
+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.
-If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you.
+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.
@@ -40,7 +40,7 @@ If you want others to use, distribute, modify, or contribute back to your projec
You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project.
-[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/).
+[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), 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/).
@@ -54,21 +54,23 @@ When you create a new project on GitHub, you'll be [asked to add a license](http
## Which open source license is appropriate for my project?
-If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to.
+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**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD.
+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).
-On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3.
+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.
+
You may also want to consider the **communities** you hope will use and contribute to your project:
* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
-* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered.
+* **Do you want your project to appeal to 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/) (and them) covered.
* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+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/).
@@ -82,9 +84,9 @@ For example, as your project grows it adds dependencies or users, or your compan
**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**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 agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+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?
@@ -120,11 +122,11 @@ For better or worse, consider letting them know even if it's a personal project.
**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about:
-* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project.
+* **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).
+* **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.
@@ -134,13 +136,13 @@ If you're releasing your company's first open source project, the above is more
Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe:
-* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **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/).
Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/maintaining-balance-for-open-source-maintainers.md b/_articles/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..51d312d3499
--- /dev/null
+++ b/_articles/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+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/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/metrics.md b/_articles/metrics.md
index 78c094f878a..145dd18119b 100644
--- a/_articles/metrics.md
+++ b/_articles/metrics.md
@@ -112,7 +112,7 @@ Unresponsive maintainers become a bottleneck for open source projects. If someon
[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions.
-Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_
+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:
diff --git a/_articles/ms/how-to-contribute.md b/_articles/ms/how-to-contribute.md
index ea1bc6af630..285de934529 100644
--- a/_articles/ms/how-to-contribute.md
+++ b/_articles/ms/how-to-contribute.md
@@ -213,7 +213,6 @@ Anda juga boleh menggunakan salah satu sumber berikut untuk membantu anda menemu
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/ms/legal.md b/_articles/ms/legal.md
index 6bccef8e1d6..0881810920f 100644
--- a/_articles/ms/legal.md
+++ b/_articles/ms/legal.md
@@ -134,13 +134,13 @@ Sekiranya anda melepaskan projek sumber terbuka pertama syarikat anda, perkara d
Jangka panjang, pasukan undang-undang anda boleh melakukan lebih banyak perkara untuk membantu syarikat mendapatkan lebih banyak hasil daripada penglibatannya dalam sumber terbuka, dan tetap selamat:
-* **Dasar sumbangan pekerja:** Pertimbangkan untuk mengembangkan polisi korporat yang menentukan bagaimana pekerja anda menyumbang untuk projek sumber terbuka. Dasar yang jelas akan mengurangkan kekeliruan di kalangan pekerja anda dan membantu mereka menyumbang kepada projek sumber terbuka demi kepentingan syarikat, sama ada sebagai sebahagian daripada pekerjaan mereka atau pada masa lapang. Contoh yang baik ialah Rackspace [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Dasar sumbangan pekerja:** Pertimbangkan untuk mengembangkan polisi korporat yang menentukan bagaimana pekerja anda menyumbang untuk projek sumber terbuka. Dasar yang jelas akan mengurangkan kekeliruan di kalangan pekerja anda dan membantu mereka menyumbang kepada projek sumber terbuka demi kepentingan syarikat, sama ada sebagai sebahagian daripada pekerjaan mereka atau pada masa lapang. Contoh yang baik ialah Rackspace [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
Membiarkan IP yang berkaitan dengan patch membina asas pengetahuan dan reputasi pekerja. Ini menunjukkan bahawa syarikat dilaburkan dalam pengembangan pekerja tersebut dan mewujudkan rasa pemberdayaan dan autonomi. Semua faedah ini juga membawa kepada semangat kerja yang lebih tinggi dan pengekalan pekerja yang lebih baik.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/ms/maintaining-balance-for-open-source-maintainers.md b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..86b3d3f9cfd
--- /dev/null
+++ b/_articles/ms/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ms
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/nl/how-to-contribute.md b/_articles/nl/how-to-contribute.md
index 4d561689084..cc07950d858 100644
--- a/_articles/nl/how-to-contribute.md
+++ b/_articles/nl/how-to-contribute.md
@@ -221,7 +221,6 @@ U kunt ook een van de volgende bronnen gebruiken om u te helpen bij het ontdekke
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/nl/legal.md b/_articles/nl/legal.md
index 1b06118b779..67be0267f2b 100644
--- a/_articles/nl/legal.md
+++ b/_articles/nl/legal.md
@@ -139,7 +139,7 @@ Als u het eerste open source-project van uw bedrijf uitbrengt, is het bovenstaan
Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen meer uit zijn betrokkenheid bij open source te halen en veilig te blijven:
-* **Beleid inzake werknemersbijdragen:** Overweeg om een bedrijfsbeleid te ontwikkelen dat aangeeft hoe uw werknemers bijdragen aan open source-projecten. Een duidelijk beleid zal de verwarring onder uw medewerkers verminderen en hen helpen bij te dragen aan open source-projecten in het belang van het bedrijf, zowel als onderdeel van hun baan als in hun vrije tijd. Een goed voorbeeld is Rackspace's [Model IP and Open Source Contribution Policy] (https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Beleid inzake werknemersbijdragen:** Overweeg om een bedrijfsbeleid te ontwikkelen dat aangeeft hoe uw werknemers bijdragen aan open source-projecten. Een duidelijk beleid zal de verwarring onder uw medewerkers verminderen en hen helpen bij te dragen aan open source-projecten in het belang van het bedrijf, zowel als onderdeel van hun baan als in hun vrije tijd. Een goed voorbeeld is Rackspace's [Model IP and Open Source Contribution Policy] (https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
@@ -148,7 +148,7 @@ Op de langere termijn kan uw juridische team meer doen om het bedrijf te helpen
_Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention._
-— @vanl, ["Een modelbeleid inzake intellectuele eigendom en bijdragen aan open source"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Een modelbeleid inzake intellectuele eigendom en bijdragen aan open source"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/nl/maintaining-balance-for-open-source-maintainers.md b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..df593ff4b32
--- /dev/null
+++ b/_articles/nl/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: nl
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/nl/starting-a-project.md b/_articles/nl/starting-a-project.md
index ec42aa7bd21..6cb613a87ac 100644
--- a/_articles/nl/starting-a-project.md
+++ b/_articles/nl/starting-a-project.md
@@ -16,7 +16,7 @@ Dus je denkt erover om aan de slag te gaan met open source? Gefeliciteerd! De we
### Wat betekent "open source"?
-Als een project open source is, betekent dit **dat iedereen vrij is om uw project voor elk doel te gebruiken, bestuderen, wijzigen en distribueren.** Deze machtigingen worden afgedwongen via [een open source-licentie](https://opensource.org/licenties).
+Als een project open source is, betekent dit **dat iedereen vrij is om uw project voor elk doel te gebruiken, bestuderen, wijzigen en distribueren.** Deze machtigingen worden afgedwongen via [een open source-licentie](https://opensource.org/licenses).
Open source is krachtig omdat het de barrières voor acceptatie en samenwerking verlaagt, waardoor mensen projecten snel kunnen verspreiden en verbeteren. Ook omdat het gebruikers de mogelijkheid geeft om hun eigen computergebruik te beheersen, in vergelijking met closed source. Een bedrijf dat open source software gebruikt, heeft bijvoorbeeld de mogelijkheid om iemand in te huren om aangepaste verbeteringen aan de software aan te brengen, in plaats van uitsluitend te vertrouwen op de productbeslissingen van een closed source-leverancier.
diff --git a/_articles/pl/how-to-contribute.md b/_articles/pl/how-to-contribute.md
index 399cd50af2f..fd9c07fb69c 100644
--- a/_articles/pl/how-to-contribute.md
+++ b/_articles/pl/how-to-contribute.md
@@ -221,7 +221,6 @@ Możesz także skorzystać z jednego z następujących zasobów, aby pomóc ci o
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index 8de980aee30..63fff32dc1d 100644
--- a/_articles/pl/legal.md
+++ b/_articles/pl/legal.md
@@ -70,7 +70,7 @@ Możesz także rozważyć **społeczności**, które mają nadzieję wykorzysta
* **Czy chcesz, aby Twój projekt spodobał się dużym firmom?** Duży biznes prawdopodobnie będzie chciał uzyskać wyraźną licencję patentową od wszystkich autorów. W takim przypadku usługa [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) obejmuje Ciebie (i ich).
* **Czy chcesz, aby Twój projekt był atrakcyjny dla autorów, którzy nie chcą, aby ich wkład był wykorzystywany w oprogramowaniu zamkniętym?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) lub (jeśli nie chcą również wnosić wkładu do usług zamkniętego źródła) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) przejdzie dobrze.
-Twoja **firma** może mieć określone wymagania licencyjne dla swoich projektów open source. Na przykład, może wymagać zezwolenia licencyjnego, aby firma mogła wykorzystać Twój projekt w zamkniętym źródłowym produkcie firmy. Lub Twoja firma może wymagać silnej licencji copyleft i dodatkowej umowy o współautorze (patrz poniżej), aby tylko Twoja firma i nikt inny nie mógł używać twojego projektu w oprogramowaniu zamkniętym. Lub Twoja firma może mieć pewne potrzeby związane ze standardami, odpowiedzialnością społeczną lub przejrzystością, z których każda może wymagać określonej strategii licencjonowania. Porozmawiaj z działem prawnym swojej firmy](#what-does-my-companys-legal-team-need-to-know).
+Twoja **firma** może mieć określone wymagania licencyjne dla swoich projektów open source. Na przykład, może wymagać zezwolenia licencyjnego, aby firma mogła wykorzystać Twój projekt w zamkniętym źródłowym produkcie firmy. Lub Twoja firma może wymagać silnej licencji copyleft i dodatkowej umowy o współautorze (patrz poniżej), aby tylko Twoja firma i nikt inny nie mógł używać twojego projektu w oprogramowaniu zamkniętym. Lub Twoja firma może mieć pewne potrzeby związane ze standardami, odpowiedzialnością społeczną lub przejrzystością, z których każda może wymagać określonej strategii licencjonowania. Porozmawiaj z [działem prawnym swojej firmy](#co-powinien-wiedzieć-zespół-prawny-mojej-firmy).
Podczas tworzenia nowego projektu w GitHub masz możliwość wybrania licencji. Dołączenie jednej z wyżej wymienionych licencji sprawi, że Twój projekt GitHub stanie się open source. Jeśli chcesz zobaczyć inne opcje, sprawdź [choosealicense.com](https://choosealicense.com), aby znaleźć odpowiednią licencję dla swojego projektu, nawet jeśli nie jest to [oprogramowanie](https://choosealicense.com/non-software/).
@@ -138,7 +138,7 @@ Jeśli wypuszczasz pierwszy projekt open source swojej firmy, powyższe rozwiąz
W dłuższej perspektywie Twój zespół prawny może zrobić więcej, aby pomóc firmie lepiej wykorzystać zaangażowanie w open source i zachować bezpieczeństwo:
-* **Zasady dotyczące składek pracowniczych:** Rozważ opracowanie zasad korporacyjnych, które określają, w jaki sposób pracownicy przyczyniają się do projektów typu open source. Jasna polityka zmniejszy zamieszanie wśród pracowników i pomoże im przyczyniać się do projektów typu open source w najlepszym interesie firmy, zarówno w ramach pracy, jak i czasu wolnego. Dobrym przykładem jest [Model IP i Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Zasady dotyczące składek pracowniczych:** Rozważ opracowanie zasad korporacyjnych, które określają, w jaki sposób pracownicy przyczyniają się do projektów typu open source. Jasna polityka zmniejszy zamieszanie wśród pracowników i pomoże im przyczyniać się do projektów typu open source w najlepszym interesie firmy, zarówno w ramach pracy, jak i czasu wolnego. Dobrym przykładem jest [Model IP i Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
@@ -146,7 +146,7 @@ W dłuższej perspektywie Twój zespół prawny może zrobić więcej, aby pomó
Letting out the IP associated with a patch builds the employee's knowledge base and reputation. It shows that the company is invested in the development of that employee and creates a sense of empowerment and autonomy. All of these benefits also lead to higher morale and better employee retention.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/pl/maintaining-balance-for-open-source-maintainers.md b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..bc1894fcfde
--- /dev/null
+++ b/_articles/pl/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: pl
+untranslated: true
+title: Utrzymanie równowagi dla opiekunów Open Source
+description: Wskazówki dotyczące dbania o siebie i unikania wypalenia jako opiekun.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+W miarę jak popularność projektu open source rośnie, ważne staje się ustalenie jasnych granic, które pomogą zachować równowagę, aby zachować świeżość i produktywność na dłuższą metę.
+
+Aby uzyskać zrozumienie doświadczeń opiekunów i ich strategii znajdowania równowagi, przeprowadziliśmy warsztaty z 40 członkami opiekunów społeczności , pozwalając nam poznać ich własne doświadczenia z wypaleniem w open source i praktyki, które pomogły im zachować równowagę w pracy. W tym miejscu pojawia się koncepcja osobistej ekologii.
+
+Czym więc jest ekologia osobista? Zgodnie z opisem Rockwood Leadership Institute ,obejmuje ona "utrzymywanie równowagi, tempa i wydajności, aby utrzymać naszą energię przez całe życie ." To nadało ramy naszym rozmowom, pomagając opiekunom rozpoznać ich działania i wkład jako części większego ekosystemu, który ewoluuje w czasie.Wypalenie, syndrom wynikający z przewlekłego stresu w miejscu pracy, zgodnie z [definicja WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), nie jest niczym niezwykłym wśród opiekunów. Często prowadzi to do utraty motywacji, niemożności skupienia się i braku empatii dla współpracowników i społeczności, z którą pracujesz.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+Przyjmując koncepcję osobistej ekologii, opiekunowie mogą aktywnie unikać wypalenia, traktować priorytetowo dbanie o siebie i utrzymywać poczucie równowagi, aby wykonywać swoją najlepszą pracę.
+
+## Wskazówki dotyczące dbania o siebie i unikania wypalenia zawodowego w roli opiekuna:
+
+### Określ swoje motywacje do pracy w open source
+
+Poświęć trochę czasu na zastanowienie się nad tym, jakie części utrzymania open source cię energetyzują. Zrozumienie swoich motywacji może pomóc w ustaleniu priorytetów pracy w sposób, który sprawi, że będziesz zaangażowany i gotowy na nowe wyzwania. Niezależnie od tego, czy chodzi o pozytywne opinie użytkowników, radość ze współpracy i kontaktów towarzyskich ze społecznością, czy też satysfakcję z zagłębiania się w kod, rozpoznanie motywacji może pomóc w skupieniu się na pracy.
+
+### Zastanów się, co powoduje, że tracisz równowagę i stresujesz się
+
+Ważne jest, aby zrozumieć, co powoduje nasze wypalenie. Oto kilka wspólnych tematów, które zaobserwowaliśmy wśród opiekunów open source:
+
+* **Brak pozytywnych opinii:** Użytkownicy są znacznie bardziej skłonni do zgłaszania swoich skarg. Jeśli wszystko działa świetnie, mają tendencję do milczenia. Może to być zniechęcające, gdy widzi się rosnącą listę problemów bez pozytywnych opinii pokazujących, w jaki sposób Twój wkład robi różnicę.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **Nie mówienie 'nie':** Łatwo jest wziąć na siebie więcej obowiązków niż jest to konieczne w projekcie open source. Niezależnie od tego, czy chodzi o użytkowników, współpracowników czy innych opiekunów - nie zawsze możemy spełnić ich oczekiwania.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **Praca w samotności:** Bycie opiekunem może być niezwykle samotne. Nawet jeśli pracujesz z grupą opiekunów, ostatnie kilka lat było trudne dla osobistego zwoływania rozproszonych zespołów.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **Niewystarczająca ilość czasu lub zasobów:** Jest to szczególnie prawdziwe w przypadku opiekunów-wolontariuszy, którzy muszą poświęcić swój wolny czas na pracę nad projektem.
+
+
+
+* **Sprzeczne oczekiwania:** Open source jest pełne grup o różnych motywacjach, co może być trudne w obsłudze. Jeśli płacą ci za pracę nad open source, interesy twojego pracodawcy mogą być czasami sprzeczne ze społecznością.
+
+
+
+### Zwróć uwagę na oznaki wypalenia
+
+Czy jesteś w stanie utrzymać tempo przez 10 tygodni? 10 miesięcy? 10 lat?
+
+Istnieją narzędzia, takie jak [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) od [@shaunagm](https://github.com/shaunagm) i od Mozilla [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) , które mogą pomóc ci zastanowić się nad twoim obecnym tempem i sprawdzić, czy są jakieś poprawki, które możesz wprowadzić. Niektórzy opiekunowie używają również technologii do monitorowania takich wskaźników jak jakość snu i zmienność tętna (oba powiązane ze stresem).
+
+
+
+### Czego potrzebujesz, aby utrzymać siebie i swoją społeczność?
+
+Będzie to wyglądać inaczej dla każdego opiekuna i będzie się zmieniać w zależności od etapu życia i innych czynników zewnętrznych. Ale oto kilka tematów, które usłyszeliśmy:
+
+* **Odciążenie społeczności:** Delegowanie i znajdowanie współpracowników może zmniejszyć obciążenie pracą. Posiadanie wielu osób do kontaktu w sprawie projektu może pomóc ci zrobić sobie przerwę bez zmartwień. Nawiązuj kontakty z innymi opiekunami i szerszą społecznością - w grupach takich jak [Maintainer Community](http://maintainers.github.com/). Może to być świetne źródło wzajemnego wsparcia i nauki.
+
+ Możesz także szukać sposobów na zaangażowanie społeczności użytkowników, aby regularnie otrzymywać informacje zwrotne i zrozumieć znaczenie swojej pracy w open source.
+
+* **Znajdź finansowanie:** Niezależnie od tego, czy szukasz pieniędzy na pizzę, czy próbujesz przejść na pełny etat open source, istnieje wiele zasobów, które mogą Ci pomóc! Pierwszym krokiem jest włączenie opcji [Sponsorzy GitHub](https://github.com/sponsors), aby umożliwić innym sponsorowanie twojej pracy open source. Jeśli myślisz o przejściu na pełny etat, zgłoś się do następnej rundy [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **Korzystaj z narzędzi:** Poznaj narzędzia takie jak [GitHub Copilot](https://github.com/features/copilot/) i [GitHub Actions](https://github.com/features/actions), aby zautomatyzować proste zadania i uwolnić swój czas na bardziej znaczący wkład.
+
+
+
+* **Odpoczynek i regeneracja:** Znajdź czas na swoje hobby i zainteresowania poza open source. Weź wolne weekendy, aby się zrelaksować i zregenerować - i ustaw swój [status GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), aby odzwierciedlał twoją dostępność! Dobry sen może mieć duży wpływ na twoją zdolność do utrzymania wysiłków w dłuższej perspektywie.
+
+ Jeśli pewne aspekty projektu sprawiają ci szczególną przyjemność, postaraj się tak zaplanować pracę, abyś mógł doświadczać ich w ciągu dnia.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **Wyznacz granice:** Nie możesz zgodzić się na każdą prośbę. Może to być tak proste, jak powiedzenie: "Nie mogę się tym teraz zająć i nie planuję tego w przyszłości" lub wyszczególnienie tego, co chcesz zrobić, a czego nie, w pliku README. Na przykład, można powiedzieć: "Łączę tylko PR-y, które mają jasno wymienione powody, dla których zostały stworzone" lub "Przeglądam sprawy tylko we czwartki od 18:00 do 19:00". Określa to oczekiwania wobec innych i daje ci coś, na co możesz wskazać w innych momentach, aby pomóc zmniejszyć wymagania ze strony współpracowników lub użytkowników dotyczące twojego czasu.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ Naucz się stanowczo odrzucać szkodliwe zachowania i negatywne interakcje. W dobrym tonie jest nie poświęcać energii rzeczom, na których ci nie zależy.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Pamiętaj, że ekologia osobista to ciągła praktyka, która będzie ewoluować w miarę postępów w podróży open source. Traktując priorytetowo dbanie o siebie i utrzymywanie poczucia równowagi, możesz wnieść swój wkład w społeczność open source w sposób skuteczny i zrównoważony, zapewniając zarówno dobre samopoczucie, jak i sukces swoich projektów na dłuższą metę.
+
+## Dodatkowe materiały
+
+* [Społeczność opiekunów](http://maintainers.github.com/)
+* [Umowa społeczna open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [Jak radzić sobie z toksycznymi ludźmi](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Zestaw do samooceny ekologii osobistej](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Sztuka przywództwa](https://rockwoodleadership.org/art-of-leadership/), Rockwood
+* [Mówienie "nie"](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Otwartość zarządzania](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Program warsztatów został zaczerpnięty z serii [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org)
+
+## Współtwórcy
+
+Bardzo dziękujemy wszystkim opiekunom, którzy podzielili się z nami swoimi doświadczeniami i wskazówkami na potrzeby tego przewodnika!
+
+Ten przewodnik został napisany przez [@abbycabs](https://github.com/abbycabs) z wkładem od:
+
+[@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) + wiele innych osób!
diff --git a/_articles/pl/starting-a-project.md b/_articles/pl/starting-a-project.md
index 72bba217ab1..ed7caa0598b 100644
--- a/_articles/pl/starting-a-project.md
+++ b/_articles/pl/starting-a-project.md
@@ -38,7 +38,7 @@ _Wolne oprogramowanie_ odnosi się do tego samego zestawu projektów, co _otwart
* **Współpraca:** Projekty open source mogą akceptować zmiany od każdego na świecie. [Exercism](https://github.com/exercism/), na przykład, jest platformą ćwiczeń programistycznych z ponad 350 uczestnikami.
-* **Adopcja i remiksowanie:** projekty open source mogą być wykorzystywane przez każdego do prawie dowolnego celu. Ludzie mogą nawet używać go do budowania innych rzeczy. [WordPress](https://github.com/WordPress), na przykład, zaczął się jako rozwidlenie istniejącego projektu o nazwie[b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
+* **Adopcja i remiksowanie:** projekty open source mogą być wykorzystywane przez każdego do prawie dowolnego celu. Ludzie mogą nawet używać go do budowania innych rzeczy. [WordPress](https://github.com/WordPress), na przykład, zaczął się jako rozwidlenie istniejącego projektu o nazwie [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md).
* **Transparentność:** Każdy może sprawdzić projekt open source pod kątem błędów lub niespójności. Przejrzystość ma znaczenie dla rządów takich jak [Bułgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) lub [Stany Zjednoczone](https://sourcecode.cio.gov/), regulowane branże, takie jak bankowość lub opieka zdrowotna, oraz oprogramowanie zabezpieczające, takie jak [Let's Encrypt](https://github.com/letsencrypt).
diff --git a/_articles/pt/how-to-contribute.md b/_articles/pt/how-to-contribute.md
index e6ee8a1c380..efad946eb21 100644
--- a/_articles/pt/how-to-contribute.md
+++ b/_articles/pt/how-to-contribute.md
@@ -207,7 +207,6 @@ Você também pode usar um dos seguintes recursos para ajudá-lo a descobrir e c
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/pt/legal.md b/_articles/pt/legal.md
index 3aa0babf75e..be1934460d1 100644
--- a/_articles/pt/legal.md
+++ b/_articles/pt/legal.md
@@ -134,13 +134,13 @@ Se você está lançando o primeiro projeto open source da sua empresa, as dicas
A longo prazo, sua equipe jurídica pode fazer mais para ajudar a empresa a obter mais de seu envolvimento em open source e permanecer segura:
-* **Políticas de contribuição para funcionários:** Considere desenvolver uma política corporativa que especifique como seus funcionários contribuem para projetos open source. Uma política clara reduzirá a confusão entre seus funcionários e os ajudará a contribuir para projetos open source no melhor interesse da empresa, seja como parte de seus trabalhos ou em seu tempo livre. Um bom exemplo é o [Modelo de propriedade intelectual e políticas de contribuição para projetos abertos](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) da Rackspace.
+* **Políticas de contribuição para funcionários:** Considere desenvolver uma política corporativa que especifique como seus funcionários contribuem para projetos open source. Uma política clara reduzirá a confusão entre seus funcionários e os ajudará a contribuir para projetos open source no melhor interesse da empresa, seja como parte de seus trabalhos ou em seu tempo livre. Um bom exemplo é o [Modelo de propriedade intelectual e políticas de contribuição para projetos abertos](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) da Rackspace.
Liberar a propriedade intelectual associada com um patch constrói a base de conhecimento do funcionário e sua reputação. Mostra que a empresa é empenhada no desenvolvimento desse funcionário e cria um senso de emponderamento e autonomia. Todos esses benefícios também levam a uma maior moral e uma melhor retenção de funcionários.
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..7a97674bf76
--- /dev/null
+++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,220 @@
+---
+lang: pt
+title: Mantendo o Equilíbrio para Mantenedores de Código Aberto
+description: Dicas para o autocuidado e evitar o esgotamento como mantenedor.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+Com o crescimento de popularidade de projetos código aberto, se torna importante definir limites para te ajudar a equilibrar se manter motivado e produtivo ao longo do tempo.
+
+Para obter insights sobre as experiências dos mantenedores e suas estratégias para encontrar equilíbrio, realizamos uma oficina com 40 membros da Comunidade de Mantenedores , permitindo-nos aprender com suas experiências pessoais de esgotamento em código aberto e as práticas que os ajudaram a manter o equilíbrio em seu trabalho. É aqui que o conceito de ecologia pessoal entra em jogo.
+
+Então, o que é a ecologia pessoal? Conforme descrito pelo Instituto de Liderança Rockwood , envolve "manter o equilíbrio, o ritmo e a eficiência para sustentar nossa energia ao longo de uma vida ." Isso moldou nossas conversas, ajudando os mantenedores a reconhecerem suas ações e contribuições como partes de um ecossistema maior que evolui ao longo do tempo. O esgotamento, uma síndrome resultante do estresse crônico no local de trabalho, conforme [definido pela OMS](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), não é incomum entre mantenedores. Isso frequentemente leva a uma perda de motivação, incapacidade de se concentrar e falta de empatia pelos colaboradores e comunidade com os quais você trabalha.
+
+
+
+ Eu não conseguia me concentrar ou começar uma tarefa. Eu tinha uma falta de empatia pelos usuários.
+
+— @gabek , mantenedor do servidor de streaming ao vivo Owncast, sobre o impacto do esgotamento em seu trabalho de código aberto
+
+
+
+Ao abraçar o conceito de ecologia pessoal, os mantenedores podem evitar o esgotamento de forma proativa, priorizar o autocuidado e manter um senso de equilíbrio para fazer o seu melhor trabalho.
+
+## Dicas de Autocuidado e Prevenção do Esgotamento como Mantenedor:
+
+### Identifique suas motivações para trabalhar em código aberto
+
+Dedique um tempo para refletir sobre quais aspectos da manutenção em código aberto o energizam. Compreender suas motivações pode ajudá-lo a priorizar o trabalho de uma maneira que o mantenha envolvido e pronto para novos desafios. Seja o retorno positivo dos usuários, a alegria de colaborar e socializar com a comunidade ou a satisfação de mergulhar no código, reconhecer suas motivações pode ajudar a direcionar o seu foco.
+
+### Reflita sobre o que causa desequilíbrio e estresse
+
+É importante entender o que nos leva ao esgotamento. Aqui estão alguns temas comuns que encontramos entre mantenedores de código aberto:
+
+* **Falta de feedback positivo:** Os usuários tendem a entrar em contato quando têm uma reclamação. Se tudo funciona bem, tendem a ficar em silêncio. Pode ser desanimador ver uma crescente lista de problemas sem o feedback positivo mostrando como suas contribuições fazem a diferença.
+
+
+
+ Às vezes, parece um pouco como gritar no vazio e acho que o feedback realmente me energiza. Temos muitos usuários felizes, mas silenciosos.
+
+— @thisisnic , mantenedor do Apache Arrow
+
+
+
+* **Não dizer 'não':** Pode ser fácil assumir mais responsabilidades do que se deveria em um projeto de código aberto. Seja de usuários, colaboradores ou outros mantenedores, nem sempre podemos corresponder às expectativas deles.
+
+
+
+ Percebi que estava assumindo mais do que deveria e tendo que fazer o trabalho de várias pessoas, como comumente é feito em FOSS.
+
+— @agnostic-apollo , mantenedor do Termux, sobre o que causa o esgotamento em seu trabalho
+
+
+
+* **Trabalhar sozinho:** Ser um mantenedor pode ser incrivelmente solitário. Mesmo se você trabalha com um grupo de mantenedores, os últimos anos têm sido difíceis para reunir equipes distribuídas pessoalmente.
+
+
+
+ Especialmente desde a COVID e o trabalho em casa, é mais difícil nunca ver ninguém ou falar com ninguém.
+
+— @gabek , mantenedor do servidor de streaming ao vivo Owncast, sobre o impacto do esgotamento em seu trabalho de código aberto
+
+
+
+* **Falta de tempo ou recursos:** Isso é especialmente verdade para mantenedores voluntários que têm que sacrificar seu tempo livre para trabalhar em um projeto.
+
+
+
+* **Demandas conflitantes:** O código aberto é cheio de grupos com diferentes motivações, o que pode ser difícil de navegar. Se você é pago para fazer código aberto, os interesses de seu empregador às vezes podem entrar em conflito com a comunidade.
+
+
+
+### Fique atento aos sinais de esgotamento
+
+Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos?
+
+Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o [kit de autoavaliação de ecologia pessoal da Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas ligadas ao estresse).
+
+
+
+### O que você precisa para continuar sustentando a si mesmo e à sua comunidade?
+
+Isso será diferente para cada mantenedor e mudará dependendo de sua fase de vida e outros fatores externos. Mas aqui estão alguns temas que ouvimos:
+
+* **Conte com a comunidade:** Delegação e encontrar colaboradores podem aliviar a carga de trabalho. Ter vários pontos de contato para um projeto pode ajudar você a tirar uma folga sem preocupações. Conecte-se com outros mantenedores e a comunidade em geral – em grupos como a [Comunidade de Mantenedores](http://maintainers.github.com/). Isso pode ser uma ótima fonte de apoio mútuo e aprendizado.
+
+ Você também pode procurar maneiras de se envolver com a comunidade de usuários, para ouvir regularmente feedback e entender o impacto de seu trabalho de código aberto.
+
+* **Explore o financiamento:** Esteja você procurando um dinheiro extra para pizza ou tentando se dedicar integralmente ao código aberto, há muitos recursos disponíveis! Como primeiro passo, considere ativar [Patrocinadores do GitHub](https://github.com/sponsors) para permitir que outros patrocinem seu trabalho de código aberto. Se você está pensando em dar o salto para o tempo integral, inscreva-se para a próxima rodada do [GitHub Accelerator](http://accelerator.github.com/).
+
+
+
+ Participei de um podcast há algum tempo e estávamos conversando sobre manutenção de código aberto e sustentabilidade. Descobri que mesmo um pequeno número de pessoas apoiando meu trabalho no GitHub me ajudou a tomar uma decisão rápida de não ficar na frente de um jogo, mas sim fazer uma pequena contribuição ao código aberto.
+
+— @mansona , mantenedor do EmberJS
+
+
+
+* **Use ferramentas:** Explore ferramentas como [GitHub Copilot](https://github.com/features/copilot/) e [GitHub Actions](https://github.com/features/actions/) para automatizar tarefas mundanas e liberar tempo para contribuições mais significativas.
+
+
+
+* **Descanse e recarregue:** Reserve tempo para seus hobbies e interesses fora do código aberto. Tire os fins de semana para relaxar e rejuvenescer - e ajuste seu [status do GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) para refletir sua disponibilidade! Uma boa noite de sono pode fazer uma grande diferença em sua capacidade de manter seus esforços a longo prazo.
+
+ Se você encontrar certos aspectos de seu projeto particularmente agradáveis, tente estruturar seu trabalho de forma que você possa experimentá-los ao longo do dia.
+
+
+
+ Estou encontrando mais oportunidade para espalhar 'momentos de criatividade' no meio do dia, em vez de tentar desligar à noite.
+
+— @danielroe , mantenedor do Nuxt
+
+
+
+* **Estabeleça limites:** Você não pode dizer sim para todos os pedidos. Isso pode ser tão simples quanto dizer: "Não consigo fazer isso agora e não tenho planos de fazê-lo no futuro" ou listar o que você tem interesse em fazer e o que não tem no README. Por exemplo, você pode dizer: "Só aceito solicitações de pull que tenham razões claras para sua criação" ou "Só reviso problemas em todas as quintas-feiras, das 18h às 19h." Isso estabelece expectativas para os outros e fornece algo a que você pode se referir em outros momentos para ajudar a reduzir as demandas de colaboradores ou usuários sobre o seu tempo.
+
+
+
+Para confiar de forma significativa em outras pessoas nesses aspectos, você não pode ser alguém que diz sim para todos os pedidos. Ao fazer isso, você não mantém limites, profissionais ou pessoais, e não será um colega confiável.
+
+— @mikemcquaid , mantenedor do Homebrew em [Dizer Não](https://mikemcquaid.com/saying-no/)
+
+
+
+ Aprenda a ser firme em desligar comportamentos tóxicos e interações negativas. Não há problema em não dar energia a coisas com as quais você não se importa.
+
+
+
+Meu software é gratuito, mas meu tempo e atenção não são.
+
+— @IvanSanchez , mantenedor do Leaflet
+
+
+
+
+
+Não é segredo que a manutenção de código aberto tem seus lados negros, e um deles é ter que interagir às vezes com pessoas bastante ingratas, arrogantes ou abertamente tóxicas. À medida que a popularidade de um projeto aumenta, aumenta também a frequência desse tipo de interação, aumentando o fardo dos mantenedores e se tornando possivelmente um fator de risco significativo para o esgotamento do mantenedor.
+
+— @foosel , mantenedor do Octoprint em [Como lidar com pessoas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+Lembre-se, a ecologia pessoal é uma prática contínua que evoluirá à medida que você avança em sua jornada de código aberto. Ao priorizar o autocuidado e manter um senso de equilíbrio, você pode contribuir para a comunidade de código aberto de forma eficaz e sustentável, garantindo tanto o seu bem-estar quanto o sucesso de seus projetos a longo prazo.
+
+## Recursos Adicionais
+
+* [Comunidade de Mantenedores](http://maintainers.github.com/)
+* [O contrato social do código aberto](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [Como lidar com pessoas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Kit de autoavaliação de ecologia pessoal](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Arte da Liderança Rockwood](https://rockwoodleadership.org/art-of-leadership/)
+* [Dizer Não](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governança do Código Aberto](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* A agenda do workshop foi adaptada a partir da série [Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) da Mozilla.
+
+## Contribuidores
+
+Muito obrigado a todos os mantenedores que compartilharam suas experiências e dicas conosco para este guia!
+
+Este guia foi escrito por [@abbycabs](https://github.com/abbycabs) com contribuições de:
+
+[@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) + muitos outros!
diff --git a/_articles/ro/how-to-contribute.md b/_articles/ro/how-to-contribute.md
index ed1a435c010..3c2fcb95ebf 100644
--- a/_articles/ro/how-to-contribute.md
+++ b/_articles/ro/how-to-contribute.md
@@ -237,7 +237,6 @@ Poți de asemenea folosi una dintre următoarele resurse pentru a te ajuta să d
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/ro/legal.md b/_articles/ro/legal.md
index 0dcf7c8dcec..14a1c197dab 100644
--- a/_articles/ro/legal.md
+++ b/_articles/ro/legal.md
@@ -147,7 +147,7 @@ Dacă lansezi primul proiect cu sursă deschisă al companiei, ce este scris mai
Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta compania să obțină mai mult din implicarea ei în open source, și pentru a rămâne în siguranță:
-* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/) al Rackspace.
+* **Politici de contribuție a angajaților:** Consideră dezvoltarea unei politici corporative care specifică felul în care angajații dumneavoastră contribuie la proiecte cu sursă deschisă. O politică clară va reduce confuzia în rândul angajaților dumneavoastră și îi va ajuta să contribuie la proiecte cu sursă deschisă în interesul companiei, fie ca parte a locurilor lor de muncă sau în timpul lor liber. Un exemplu este [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) al Rackspace.
@@ -160,7 +160,7 @@ Pe termen lung, echipa voastră juridică poate face mai mult pentru a ajuta com
-— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["A Model IP and Open Source Contribution Policy"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/ro/maintaining-balance-for-open-source-maintainers.md b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..5c1efa15935
--- /dev/null
+++ b/_articles/ro/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ro
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/ru/how-to-contribute.md b/_articles/ru/how-to-contribute.md
index ddef7a39287..581fb52138d 100644
--- a/_articles/ru/how-to-contribute.md
+++ b/_articles/ru/how-to-contribute.md
@@ -213,7 +213,6 @@ related:
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/ru/legal.md b/_articles/ru/legal.md
index 00cd216088c..b010b6a7046 100644
--- a/_articles/ru/legal.md
+++ b/_articles/ru/legal.md
@@ -134,13 +134,13 @@ related:
В долгосрочной перспективе ваша команда юристов может сделать больше, чтобы помочь компании получить больше от своего участия в проектах с открытым исходным кодом и оставаться в безопасности:
-* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Типовая политика в отношении интеллектуальной собственности и открытого исходного кода](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Политики участия сотрудников:** Рассмотрите возможность разработки корпоративной политики, определяющей, как ваши сотрудники вносят вклад в проекты с открытым исходным кодом. Четкая политика уменьшит путаницу среди ваших сотрудников и поможет им внести свой вклад в проекты с открытым исходным кодом в интересах компании, будь то в рамках своей работы или в свободное время. Хорошим примером является политика Rackspace [Типовая политика в отношении интеллектуальной собственности и открытого исходного кода](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
Предоставление IP-адреса, связанного с патчем, создает базу знаний и репутацию сотрудника. Это показывает, что компания инвестирует в развитие этого сотрудника, и создает ощущение полномочий и автономии. Все эти преимущества также приводят к повышению морального духа и лучшему удержанию сотрудников.
-— @vanl, ["Типовая политика в отношении интеллектуальной собственности и открытого исходного кода"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Типовая политика в отношении интеллектуальной собственности и открытого исходного кода"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/ru/maintaining-balance-for-open-source-maintainers.md b/_articles/ru/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..047e92d015a
--- /dev/null
+++ b/_articles/ru/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ru
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/ta/legal.md b/_articles/ta/legal.md
index 5807627bea6..57a0ca8ce29 100644
--- a/_articles/ta/legal.md
+++ b/_articles/ta/legal.md
@@ -133,13 +133,13 @@ Yஉங்கள் திட்டம் **சார்புகள்** கொ
நீண்ட காலமாக, உங்கள் சட்ட குழு நிறுவனம், திறந்த மூலத்தில் அதன் ஈடுபாட்டிலிருந்து நிறுவனத்தின் உதவியை அதிகரிக்க உதவ முடியும், மேலும் பாதுகாப்பாக இருக்கவும்:
-* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/).
+* **Eபணியாளர் பங்களிப்பு கொள்கைகள்:** உங்கள் பணியாளர்கள் மூல திட்டங்களை திறக்க எப்படி உதவுகிறது என்பதைக் குறிப்பிடும் ஒரு பெருநிறுவனக் கொள்கையை உருவாக்குங்கள். ஒரு தெளிவான கொள்கை உங்கள் ஊழியர்களிடையே குழப்பத்தை குறைக்கும் மற்றும் நிறுவனங்களின் சிறந்த வட்டி, அவர்களது வேலைகள் அல்லது தங்களின் இலவச நேரத்திலோ, மூல திட்டங்களை திறக்க உதவுகிறது. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/).
ஒரு இணைப்புடன் தொடர்புடைய ஐபி முகவரியை ஊழியர் அறிவுத் தளம் மற்றும் புகழ் உருவாக்குகிறது. அந்த நிறுவனம் அந்த ஊழியரின் வளர்ச்சியில் முதலீடு செய்யப்பட்டு, அதிகாரமளித்தல் மற்றும் சுயாட்சியை உருவாக்குவதற்கான உணர்வுகளை உருவாக்குகிறது என்பதை இது காட்டுகிறது. இந்த நன்மைகள் அனைத்தும் உயர்ந்த மன வலிமையயும், சிறந்த பணியாளருக்கும் தக்கவைக்கும்.
-— @vanl, ["மாதிரி ஐபி மற்றும் திறந்த மூல பங்களிப்பு கொள்கை"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["மாதிரி ஐபி மற்றும் திறந்த மூல பங்களிப்பு கொள்கை"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/ta/maintaining-balance-for-open-source-maintainers.md b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..ed52f315d72
--- /dev/null
+++ b/_articles/ta/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: ta
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/tr/how-to-contribute.md b/_articles/tr/how-to-contribute.md
index e97b7d07903..189f26e183e 100644
--- a/_articles/tr/how-to-contribute.md
+++ b/_articles/tr/how-to-contribute.md
@@ -213,7 +213,6 @@ Yeni projeleri keşfetmenize ve katkıda bulunmanıza yardımcı olmak için aş
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](https://up-for-grabs.net/)
-* [Contributor-ninja](https://contributor.ninja)
* [First Contributions](https://firstcontributions.github.io)
* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/)
diff --git a/_articles/tr/legal.md b/_articles/tr/legal.md
index 9fd2f1a1c94..0a63171ce68 100644
--- a/_articles/tr/legal.md
+++ b/_articles/tr/legal.md
@@ -134,13 +134,13 @@ Daha iyi veya daha kötüsü, kişisel bir proje olsa bile, onlara bildirmeyi d
Daha uzun vadede hukuk ekibiniz, şirketin açık kaynaklara katılımından daha fazlasını elde etmesi ve güvende kalması için daha fazlasını yapabilir:
-* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)'dır.
+* **Çalışanlar için katkı politikaları:** Çalışanlarınızın açık kaynaklı projelere nasıl katkıda bulunduğunu belirten bir kurumsal politika geliştirmeyi düşünün. Açık bir politika, çalışanlarınız arasındaki karmaşayı azaltacaktır ve işlerinin bir parçası olarak veya boş zamanlarında, şirketin çıkarlarına faydalı olacak şekilde açık kaynak projelere katkıda bulunmalarına yardımcı olacaktır. Buna iyi bir örnek Rackspace'in [Model IP'si ve Açık Kaynak Katkı Politikası](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)'dır.
Bir yama ile ilgili IP'nin serbest bırakılması, çalışanın bilgi birikimini ve itibarını arttırır. Şirketin bu çalışanın gelişimine yatırım yaptığını ve bir güçlendirme ve özerklik duygusu yarattığını göstermektedir. Tüm bu faydalar ayrıca daha yüksek moral ve daha iyi bir çalışanın kalmasına yol açmaktadır.
-— @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/)
+— @vanl, ["Bir Model IP ve Açık Kaynak Katkı Politikası"](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/)
diff --git a/_articles/tr/maintaining-balance-for-open-source-maintainers.md b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..3f3ca65161b
--- /dev/null
+++ b/_articles/tr/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: tr
+untranslated: true
+title: Maintaining Balance for Open Source Maintainers
+description: Tips for self-care and avoiding burnout as a maintainer.
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run.
+
+To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community , allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As described by the Rockwood Leadership Institute , it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime ." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with.
+
+
+
+ I was unable to focus or start on a task. I had a lack of empathy for users.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+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.
+
+
+
+ Sometimes it feels a bit like shouting into the void and I find that feedback really energizes me. We have lots of happy but quiet users.
+
+— @thisisnic , maintainer of Apache Arrow
+
+
+
+* **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.
+
+
+
+ I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+
+— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+
+
+
+* **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.
+
+
+
+ Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+
+— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+
+
+
+* **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) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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/).
+
+
+
+ I was on a podcast a while ago and we were chatting about open source maintenance and sustainability. I found that even a small number of people supporting my work on GitHub helped me make a quick decision not to sit in front of a game but instead to do one little thing with open source.
+
+— @mansona , maintainer of EmberJS
+
+
+
+* **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.
+
+
+
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+
+— @danielroe , maintainer of Nuxt
+
+
+
+* **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.
+
+
+
+To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
+
+— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+
+
+
+ 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.
+
+
+
+My software is gratis, but my time and attention is not.
+
+— @IvanSanchez , maintainer of Leaflet
+
+
+
+
+
+It's no secret that open source maintenance has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.
+
+— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+
+
+
+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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!
diff --git a/_articles/zh-hans/best-practices.md b/_articles/zh-hans/best-practices.md
index 4549cdadebc..f68fbfe41ea 100644
--- a/_articles/zh-hans/best-practices.md
+++ b/_articles/zh-hans/best-practices.md
@@ -94,7 +94,7 @@ redirect_from: /zh-cn/best-practices/
- 管理大型开源项目的关键就是保证 issue 活跃。尽量避免让 issue 停滞不前。如果你是一个IOS开发者,你会知道提交雷达 是多么让人沮丧。您可能会在2年后收到回复,并被告知要再次使用最新版本的iOS。
+ 管理大型开源项目的关键就是保证 issue 活跃。尽量避免让 issue 停滞不前。如果你是一个iOS开发者,你会知道提交雷达 是多么让人沮丧。您可能会在2年后收到回复,并被告知要再次使用最新版本的iOS。
— @KrauseFx, ["开源社区黑客增长"](https://krausefx.com/blog/scaling-open-source-communities)
diff --git a/_articles/zh-hans/building-community.md b/_articles/zh-hans/building-community.md
index 2c77538531b..1e0591f409e 100644
--- a/_articles/zh-hans/building-community.md
+++ b/_articles/zh-hans/building-community.md
@@ -132,7 +132,7 @@ redirect_from: /zh-cn/building-community/
随着项目的成长,好的文档会变得愈加重要。临时贡献者或路人是不可能一下子就对项目非常熟悉,一份好的文档,能够很快找到他们需要的。
-在 CONTRIBUTING 文件里,需要明确告诉新来的贡献者该如何开始。而且若是可能为了想要达到这个目的,还需要准备一个专门的部分。
+在 CONTRIBUTING 文件里,需要明确告诉新来的贡献者该如何开始。你甚至可能为此专门准备一个独立的部分:例如 [Django](https://github.com/django/django), 就提供一个专门的首页面来欢迎和指导新晋贡献者。
![django new contributors page](/assets/images/building-community/django_new_contributors.png)
@@ -144,7 +144,7 @@ redirect_from: /zh-cn/building-community/
例如,这里是[Rubinius](https://github.com/rubinius/rubinius/)如何开始[它的贡献指南](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
-> 我们想感谢你们使用Rubinius。这个项目是一个充满爱的工作,我们希望所有用户查找bugs,取得性能上的提升,以及帮助完善文档。每一个贡献都是有意义的,所以感谢你们的参与。话虽如此,但我们还是要求你们遵守一些指南,这样我们就能够找到你们的issue。
+> 我们想感谢你们使用Rubinius。这个项目是一个充满爱的工作,我们希望所有用户查找bugs,取得性能上的提升,以及帮助完善文档。每一个贡献都是有意义的,所以感谢你们的参与。话虽如此,但我们还是要求你们遵守一些指南,这样我们就能够解决你们的issue。
### 共享项目所有权
@@ -164,7 +164,7 @@ redirect_from: /zh-cn/building-community/
![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
-* **在项目中添加一个贡献者或者作者文件** 用于记录每一个参与贡献的人。
+* **在项目中添加一个贡献者文件(CONTRIBUTORS) 或者作者文件(AUTHORS)** 用于记录每一个参与贡献的人。
* 如果社区有了一定的规模,那么 **发送一封信或者发表一篇博客** 感谢贡献者们。Rust的[Rust周报](https://this-week-in-rust.org/)和Hoodie的[Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)就是两个非常好的范例。
@@ -174,7 +174,7 @@ redirect_from: /zh-cn/building-community/
事实上很多项目只有一个或者两个做大量工作的维护者。随着项目以及社区越来越大,就会有更多的人参与进来。
-虽然并不是一直都有人在回答问题,但是你可以去增加一些信号,以让他人有能够接触的机会,越是尽早开始,越是能够获得帮助。
+虽然并不是一直都有人在回答问题,但是你可以去增加一些信号,以让他人有能够加入的机会,越是尽早开始,越是能够获得帮助。
@@ -213,8 +213,8 @@ redirect_from: /zh-cn/building-community/
### 将你们的README视为最高法则
-README [不仅仅是一组指令](../starting-a-project/#撰写自述文件)。它也是一个谈论目标、产品愿景和路线的地方。
-如果人们过分专注于讨论特定功能的优点,它可能有助于重新审视您的README,并谈论项目的更高的愿景。关注README也会使对话变得个人化,所以可以进行建设性的讨论。
+README [不仅仅是一个简单的说明](../starting-a-project/#撰写自述文件)。它也是一个谈论目标、产品愿景和路线的地方。
+如果人们过分专注于讨论特定功能的优点,那么你可能需要重新审视您的README,并谈论项目的更高的愿景。关注README也会使对话变得个人化,所以可以进行建设性的讨论。
### 专注过程,而不是结果
diff --git a/_articles/zh-hans/finding-users.md b/_articles/zh-hans/finding-users.md
index 37d969e64cb..01e4548b564 100644
--- a/_articles/zh-hans/finding-users.md
+++ b/_articles/zh-hans/finding-users.md
@@ -13,112 +13,112 @@ redirect_from: /zh-cn/finding-users/
## 四处传播
-并没有什么规范说当你创建一个开源项目时,要怎么去推广它。但没有任何理由说必须默默无闻的在开源项目上工作。相反,如果你想要有更多的人发现和使用你的开源项目,你就应该让所有人知道你所努力的成果!
+当你创建了一个开源项目时,并没有规定你要如何宣传它。也不是说你要默默地维护你的项目。相反,如果你希望更多人发现并使用你的开源项目,你应该大胆地让所有人知道你的努力!
## 发出你的声音
-在开始推广你的项目之前,你应该能够解释你的项目是做什么的,为什么大家需要它?
+你在开始宣传你的项目之前,应该解释你的项目是做什么的,以及大家为什么需要它?
-是什么让你的项目变得不同或者有趣,在自己心中问这些问题会让你更容易说服别人。
+你的项目有什么与众不同或者有趣的地方,如果你自己心中明白这些问题会让你更容易地说服别人。
-牢记一件事情,别人之所以使用你的项目,甚至是为你的项目做贡献,是因为你的项目解决了他们的问题。所以你要找出他们需要什么,然后把它当成你项目的卖点或者说价值所在。
+请牢记一点,别人之所以会使用你的项目,甚至为你的项目做贡献,是因为你的项目解决了他们的问题。所以你需要找出他们的痛点,然后把它当成你项目的卖点或者说价值所在。
-举个例子,[@robb](https://github.com/robb)用代码实例来清晰的阐述为什么他的项目[Cartography](https://github.com/robb/Cartography)是有用的。
+举个例子,[@robb](https://github.com/robb)用代码实例来清晰的阐述为什么他的项目 [Cartography](https://github.com/robb/Cartography) 是有用的。
![cartography readme](/assets/images/finding-users/cartography.jpg)
-如果你想深入了解如何挖掘项目的"卖点",看一下Mozilla的["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/),练习如何建立用户的形象。
+如果你想深入了解如何挖掘项目的"卖点",看一下 Mozilla 的 ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/),学习如何建立用户形象。
-## 帮助用户找到并且追随你的项目
+## 帮助用户发现并关注你的项目
- 你最好有一个唯一的"主页"链接用来推广,引导人们关注你的项目。你不需要找一个炫酷的模板或者域名,但是你的项目确实需要一个入口。
+ 你最好有一个唯一的官方"主页"链接用来宣传,引导人们关注你的项目。你不需要找炫酷的模板或者域名,但是你的项目确实需要一个入口。
— Peter Cooper & Robert Nyman, ["How to Spread the Word About Your Code"](https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/)
-通过引导他们到一个唯一的地址来帮助人们发现和记住你的项目。
+通过引导他们到一个唯一的官方地址来帮助人们发现和记住你的项目。
-**要有一个推广的主阵地。**一个Twitter账号,GitHub链接,或者IRC频道是引导人们查看你的项目的一个简单方式。这些方式也给你日益增长的社区一个讨论的好地方。
+**要有一个宣传的主阵地**。一个 Twitter 账号、GitHub 链接或者 IRC 频道是引导人们查看你项目的简单方式。这些方式也将会给你后续成长起来的社区有一个讨论的地方。
-如果你目前还不想给你的项目搞这么多乱七八糟的东西,只要在有机会的时候推广你的Twitter账户和GitHub账户即可。举个例子,如果你在某一个讨论会或者活动上发言要保证在你的简历或者幻灯片上包含这些信息。只有这样人们才会知道怎么找到你或者关注你的工作。
+如果你目前还不想给你的项目搞这么多乱七八糟的东西,只想在合适的时候再宣传你的 Twitter 账户和 GitHub 账户即可。举个例子,当你在某次讨论或者活动上发言时,你可以在简介或者幻灯片上写上这些信息。这样人们就会了解你或者关注你的项目。
- 我之前犯过的一个错误就是没有给项目开一个Twitter账户。Twitter是一个让人们知晓项目进展的好渠道,也可以让人们持续的接触到你的项目。
+ 我之前的一个失误就是没给项目开一个 Twitter 账户。Twitter 是一个让人们了解项目进展的好渠道,也可以让人们持续地接触你的项目。
— @nathanmarz, ["History of Apache Storm and Lessons Learned"](http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html)
-**考虑给你的项目做一个网站**一个网站可以让你的项目更加友好,而且更加容易浏览,更重要的是附上清晰的文档和教程。这也是象征着你的项目还是活跃的,这会让你的用户在使用项目时感觉更放心。可以用一些例子告诉人们如何使用你的项目。
+**考虑给你的项目做个网站**一个网站可以让你的项目更加友好,也更加容易浏览,更重要的是附上清晰的文档和教程。这也证明你的项目是活跃的,会让你的用户更放心地使用项目。可以用一些例子告诉人们如何使用你的项目。
-[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django的作者说,我们给Django做的网站可以说是"在早期开发Django的时候做的最好的一件事情了"。
+[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django 的作者说,我们给 Django 做的网站可以说是"在早期开发 Django 的时候做的最好的一件事情了"。
-如果你的项目是托管在GitHub上的,你可以用[GitHub Pages](https://pages.github.com/)简单地创建一个网站。[Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) 是一些优秀的内容详尽的网站[例子](https://github.com/showcases/github-pages-examples)
+如果你的项目是托管在 GitHub 上的,你可以用 [GitHub Pages](https://pages.github.com/) 简单创建一个网站。[Yeoman](http://yeoman.io/)、[Vagrant](https://www.vagrantup.com/) 和 [Middleman](https://middlemanapp.com/) 是一些内容详细的优质网站[示例](https://github.com/showcases/github-pages-examples)。
![vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
-现在你的项目有了"卖点",和让人们很容易发现你项目的渠道,接下来我们谈谈如何和你的用户交流吧!
+现在你的项目有了"卖点"和容易被人们发现的渠道,接下来我们谈谈如何与你的用户交流吧!
-## 在线上寻找你的项目用户
+## 在网上寻找你项目的用户
-网上拓展是分享和快速宣传项目的一个好方法。借助一些网上的渠道,你有可能找到一大批受众。
+网络社区与论坛是分享和快速宣传项目的一个好地方。借助这些渠道,你有可能找到一大批受众。
-利用好已有的线上社区和平台去找你的受众。如果你的开源项目是一个软件项目,你可能会在[Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), 或者[Quora](https://www.quora.com/),找到你认为最有可能从你的项目中受益或者对你项目感兴趣的渠道。
+利用好已有的线上社区和平台去找你的受众。如果你的开源项目是一个软件项目,你可以在 [Stack Overflow](https://stackoverflow.com/)、[reddit](https://www.reddit.com)、[Hacker News](https://news.ycombinator.com/) 或 [Quora](https://www.quora.com/) 找到可能从你的项目中受益或者感兴趣的话题。
- 每个程序都会有那么一些方法只有一部分人才会用到,所以不要想着去打扰每一个人,把你的力气用在可能会从你项目受益的社区就好。
+ 每个程序都会有一些方法是只有一部分人才用得到的,所以不打扰到所有人,把你的关注点放在可能会从你项目受益的话题就好。
— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
-来看看下面的一些方法吧,也许推广你的项目的时候用得着。
+看看下面的这些方法,获取在宣传你的项目时用得着。
-* **快找找有没有相关的开源项目和社区。**有时候,你不需要直接推广你的项目。如果你的项目对使用Python的数据科学家来说是无可挑剔的,那么就去找Python数据科学的社区。等他们知道你的项目之后,很自然的就会谈论然后分享你的工作成果。
-* **如果你的项目尝试解决某些问题,那么找到会遇到这些问题的人。**想一下你的项目受众会在哪些论坛,然后搜索这些论坛,回答他们的问题,然后找一个合适的时机,向他们建议使用你的项目来作为一种解决方案。
-* **寻求反馈。**向一个可能会用到你项目的人介绍你自己和你做的工作。对哪些人会从你的项目受益要很明确。尝试完善一下下面这句话:"我觉得我的项目能够帮助到A,那些尝试做B事情的人"。听取和回复别人的反馈,而不是简单的推广。
+* **快速找一下有没有相关的开源项目和社区**。有时候,你不要直接宣传你的项目。如果你的项目对使用 Python 的数据科学家来说是无可挑剔的,那么就去 Python 数据科学的社区宣传。等他们知道你的项目之后,很自然的就会谈论然后分享你的成果。
+* **如果你的项目能够解决特定问题,找到会遇到这些问题的人**。想想你的项目受众会在哪些论坛,然后搜索这些论坛,回答他们提出的问题,然后找一个合适的时机,向他们建议使用你的项目来作为一种解决方案。
+* **寻求反馈**。向可能会用到你项目的人介绍你自己和你的项目。请确保这些人是从你项目中受益的人。试着完善下面这句话:"我觉得我的项目能够帮助到 A,或者那些尝试做 B 事情的人"。不要只是简单地宣传,更需要学会倾听和回复别人的反馈。
-一般来说,在你索取什么回报之前先把精力放在帮助别人上。因为在网上推广一个项目对任何人都是一个不难的事情,肯定会有一些不同的声音。告诉人们你是谁,而不是你想要什么,这样才能从众多推广者中脱颖而出。
+通常,你应该先想着帮助别人而不是获取回报。因为在网上宣传一个项目对任何人来说都很简单,所以肯定会有很多人在做同样的事情。告诉人们你是谁,而不是你想要什么,这样才能从众多宣传者中脱颖而出。
-如果没有人对你的推广感兴趣,不要灰心!大部分的项目的开展都是一个要花费数月和数年的反复过程。如果你第一次没收到反应,尝试换一种策略,或者找办法给别人的项目做做贡献。这都是些需要时间和奉献精神的事情。
+如果没有人对你的宣传感兴趣,不要灰心!大部分项目的发展都可能需要花费数月甚至数年。如果你开始的宣传没收到任何反馈,尝试换一种策略,或者想办法给别人的项目做贡献。这些都是需要时间和奉献精神的。
## 在线下寻找你的项目用户
![public speaking](/assets/images/finding-users/public_speaking.jpg)
-线下活动是向观众推广新项目的常见方式之一。这是一个接触某个忠实听众和建立深层次联系的好方式,特别是如果你对到场的开发者感兴趣的话。
+线下活动是向观众宣传新项目的常见方式之一。这是一个接触忠实倾听者,建立深层次联系的好方法,如果你对到场的开发者感兴趣的话那就更好了。
-如果你还是个[公众演讲的新手](https://speaking.io/),从寻找一个和你项目使用的语言或者生态系统相关的当地的聚会开始吧。
+如果你还是个[公开演讲的新手](https://speaking.io/),找一个你项目使用的语言或者生态系统相关的线下聚会去尝试吧。
- 我去PyCon的时候非常紧张。我要发表一个演讲,在那儿我就认识几个人,还在那儿呆了整整一周。但是其实我不应该焦虑的。PyCon真是太棒了!每个人都是超级友好外向,以至于我很少有时间不和别人讲话。
+ 我去 PyCon 的时候非常紧张。我要发表一次演讲,在那儿我只认识几个人,还是在那儿呆了整整一周。其实我不应该焦虑的。PyCon 真是太棒了!每个人都是非常友好热情,以至于我也非常愿意和大家讨论。
— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)
-如果你从来没在公共场合讲过话,感觉紧张那就太正常啦!记住你的听众就在那儿,因为他们都是真正的想听你介绍你的项目。
+如果你从来没在公共场合演讲过,感到紧张是很正常的!记住你的听众和你在一起,他们都是真正想听你介绍你的项目。
-当你在写你的演讲稿的时候,把重点放在你的听众会感兴趣而且能获取价值的事情上。保证你的语言要友好和亲切。笑一笑,深呼吸,幽默一点儿。
+当你在写你演讲稿的时候,把重点放在你的听众会感兴趣而且有价值的事情上。保证你的语言要友好且亲切。笑一笑,深呼吸,幽默一点儿。
- 当你开始写你的演讲稿的时候,不管你的主题是什么,如果你能把你的演讲当成是给别人讲故事的话,效果会更好。
+ 你写演讲稿的时候,不管你的主题是什么,如果你能把你的演讲当成是给别人讲故事的话,效果会更好。
— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)
-等你准备好了,考虑一下在某个会议上发言的时候推广你的项目研讨会可以帮助你接触更多人,有时候是来自全世界各地的人。
+等你准备好了,考虑在某个会议上发言的时候宣传你的项目讨论可以帮助你接触更多人,可能会是来自世界各地的人。
- 我非常认真的给JSConf的人写了一封信,然后求他们给我一点时间在JSConf上展示我的项目。同时我又非常担心,这个项目我做了六个月,要是大家不认可怎么办。那时候我就一直在想,我的天,我在这里都干些什么事啊?
+ 我非常认真地给 JSConf 的人写了一封信,然后请求他们给我一点时间在 JSConf 上展示我的项目。同时我也会担心,这个项目我做了六个月,如果大家不认可怎么办。那时候我就一直在想,我的天,我在这里都干些什么事啊?
— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)
@@ -128,22 +128,22 @@ redirect_from: /zh-cn/finding-users/
除了上面提到的策略之外,邀请人们分享和支持你的项目的最好办法就是分享和支持他们的项目。
-帮助新手,分享资源,给别人的项目认真的做贡献会帮助你建立起良好的声誉。然后他们就很有可能知道你的项目而且更有可能关注和分享你在做的事情。
+帮助新手,分享资源,认真地给别人的项目做贡献,会帮助你建立起良好的声誉。然后他们就很有可能知道你的项目而且更有可能关注和分享你在做的事情。
-有时候,这些关系还会进一步发展成更广阔的生态系统中的官方合作伙伴(意思是你有可能成为那些知名社区的成员)
+有时候,这些关系还会进一步发展成更宽泛的生态中的官方合作伙伴(意思是你有可能成为那些知名社区的成员)
- urllib3现在成为最流行的Python第三方库的唯一原因就是大家都需要它。
+ urllib3 现在成为最流行的 Python 第三方库的唯一原因就是大家都需要它。
— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov/)
-种一棵树的最好时间是十年前,其次是现在。所以任何时候开始建立你的声望都不晚。即使是你早就已经建立了自己的项目,也还是要继续找办法帮助别人。
+种一棵树最好是在十年前,也是现在。所以任何时候开始建立你的声誉都不晚。即使是你是在很久以前建立的项目,也需要继续维护它并找办法帮助别人。
-建立用户群没有一蹴而就的方法。获取别人的信任和尊重需要时间,同样,建立声望的过程也永远不会停止。
+建立用户基础并不是一蹴而就的。获取别人的信任和尊重需要时间,同样,建立声誉也需要一直坚持下去。
## 保持下去!
-有时候,让人们注意你的开源项目会花费很多时间。但是没关系!一些今天很流行的项目都是花了很多年才有如今的高活跃度。把重点放在建立声望上而不是企图一夜成名。耐心一点,一如既往的和那些可能会从中受益的人分享你的项目。
+有时候,让人们关注你的开源项目会花费很多时间。没关系!一些今天很流行的项目都是花了很多年才有如今的高活跃度的。把重点放在建立声誉上而不要企图一夜成名。保持耐心,请一如既往地和那些可能会从中受益的人分享你的项目。
diff --git a/_articles/zh-hans/legal.md b/_articles/zh-hans/legal.md
index 41a505b3191..ca8ac47e9be 100644
--- a/_articles/zh-hans/legal.md
+++ b/_articles/zh-hans/legal.md
@@ -89,7 +89,7 @@ redirect_from: /zh-cn/legal/
## 我们的项目需要额外的贡献者协议吗?
-可能不要。对于大多数的开源项目,一个开源许可协议可作用与所有贡献者和用户。
+可能不要。对于大多数的开源项目,一个开源许可协议可作用于所有贡献者和用户。
贡献者协议会给维护者带来额外的管理工作。这些协议增加了多少工作得取决去项目和实施。简单的协议可能要求贡献者确认和点击,在项目的开源许可协议下他们有权利贡献。更复杂的协议可能需要法律的审查和贡献者的雇主的签字。
diff --git a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..e4996e13c30
--- /dev/null
+++ b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,221 @@
+---
+lang: zh-hans
+untranslated: true
+title: 保持开源维护者的平衡
+description: 作为维护者的自我护理和避免倦怠的技巧。
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+当一个开源项目越来越受欢迎时,设定清晰的边界来帮助您长时间保持活力和生产力就变得尤为重要了。
+
+为了深入了解维护者的经验及他们如何找到工作平衡,我们与维护者社区 的 40 名成员举办了一个 workshop。通过这样的方式,我们得以学习到他们在开源领域所经历的疲劳过度的第一手情况,以及他们采取了哪些实践来在工作中维持平衡。这正是"个人生态学"概念得以应用的场景。
+
+那么,个人生态学是什么?根据 Rockwood Leadership Institute 的描述 ,它是"在我们的一生中,维持平衡、节奏和效率以保持能量 ”。这种观点为我们的交流提供了一个结构,帮助维护者意识到随时间发展,他们的行为和贡献是一个更大的生态系统中的组成部分。根据[世卫组织的定义](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281),由长时间的工作压力引起的综合症状,即"疲劳过度",在维护者中并不罕见。这常常会导致失去工作动力、无法集中精力,以及对与之合作的贡献者和社区感到缺乏同情和理解。
+
+
+
+通过理解个人生态学的理念,维护者可以主动避免疲劳,把自我护理放在首位,并保持心态平和,从而更好地工作。
+
+## 作为维护者的自我护理和避免疲劳的提示:
+
+### 确定您参与开源工作的动机
+
+花时间思考哪些开源维护任务能激发您的热情。明白自己的驱动力可以帮您更有针对性地安排工作,保持热情并随时迎接新挑战。不论是用户的正面反馈、与社区的互动乐趣,还是深入探索代码带来的成就感,了解这些驱动力都能帮助您更好地集中精力。
+
+### 反思什么使您失去平衡并感到压力
+
+知道哪些因素导致我们感到疲倦是非常关键的。以下是在开源维护者中常见的一些情况:
+
+* **缺乏积极的反馈:** 用户在遇到问题时更容易给出反馈。而当一切正常时,他们往往不会说什么。看到问题列表不断增长,而缺乏正面反馈来展示您的贡献所带来的改变,这可能会让人感到挫败。
+
+
+
+* **不说'不':** 在开源项目中,很容易承担超过自己能力范围的责任。不论是来自用户、贡献者还是其他维护者,我们不能始终满足每个人的期望。
+
+
+
+* **独自工作:** 作为维护者可能会感到很孤单。即使你与一群维护者合作,过去几年也很难召集分布在各地的团队。
+
+
+
+* **时间或资源不足:** 对于那些不得不牺牲自己休息时间来参与项目的志愿维护者来说,这尤其是真实的。
+
+
+ [我希望]能得到更多的经济支持,这样我可以全心投入到开源工作中,而不是消耗掉自己的储蓄,然后担心未来需要做大量的工作来补偿这一损失。
+
+— 开源维护者
+
+
+
+* **需求冲突:** 开源社区有很多出于不同目的而参与的团队,这有时会难以处理。如果您是被雇来进行开源工作的,那么您的雇主的利益有时与社区的利益可能不会完全一致。
+
+
+ 在有偿的开源工作中,雇主的关注点和对社区最有益的事物之间可能会存在矛盾。
+
+— 开源维护者
+
+
+
+### 注意疲劳的迹象
+
+这样的节奏你能保持多久?10周?10个月?还是10年?
+
+有像 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 Mozilla 的[个人生态自评工具包](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw)这样的工具可以帮助你反思自己现在的工作节奏,看是否需要进行某些调整。一些维护者还利用可穿戴设备来监测睡眠质量和心率变异性等与压力有关的指标。
+
+
+ 我深信好的可穿戴设备的作用。有了其背后的科学依据,你可以了解如何更好地调整自己,达到完成任务的最佳状态。
+
+— 开源维护者
+
+
+
+### 您需要什么来继续支撑自己和您的社区?
+
+对每位维护者而言,这都会有所区别,并且会随着您的生活阶段和其他外部因素发生变化。但以下是我们收到的一些共同点:
+
+* **依赖社区:** 分配任务和寻找贡献者可以帮助减轻你的负担。对一个项目而言,有多个协作者能让你放心休息。与其他维护者以及更广大的社区,如 [Maintainer Community](http://maintainers.github.com/) 建立联系,这对于获得同行的支持和学习都是宝贵的资源。
+
+ 您还可以探索与用户社区的交互方式,这样可以定期收到反馈,了解您在开源工作中所做的贡献的影响。
+
+* **寻找资金:** 不管您是想找点小钱买披萨,还是计划全职投身开源,都有众多资源可供参考!首先,可以考虑开通 [GitHub Sponsors](https://github.com/sponsors) 让其他人赞助您的开源项目。如果您打算全职转型,可以申请下一期的 [GitHub Accelerator](http://accelerator.github.com/)。
+
+
+
+* **使用工具:** 考虑使用像 [GitHub Copilot](https://github.com/features/copilot/) 和 [GitHub Actions](https://github.com/features/actions) 这样的工具,自动化常规任务,从而为更有价值的工作腾出时间。
+
+
+ 使用 [Copilot](https://github.com/features/copilot/) 来处理无聊的事情 - 做有趣的事情
+
+— 开源维护者
+
+
+
+* **休息和充电:** 留出时间享受开源之外的爱好和兴趣。利用周末休息和充电,并调整您的 [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) 来显示您是否在线!良好的睡眠对于长期保持工作热情和效率至关重要。
+
+ 如果您发现项目中某些部分特别令人享受,试着调整您的工作,这样您每天都可以体验到这种愉悦。
+
+
+
+* **设定界限:** 您不能对每个请求都回应"好"。您可以简单地回答:"我现在做不到,而且未来可能也不会这么做。"或者在 README 中明确列出您愿意做和不愿意做的事情。例如,您可以写:"我只会合并那些清晰解释了为何创建的 PR。”或者,"我只在每两周的星期四的6-7点审查问题。”这样可以为他人设定预期,并在其他时间为您提供一个可以参考的依据,从而减少贡献者或用户对您时间的要求。
+
+
+
+学会坚决制止有毒的行为和消极的互动。不对你不在乎的事情投入精力是完全可以的。
+
+
+
+
+
+请记住,个人生态是随着您在开源之旅中不断前行而演变的持续实践。通过把自我护理和保持平衡放在首位,您可以为开源社区提供持续有效的贡献,确保自己的健康和项目的长久发展。
+
+## 额外资源
+
+* [Maintainer Community](http://maintainers.github.com/)
+* [开源的社会契约](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
+* [如何应对有毒的人](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [个人生态自评工具包](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood领导艺术](https://rockwoodleadership.org/art-of-leadership/)
+* [说"不"](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop 议程改编自 [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) 系列活动
+
+## 贡献者
+
+非常感谢所有与我们分享经验和技巧的维护者!
+
+本指南是由[@abbycabs](https://github.com/abbycabs)编写的,由以下人员贡献:
+
+[@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/zh-hans/starting-a-project.md b/_articles/zh-hans/starting-a-project.md
index 6ce2f91161e..c0e03af3875 100644
--- a/_articles/zh-hans/starting-a-project.md
+++ b/_articles/zh-hans/starting-a-project.md
@@ -243,7 +243,7 @@ redirect_from: /zh-cn/starting-a-project/
### 你的写作(和代码)如何影响你的品牌
-在项目的整个生命周期中,你需要做很多文字工作:READMEs,教程,社区文档,回复issues,甚至肯能要处理很多来信和邮件。
+在项目的整个生命周期中,你需要做很多文字工作:READMEs,教程,社区文档,回复issues,甚至可能要处理很多来信和邮件。
是否是官方文档或者一封普通的邮件,你的书写风格都是你项目品牌的一部分。考虑你可能会拥有粉丝,以及这是你想传达的声音。
diff --git a/_articles/zh-hant/how-to-contribute.md b/_articles/zh-hant/how-to-contribute.md
index eb09d712faf..a74d706c7a3 100644
--- a/_articles/zh-hant/how-to-contribute.md
+++ b/_articles/zh-hant/how-to-contribute.md
@@ -204,7 +204,6 @@ redirect_from: /zh-tw/how-to-contribute/
* [GitHub 探索](https://github.com/explore/)
* [First Timers Only](http://www.firsttimersonly.com/)
-* [你的第一個 PR](https://yourfirstpr.github.io/)
* [CodeTriage](https://www.codetriage.com/)
* [24 Pull Requests](https://24pullrequests.com/)
* [Up For Grabs](http://up-for-grabs.net/)
diff --git a/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
new file mode 100644
index 00000000000..01518f796eb
--- /dev/null
+++ b/_articles/zh-hant/maintaining-balance-for-open-source-maintainers.md
@@ -0,0 +1,219 @@
+---
+lang: zh-hant
+untranslated: false
+title: 保持平衡——開源專案維護者的指南
+description: 作為一名維護者,照顧自己並避免疲憊的小建議。
+class: balance
+order: 0
+image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
+---
+
+隨著一個開源專案的受歡迎程度不斷增長,設定清晰的界限變得至關重要,以幫助您保持平衡,確保長期保持清新和高效。
+
+為了深入了解維護者的經驗以及他們尋找平衡的策略,我們與Maintainer Community 的40名成員一起進行了一個工作坊,讓我們能夠從他們在開源領域遭受疲憊的第一手經驗中學習,以及幫助他們在工作中保持平衡的實踐。這就是個人生態學的概念派上用場的地方。
+
+那麼,什麼是個人生態學?正如Rockwood Leadership Institute所描述的 ,它涉及"保持平衡、節奏和效率,以維持我們在長期活動中的能量 。" 這個概念幫助維護者認識到他們的行為和貢獻是一個隨時間演變的更大生態系統的一部分。在維護者中,經常出現由於長期的工作壓力而導致的疲憊,這通常會導致動機的喪失,無法集中注意力,以及對您一起工作的貢獻者和社區缺乏同理心。根據世界衛生組織的定義,疲憊是一種由於長期的工作場所壓力而引起的綜合症狀,這種情況在維護者中並不少見。
+
+
+
+透過擁抱個人生態學的概念,維護者可以主動避免疲憊,優先考慮自我照顧,並保持平衡感,以便做出最佳的工作表現。
+
+## 作為維護者的自我照顧和避免疲憊的建議:
+
+### 辨識您參與開源工作的動機
+
+花些時間反思開源維護中哪些部分能夠為您注入活力。了解您的動機可以幫助您以一種讓自己保持參與和迎接新挑戰的方式來優先考慮工作。無論是來自使用者的積極反饋、與社區合作和社交的樂趣,還是深入研究程式碼所帶來的滿足感,認識自己的動機可以幫助引導您的關注點。
+
+### 反思是什麼使您失去平衡並感到壓力重重
+
+了解導致我們感到疲憊的原因至關重要。以下是一些我們在開源維護者中常見的主題:
+
+* **缺乏積極的回饋:** 使用者更有可能在他們有投訴時聯絡您。如果一切都運作良好,他們通常會保持沉默。看到問題清單不斷增長,卻沒有積極的回饋顯示您的貢獻正在產生影響,可能會讓人感到沮喪。
+
+
+
+* **不說"不":** 在開源專案中,很容易承擔比您應該負責的更多責任。無論是來自使用者、貢獻者還是其他維護者,我們不能總是滿足他們的期望。
+
+
+
+* **單獨工作:** 做一名維護者可能會讓人感到極度孤獨。即使您與一組維護者一起工作,過去幾年來,因分散的團隊難以親自聚會而變得困難。
+
+
+
+* **時間和資源不足:** 對於那些必須犧牲自己的空閒時間來參與項目的志願維護者來說,這一點尤其真實。
+
+
+ [我希望有] 更多的財務支持,這樣我就可以專注於開源工作,而不會消耗我的積蓄,並知道以後必須做很多合同工作來彌補。
+
+— 開源維護者
+
+
+
+* **需求衝突:** 開源充滿了擁有不同動機的群體,這可能很難應對。如果您受薪工作於開源項目,您的雇主的利益有時可能與社區的利益相衝突。
+
+
+ 有薪開源中,雇主的關注點與社區最佳利益之間的衝突
+
+— 開源維護者
+
+
+
+### 注意疲憊的跡象
+
+您能夠保持這種節奏達10週嗎?10個月?10年?
+
+有一些工具,例如來自 [@shaunagm](https://github.com/shaunagm) 的 [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) 和 Mozilla 的 [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw),可以幫助您反思您目前的節奏,並查看是否有任何調整的空間。一些維護者還使用可穿戴技術來追蹤睡眠質量和心率變異性等指標(這些都與壓力有關)。
+
+
+ 我非常相信優質的可穿戴設備。有了背後的科學知識,您可以了解如何做得更好,以及如何達到您想要達到的最佳狀態。
+
+— 開源維護者
+
+
+
+### 您需要什麼來持續支持自己和您的社群?
+
+對每位維護者來說,這可能因年齡階段和其他外部因素而有所不同。但以下是一些我們聽到的主題:
+
+* **依賴社群:** 委託和找到貢獻者可以減輕工作負荷。項目有多個聯絡點可以幫助您在休息時不必擔心。與其他維護者和更廣泛的社群建立聯繫,例如 [Maintainer Community](http://maintainers.github.com/)。這可以是同儕支持和學習的重要資源。
+
+您還可以尋找與使用者社群互動的方式,以便定期聽取反饋並了解您的開源工作的影響。
+
+* **探索資金支持:** 無論您是尋找一些額外的財政支持,還是嘗試全職投入開源,都有許多資源可以幫助您!作為第一步,考慮啟用 [GitHub Sponsors](https://github.com/sponsors),以允許其他人贊助您的開源工作。如果您考慮轉向全職,請申請下一輪的 [GitHub Accelerator](http://accelerator.github.com/)。
+
+
+
+* **使用工具:** 探索工具,如 [GitHub Copilot](https://github.com/features/copilot/) 和 [GitHub Actions](https://github.com/features/actions),以自動化乏味的任務,釋放更多時間進行有意義的貢獻。
+
+
+ 使用 [Copilot](https://github.com/features/copilot/) 來處理沉悶的事情 - 做有趣的事情
+
+— 開源維護者
+
+
+
+* **休息和恢復:** 為自己的興趣和愛好留出時間,遠離開源項目的工作。週末休息一下,放鬆身心,並設定您的 [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) 以反映您的可用性!一晚好的睡眠對於您長期維護努力的能力可能會產生重大影響。
+
+如果您發現項目的某些方面特別令人愉快,請嘗試結構化您的工作,以便您可以在一天中體驗到這些樂趣。
+
+
+
+ 我發現在白天更多機會嵌入"創造性時刻",而不是試圖在晚上關掉。
+
+— @danielroe ,Nuxt的維護者
+
+
+
+* **設定界限:** 您無法對每個請求都答應。這可以是簡單地說,"我現在無法處理這個,並且將來也沒有計劃",或在 README 中列出您有興趣和不願意做的事情。例如,您可以說:"我只會合併明確列出為什麼要這樣做的 PR",或者,"我只會在每兩週的週四晚上 6 點到 7 點之間審查問題。" 這會讓其他人對您的期望有所了解,並且在其他時候有助於緩解貢獻者或使用者對您的時間的需求。
+
+
+學會堅定地制止有毒行為和負面互動。不對您不關心的事情付出精力是可以接受的。
+
+
+
+
+
+開源維護有其黑暗面,其中之一是有時必須與相當不感激、自以為是或明顯有毒的人互動。隨著項目的受歡迎程度增加,這種互動的頻率也增加,增加了維護者的負擔,可能成為維護者疲憊的重要風險因素。
+
+
+
+請記住,個人生態學是一個不斷演變的實踐,隨著您在開源之旅中的進展而變化。通過優先考慮自我照顧和保持平衡感,您可以有效且持久地貢獻於開源社群,確保自己的幸福以及項目的長期成功。
+
+## 額外資源
+
+* [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/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
+## 貢獻者
+
+非常感謝所有與我們分享他們經驗和建議的維護者!
+
+本指南由[@abbycabs](https://github.com/abbycabs)撰寫,[@jianan1104](https://github.com/jianan1104)翻譯,並得到以下貢獻者的貢獻:
+
+[@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) + 很多人!
diff --git a/_articles/zh-hant/starting-a-project.md b/_articles/zh-hant/starting-a-project.md
index ca4a49e897b..537bcf8ffa2 100644
--- a/_articles/zh-hant/starting-a-project.md
+++ b/_articles/zh-hant/starting-a-project.md
@@ -243,7 +243,7 @@ redirect_from: /zh-tw/starting-a-project/
### 你的寫作(和代碼)如何影響你的品牌
-在專案的整個生命週期中,你需要做很多文字工作:READMEs,教程,社群文檔,回覆issues,甚至肯能要處理很多來信和郵件。
+在專案的整個生命週期中,你需要做很多文字工作:READMEs,教程,社群文檔,回覆issues,甚至可能要處理很多來信和郵件。
是否是官方文檔或者一封普通的郵件,你的書寫風格都是你專案品牌的一部分。考慮你可能會擁有粉絲,以及這是你想傳達的聲音。
diff --git a/_data/locales/de.yml b/_data/locales/de.yml
index d2891744842..0997210c73a 100644
--- a/_data/locales/de.yml
+++ b/_data/locales/de.yml
@@ -28,4 +28,4 @@ de:
# Label für das Herz-Octicon
love_label: love
# Label für das Octicon der Mitwirkenden
- friends_label: friends
+ friends_label: Freunden
diff --git a/_data/locales/hi.yml b/_data/locales/hi.yml
new file mode 100644
index 00000000000..076cf4e9203
--- /dev/null
+++ b/_data/locales/hi.yml
@@ -0,0 +1,32 @@
+hi:
+ locale_name: Hindi
+ nav:
+ about: बारे में
+ contribute: योगदान करें
+ index:
+ lead: ओपन सोर्स सॉफ़्टवेयर उन लोगों द्वारा बनाया जाता है जैसे कि आप। जानें कि आप कैसे अपने प्रोजेक्ट को शुरू कर सकते हैं और उसे बढ़ा सकते हैं।
+ opensourcefriday: यह शुक्रवार है! कुछ घंटे निवेश करके उन सॉफ़्टवेयर में योगदान करें जिन्हें आप उपयोग करते हैं और पसंद करते हैं
+ article:
+ table_of_contents: सामग्री की सूची
+ back_to_all_guides: सभी मार्गदर्शिकाओं पर वापस जाएं
+ related_guides: संबंधित मार्गदर्शिकाएं
+ footer:
+ contribute:
+ heading: योगदान करें
+ description: क्या आपका कोई सुझाव है? यह सामग्री ओपन सोर्स है। हमें इसे सुधारने में मदद करें।
+ button: योगदान करें
+ subscribe:
+ heading: संपर्क में रहें
+ description: गिटहब की नवीनतम ओपन सोर्स युक्तियों और संसाधनों की पहली जानकारी पाने के लिए पहले ही सुनें।
+ label: ईमेल पता
+ button: सदस्यता लें
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] के साथ [love] द्वारा [github] और [friends]"
+ # Label for code octicon
+ code_label: कोड
+ # Label for love octicon
+ love_label: प्रेम
+ # Label for the contributors link
+ friends_label: मित्र
+
diff --git a/_includes/footer.html b/_includes/footer.html
index 4e7e19b9c67..6680765bf2e 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -1,4 +1,5 @@
{% assign t = site.data.locales[page.lang][page.lang] %}
+Scroll to Top
diff --git a/_layouts/default.html b/_layouts/default.html
index 7cf57d4efa6..89e492849c5 100644
--- a/_layouts/default.html
+++ b/_layouts/default.html
@@ -9,6 +9,7 @@
+