What can the Drupal Community do about Burnout?
This post is the last in a series in preparation for the Burnout core conversation at Drupalcon London. The first post discussed what burnout is; the second is about what individuals can do about burnout; the third was about how the Drupal Community burns people out.
The key point of this series is that we need to do strategic thinking as a community about how to treasure and keep our wonderful contributors. That's the point of the core conversation. It will not be a support group for people to share their burnout stories, but a gathering to think strategically about how the community can prevent or heal burnout to protect and keep our members.
We must value, keep, and grow our contributors. Burnout is not a problem we can ignore. It costs incredible productivity, of course, when a contributor becomes contribution-disabled or disappears. It actually costs huge sums of money to all the economically invested members of the community. But most important, we as a community care about our members and don't want to see them damaged by the fact that they care and invest themselves.
To begin the conversation, here is some brainstorming (thanks for your notes @Bojhan!). Here are some free-form thoughts to prime the pump for our core conversation:
- Explicitly and deliberately eschew unsustainable processes and projects: We have a number of projects that seem to only increase disillusion and hopelessness because they're unsustainable the way we currently look at them. We'll have to figure out how to define what "unsustainable" is, of course.
- The docs and UX projects are potential examples. What do we have to do to change these tasks to make them sustainable?
- The full project application process currently has applications in "Needs review" that go back many weeks, and even a significant backlog of RTBC applications that have not been promoted. What do we do to make this sustainable?
- Creating a module or theme implicitly makes you the owner/maintainer, multiplying the commitments (or guilt level) of our most prolific contributors. Can we find a way to do this differently?
- There are some places where we can deliberately increase the resources available and resolve the strain that way. In the Drupal.org redesign, which was mired in never-never land for a long time, money, organization, and paid work were leveraged to lead to a (very) successful conclusion. Money is an easy answer, but there are many other ways to increase resources for a project. What are they?
- Does Drupal need a human resources department? A human resources initiative leader?
- Develop explicit replacement strategies for people. Provide a "recycling" area or forum where people can explicitly publicize responsibilities they're trying to get rid of.
- Promote and publicize the personal side of burnout management, as discussed in the first couple of posts here.
- Promote balance in community responsibilities.
- Learn from what we do right.
- We do much right with contrib modules. Maintainers are enabled to do what they need to do with their modules. Others are enabled to get involved through the issue queue. This is all good. What are other examples of what we do right?
- The new D8 initiatives, with lieutenants and more explicit decisionmaking authority, may be a real step forward in dealing with the "lack of control of our work" issues.
- Recognize that enabling others requires giving up some control. Bring on co-maintainers, for example. Mentor them. But let them work. Some will stick. Module owners may need to be more liberal in granting commit access.
- Make it clear to all that there are alternatives to withdrawing from the community. Publicize those alternatives.
- Establish communication channels amongst community leadership, develop leadership support groups.
- Understand that timely communication is half the work. Often people communicate too late, requiring passionate people to do damage control rather than creating something great.
- Increase the visibility of “coordination” efforts such as docs team lead, git migration lead, etc..
- Say "No" when necessary. If we can't be successful individually or as a community and retain our balance, let's not undertake the project.
- List and study the areas where a lack of control by contributors leads to ineffectiveness and burnout.
- Cultivate the resilience and health of our overall community. We've long valued civility. Let's grow that civility and community health. We need to commit to courtesy, civility, and valuing our community. Every aggressive tweet will hurt somebody's feelings. Promote civility. Even on Twitter.
A last note: Burnout as Opportunity
We should remember that people wearing out on their projects is actually an opportunity. If we can get them moved to new things they can be more effective and motivated, and if we can get new people into the burned-out areas, we can get better maintenance there. If people know they can move around, they can be refreshed. New blood can be inserted into key tasks.
Please comment with your ideas
In preparation for the core conversation, please post ideas here that can be included on Monday, whether you can be there or not.