Summary: Engaging / Retaining New Community Devs

Merged discussions:

  • I can’t get no traction: how community devs can get involved in Trac 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


  • 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 core 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 UX / UI 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 ping 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 P2 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 header 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