Cathy Theys, Drupal-Entwicklerin

Knowledge

Bringing in people to help make Drupal better

There is a little something in here about

for

  • people wondering if/how they can contribute,
  • people wanting to get more people to help them with issues they care about,
  • people wanting to mentor new contributors, and
  • people wondering what the Multilingual Initiative is up to.

Growing the number of contributors

I'm passionate about bringing in new contributors. I don't just want to help a couple of people. I want to grow contributors exponentially, so that the people I help contribute, will help others enter the community and contribute too, like a binary tree (or a even faster growing tree like a quaternary tree, but of course that might fallback as binary as it's expected that some contribute but don't then mentor, or stop contributing after a while.. which reminds me of a Vi Hart math video).

As was said by someone wittier than I: core office hours are a great example of this, where the mentors mentor new mentors which mentor new contributors, which tend to be come mentors who help more new contributors.

"New contributors" are not only people new to Drupal. Some are experienced long time users. Some work at Drupal shops, are Drupal freelancers, or work at companies and do Drupal for the company. So, I've found myself in the situation of mentoring someone who knows more technical Drupal information than I do. But I can still mentor by showing them the ropes of working with the Drupal community, pointing out resources available to them, and helping them use their skills to contribute to Drupal.

Core office hours

Core office hours are great and I recommend you try it at least once, either as a new contributor, or as a mentor. Attending core office hours will give you hands on experience with how core mentoring works. Then, you will be able to recommend it and describe it to others. So instead of telling a co-worker "I've heard core office hours are good and you should do it", you can say "I've done core office hours. I got X out of the experience. Give it a try and see what you get out of it." Warning, like working on core in general, core office hours can be habit forming!

Contributor Task: Y

Core office hours makes use of great documentation that has been added to drupal.org. The Contributor Task documentation pages are written to apply to contributing in general and not core office hours specifically.

I think these Contributor Task documents can be used even more. On drupal.org, when creating a new issue, there are instructions. (We tend to skip reading the instructions, I know.) In the instructions, it mentions a recommendation for using the Issue Summary Template. Part of the issue summary template is a section for Remaining Tasks. This is a great way to get other people to help. A list of remaining tasks lets others see where they can step in and help with an issue. Sometimes remaining tasks might be: write a patch, review a patch, manually test a patch. Here is where another use for the Contributor Task document pages comes in. In the issue summary, in the Remaining Tasks section, in addition to listing, for example, manually test patch, the Contributor Task: Manually test a patch for a Drupal issue could be linked. This really helps welcome new contributors because it makes it obvious what needs to be done and how to do it. Not every issue requires that much detail in the issue summary. But, issues that have this will be very welcoming to people jumping into an issue.

+Needs Z

Another thing that helps issues are tags. People experienced in working the Drupal core issue queue are already familiar with how useful tags are. Some common tags are:

  • needs accessibility review
  • Needs manual testing
  • Needs screenshot
  • Needs steps to reproduce
  • needs backport
  • Issue summary initiative (In some situations, I think it would be more accurate to use: Needs issue summary update.)
  • Needs change notification
  • Needs tests

There is a document Guidelines for adding tags which links to a few pages of comprehensive lists of tags. The +Needs Z tags are in the Special issue tags list.

Tags not only help to add information about the topic or current needs of an issue, but they also help people find issues they have the skills to help with. People who can do manual testing, but cannot write patches, can use the advanced search form and search for issues with the Needs manual testing tag.

The 3-tuple of a Remaining Tasks list in the issue summary, links to the Contributor Task documents for those, and Needs tags can be help make a difference between wondering why no one is helping with an issue you have interest in, and seeing people come in and help.

Multilingual Initiative

Tagging issues has allowed Gabor's d8mi focus board to stay automatically up-to-date. The multilingual initiative is brain storming on how it can better welcome in people to d8mi issues. Using tags, and expanding the focus board idea with more specific targets, is an idea under consideration. Targeted focus boards around the Needs tags can also be prefaced with links to relevant Contributor Task documents to empower new contributors with the information they need, and present sets of issues in a non-overwhelming way.

Recent cool multilingual stuff

plach was featured on Episode 049 about Entity Translation of the Modules Unraveled Podcast.

The question during the podcast from tsvenson inspired an irc conversation which inspired documenting the issues that are key to a Translation Editorial Workflow META issue. (An aside about why that issue was created: Sometimes the issues alone seem intellectual, or specifically technical. META issues can sometimes pull key issues together and make them of practical interest. This is a small example. Bigger examples of META issues are like Views in Core or Entity Translation UI improvements. Organizing issues and explaining their bigger influence can inspire people to work on sub-issues, and inspire sponsorships to help fund work on issues. It makes issues relevant to what people want Drupal to do.)

Gábor Hojtsy wrote a great summary of the usability testing he did in the Internationalization group on groups.drupal.org.

The video from Gabor's Drupal 8's Multilingual Wonderland session from BADCamp is posted.

Some resources