Tom Auger 10:58 pm on November 14, 2012  

Summary: Engaging / Retaining New Community Devs

Merged discussions:

  • I can’t get no traction: how community devs can get involved in TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. culture without giving up their day jobs? – Jonathan Davis
  • State of the idea of Component Leaders – Konstantin (?)
  • How to help contributors in a good way 3.4-ish – Marko H
  • What can we do to better engage/retain new contributors? – Tom Auger

Attendees

  • Jonathan Davis (discussion leader)
  • Peter Chester
  • Chris Olbekson
  • William Davis
  • Aaron Campbell
  • Chris Jean
  • Marko Heijnen
  • Scott Taylor
  • Michael Pretty
  • Jon Cave
  • Ryan McCue
  • Nikolay Bachiyski
  • Justin Kopepasah
  • Simon Wheatley
  • Kailey Lampert
  • Konstantin Kovshenin
  • Brad Williams
  • Mike Hansen
  • Ptah Dunbar
  • Tom Auger
  • Alex King
  • Andy Peatling
  • Andrew Norcross
  • Helen Hou-Sandi

Many conversations carry on for a long time with no end in sight.

One of the problems is that code is often too toxic to proceed. Toxic code can be addressed by unit tests

One of the problems is that you submit a ticket and it just dies.

How should the process of contributing work? Trac? It’s hard to figure out who’s who on Trac. Once you know it’s easier to move tickets through.

Tickets die if coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. devs don’t buy in to tickets. It takes persistence and day job time to get your work pushed.

There’s a difference in motivation of fun vs. business. How do we support customer driven, time sensitive contributions?

Is that the right motivation? Dangerous to promise/use contributions as leverage with clients.

There are detailed tickets that are awesome and perfect. And other times when the detailed ticket is hopeless and instantly denied.

It would help if Trac profiles had ‘specialties’ so that people who are specialized in areas get routed.

Nacin: We used to have component owners, but found that this stifles contribution. I’d like to discuss building teams for components. This would help for quick response to tickets.

How do you fix a stalled ticket? Communication is key. Even if the communication is “we’re looking into it”. If UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. / UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. are your blockers, we do bug scrubs in IRC so we can move tickets forward regularly.

Nacin: We have the weekly project chat, but it’s designed for status checks and not ‘come with your ticket’. The key now is, come into IRC and pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” someone. You don’t have to ping me directly, just drop a ticket and see who chats:

I didn’t even know this stuff. It should be more clearly written out. Each P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/. needs the essential info at that top of the page.

I’d like to see more chatter from us on IRC. We need to reference the IRC chat in tickets.

  • Biggest change for me was subscribing to Trac emails.
  • How many emails?
  • A lot.
  • That doesn’t seem realistic as a solution.
  • It gives you a better perspective of how much is happening and where.

We’re all contributors. We have limited time. Spending it licking a firehose is maybe not the most effective way to use our time. I think we need to know where our tickets / components are going.

For every ticket that needed a patch, there is a difficulty. First time contributors, start with ‘easy’ tickets. This made it very easy to do your first contribution.

I don’t think the problem is finding a ticket, it’s getting the ticket you want to get passed.

What about a signal that is basically, “I’m new here, I want to submit a patch. Can someone hold my hand?”

What can we accomplish in the near term?

  1. P2s need headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. with info about how to get involved.
  2. Dev handbook needs to be more prominent including how to submit a patch.
  3. Come up with an ideal flow to eventually be a roadmap to better Trac/submission/patch process

Triaging tickets could be a perfect medium task. How do we define triage? This is a bit more modular issue.

  • Bug reporting
  • Enhancement / Feature requests
  • Bug gardening

Action Item: P2s need header with info about how to get involved