Add copy from Google Doc

_articles/maintaining-balance-for-open-source-maintainers.md

@@ -7,26 +7,216 @@ order: 15
 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 a balance to stay refreshed and productive for the long run. This is where the concept of personal ecology comes into play.
+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 <a href="http://maintainers.github.com/">Maintainer Community</a>, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play.
+
+So, what is personal ecology? As <a href="https://rockwoodleadership.org/nonprofit-four-day-workweek-can-take-care-still-change-world/#:~:text=personal%20ecology%3A%20maintaining%20balance%2C%20pacing%20and%20efficiency%20to%20sustain%20your%20energy%20over%20a%20lifetime%20of%20activism">described by the Rockwood Leadership Institute</a>, it involves "<strong>maintaining balance, pacing, and efficiency to sustain our energy over a lifetime</strong>." 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.
+
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
   I was unable to focus or start on a task. I had a lack of empathy for users.
   <p markdown="1" class="pquote-credit">
-— @gabek, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work.
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
   </p>
 </aside>
 
+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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/thisisnic?s=180" class="pquote-avatar" alt="avatar">
+  I was unable to focus or start on a task. I had a lack of empathy for users.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/thisisnic">@thisisnic</a>, maintainer of Apache Arrow
+  </p>
+</aside>
+
+* **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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/agnostic-apollo?s=180" class="pquote-avatar" alt="avatar">
+  I found I was taking on more than one should and having to do the job of multiple people, like commonly done in FOSS.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/agnostic-apollo">@agnostic-apollo</a>, maintainer of Termux, on what causes burnout in their work
+  </p>
+</aside>
+
+* **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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/gabek?s=180" class="pquote-avatar" alt="avatar">
+ Especially since COVID and working from home it’s harder to never see anybody or talk to anybody.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/gabek">@gabek</a>, maintainer of the Owncast live streaming server, on the impact of burnout on his open source work
+  </p>
+</aside>
+
+* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project.
+
+<aside markdown="1" class="pquote">
+  [I would like to have] more financial support, so that I can focus on the open source work without burning through my savings and knowing I'll have to do a lot of contracting to make up for it later.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **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.
+
+<aside markdown="1" class="pquote">
+  With paid open source, conflict between employer’s focus and what’s best for the community
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
 ### Watch out for signs of burnout
 
+Can you keep up your pace for 10 weeks? 10 months? 10 years?
+
+There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla’s [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress).
+
+<aside markdown="1" class="pquote">
+ I’m a big believer in good wearables. With the science behind it, you can understand how you could have done better and how to get to an optimal state of what you want to do.
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
 ### What would you need to continue sustaining yourself and your community?
 
+This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard:
+
+* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. 
+
+  You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work.
+
+* **Explore funding:** Whether you’re looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you’re thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/).
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mansona?s=180" class="pquote-avatar" alt="avatar">
+ 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.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mansona">@mansona</a>, maintainer of EmberJS
+  </p>
+</aside>
+
+* **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.
+
+<aside markdown="1" class="pquote">
+ Use [Copilot](https://github.com/features/copilot/) for the boring stuff - do the fun stuff
+  <p markdown="1" class="pquote-credit">
+— open source maintainer
+  </p>
+</aside>
+
+* **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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
+ I’m finding more opportunity to sprinkle ‘moments of creativity’ in the middle of the day rather than trying to switch off in evening.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
+  </p>
+</aside>
+
+* **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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">
+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.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/mikemcquaid">@mikemcquaid</a>, maintainer of Homebrew on [Saying No](https://mikemcquaid.com/saying-no/)
+  </p>
+</aside>
+
+  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.
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/IvanSanchez?s=180" class="pquote-avatar" alt="avatar">
+My software is gratis, but my time and attention is not.
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/IvanSanchez">@IvanSanchez</a>, , maintainer of Leaflet
+  </p>
+</aside>
+
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/foosel?s=180" class="pquote-avatar" alt="avatar">
+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.  
+  <p markdown="1" class="pquote-credit">
+— <a href="https://github.com/foosel">@foosel</a>, ,maintainer of Octoprint on [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs)
+  </p>
+</aside>
+
+Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run.
+
 ## Additional Resources
 
+* [Maintainer Community](http://maintainers.github.com/)
+* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon
+* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg 
+* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge
+* [SustainOSS](https://sustainoss.org/)
+* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla
+* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/)
+* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid
+* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com)
+* Workshop agenda was remixed from [Mozilla’s Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series
+
 ## Contributors
+
+Many thanks to all the maintainers who shared their experiences and tips with us for this guide!
+
+This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: 
+
+[@agnostic-apollo](https://github.com/agnostic-apollo)
+[@AndreaGriffiths11](https://github.com/AndreaGriffiths11)
+[@antfu](https://github.com/antfu)
+[@anthonyronda](https://github.com/anthonyronda)
+[@CBID2](https://github.com/CBID2)
+[@Cli4d](https://github.com/Cli4d)
+[@confused-Techie](https://github.com/confused-Techie)
+[@danielroe](https://github.com/danielroe)
+[@Dexters-Hub](https://github.com/Dexters-Hub)
+[@eddiejaoude](https://github.com/eddiejaoude)
+[@Eugeny](https://github.com/Eugeny)
+[@ferki](https://github.com/ferki)
+[@gabek](https://github.com/gabek)
+[@geromegrignon](https://github.com/geromegrignon)
+[@hynek](https://github.com/hynek)
+[@IvanSanchez](https://github.com/IvanSanchez)
+[@karasowles](https://github.com/karasowles)
+[@KoolTheba](https://github.com/KoolTheba)
+[@leereilly](https://github.com/leereilly)
+[@ljharb](https://github.com/ljharb)
+[@nightlark](https://github.com/nightlark)
+[@plarson3427](https://github.com/plarson3427)
+[@Pradumnasaraf](https://github.com/Pradumnasaraf)
+[@RichardLitt](https://github.com/RichardLitt)
+[@rrousselGit](https://github.com/rrousselGit)
+[@sansyrox](https://github.com/sansyrox)
+[@schlessera](https://github.com/schlessera)
+[@shyim](https://github.com/shyim)
+[@smashah](https://github.com/smashah)
+[@ssalbdivad](https://github.com/ssalbdivad)
+[@The-Compiler](https://github.com/The-Compiler)
+[@thehale](https://github.com/thehale)
+[@thisisnic](https://github.com/thisisnic)
+[@tudoramariei](https://github.com/tudoramariei)
+[@UlisesGascon](https://github.com/UlisesGascon)
+[@waldyrious](https://github.com/waldyrious) + many others!