Recently I found an issue with the Drupal Views module. I have submitted a patch to fix it.

Does anyone know what the process is to:

  1. get this issue (and related patch) reviewed?
  2. ultimately get the patch committed to the project?

Due to the amount of open issues (like over 3.700 ...) it appears the maintainers for Views are possibly dealing with more complex issues, or there might be a views project specific process to get a patch committed?

Does anyone know the answer to my questions?

Note: The specific issue I have fixed can be found at https://www.drupal.org/node/2428065, so if anyone could check this any confirm on the issue if this is fixed that would be appreciated.

  • 1
    The specific issue I have fixed is here, so if anyone could check this any confirm on the issue if this is fixed that would be appreciated: drupal.org/node/2428065
    – Jeff Logan
    Mar 26, 2015 at 20:17

2 Answers 2


A pitty that nobody has reviewed your patch so far. I think you should consider posting a question in one of the Drupal.org forums, with some kind of friendly reminder about it. Something like "can anybody help me on this specific issue to get it in status Reviewed & Tested by the Community (RTBC) please?".

By the way: RTBC is not to be considered as a synonym of "Patch to be ported". Though as a maintainer of a few Drupal modules, I often treat an issue in such status as "Ready To Be Committed".

RTBC is, in my opinion, the next status that your issue should be changed to (assuming your patch is tested by somebody else, and confirm to indeed solve the issue).

After the issue receives RTBC status, it's up to any of the (co-) maintainers of that project to actually apply the submitted patch to the most current dev version (make sure your patch was created as compared to that, if not there is a risk the patch needs to be re-rolled, which in turn will cause more delays until that gets done). It is perceived as a good practice in Drupal to also "give credit" to the submitter of the patch, by indicating your drupal userid as part of the commit message.

And from then on, it's a matter of waiting for a new release that includes the corresponding commit of course.

A great illustration of this workflow can be found in the issue at https://www.drupal.org/node/1947876 ... Even though that specific issue has taken really long (over 2 years ...) before it made it to the finish, i.e. status fixed and closed. What I find so amazing about this issue is that it is a perfect illustration of "the community at work", where each of the players did their part of the work ...

FYI: I'm a (co-) maintainer of a few Drupal modules (refer to my SE profile for details), sometimes it's hard to find sufficient time to process such RTBC-patches (waiting to be committed). But whenever I have time, I always give those RTBC-issues the highest priority, out of respect for the contributors of such patches (and the people who reviewed them) ...

PS: even if your patch doesn't get committed as fast as you'd like it to be, you should still continue submitting patches. Because that way you have them available for any sites where you believe this patch is required. This may require however that occasionally you need to update / rework your patches.

  • Hm, I wonder why my answer here received some recent upvotes. I just "documented" how "I" try to give back to deserving contributors for the patches they submitted, no? Or maybe I should phrase it like "I'm just like a release manager to final approve all such RTBC-ed patches"? Anyway, most recently I've learned the importance of mentioning the D.O userid of the patch submitter also in the commit message (I realize now I probably didn't do that enough in the past, and now wonder which GIT commit cmd option I should use to get that repaired, if still possible ... Apr 6, 2015 at 9:59
  • Thanks for answering my question, it does help a lot whilst i'm getting up to speed with contributing to drupal. I took your advice and asked in the Drupal Forum to see if anyone has time to test my patch.
    – Jeff Logan
    Apr 6, 2015 at 20:09

There is nothing wrong with Pierre.Vriens answer, but I just want to add a few points to what he says:

  1. If the module has a huge backlog of uncommited patches, and you feel like helping out with getting things done in a more timely fashion, you should consider offering to co-maintain the module. Just post an offer to co-maintain in the project's issue queue, with a copy to the project owner as a PM using his/hers Drupal.org contact form, point out your patches (that helps the owner evaluate your skills as a developer), and wait at most two weeks for a reply. The maintainer is not obliged to accept your offer (some owners insist on being in total control), but most owners will appreciate a helping hand. Btw. if you're made co-maintainer, it is not considered good form to commit your own patch until it has received at least one positive review from another user - but I know that not all co-maintainers respect this rule.

  2. If your offer to co-maintain is not answered in two weeks, and the maintainer also appears to be missing in action (patches are no longer committed or rejected, the maintainer no longer responds to issues being raised in the issue queue), you may consider initiating the unsupported (abandoned) project process. You may enter this process to take over the project yourself to make it properly maintained, or just to get it flagged "Unsupported". The latter status signifies that the project is "put up for adoption".

The Views project is my no means abandoned, but its team is very busy with the D8 port (Views is in core for D8) - so the D7 version could probably use some extra love.

  • what a great addition to my earlier answer! Guess who just voted it up ... Even though your answer has a tiny typo in it (= "a offer" or "an offer"?) ... FYI: both scenarios (points) that you described happened to me in the past few months or so. And actually I've even run into some variations of them. It appears to me like not appropriate to explain these variations here (via another answer). Maybe I should do so in the format of a new question (+ my own answer about how I got it resolved)? Some days ago I earned a title like "legacy maintainer" for 1 popular D6 module ... Apr 2, 2015 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.