![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
Reviewers. More precisely, the lack of them. People come to me months after a release and complain that they do not like how feature X is implemented. Others complain that patches in core queue just languish and they move to contrib instead where they can achieve something. This in itself is responsible for the quality of contrib -- they can achieve something because there commits happen without peer reviews. Here is a simple rule of thumb: if you spend a day creating a Drupal site, spend one hour on reviewing patches related to the functionality you just touched be it contrib or core.
This post was inspired by the Unit testing plan thread where it clearly shows how a good idea can be made great by someone else thinking on it. This is not the first time Peter Wolanin took some idea of mine and run with it and Drupal benefits from that. Why are not you doing the same?
Commenting on this Story is closed.
Isnt the biggest problem of reviewing, that people dont listen? I have seen lots of good tips and suggestions gone by without use, just because people couldnt be botherd to read and apply - they rather discuss then experiment.
If the community is open to suggestions and tips its great, but practicly? Allot of times its not the case, more a push to the I have no time do it yourself idea. I tend to agree with Steven Wittens here that quality assurance by improving the back and UI isnt done as way much as it should be, while the tips and suggestions are really out there.
Maby the second, or primary problem is not that we dont have enough reviewers, is that we dont take good care of the people (and there suggestions) who submit good reviews. I think there are enough reviewers, maby not for every project but certainly in general.
However this is about the reviewing in a pure theoratical sence, when it comes to patches I like catch his idea of reintroducing the bot again.
issues in RTBC for drupal 7
There are more than 50 issues. I think many of them need to be rerolled later. I am sorry, I have no intention for adding more to this list at the moment..
50 in the RTBC queue is nothing compared to the 180 in the needs review queue. There's nothing stopping anyone from reviewing RTBC patches and setting them back to needs work. Also most reviews tend to go to CNW rather than RTBC - especially for brand new patches.
Also the 50 in the RTBC queue is slightly inflated at the moment because a lot of patches in that state against Drupal6 got bumped to D7 before HEAD opened for development. Not to mention Dries has just been on holiday for a week, and there's no D7 co-maintainer. All of this is temporary, and a consequence of being early in the development cycle.
What we really need to get to is a situation where there's no more than 30-40 patches needing review, then it focuses attention on them and looks a lot less daunting for new people trying to get involved. Additionally there really aren't enough people reviewing patches. Some issues will run away with a lot of discussion and *subscribes* but very little activity on those issues is people actually testing the patch and/or doing in-depth visual reviews of the code.
I really, really miss the automated patch applying bot from testing.drupal.org - not SimpleTests yet, just whether it applies or not and marking to 'needs work' if it doesn't. Having that running again would cut the 'needs review' queue in less than half (or more...) and save a lot of wasted time finding this out manually. Although SimpleTests are important, using what reviewer time we have as efficiently as possible would help a lot as well.