Neuen Kommentar schreiben

How to become a community leader

[Gábor] Preface: I’d like to state that I’m extremely lucky in the Drupal 8 Multilingual Initiative that I have such a broad scope of things to work on that can match a huge number of people and that I had the opportunity to collaborate on this with such great people, especially Cathy Theys (YesCT) being very helpful in helping scale out the initiative. The wisdom shared here is experience we collected together on the long ride. And it is not over yet :)

The following is a paraphrased conversation between Gábor Hojtsy and Jesse Beach. Jesse asked Gábor how to become a better initiative leader. Jesse asked the following questions and Gábor answered them with interjections from Jesse.

I feel like I don’t have enough time to address all the issues that are important to me? How do I scale myself up?

First off you need to have a list of those things. While having a backlog of issues sounds so old-school, there is nothing that beats that. If you read Gettings Things Done and most methodologies written before or after, the central thing is always knowing your list of things. You don’t need to plan it all out, but having a list of things gives visibility on the pool of things in your area. (It also gives peace of mind that if you forget, you still have it recorded).

[Jesse]: Ok, so I should keep a list of issues on drupal.org in a project issue queue that I would like to see addressed eventually.

Specific tools on drupal.org that people use for this are issue categories and even more so issue tags. Having tags for your area (possibly a master tag for the whole area and subtags for subsections) helps a lot to identify issues. Several initiatives adopted using the "sprint" tag additionally to their other tags to mark issues that are "currently in focus". Not necessarily meaning a specific timeframe, but to highlight current focus issues.

I even built a tool named Rocketship that helps visualize the issues. For example, the sprint issues for multilingual are at http://www.drupal8multilingual.org/issues/focus, which helps show people the currently important things. I love visualizations, and I think this is a huge improvement over how drupal.org presents issues. I did make a point of taking data only from drupal.org for these visualizations, so we don’t externalize part of the community and/or potentially loose data.

[Jesse]: So there are tools I can use (and help improve!) on top of the existing drupal.org issue management infrastructure.

Why would other people care about my initiative?

They already care. The trick is to find the people who would also be inclined to help out. It is admittedly easiest to get new people on board on in-person sprints. Tools I used to get people who are interested involved in issues:

  • I regularly held a "Multilingual therapy BoF" at DrupalCons and Drupal Camps, where people can come with their pain points and get answers on the spot; we direct people at modules and issues which solve their problems from where they can get involved
  • I’ve got feedback on my regular Drupal 8 multilingual session that more time would be good because the content is too much so I did a full day training at DrupalCamp Vienna, which helped find issues and get people on the training involved in fixing those issues
  • I started a whole article series on Drupal 8 multilingual improvements at http://hojtsy.hu/multilingual-drupal8 where I explain improvements and each article ends with a list of issues still open in that area; so people reading those get excited for the new awesome things and then get a list of issues to help fix
  • When I’m at an event with sprints, I pre-announce a multilingual sprint with marked tables at the event for the team. I also attempt to ensure that I arrive on time for the day to start in the morning. One simple tip is to get hold of new people wandering in in the morning.
  • You may add additional acts of kindness, like ice cream or chocolate bars for the sprinters that is small favour for the great contributions they do. These are relatively easy to cover out of pocket. When I had (bigger) sponsors, I also invited the team for a dinner together.

[Jesse]: We have local meetups in Boston every month. Maybe I can seek out contributors there first and encourage my existing collaborators to do the same.

How do I keep up momentum in my initiative?

I think this is highly related to getting new people in. I think the keyword here is to provide success.

[Jesse]: I really like that concept. Provide success. I can admit that’s what keeps me involved and others have done this for me in the past.

You need to ensure that the right people are matched with the right issues and that you help as much as possible for the whole lifetime of the issue. It sometimes takes some nodding, connecting more people to look at one issue, etc. to get things started. Sometimes though you get patches but there is nobody to test them. I always had people who cannot code or would only be interested in test writing, so you can ask them to manually test or write tests respectively. Again, all this is based on knowing your issues in the first place.

Getting the issues in requires that there is an agreement on the solution. I find this is critically important especially at in-person sprints, that we focus on resolving issues and getting them to a committable state. Focus on quality (committable state) over quantity (move more issues forward). When the sprint is over, people will go home and get back to their "real" life, not engaged with the task anymore. Getting someone else fresh on the task later is harder than you may think. So focus on pairing people up to get issues to a committable state.

[Jesse]: Right, encourage new-comers to become mentors as quickly as possible.

Being in that state does not mean they are committed. They will likely linger in the queue for a long time. Especially for new contributors, their issues are likely not major or critical, so their issues may linger around in the queue for pretty long. But what you need is for them to land in core, so your contributors are actually successful. There is nothing more stressing than hard work to get something committable and then no attention on it ever. Strategic tagging, using proper issue priorities (sometimes the issue turns out to be actually major instead of normal) and sometimes some nagging the core committers helps. They equally understand the value of bringing new people in.

Once you made your (new) people successful, some of them will come back and want to do it again. Rinse and repeat.

How do I keep my team members engaged?

Different teams in Drupal core do different things for this. Some teams have Google Hangout meetings which are more personal, but require more rapid English skills. That may be a barrier to some, but may also be very productive if the people involved are good verbal communicators. The multilingual initiative chose to go the IRC meeting route, where we usually have a meeting every other Wednesday at the same time. This allows for participation of people speaking less fluent English as well. The meeting is archived and the archives are accessible from the announcement posts later.

As part of these meetings, at the in-person sprints and generally on the web (Drupal Planet, twitter, etc) it is important to celebrate the successes you had.

If your area is not successful for a prolonged time, that is your biggest problem. However look at how you define success. A new person solving a relatively simple issue could be a big success for that person. Celebrate new people, issues resolved, recurring contributors, etc. At the multilingual initiative, we set up a whole site to present the initiative, and we made a point to celebrate the following ways:

In short, the key is to value all your contributors and not only ensure their success but also make a big deal out of it. Make people proud of their good work. Your collaborators work on important things and they love to feel they do.

Will I need to give up coding?

You’ll do a lot of other things outside of coding. You’ll present work of others, you’ll demo their work, you’ll identify issues, you’ll categorize and help find people for them. You’ll watch issues and ensure they move. You’ll prioritize and de-prioritize issues to help your team focus. You’ll write blog posts and celebrate with your team. I think these are fun things as well. Coding itself will not help you scale yourself. You need to do meta-things to enable others to work with you on things that matter.

That said, there will definitely be times, when that RTBC patch is not applying anymore, needing a reroll, when you find no way to pair someone up to write a test for something or do a review. When somebody or multiple people on your initiative concurrently have life events and they need to withdraw from your initiative. You’ll need to step in and then code as much as needed, but make sure to spend time onboarding others in that area of focus, so you don’t fall into the trap of only you knowing the whole thing again.

[Jesse]: Yes, I can’t be the only person who knows the code if I want to see progress made. The first thing I need to admit is that my initiative is bigger and more complex than I alone can handle. I need to give up some control, invite others in and acknowledge that the initiative will evolve in ways that I may not always agree with, but that ultimately will result in solutions and improvements.

I want to thank Gábor for writing up his thoughts and providing mentorship, something he so readily and selflessly provides.

Plain text

  • Keine HTML-Tags erlaubt.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
  • Zulässige HTML-Tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.
By submitting this form, you accept the Mollom privacy policy.