Opensource.guide: [RFC] Troubleshooting > Feeling guilty or burned out

[nayafia]

Hey open source maintainers! We would love your feedback on the Troubleshooting > Feeling guilty or burned out article. We will leave this open for comments until Sep 1, 2016.

Does anything seem inconsistent with your experience? What is missing? Are there any other helpful resources on this topic?

Feel free to comment and discuss here, or even open a pull request to suggest changes.

View | Edit

[orta]

I feel like you jump from "just you running it" to "let someone else do it". Which skips over the idea that you can deputize other contributors to try and reduce the workload for you as an individual as a mid-way point.

[MikeMcQuaid]

the easier your life will be. 😎 One

the 😎 feels a bit of of place in this document in relation to others.

It might also be worth linking back to the "saying no" section in one of the other documents as I think these are tied pretty closely together. A project where you don't say no is one where you're going to be guiltily ploughing through fixing issues for people.

[MikeMcQuaid]

Otherwise: 👍

[jessfraz]

This is awesome 👍

[steveklabnik]

A minor issue, but since this is the last bit, the display ends up looking a bit weird at the end

This section also feels different than the rest, which I guess is the idea, since I can't just click "next" to read through them, I have to open up this bullet list in new tabs.

[bkeepers]

This section also feels different than the rest, which I guess is the idea, since I can't just click "next" to read through them, I have to open up this bullet list in new tabs.

Yeah, we have to figure out how we want to navigate content that is not in the main flow. I expect we'll soon be adding a lot of FAQs, which this section is probably more consistent with.

[nayafia]

@parkr and @nathansobo: would also love your feedback on this one :)

[parkr]

Hey @nayafia! This is a great document. I am certainly dealing with burn-out a lot now so reading this document this morning helped keep some perspective. I just got back from vacation, speaking of taking breaks!

Jekyll, CocoaPods, and Homebrew are several examples of projects that have ground rules for maintainers and contributors.

We merged our PR, so I'd love it if we could update the link behind "Jekyll" to https://github.com/jekyll/jekyll/tree/master/docs so it's always up-to-date.

I agree with @orta in that it would be good to mention various ways of deputizing contributors. For Jekyll, we're toying with the idea of Affinity Team Captains being automatically assigned and taking responsibility for issue triage & PR review. It's still in its infancy, but with a Core team that has historically not had much bandwidth, it's a way of quickly and easily distributing work to others with expertise in a specific area of the code base. This is just one way to do it. Ultimately, we want to distribute the load to many people and want to avoid diffusion of responsibility by having one captain responsible for an issue, rather than leaving it up to anyone.

[nathansobo]

I like everything in here. Not sure if it's appropriate but one technique could be to add APIs or customization hooks to your project so that people can meet their own needs without modifying the source directly. But that's technical advice and this seems more geared toward social strategies.

[MikeMcQuaid]

I like everything in here. Not sure if it's appropriate but one technique could be to add APIs or customization hooks to your project so that people can meet their own needs without modifying the source directly. But that's technical advice and this seems more geared toward social strategies.

I do agree with that point. Homebrew didn't have them in the early days and adding them made it _much_ easier to fob people off suggest their problem may be better solved outside the main repository.

[orta]

Agreed with Mike re:extensions, in the iOS OSS world all of the biggest projects are now using plugin structures to let others fix holes that the dev teams don't have time to look at, I covered this in a post on "building OSS defensively"

[nayafia]

Thanks all! I think it's worth adding something related to @nathansobo's point, even if it's just to plant the seed. :) will update that, as well as something about deputizing contributors.

@parkr just fixed that link, ty for the heads up https://github.com/github/open-source-handbook/commit/6d29b1fb47abc2d92b7b710a552f152b5740b5c3

[nayafia]

Closed per #96.