From 1b4f5fcbb81a86b81bff4c11ca2841ce72df31cc Mon Sep 17 00:00:00 2001
From: Joseph Hale
Date: Sat, 2 Sep 2023 16:08:20 -0700
Subject: [PATCH 01/29] Update legal.md
- Simplify the legalese in a few places
- Add more links to licenses and data behind various claims
- Add more descriptions for different classes of licenses.
- Improve internal linking within the article.
---
_articles/legal.md | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/_articles/legal.md b/_articles/legal.md
index 8adc3897659..a64a77cd167 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 legal crash course 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 state these permissions in a document called 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 the [most popular open source licenses](https://libraries.io/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.
+* **"Permissive" licenses** give you permission to use, modify, and share the library without any conditions on how you license your project. Common permissive licenses include [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).
+* **"Limited copyleft" licenses** (sometimes called "weak copyleft") are similar to permissive licenses -- generally your project can use whatever license you want -- but modifications to the library itself must be shared under an identical/compatible license. Common limited copyleft licenses include the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and the [LGPL](https://choosealicense.com/licenses/lgpl-3.0/).
+* **"Strong copyleft" licenses** also give you permission to use, modify, and share the library, but only if your project uses an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses). Common strong copyleft licenses include [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), and [AGPLv3](https://choosealicense.com/licenses/agpl-3.0).
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 will likely want an express patent license from all contributors and the ability to use the project in proprietary software. In this case, the permissive [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) or the limited copyleft [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) has you (and them) covered.
* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well.
-Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
+Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive or limited copyleft license so your project can be used in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know).
When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/).
@@ -84,7 +86,7 @@ For example, as your project grows it adds dependencies or users, or your compan
**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
-Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
+Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- [see below](#does-my-project-need-an-additional-contributor-agreement)) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
## Does my project need an additional contributor agreement?
@@ -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.
From fff435de75a1eea29af854a7efcd089b7b013cc1 Mon Sep 17 00:00:00 2001
From: Joseph Hale
Date: Sat, 2 Sep 2023 16:16:11 -0700
Subject: [PATCH 02/29] Add link to git-authorship in legal.md
Git Authorship is a project that helps maintainers identify the
individuals who have committed code present in the current version
of the project.
Added with the permission of @ahpook to avoid "self-promotion"
concerns since this is one of my own projects.
The commented section at the end of the article discusses ideas
for future additions to this article.
---
_articles/legal.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/_articles/legal.md b/_articles/legal.md
index a64a77cd167..77a0f4fe245 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -84,7 +84,7 @@ 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](#does-my-project-need-an-additional-contributor-agreement)) 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.
From d3ca9b209f2138563ec734c386b3abc2f07f1751 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?=
Date: Fri, 6 Oct 2023 21:40:35 +0300
Subject: [PATCH 03/29] Update German translation
---
...ing-balance-for-open-source-maintainers.md | 28 +++++++++----------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 29808f19840..58d1d199c4f 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -1,16 +1,16 @@
---
lang: de
-untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+untranslated: false
+title: Balance für Open-Source-Maintainer halten
+description: Tipps zur Selbsthilfe und zur Vermeidung von Burnout als 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.
+Wenn ein Open-Source-Projekt immer beliebter wird, ist es wichtig, sich klare Grenzen zu setzen, um die Balance zu halten, damit man auf lange Sicht motiviert und produktiv bleibt.
-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.
+Um Einblicke in die Erfahrungen von Maintainern und ihre Strategien, eine Balance zu finden, zu gewinnen, haben wir einen Workshop mit 40 Mitgliedern der Maintainer-Community durchgeführt. So konnten wir aus erster Hand von ihren Erfahrungen mit Burnout in der Open-Source-Branche und den Praktiken lernen, die ihnen geholfen haben, bei ihrer Arbeit eine Balance zu halten. An dieser Stelle kommt das Konzept der persönlichen Ökologie ins Spiel.
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.
@@ -22,25 +22,25 @@ So, what is personal ecology? As
- 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.
+ Manchmal fühlt es sich so an, als würde man ins Leere schreien, und ich finde, dass mich dieses Feedback wirklich anspornt. Wir haben viele glückliche, aber stille Nutzer.
-— @thisisnic , maintainer of Apache Arrow
+— @thisisnic , Maintainer von Apache Arrow
From 05b6ec3e1784a7e97576385391f8aeffa5c580fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?=
Date: Fri, 6 Oct 2023 21:44:49 +0300
Subject: [PATCH 04/29] Update German translation in footer
---
_data/locales/de.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
From 5ba5ad60a0287eca1c6f1fb67a101144b572d7a3 Mon Sep 17 00:00:00 2001
From: zaki-hussain
Date: Sat, 7 Oct 2023 16:24:49 +0100
Subject: [PATCH 05/29] Fixed typos by adding spaces after commas
---
_articles/how-to-contribute.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index db837415d40..1a952f1c86e 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -87,7 +87,7 @@ Even if you like to write code, other types of contributions are a great way to
### Do you like to write?
-* Write and improve the project's documentation,[like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
+* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151)
* Curate a folder of examples showing how the project is used
* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/)
* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
@@ -209,7 +209,7 @@ Open source isn't an exclusive club; it's made by people just like you. "Open so
You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about!
-> According to a study conducted by Igor Steinmacher and other Computer Science researchers,[28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation.
+> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation.
If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)).
From 80ccb34b23e35be6f162640a7ffe2d640f7ec83f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?=
Date: Sun, 8 Oct 2023 21:54:32 +0300
Subject: [PATCH 06/29] Update
maintaining-balance-for-open-source-maintainers.md
---
...aintaining-balance-for-open-source-maintainers.md | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 58d1d199c4f..23241359dcf 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -16,9 +16,9 @@ So, what is personal ecology? As
- I was unable to focus or start on a task. I had a lack of empathy for users.
+ Ich war nicht in der Lage, mich zu konzentrieren oder mit einer Aufgabe zu beginnen. Mir fehlte es an Empathie für die Benutzer.
-— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— @gabek , Maintainer des Owncast Live-Streaming-Servers, über die Folgen von Burnout auf seine Arbeit mit Open Source
@@ -44,17 +44,17 @@ Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein p
-* **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.
+* **Nicht "Nein" sagen:** Es kann leicht passieren, dass man bei einem Open-Source-Projekt mehr Verantwortung übernimmt, als man sollte. Ob von Nutzern, Mitwirkenden oder anderen Betreuern - wir können nicht immer ihren Erwartungen gerecht werden.
- I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+ Ich stellte fest, dass ich mehr als eine Aufgabe übernehmen und die Arbeit mehrerer Personen erledigen musste, wie es bei FOSS üblich ist.
-— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+— @agnostic-apollo , Maintainer von Termux, über die Ursachen von Burnout bei seiner Arbeit
-* **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.
+* **Alleine arbeiten:** Ein Maintainer zu sein, kann unglaublich einsam sein. Selbst wenn Sie mit einer Gruppe von Betreuern zusammenarbeiten, war es in den letzten Jahren schwierig, sich persönlich mit zerstreuten Teams zu treffen.
From accfc83dbe57e7895d3aabf860e9ef3a6b158d6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?=
Date: Mon, 9 Oct 2023 14:15:58 +0300
Subject: [PATCH 07/29] Update
maintaining-balance-for-open-source-maintainers.md
---
...ing-balance-for-open-source-maintainers.md | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 23241359dcf..c4b508f5f72 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -58,44 +58,44 @@ Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein p
- Especially since COVID and working from home it's harder to never see anybody or talk to anybody.
+ Vor allem seit Corona und der Arbeit von zu Hause aus ist es schwieriger, nie jemanden zu sehen oder mit jemandem zu sprechen.
-— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— @gabek , Maintainer des Owncast Live-Streaming-Servers, über die Folgen von Burnout auf seine Open-Source-Arbeit
-* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+* **Nicht genug Zeit oder Ressourcen:** Dies gilt insbesondere für freiwillige Maintainer, die ihre Freizeit für die Arbeit an einem Projekt opfern müssen.
-* **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.
+* **Unterschiedliche Forderungen:** Open Source ist voll von Gruppen mit unterschiedlichen Motivationen, die schwer zu durchschauen sind. Wenn Sie für Ihre Arbeit an Open Source bezahlt werden, können die Interessen Ihres Arbeitgebers manchmal mit denen der Community kollidieren.
-### Watch out for signs of burnout
+### Halte Ausschau nach Zeichen für Burnout
-Can you keep up your pace for 10 weeks? 10 months? 10 years?
+Können Sie Ihr Tempo 10 Wochen lang beibehalten? 10 Monate? 10 Jahre?
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?
+### Was brauchen Sie, um sich und Ihre Gemeinschaft weiterhin zu erhalten?
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:
From 280dc2c573e97bc07ede66c541c6fff024890812 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?=
Date: Mon, 9 Oct 2023 21:12:07 +0300
Subject: [PATCH 08/29] Update
maintaining-balance-for-open-source-maintainers.md
---
...aining-balance-for-open-source-maintainers.md | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index c4b508f5f72..518a803ccd6 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -97,19 +97,19 @@ There are tools like the [Burnout Checklist](https://governingopen.com/resources
### Was brauchen Sie, um sich und Ihre Gemeinschaft weiterhin zu erhalten?
-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:
+Dies wird für jeden Betreuer unterschiedlich sein und sich je nach Lebensphase und anderen äußeren Faktoren ändern. Aber hier sind ein paar Aspekte, die wir gehört haben:
-* **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.
+* **Vertrauen Sie der 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.
+ Sie können auch nach Möglichkeiten suchen, mit der Nutzergemeinde in Kontakt zu treten, damit Sie regelmäßig Feedback erhalten und die Auswirkungen Ihrer Open-Source-Arbeit verstehen.
-* **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/).
+* **Finanzierung erforschen:** 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.
+ Ich war vor einiger Zeit in einem Podcast und wir sprachen über die Instandhaltung von Open Source und Nachhaltigkeit. Ich fand, dass selbst eine kleine Anzahl von Leuten, die meine Arbeit auf GitHub unterstützen, mir geholfen hat, eine schnelle Entscheidung zu treffen, nicht vor einem Spiel zu sitzen, sondern stattdessen eine kleine Sache mit Open Source zu machen.
-— @mansona , maintainer of EmberJS
+— @mansona , Maintainer von EmberJS
@@ -118,13 +118,13 @@ This will look different for each maintainer, and will change depending on your
* **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.
+ Wenn Ihnen bestimmte Aspekte Ihres Projekts besonders viel Spaß machen, versuchen Sie, Ihre Arbeit so zu strukturieren, dass Sie sie während des Tages erleben können.
From db02ec4b9f64ff8837a5280604fa5ccfb51b95b2 Mon Sep 17 00:00:00 2001
From: Olsza
Date: Wed, 11 Oct 2023 08:44:59 +0200
Subject: [PATCH 09/29] fix link in Legal for PL
---
_articles/pl/legal.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/_articles/pl/legal.md b/_articles/pl/legal.md
index 20e7a4f713d..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/).
From bf307a0b31c29635187d42deaf02351023552fff Mon Sep 17 00:00:00 2001
From: Olsza
Date: Wed, 11 Oct 2023 09:05:55 +0200
Subject: [PATCH 10/29] refactoring - space added in PL
---
_articles/pl/starting-a-project.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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).
From 0db8d00f4071cf7a9d68ae145052ed353730c49d Mon Sep 17 00:00:00 2001
From: Olsza
Date: Wed, 11 Oct 2023 09:06:27 +0200
Subject: [PATCH 11/29] fix link in starting-a-project for HI
---
_articles/hi/starting-a-project.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/_articles/hi/starting-a-project.md b/_articles/hi/starting-a-project.md
index e1eb3ed63c0..dd0179ba62f 100644
--- a/_articles/hi/starting-a-project.md
+++ b/_articles/hi/starting-a-project.md
@@ -20,7 +20,7 @@ related:
खुला स्रोत शक्तिशाली है क्योंकि यह अपनाने और सहयोग की बाधाओं को कम करता है, जिससे लोगों को परियोजनाओं को तेजी से फैलाने और सुधारने की अनुमति मिलती है। इसके अलावा, क्योंकि यह उपयोगकर्ताओं को बंद स्रोत के सापेक्ष, अपने स्वयं के कंप्यूटिंग को नियंत्रित करने की क्षमता देता है। उदाहरण के लिए, ओपन सोर्स सॉफ़्टवेयर का उपयोग करने वाले व्यवसाय के पास किसी बंद स्रोत विक्रेता के उत्पाद निर्णयों पर विशेष रूप से निर्भर रहने के बजाय सॉफ़्टवेयर में कस्टम सुधार करने के लिए किसी को नियुक्त करने का विकल्प होता है।
-_मुफ़्त सॉफ़्टवेयर_ परियोजनाओं के उसी सेट को संदर्भित करता है जो _ओपन सोर्स_ है। कभी-कभी आप [इन शर्तों](https://en.wikipedia.org/wiki/Free_and_open-source_software) को "फ्री और ओपन सोर्स सॉफ्टवेयर" (FOSS) या "फ्री, लिब्रे और ओपन सोर्स सॉफ्टवेयर" के रूप में भी देखेंगे। (दाँत साफ करने का धागा)। _मुक्त_ और _मुक्ति_ का तात्पर्य स्वतंत्रता से है, [कीमत से नहीं](#does-open-source-mean-free-of-charge)।
+_मुफ़्त सॉफ़्टवेयर_ परियोजनाओं के उसी सेट को संदर्भित करता है जो _ओपन सोर्स_ है। कभी-कभी आप [इन शर्तों](https://en.wikipedia.org/wiki/Free_and_open-source_software) को "फ्री और ओपन सोर्स सॉफ्टवेयर" (FOSS) या "फ्री, लिब्रे और ओपन सोर्स सॉफ्टवेयर" के रूप में भी देखेंगे। (दाँत साफ करने का धागा)। _मुक्त_ और _मुक्ति_ का तात्पर्य स्वतंत्रता से है, [कीमत से नहीं](#क्या-ओपन-सोर्स-का-मतलब-निःशुल्क-है)।
### लोग अपना काम ओपन सोर्स क्यों करते हैं?
From 65b5ca97cdfc260f5b98e35ad3cccc078675cfd4 Mon Sep 17 00:00:00 2001
From: Olsza
Date: Wed, 11 Oct 2023 09:06:41 +0200
Subject: [PATCH 12/29] fix link in Legal for HI
---
_articles/hi/legal.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/_articles/hi/legal.md b/_articles/hi/legal.md
index aae22fa1d16..4e005274bba 100644
--- a/_articles/hi/legal.md
+++ b/_articles/hi/legal.md
@@ -71,7 +71,7 @@ related:
* **क्या आप चाहते हैं कि आपका प्रोजेक्ट उन योगदानकर्ताओं को आकर्षित करे जो नहीं चाहते कि उनके योगदान का उपयोग बंद स्रोत सॉफ़्टवेयर में किया जाए?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) या (यदि वे भी बंद स्रोत सेवाओं में योगदान नहीं करना चाहते हैं) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)
अच्छा चलेगा।
-आपकी **कंपनी** को अपने ओपन सोर्स प्रोजेक्ट्स के लिए विशिष्ट लाइसेंसिंग आवश्यकताएं हो सकती हैं। उदाहरण के लिए, इसके लिए एक अनुमेय लाइसेंस की आवश्यकता हो सकती है ताकि कंपनी आपके प्रोजेक्ट का उपयोग कंपनी के बंद स्रोत उत्पाद में कर सके। या आपकी कंपनी को एक मजबूत कॉपीलेफ्ट लाइसेंस और एक अतिरिक्त योगदानकर्ता समझौते (नीचे देखें) की आवश्यकता हो सकती है ताकि केवल आपकी कंपनी, और कोई नहीं, बंद स्रोत सॉफ़्टवेयर में आपके प्रोजेक्ट का उपयोग कर सके। या आपकी कंपनी को मानकों, सामाजिक जिम्मेदारी, या पारदर्शिता से संबंधित कुछ ज़रूरतें हो सकती हैं, जिनमें से किसी के लिए एक विशेष लाइसेंसिंग रणनीति की आवश्यकता हो सकती है। आप अपने [कंपनी का कानूनी विभाग](#what-does-my-companys-legal-team-need-to-know) से बातें करें।
+आपकी **कंपनी** को अपने ओपन सोर्स प्रोजेक्ट्स के लिए विशिष्ट लाइसेंसिंग आवश्यकताएं हो सकती हैं। उदाहरण के लिए, इसके लिए एक अनुमेय लाइसेंस की आवश्यकता हो सकती है ताकि कंपनी आपके प्रोजेक्ट का उपयोग कंपनी के बंद स्रोत उत्पाद में कर सके। या आपकी कंपनी को एक मजबूत कॉपीलेफ्ट लाइसेंस और एक अतिरिक्त योगदानकर्ता समझौते (नीचे देखें) की आवश्यकता हो सकती है ताकि केवल आपकी कंपनी, और कोई नहीं, बंद स्रोत सॉफ़्टवेयर में आपके प्रोजेक्ट का उपयोग कर सके। या आपकी कंपनी को मानकों, सामाजिक जिम्मेदारी, या पारदर्शिता से संबंधित कुछ ज़रूरतें हो सकती हैं, जिनमें से किसी के लिए एक विशेष लाइसेंसिंग रणनीति की आवश्यकता हो सकती है। आप अपने [कंपनी का कानूनी विभाग](#मेरी-कंपनी-की-कानूनी-टीम-को-क्या-जानना-आवश्यक-है) से बातें करें।
जब आप GitHub पर एक नया प्रोजेक्ट बनाते हैं, तो आपको लाइसेंस चुनने का विकल्प दिया जाता है। ऊपर उल्लिखित लाइसेंसों में से एक को शामिल करने से आपका GitHub प्रोजेक्ट खुला स्रोत बन जाएगा। यदि आप अन्य विकल्प देखना चाहते हैं, तो देखें [choosealicense.com](https://choosealicense.com) अपने प्रोजेक्ट के लिए सही लाइसेंस ढूँढ़ने के लिए, भले ही वह हो [isn't software](https://choosealicense.com/non-software/).
From ded20a7f42b0e92e4fd64774334807cc82455b16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?=
Date: Thu, 12 Oct 2023 17:09:02 +0300
Subject: [PATCH 13/29] Update
maintaining-balance-for-open-source-maintainers.md
---
.../maintaining-balance-for-open-source-maintainers.md | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 518a803ccd6..8d29b5c8607 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -12,7 +12,7 @@ Wenn ein Open-Source-Projekt immer beliebter wird, ist es wichtig, sich klare Gr
Um Einblicke in die Erfahrungen von Maintainern und ihre Strategien, eine Balance zu finden, zu gewinnen, haben wir einen Workshop mit 40 Mitgliedern der Maintainer-Community durchgeführt. So konnten wir aus erster Hand von ihren Erfahrungen mit Burnout in der Open-Source-Branche und den Praktiken lernen, die ihnen geholfen haben, bei ihrer Arbeit eine Balance zu halten. An dieser Stelle kommt das Konzept der persönlichen Ökologie ins Spiel.
-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.
+Was also ist persönliche Ökologie? Laut dem Rockwood Leadership Institute geht es darum, "das Gleichgewicht, das Tempo und die Effizienz aufrechtzuerhalten, um unsere Energie ein Leben lang zu erhalten ." Dies gab unseren Gesprächen einen Rahmen und half den Maintainern, ihre Beiträge als Teil eines größeren Ökosystems zu erkennen, das sich im Laufe der Zeit weiterentwickelt. Burnout, ein Syndrom, das aus chronischem Stress am Arbeitsplatz resultiert, wie [von der WHO definiert](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), ist unter Maintainern keine Seltenheit. Dies führt oft zu einem Motivationsverlust, einer Unfähigkeit, sich zu konzentrieren, und einem Mangel an Empathie für die Mitwirkenden und die Community, mit der man arbeitet.
@@ -67,7 +67,7 @@ Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein p
* **Nicht genug Zeit oder Ressourcen:** Dies gilt insbesondere für freiwillige Maintainer, die ihre Freizeit für die Arbeit an einem Projekt opfern müssen.
- [Ich hätte gerne] mehr finanzielle Unterstützung, sodass ich mich auf die Open-Source-Arbeit konzentrieren kann, ohne mein Erspartes aufzubrauchen und zu wissen, dass ich später eine Menge Auftragsarbeiten erledigen muss, um das zu kompensieren.
+ Ich hätte gerne mehr finanzielle Unterstützung, sodass ich mich auf die Open-Source-Arbeit konzentrieren kann, ohne mein Erspartes aufzubrauchen und zu wissen, dass ich später eine Menge Auftragsarbeiten erledigen muss, um das zu kompensieren.
— Open-Source-Maintainer
@@ -86,7 +86,7 @@ Es ist wichtig zu verstehen, was die Ursachen für Burnout sind. Hier sind ein p
Können Sie Ihr Tempo 10 Wochen lang beibehalten? 10 Monate? 10 Jahre?
-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).
+Es gibt Tools wie die [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) von [@shaunagm](https://github.com/shaunagm) und Mozillas [Personal Ecology Self-Assessment Kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), die Ihnen dabei helfen können, Ihr aktuelles Tempo zu reflektieren und zu sehen, ob Sie Anpassungen vornehmen können. Einige Betreuer verwenden auch Wearables, um Messwerte wie Schlafqualität und Herzfrequenzvariabilität (die beide mit Stress in Verbindung stehen) zu verfolgen.
Ich bin ein großer Befürworter von guten Wearables. Mit der Wissenschaft dahinter kann man verstehen, was man hätte besser machen können und wie man seine Ziele optimal erreichen kann.
@@ -113,10 +113,10 @@ Dies wird für jeden Betreuer unterschiedlich sein und sich je nach Lebensphase
-* **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.
+* **Tools einsetzen:** Entdecken Sie Tools wie [GitHub Copilot](https://github.com/features/copilot/) und [GitHub Actions](https://github.com/features/actions), um alltägliche Aufgaben zu automatisieren und Zeit für sinnvollere Beiträge zu gewinnen.
- Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+ Verwenden Sie [Copilot](https://github.com/features/copilot/) für die langweiligen Dinge - machen Sie die Dinge, die Ihnen Spaß machen
— Open-Source-Maintainer
From d379e775313a82756ca7033f707dea091d28eefd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?=
Date: Fri, 13 Oct 2023 09:23:56 +0300
Subject: [PATCH 14/29] Update
maintaining-balance-for-open-source-maintainers.md
---
...ing-balance-for-open-source-maintainers.md | 35 ++++++++++---------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 8d29b5c8607..3e0bd610559 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -122,49 +122,49 @@ Dies wird für jeden Betreuer unterschiedlich sein und sich je nach Lebensphase
-* **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.
+* **Ausruhen und regenerieren:** Nehmen Sie sich Zeit für Ihre Hobbys und Interessen außerhalb von Open Source. Nehmen Sie sich am Wochenende frei, um sich zu entspannen und zu erholen - und stellen Sie Ihren [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) so ein, dass er Ihre Verfügbarkeit widerspiegelt! Erholsamer Schlaf kann einen großen Unterschied machen, wenn es darum geht, Ihre Leistung langfristig aufrechtzuerhalten.
Wenn Ihnen bestimmte Aspekte Ihres Projekts besonders viel Spaß machen, versuchen Sie, Ihre Arbeit so zu strukturieren, dass Sie sie während des Tages erleben können.
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+ Ich finde mehr Zeit, um "kreative Momente" in den Tag zu bringen, als dass ich versuche, am Abend abzuschalten.
-— @danielroe , maintainer of Nuxt
+— @danielroe , Maintainer von 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.
+* **Grenzen setzen:** Sie können nicht zu jeder Anfrage Ja sagen. Das kann so einfach sein, wie zu sagen: "Das kann ich im Moment nicht machen und ich habe auch nicht vor, es in Zukunft zu machen", oder in der README aufzulisten, was Sie gerne machen würden und was nicht. Sie könnten zum Beispiel sagen: "Ich führe nur PRs zusammen, die eine klare Begründung haben, warum sie gemacht wurden", oder "Ich überprüfe Probleme nur abwechselnd donnerstags von 18 - 19 Uhr". Das setzt Erwartungen für andere und gibt Ihnen etwas, auf das Sie zu anderen Zeiten verweisen können, um Forderungen von Mitwirkenden oder Benutzern nach Ihrer Zeit zu deeskalieren.
-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.
+Um auf diesen Säulen wirklich vertrauen zu können, darf man nicht zu jeder Anfrage Ja sagen. Wenn Sie das tun, halten Sie sich weder beruflich noch persönlich an Grenzen und werden kein verlässlicher Mitarbeiter sein.
-— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+— @mikemcquaid , Maintainer von Homebrew zum [Nein-Sagen](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.
+ Lernen Sie, giftiges Verhalten und negative Interaktionen konsequent zu unterbinden. Es ist in Ordnung, keine Energie für Dinge aufzuwenden, die Ihnen egal sind.
-My software is gratis, but my time and attention is not.
+Meine Software ist gratis, aber meine Zeit und Aufmerksamkeit sind es nicht.
-— @IvanSanchez , maintainer of Leaflet
+— @IvanSanchez , Maintainer von 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.
+Es ist kein Geheimnis, dass die Entwicklung von Open-Source-Projekten auch ihre Schattenseiten hat, und eine davon ist, dass man manchmal mit undankbaren, überheblichen oder regelrecht toxischen Leuten interagieren muss. Mit zunehmender Popularität eines Projekts steigt auch die Häufigkeit dieser Interaktion, was die Belastung der Maintainer erhöht und möglicherweise zu einem bedeutenden Risikofaktor für ein Burnout der Maintainer wird.
-— @foosel , maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— @foosel , Maintainer von Octoprint zu [Umgang mit toxischen Leuten](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.
+Denken Sie daran, dass persönliche Ökologie eine fortlaufende Praxis ist, die sich im Laufe Ihrer Open-Source-Reise weiterentwickeln wird. Indem Sie Ihre Selbstfürsorge in den Vordergrund stellen und ein Gleichgewicht aufrechterhalten, können Sie einen effektiven und nachhaltigen Beitrag zur Open-Source-Gemeinschaft leisten und sowohl Ihr Wohlbefinden als auch den Erfolg Ihrer Projekte auf lange Sicht sicherstellen.
-## Additional Resources
+## Weitere Artikel
* [Maintainer Community](http://maintainers.github.com/)
* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
@@ -177,11 +177,11 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
* [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
+## Mitwirkende
-Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+Vielen Dank an alle Maintainer, die uns ihre Erfahrungen und Tipps für diesen Leitfaden zur Verfügung gestellt haben!
-This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from:
+Dieser Leitfaden wurde von [@abbycabs](https://github.com/abbycabs) geschrieben mit Beiträgen von:
[@agnostic-apollo](https://github.com/agnostic-apollo)
[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
@@ -218,4 +218,5 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu
[@thisisnic](https://github.com/thisisnic)
[@tudoramariei](https://github.com/tudoramariei)
[@UlisesGascon](https://github.com/UlisesGascon)
-[@waldyrious](https://github.com/waldyrious) + many others!
+[@waldyrious](https://github.com/waldyrious)
+[@WebSnke(https://github.com/WebSnke)] + vielen anderen!
From cca727699824b8d58ebefc93471d6153c6224ea7 Mon Sep 17 00:00:00 2001
From: Joseph Hale
Date: Fri, 13 Oct 2023 21:28:11 -0700
Subject: [PATCH 15/29] Incorporate feedback into legal.md
---
_articles/legal.md | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/_articles/legal.md b/_articles/legal.md
index 77a0f4fe245..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, with this legal crash course you don't have to start from scratch. (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,7 +20,7 @@ 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 to explicitly state these permissions in a document called a license.
+Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need to explicitly give these permissions with a license.
These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions.
@@ -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](https://libraries.io/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/).
@@ -60,17 +60,17 @@ Otherwise, picking the right open source license for your project depends on you
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).
-* **"Permissive" licenses** give you permission to use, modify, and share the library without any conditions on how you license your project. Common permissive licenses include [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).
-* **"Limited copyleft" licenses** (sometimes called "weak copyleft") are similar to permissive licenses -- generally your project can use whatever license you want -- but modifications to the library itself must be shared under an identical/compatible license. Common limited copyleft licenses include the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and the [LGPL](https://choosealicense.com/licenses/lgpl-3.0/).
-* **"Strong copyleft" licenses** also give you permission to use, modify, and share the library, but only if your project uses an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses). Common strong copyleft licenses include [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), and [AGPLv3](https://choosealicense.com/licenses/agpl-3.0).
+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 and the ability to use the project in proprietary software. In this case, the permissive [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) or the limited copyleft [MPL 2.0](https://choosealicense.com/licenses/mpl-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 or limited copyleft license so your project can be used 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/).
@@ -86,7 +86,7 @@ For example, as your project grows it adds dependencies or users, or your compan
**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](#does-my-project-need-an-additional-contributor-agreement)) 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?
From f03a50462ab7d2bfb15cc16eb32ed59343b3d663 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B6nke=20Joppien?=
Date: Sat, 14 Oct 2023 10:48:38 +0300
Subject: [PATCH 16/29] Update
_articles/de/maintaining-balance-for-open-source-maintainers.md
Co-authored-by: Eric Sorenson
---
_articles/de/maintaining-balance-for-open-source-maintainers.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/_articles/de/maintaining-balance-for-open-source-maintainers.md b/_articles/de/maintaining-balance-for-open-source-maintainers.md
index 3e0bd610559..a16f77db2d2 100644
--- a/_articles/de/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/de/maintaining-balance-for-open-source-maintainers.md
@@ -219,4 +219,4 @@ Dieser Leitfaden wurde von [@abbycabs](https://github.com/abbycabs) geschrieben
[@tudoramariei](https://github.com/tudoramariei)
[@UlisesGascon](https://github.com/UlisesGascon)
[@waldyrious](https://github.com/waldyrious)
-[@WebSnke(https://github.com/WebSnke)] + vielen anderen!
+[@WebSnke](https://github.com/WebSnke) + vielen anderen!
From c82ffc6750b46c1c1a5849e3f9495b06225021cf Mon Sep 17 00:00:00 2001
From: Xudong Guo
Date: Mon, 16 Oct 2023 16:55:16 +0800
Subject: [PATCH 17/29] docs: add zh-hans translation for
maintaining-balance-for-open-source-maintainers
---
...ing-balance-for-open-source-maintainers.md | 134 +++++++++---------
1 file changed, 67 insertions(+), 67 deletions(-)
diff --git a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
index df51babccb0..12db80a802d 100644
--- a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
@@ -1,187 +1,187 @@
---
lang: zh-hans
untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: 保持开源维护者的平衡
+description: 作为维护者的自我护理和避免倦怠的技巧。
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.
+为了深入了解维护者的经验及他们如何找到工作平衡,我们与维护者社区 的 40 名成员举办了一个 workshop。通过这样的方式,我们得以学习到他们在开源领域所经历的疲劳过度的第一手情况,以及他们采取了哪些实践来在工作中维持平衡。这正是“个人生态学”概念得以应用的场景。
-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.
+那么,个人生态学是什么?根据 Rockwood Leadership Institute 的描述 ,它是“在我们的一生中,维持平衡、节奏和效率以保持能量 ”。这种观点为我们的交流提供了一个结构,帮助维护者意识到随时间发展,他们的行为和贡献是一个更大的生态系统中的组成部分。根据[世卫组织的定义](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281),由长时间的工作压力引起的综合症状,即“疲劳过度”,在维护者中并不罕见。这常常会导致失去工作动力、无法集中精力,以及对与之合作的贡献者和社区感到缺乏同情和理解。
- 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
+— @gabek ,Owncast 直播服务的维护者,谈到疲劳对他的开源工作的影响
-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
+— @thisisnic ,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.
+ 我发现自己承担的工作超出了一个人的职责范围,不得不像 FOSS 中常见的那样,完成多人的工作。
-— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+— @agnostic-apollo ,Termux 的维护者,谈论他们工作中导致疲劳的原因
-* **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.
+ 特别是自从 COVID 和居家办公后,再也见不到人或和人说话就更难了。
-— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— @gabek ,Owncast 直播服务器的维护者,谈论疲劳对他的开源工作的影响
-* **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?
+这样的节奏你能保持多久?10周?10个月?还是10年?
-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).
+有像 [@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)这样的工具可以帮助你反思自己现在的工作节奏,看是否需要进行某些调整。一些维护者还利用可穿戴设备来监测睡眠质量和心率变异性等与压力有关的指标。
-### 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.
+* **依赖社区:** 分配任务和寻找贡献者可以帮助减轻你的负担。对一个项目而言,有多个协作者能让你放心休息。与其他维护者以及更广大的社区,如 [Maintainer Community](http://maintainers.github.com/) 建立联系,这对于获得同行的支持和学习都是宝贵的资源。
- 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/).
+* **寻找资金:** 不管您是想找点小钱买披萨,还是计划全职投身开源,都有众多资源可供参考!首先,可以考虑开通 [GitHub Sponsors](https://github.com/sponsors) 让其他人赞助您的开源项目。如果您打算全职转型,可以申请下一期的 [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.
+我曾参与一个播客,其中我们谈到了开源维护和可持续性。我发现,尽管只有少数人支持我在 GitHub 的工作,但这也帮助我做出了迅速的选择,放下游戏前端的工作转而去做一些小的开源贡献。
-— @mansona , maintainer of EmberJS
+— @mansona ,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.
+* **使用工具:** 考虑使用像 [GitHub Copilot](https://github.com/features/copilot/) 和 [GitHub Actions](https://github.com/features/actions) 这样的工具,自动化常规任务,从而为更有价值的工作腾出时间。
-* **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.
+* **休息和充电:** 留出时间享受开源之外的爱好和兴趣。利用周末休息和充电,并调整您的 [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) 来显示您是否在线!良好的睡眠对于长期保持工作热情和效率至关重要。
- 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
+— @danielroe ,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.
+* **设定界限:** 您不能对每个请求都回应“好”。您可以简单地回答:“我现在做不到,而且未来可能也不会这么做。”或者在 README 中明确列出您愿意做和不愿意做的事情。例如,您可以写:“我只会合并那些清晰解释了为何创建的 PR。”或者,“我只在每两周的星期四的6-7点审查问题。”这样可以为他人设定预期,并在其他时间为您提供一个可以参考的依据,从而减少贡献者或用户对您时间的要求。
-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/)
+— @mikemcquaid ,Homebrew 的维护者在 [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
+— @IvanSanchez ,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)
+— @foosel ,Octoprint 的维护者,在[如何应对有毒的人](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
+* [开源的社会契约](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/)
-* [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
+* [个人生态自评工具包](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 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
+* 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) 系列活动
-## 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:
+本指南是由[@abbycabs](https://github.com/abbycabs)编写的,由以下人员贡献:
[@agnostic-apollo](https://github.com/agnostic-apollo)
[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
From 15ea2dcb3c8b42e45540bb74aba2ce2a00fb75b1 Mon Sep 17 00:00:00 2001
From: Xudong Guo
Date: Mon, 16 Oct 2023 17:07:50 +0800
Subject: [PATCH 18/29] fixed warnings
---
...ntaining-balance-for-open-source-maintainers.md | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
index 12db80a802d..e4996e13c30 100644
--- a/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/zh-hans/maintaining-balance-for-open-source-maintainers.md
@@ -10,9 +10,9 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
当一个开源项目越来越受欢迎时,设定清晰的边界来帮助您长时间保持活力和生产力就变得尤为重要了。
-为了深入了解维护者的经验及他们如何找到工作平衡,我们与维护者社区 的 40 名成员举办了一个 workshop。通过这样的方式,我们得以学习到他们在开源领域所经历的疲劳过度的第一手情况,以及他们采取了哪些实践来在工作中维持平衡。这正是“个人生态学”概念得以应用的场景。
+为了深入了解维护者的经验及他们如何找到工作平衡,我们与维护者社区 的 40 名成员举办了一个 workshop。通过这样的方式,我们得以学习到他们在开源领域所经历的疲劳过度的第一手情况,以及他们采取了哪些实践来在工作中维持平衡。这正是"个人生态学"概念得以应用的场景。
-那么,个人生态学是什么?根据 Rockwood Leadership Institute 的描述 ,它是“在我们的一生中,维持平衡、节奏和效率以保持能量 ”。这种观点为我们的交流提供了一个结构,帮助维护者意识到随时间发展,他们的行为和贡献是一个更大的生态系统中的组成部分。根据[世卫组织的定义](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281),由长时间的工作压力引起的综合症状,即“疲劳过度”,在维护者中并不罕见。这常常会导致失去工作动力、无法集中精力,以及对与之合作的贡献者和社区感到缺乏同情和理解。
+那么,个人生态学是什么?根据 Rockwood Leadership Institute 的描述 ,它是"在我们的一生中,维持平衡、节奏和效率以保持能量 ”。这种观点为我们的交流提供了一个结构,帮助维护者意识到随时间发展,他们的行为和贡献是一个更大的生态系统中的组成部分。根据[世卫组织的定义](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281),由长时间的工作压力引起的综合症状,即"疲劳过度",在维护者中并不罕见。这常常会导致失去工作动力、无法集中精力,以及对与之合作的贡献者和社区感到缺乏同情和理解。
@@ -128,17 +128,17 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
-我发现在一天当中找到更多机会去散播“创意时刻”比起在晚上尝试放松更为有益。
+我发现在一天当中找到更多机会去散播"创意时刻"比起在晚上尝试放松更为有益。
— @danielroe ,Nuxt 的维护者
-* **设定界限:** 您不能对每个请求都回应“好”。您可以简单地回答:“我现在做不到,而且未来可能也不会这么做。”或者在 README 中明确列出您愿意做和不愿意做的事情。例如,您可以写:“我只会合并那些清晰解释了为何创建的 PR。”或者,“我只在每两周的星期四的6-7点审查问题。”这样可以为他人设定预期,并在其他时间为您提供一个可以参考的依据,从而减少贡献者或用户对您时间的要求。
+* **设定界限:** 您不能对每个请求都回应"好"。您可以简单地回答:"我现在做不到,而且未来可能也不会这么做。"或者在 README 中明确列出您愿意做和不愿意做的事情。例如,您可以写:"我只会合并那些清晰解释了为何创建的 PR。”或者,"我只在每两周的星期四的6-7点审查问题。”这样可以为他人设定预期,并在其他时间为您提供一个可以参考的依据,从而减少贡献者或用户对您时间的要求。
-* **No decir 'no':** Puede ser fácil asumir más responsabilidades de las que deberías en un proyecto de código abierto. Ya sea de usuarios, contribuyentes u otros mantenedores, no siempre podemos cumplir con sus expectativas.
+* **No decir 'no':** Puede ser fácil asumir más responsabilidades de las que deberías en un proyecto de código abierto. Ya sea de usuarios, contribuyentes u otros contribuidores, no siempre podemos cumplir con sus expectativas.
Descubrí que estaba asumiendo más de lo que uno debería y teniendo que hacer el trabajo de varias personas, como comúnmente se hace en el software de código abierto.
-— @agnostic-apollo , mantenedor de Termux, sobre lo que causa el agotamiento en su trabajo
+— @agnostic-apollo , contribuidor de Termux, sobre lo que causa el agotamiento en su trabajo
-* **Trabajar solo:** Ser un mantenedor puede ser increíblemente solitario. Incluso si trabajas con un grupo de mantenedores, los últimos años han sido difíciles para reunir equipos distribuidos en persona.
+* **Trabajar solo:** Ser un contribuidor puede ser increíblemente solitario. Incluso si trabajas con un grupo de contribuidores, los últimos años han sido difíciles para reunir equipos distribuidos en persona.
Especialmente desde la COVID-19 y el trabajo desde casa, es más difícil no ver a nadie ni hablar con nadie.
-— @gabek , mantenedor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
+— @gabek , contribuidor del servidor de transmisión en vivo Owncast, sobre el impacto del agotamiento en su trabajo de código abierto
-* **Falta de tiempo o recursos:** Esto es especialmente cierto para los mantenedores voluntarios que tienen que sacrificar su tiempo libre para trabajar en un proyecto.
+* **Falta de tiempo o recursos:** Esto es especialmente cierto para los contribuidores voluntarios que tienen que sacrificar su tiempo libre para trabajar en un proyecto.
@@ -78,7 +78,7 @@ Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas co
@@ -86,20 +86,20 @@ Es importante entender qué nos lleva al agotamiento. Aquí hay algunas temas co
¿Puedes mantener tu ritmo durante 10 semanas? ¿10 meses? ¿10 años?
-Existen herramientas como la [Lista de verificación de agotamiento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) y el [kit de autoevaluación de ecología personal de Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que pueden ayudarte a reflexionar sobre tu ritmo actual y ver si hay ajustes que puedas hacer. Algunos mantenedores también utilizan tecnología portátil para realizar un seguimiento de métricas como la calidad del sueño y la variabilidad de la frecuencia cardíaca (ambas vinculadas al estrés).
+Existen herramientas como la [Lista de verificación de agotamiento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) y el [kit de autoevaluación de ecología personal de Mozilla](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que pueden ayudarte a reflexionar sobre tu ritmo actual y ver si hay ajustes que puedas hacer. Algunos contribuidores también utilizan tecnología portátil para realizar un seguimiento de métricas como la calidad del sueño y la variabilidad de la frecuencia cardíaca (ambas vinculadas al estrés).
### ¿Qué necesitarías para seguir sosteniéndote a ti mismo y a tu comunidad?
-Esto será diferente para cada mantenedor y cambiará según tu fase de vida y otros factores externos. Pero aquí hay algunas temas que escuchamos:
+Esto será diferente para cada contribuidor y cambiará según tu fase de vida y otros factores externos. Pero aquí hay algunas temas que escuchamos:
-* **Apóyate en la comunidad:** Delegar y encontrar colaboradores puede aliviar la carga de trabajo. Tener múltiples puntos de contacto para un proyecto puede ayudarte a tomar un descanso sin preocupaciones. Conéctate con otros mantenedores y la comunidad en general, en grupos como la [Comunidad de Mantenedores](http://maintainers.github.com/). Esto puede ser un gran recurso para el apoyo entre pares y el aprendizaje.
+* **Apóyate en la comunidad:** Delegar y encontrar colaboradores puede aliviar la carga de trabajo. Tener múltiples puntos de contacto para un proyecto puede ayudarte a tomar un descanso sin preocupaciones. Conéctate con otros contribuidores y la comunidad en general, en grupos como la [Comunidad de Contribuidores](http://maintainers.github.com/). Esto puede ser un gran recurso para el apoyo entre pares y el aprendizaje.
También puedes buscar formas de involucrarte con la comunidad de usuarios para escuchar regularmente comentarios y comprender el impacto de tu trabajo de código abierto.
@@ -109,7 +109,7 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
Estuve en un podcast hace un tiempo y estábamos hablando sobre el mantenimiento de código abierto y la sostenibilidad. Descubrí que incluso un pequeño número de personas que apoyan mi trabajo en GitHub me ayudó a tomar una decisión rápida de no sentarme frente a un juego, sino de hacer una pequeña cosa con el código abierto.
-— @mansona , mantenedor de EmberJS
+— @mansona , contribuidor de EmberJS
@@ -118,7 +118,7 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
@@ -130,7 +130,7 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
Estoy encontrando más oportunidades para "momentos de creatividad" en medio del día en lugar de intentar desconectar por la noche.
-— @danielroe , mantenedor de Nuxt
+— @danielroe , contribuidor de Nuxt
@@ -140,7 +140,7 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
Para confiar de manera significativa en otros en estos aspectos, no puedes ser alguien que diga sí a todas las solicitudes. Al hacerlo, no mantienes límites, profesional o personalmente, y no serás un compañero confiable.
-— @mikemcquaid , mantenedor de Homebrew sobre [Cómo decir no](https://mikemcquaid.com/saying-no/)
+— @mikemcquaid , contribuidor de Homebrew sobre [Cómo decir no](https://mikemcquaid.com/saying-no/)
@@ -150,15 +150,15 @@ Esto será diferente para cada mantenedor y cambiará según tu fase de vida y o
Mi software es gratuito, pero mi tiempo y atención no lo son.
-— @IvanSanchez , mantenedor de Leaflet
+— @IvanSanchez , contribuidor de Leaflet
- No es un secreto que el mantenimiento de código abierto tiene sus lados oscuros, y uno de ellos es tener que interactuar a veces con personas bastante ingratas, exigentes o directamente tóxicas. A medida que aumenta la popularidad de un proyecto, también aumenta la frecuencia de este tipo de interacción, lo que añade una carga adicional a los mantenedores y posiblemente se convierte en un factor de riesgo significativo para el agotamiento de los mantenedores.
+ No es un secreto que el mantenimiento de código abierto tiene sus lados oscuros, y uno de ellos es tener que interactuar a veces con personas bastante ingratas, exigentes o directamente tóxicas. A medida que aumenta la popularidad de un proyecto, también aumenta la frecuencia de este tipo de interacción, lo que añade una carga adicional a los contribuidores y posiblemente se convierte en un factor de riesgo significativo para el agotamiento de los contribuidores.
-— @foosel , mantenedor de Octoprint sobre [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+— @foosel , contribuidor de Octoprint sobre [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs)
@@ -166,7 +166,7 @@ Recuerda, la ecología personal es una práctica continua que evolucionará a me
## Recursos adicionales
-* [Comunidad de Mantenedores](http://maintainers.github.com/)
+* [Comunidad de Contribuidores](http://maintainers.github.com/)
* [El contrato social del código abierto](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg
* [Cómo lidiar con personas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
@@ -179,7 +179,7 @@ Recuerda, la ecología personal es una práctica continua que evolucionará a me
## Colaboradores
-¡Muchas gracias a todos los mantenedores que compartieron sus experiencias y consejos con nosotros para esta guía!
+¡Muchas gracias a todos los contribuidores que compartieron sus experiencias y consejos con nosotros para esta guía!
Esta guía fue escrita por [@abbycabs](https://github.com/abbycabs) con contribuciones de:
From 60ed246afaa2b3a8afe0db355e40bf306cb801ae Mon Sep 17 00:00:00 2001
From: KaitoMuraoka
Date: Tue, 17 Oct 2023 15:51:14 +0900
Subject: [PATCH 23/29] Translated into Japanese
---
...ing-balance-for-open-source-maintainers.md | 124 +++++++++---------
1 file changed, 62 insertions(+), 62 deletions(-)
diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
index 0cea6e5c0fc..e472149bc65 100644
--- a/_articles/ja/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -1,174 +1,174 @@
---
lang: ja
untranslated: true
-title: Maintaining Balance for Open Source Maintainers
-description: Tips for self-care and avoiding burnout as a maintainer.
+title: オープンソースメンテナーのバランス維持
+description: メンテナンス担当者としてのセルフケアと燃え尽き症候群を避けるためのヒント。
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.
+メンテナーの経験とバランスを取るための戦略を知るために、私たちは 40 人の maintainer community のメンバーとワークショップを行い、彼らのオープンソースでの燃え尽き症候群に対する第一線での経験と、バランスを保つための実践を学ぶことができました。ここで「パーソナルエコロジー」という概念が登場します。
-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.
+「パーソナルエコロジー」とはなんでしょうか?described by the Rockwood Leadership Institute によると、「生涯にわたってエネルギーを維持するために、バランス、ペース、効率を維持すること 」を意味します。これにより、私たちの会話のフレームワークを作り、メンテナーが自分の行動や貢献を、時間とともに進化する大きな生態系の一部であると認識する助けとなりました。燃え尽き症候群は、[WHO によって定義されるように](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281) 、慢性的な職場でのストレスから生じる症候群であり、メンテナーの間では珍しくありません。これは、モチベーションの喪失、集中力の欠如、および共同作業者やコミュニティとの共感の欠如に繋がります。
- 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
+— @gabek , Owncast ライブストリーミングサーバーのメンタナー、燃え尽き症候群がオープンソースの仕事に与える影響について語る
-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
+— @thisisnic , 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.
+* **「No」と言わない:** オープンソースプロジェクトでは、必要以上の責任を負うことは簡単です。それがユーザーであれ、貢献者であれ、他のメンテナーであれ、彼らの期待に答えられるとは限りません。
- I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+ 私は、自分が一人で行うべきこと以上のことを引き受けて、多くの人々の仕事をしなければならないことに気がつきました。これは FOSS でよく行われています。
-— @agnostic-apollo , maintainer of Termux, on what causes burnout in their work
+— @agnostic-apollo , Termux のメンテナー
-* **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.
+ 特に COVID 以降、自宅で仕事をするようになってからは、誰とも会わず、誰とも話さない方が難しいです。
-— @gabek , maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+— @gabek , Owncast ライブストリーミングサーバーのメンタナー、燃え尽き症候群がオープンソースの仕事に与える影響について語る
-* **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?
+あなたは 10 週間、10 ヶ月、10 年とこのペースを続けることができますか?
-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).
+[@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)のようなツールがあり、自分の現在のペースを振り返り、調整できる点があるかどうかを確認することができます。一部のメンテナーは、睡眠の質や心拍数変動 (両方ともストレスに関連している) のような指標を追跡するためにウェアラブル技術も利用しています。
-### 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.
+* **コミュニティに頼る:** 仕事の委譲や貢献者の探し方は、仕事の負担を軽減できます。プロジェクトの連絡窓口を複数持つことで、心配することなく休憩を取ることができます。[Maintainer Community](http://maintainers.github.com/) のようなグループで他のメンテナーや広いコミュニティと繋がることができます。これは、相互支援や学びのための素晴らしいリソースとなるでしょう。
- 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/).
+* **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 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/).
+* **資金調達をさぐる:** ピザのお金を探しているのか、フルタイムのオープンソースを探しているのか、サポートするリソースはたくさんあります!最初のステップとして、[GitHub Sponsors](https://github.com/sponsors)を有効にして、他の人があなたのオープンソースの作業をスポンサーすることを許可します。フルタイムに移行することを考えている場合は、次回の [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.
+ ある時、ポッドキャストに出演して、オープンソースのメンテナンスや持続可能性について話していました。GitHub での私の作業をサポートする少数の人々が、ゲームの前に座るのではなく、オープンソースでちょっとしたことをするという素早い決定を下すのに役立ったことに気づきました。
-— @mansona , maintainer of EmberJS
+— @mansona , 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.
+* **ツールを使う:** [GitHub Copilot](https://github.com/features/copilot/) や [GitHub Actions](https://github.com/features/actions) のようなツールを使って、退屈な作業を自動化し、より意味のある貢献のために時間を確保しましょう。
-* **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.
+* **休息と充電:** オープンソース以外の趣味や興味の時間を作りましょう。週末は休んでリフレッシュし、[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) に反映させましょう!一晩ぐっすり眠れるかどうかで、長期的な努力を継続できるかどうかが大きく変わってきます。
- If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day.
+ プロジェクトのある側面が特に楽しいと感じるのであれば、その楽しさを 1 日を通して体験できるように仕事を構成してみましょう。
- 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
+— @danielroe , 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.
+* **境界線を設ける:** すべてのリクエストに「 Yes 」と言えません。これは、「今すぐにはできませんし、今後もその予定はありません」と言うだけのことかもしれません。また、README でやりたいこととやりたくないことをリストアップすることもできます。たとえば、「明確に理由を示して作成された PR のみをマージします。」とか、「issue をレビューするのは、隔週木曜日の午後6時から7時までです。」などを言うことができます。こうすることで、他の人たちに期待を持たせることができますし、他の時に、投稿者やユーザーからの時間に対する要求を緩和するのに役立つ何かを示すことができます。
-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.
+これらの軸において、他人を有意義に信頼するためには、全ての要求に対して Yes と答えるような人間になってはいけない。そうすることで、仕事上でも個人的にも境界線を保てず、信頼できる同僚にはなれない。
-— @mikemcquaid , maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+ — @mikemcquaid , Homebrew のメンテナー、 [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
+— @IvanSanchez , 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)
+— @foosel , Octoprint のメンテナー、 [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
+* [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
@@ -177,11 +177,11 @@ Remember, personal ecology is an ongoing practice that will evolve as you progre
* [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:
+このガイドブックは、[@abbycabs](https://github.com/abbycabs) によって作成されました。:
[@agnostic-apollo](https://github.com/agnostic-apollo)
[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
From 5b130fcc1dd192737ba33ee8424837469092c33a Mon Sep 17 00:00:00 2001
From: KaitoMuraoka
Date: Tue, 17 Oct 2023 22:55:50 +0900
Subject: [PATCH 24/29] partinally edited for natural Japanese
---
...ing-balance-for-open-source-maintainers.md | 29 +++++++++----------
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/_articles/ja/maintaining-balance-for-open-source-maintainers.md b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
index e472149bc65..7d99322c624 100644
--- a/_articles/ja/maintaining-balance-for-open-source-maintainers.md
+++ b/_articles/ja/maintaining-balance-for-open-source-maintainers.md
@@ -33,7 +33,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
### バランスを崩し、ストレスを感じる原因を振り返る
燃え尽きてしまう原因を理解することは重要です。オープンソースのメンテナーの間で見られるいくつかの共通のテーマは以下の通りです。
-* **肯定的なフィードバックの欠如:** ユーザーは苦情があるときに接触する可能性が高いです。全てが順調に進んでいる場合、ユーザーは黙っている傾向があります。あなたの貢献がどのような変化をもたらしているかを示すポジティブなフィードバックないまま、問題のリストが増えていくのを見るのは、がっかりするでしょう。
+* **肯定的なフィードバックの欠如:** ユーザーは苦情があるときに接触する可能性が高いです。全てが順調に進んでいる場合、ユーザーは黙っている傾向があります。あなたの貢献がどのような変化をもたらしているかを示すポジティブなフィードバックがないまま、問題のリストが増えていくのを見るのは、がっかりするでしょう。
@@ -53,7 +53,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
-* **一人での作業:** メンテナーであることは非常に孤独です。例え同じメンテナーのグループで働いていたとしても、ここ数年、分散チームを直接集めるのは難しくなっている。
+* **一人での作業:** メンテナーであることは非常に孤独です。例え同じメンテナーのグループで働いていたとしても、ここ数年、分散チームを直接集めるのは難しくなっています。
@@ -66,7 +66,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
* **時間やリソースの不足:** これは特にプロジェクトに取り組むために自分の自由な時間を犠牲にしなければならないボランティアのメンテナーにとって特に当てはまります。
- もっと経済的なサポートが欲しい。それによって私の貯金を使い果たさずに、後でそれを補うための多くの契約をする必要がなく、オープンソースの作業に専念できるのに。
+私はもっと経済的なサポートが欲しいのです。そうすれば、私の貯金を使い果たすことなくオープンソースの仕事に専念でき、後に多くの契約業務を行って補わなければならないというプレッシャーも感じずに済みます。
— オープンソースのメンテナー
@@ -75,7 +75,7 @@ image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png
* **矛盾する要求:** オープンソースは様々な動機を持ったグループで溢れており、その間を行き来するのは難しいことがあります。オープンソースの仕事で給料をもらっている場合、雇用主の利益はコミュニティの利益と対立することがあります。