Author image
Senior Developer

Playing second fiddle

While at Drupalcon I couldn't help but want to get involved in core development of Drupal. I have been involved on the fringe of Drupal core development for a number of years, and I've found bugs, submitted patches, tested others' patches, fixed others' patches and contributed documentation, but to get really involved in development you have to basically immerse yourself in it. It's really hard to follow the issue queues and get any sense of what is going on in the Drupal community. I just don't have the time to invest in core development.

Also at Drupalcon there were quite a few people that wanted to get involved but just didn't know where to do so, they didn't know where the community was focused, they didn't have any specific areas that they wanted to address themselves and just didn't know where to begin. There were also a number of people that would like to help out with core development, but not as the primary creator of a patch/feature. These people want to write a test, write some documentation or review a patch to move an issue on from its current state. I am one of these people.

These people would basically play 'second fiddle' to the primary contributor within the issue, but they would provide valuable assistance in getting the issue committed into Drupal core. Arguably there aren't many of these people, but I reckon that a lot of the 'long tail of contributors' that Dries often talks about would be willing to become them. I think that a lot of people just don't know where to start, and don't feel involved enough to contribute.

So, I'd like to propose formalising the 'second fiddle' group of people, we'd accept proposals to help out with issues that someone is struggling with, and providing that it met with certain criteria, then it would be added to a categorised list of issues that need a 'second fiddle'. Someone in the group would be able to look at the list of issues needing help and find something that met their skill level and interest. They would then help move that issue toward completion.

The criteria for accepting an issue into the 'second fiddle' group would look something like:

  • The issue must be for Drupal core, or a directly related area (e.g. the testing framework).
  • The issue must have a recent summary, outlining what the issue is about and what is required to bring the issue to completion.
  • The issue should have 'stalled' for some reason, with extra effort required to bring the issue to completion.

So how does this differ from what we have now? Well, I'd hope that because the group has more structure and a smaller set of goals, we could guide new contributors/reviewers through the process and get them comfortable with developing for Drupal core. I'd hope that the group would provide a place for people who just want to spend a couple of hours a week developing somewhere to go to find a list of easily accessible issues. And it would provide other core developers a place to go to get a second opinion or a helping hand writing a complex patch or some documentation or a test...

I really want some feedback on this idea, from current core developers, from people who would like to get involved in core development, from people who are on IRC 24/7, from people who aren't, from everyone. I would join and be an active part of this group, but ideally I'd like a lot of other people to say they join too and other core developers say that they would refer issues to the group before I get the group going.


On the whole I think it's an interesting idea. Having a standing pool of "Ugh, I need someone to review this thing, please?" people could help unstick a lot of issues.

My concern is two fold:

1) For some things, having these "second fiddle" people come in later rather than sooner means we're doing it backwards. Tests should be written before a patch is written, not after. Adding tests to narrow down a bug is great, but for new development the tests really should be coming first.

2) Often when an issue is stuck, the problem is that it's a complicated problem that only 3 people in the world actually understand. That situation itself is a bug, frankly, but I don't know that a "second fiddle team" could help there. Maybe they could by being a sounding board for the issue owner, but reviewing in a vacuum won't help much there. (That's me and most FAPI/Render API issues. I see them and run screaming, because it would take me hours to even understand the problem since the system is just so complex.)

Of course, perhaps the need to make issues more accessible to this group would be part of the benefit of having them. :-)

Overall I'm cautiously optimistic, and hope to see this go somewhere.

I agree with Larry that this is problematic. Maybe we need less of a "second fiddle" group and more of a "hand holding" group. A group where people can go to help, not knowing what to help with, staffed by a team that can direct their efforts.

Remember webchick's farmers and pirates post ( i would link but it treats me as a spammer). We still need that and quite badly. That's one thing you guys could help with. Also. There were a TON of "testingparty2008" issues that had a decent summary maybe even a patch to start with but... nothing continued. There are quite a lot of not-too-complicated-but-not-quite-novice issues as well. Finally, just *finding* the novice issues is a lot of work. So yes. The issue is sound. Find me on IRC, we can certainly work together.

I like the idea, as I also find myself immersed too much in the contrib-sphere that I tend to assume that issues in core will be resolved, magically, by the people higher up. I agree with Larry in that tests need to come first for major issues, but there's always fixing smaller things (which, as chx pointed out, they're pretty much impossible to find).

Would a new category "Level of experience" applied to issues be useful at all? It'd be interesting to categorize issues into either "novice" - "medium" - "expert" - "chx" ;)

Another thing to remember is that even with the 'big' issues, a lot of what needs to be done is very small - like re-rolling patches for conflicts, fixing/updating test failures etc., but it can be very hard to tell this from the issues without reading through a lot of comments.

chx is right that the 'farmers and pirates' post is extremely important - there's a massive a mount of triage in the core issue queue - all those patches that need review, or bug reports that are 'active', and not nearly enough people to do it actively.

Doing triage is a great way to get familiar with what's going on, you can do as much or as little as you like, and it's also a good way to actually find the smaller issues that can be tackled in a couple of hours (or even minutes in some cases).

Also I agree with David Hernandez that what's really needed is the hand-holding team - currently that's "join #drupal-contribute and say "I want to help with core" and hope someone's around who can match you with an issue" - this actually works very well when it works, but vkareh's comment about people 'higher up' pinpoints the problem - there are very bright people working on both core and contrib, and beginners working on both core and contrib. All that working on core means is where your focus is, there's nothing inherent in core developers or core issues that particularly requires more skill than contrib, although in general the way of working is quite a bit different.

I was a part of two presentations at DrupalCon that I think can help to speak to the issues in this post. The first was an Ignite presentation on how to grow new contributors. It is nice and short, 5 minutes.

The other was a full session that webchick and I did about scaling the Drupal community. It was done in interview format, and since we both kind of come at this from different angles (me more pragmatic, webchick more idealistic) it was useful for both of us to kind of play devil's advocate with each other and try and find the middle grounds in some of the growth issues we are encountering in Drupal.

I don't have any great comments on this initiative that haven't been made already. I think it is a cool idea, but it requires buy-in and commitment from the people who will act as mentors and guides for it to really work well.

Comments on this article are now closed, if you want to give us feeback you can use our contact form instead.