Issue priority for review bonus only

Events happening in the community are now at Drupal community events on www.drupal.org.
klausi's picture

Currently we have the policy that applicants can raise their application priority after 2 weeks without a response (documented in How to review Full Project applications). A review bonus is now strongly recommended in the application documentation and I think we should also adapt our application priority guidelines.

I suggest that only applications with a review bonus are allowed to raise their issue priority. That draws more attention to the review bonus program and signals more clearly that we currently choose to ignore even critical applications if there are others with a review bonus. More transparency.

What do you think?

Comments

From my experience the

KhaledBlah's picture

From my experience the application process is quite difficult and tiresome as it is. Forcing the review bonus may lead to people being more frustrated and less willing to help, I fear. I realize it only has to be done once per user/account but many people will abstain from it anyway because they feel it may not be worth it.

The problem is that without

klausi's picture

The problem is that without having the review bonus we would not get the required reviews of applications at all which would cause even more frustration. So if people think it is not worth to go through the process they probably would not be good maintainers of the full project anyway. And if they abstain from the process we have less applications to review.

Don't get me wrong - I don't want to discourage contributions, but we also need to do some basic quality assurance on drupal.org. Projects should be secure, they should not violate any licenses, they should not duplicate existing modules. And of course we don't want spammers to squat our project name space.

So while there is more automation planned for the review process we need to help each other right now to keep it going.

I can see your point and I

KhaledBlah's picture

I can see your point and I agree with what you're saying.

However, novices (like me) often have no idea how to do a review and going through all the documentation seems like a huge step that has to be made.

While code quality and the willingness to maintain a project are important this might make it look like people have to "deliver something" first before they can do what they came to do which is contribute something. I guess it's more a matter of communication - that is how to motivate these requirements - than anything else.

Don't remove review bonus lightly

arnoldbird's picture

"I suggest that only applications with a review bonus are allowed to raise their issue priority."

It may have already been decided that we are not going this route, as it looks like the 2-week rule is still in place. I would not object to removing the 2-week rule, as it's fair to expect that anyone submitting a project should review three or more other projects. re: KhaledBlah's point, everyone is a novice reviewer before they start reviewing projects. Those who can learn to write modules can certainly learn to review them.

However, once a review bonus is attained, it should not be removed from an application lightly. A review bonus should only be removed on the basis of a manual review that turns up significant problems. The bonus tag should not be removed on the basis of an automated review. It is safe to say that everyone who has attained the bonus knows about the automated reviews and how to use them. It is sufficient for a reviewer to post to the thread and say "Are you sure you've considered these issues in the automated review", setting the status back to "needs work" without removing the bonus tag. We risk removing the review bonus due only to a few false positives turned up by the sniffer, or due to a single trivial coding problem. This might tend to lengthen the review process for projects, so the queue doesn't go down.

Admittedly what I'm saying here is not based on extensive experience with the review process. If my suggestions would throw off the dynamics of the process, then please disregard.

Overall, I greatly appreciate the strenuousness of the process. It has made my module better. The application process has not yet become excessive for my particular project, but it is getting close and appears that it may wind up being excessive before all is said and done. I lost my bonus tag, seemingly because my code contained a reference to a js file that was no longer part of the module. This was a great catch by the reviewer, but caused no problems with functionality and is the sort of thing found in many beta modules. It needed fixing, but it might have been sufficient for the reviewer to point it out, change status to needs work, and leave the bonus tag in place.

Another possibility: once you lose your bonus tag, you only have to do one good manual review before you can re-apply the bonus tag.

The review process should focus on screening out modules where the author is obviously not in compliance (little or no README, insufficient project page, license problem, duplicate module, obvious failure to use the sniffer). Once an applicant has demonstrated they understand the usefullness of the sniffer, doesn't have a licensing problem, writes generally good code that makes proper use of Drupal's hooks and APIs, and is not duplicating someone else's effort, has no "normal" bugs, they should be granted full project access. We should not be requiring that modules are "Release candidates" as defined at http://drupal.org/node/467020 -- a solid beta-quality module is sufficient for a first-timer... although we should not require that the API be frozen for full access to be granted.

Thanks for reading!

Looks like the review bonus

klausi's picture

Looks like the review bonus was removed accidentally in that issue, as the post was very close to the comment where you add the tag. I would be fine if you re-add the tag.

[...]it's fair to expect that

fuzzy76's picture

[...]it's fair to expect that anyone submitting a project should review three or more other projects

No. It is completely unfair. There might be awesome programmers that have no interest whatsoever in reviewing strangers' modules. Do you really think Drupal should turn them down?

Making people jump through hoops before we accept their free, voluntary work is just plain arrogant. Open source works by encouraging participation, not by making it harder. Making it optional as a way to speed up a struggling process, might be necessary for now. But that is all.

Do you really think Drupal

arnoldbird's picture

Do you really think Drupal should turn them down?

Perhaps so. There needs to be a review process, and if I don't expect applicants to conduct reviews, then in effect I am expecting volunteer reviewers to conduct more reviews. I presume that the bonus program was started because the volunteer reviewers were overburdoned. If indeed that was the problem that led to the bonus program, what better solution do you propose?

There are numerous

fuzzy76's picture

There are numerous suggestions floating around, ranging from much more automation to removal of the process completely. And quite frankly, they all sound better than turning down good developers just because they don't want to QA modules they have no interest in. Doing that is much more damaging to the open source nature of Drupal than letting a bug or two through the application queue.

I may be coming around to

arnoldbird's picture

I may be coming around to your view on this. I have something in the application process, and have received useful feedback, but none of it has come from other applicants. It has all come from people who already have full projects and are reviewing projects on a purely voluntary basis. I suppose one other applicant told me to improve my project page and add some developer documentation, but I would have done that anyway.

As for feedback I've received from non-applicants, all of it conceivably could have come from automated tools, if the automated tools were a little better (both in terms of what the tools catch and how the tools describe the problems they catch).

In my case I do want feedback, so I likely would have willingly submitted to a review process even if it were optional. But that's not an argument in favor of the review bonus program.

One thing that can't be automated is prevention of duplicate modules. But the fear of putting a lot of work into something that doesn't provide new functionality ought to be enough to motivate developers to do the necessary research to avoid duplicates. And we can post ideas to the Contributed Modules group as well, to get feedback on possible duplication.

I dont know about numerous suggestions but..

d34dman's picture

Warning: This is my personal opinion.

I started reviewing project seriously in order to get the review bonus.

While reviewing project application i also happen to read the manual reviews done by others.

Reading manual reviews of both experienced and inexperienced programmers was quite educating. I found that most of the inexperienced programmers tend to manually install and test the modules and report bugs. And on the other hand the experienced one delved deep into the code and reported conflicts which ranged from trivial to those that catastrophically hamper drupal experience.

Reading them made me understand Drupal better, and most importantly how to interact with Drupal ( from module/theme developer's perspective ) better.

So i personally believe, time spend on reviewing is not time wasted, but in fact its time educated in understanding Drupal better.

I know the review process could be be demotivating. Demotivating for those who seek immediate applause for their project and immediately granted "promote to full project" status.

I suggest that only

jthorson's picture

I suggest that only applications with a review bonus are allowed to raise their issue priority.

Personally, I don't think that anyone actually pays attention to issue priority at the moment, despite our attempt to use it to flag long awaited reviews. As a result, this feels like an empty and meaningless change.

That draws more attention to

jthorson's picture

That draws more attention to the review bonus program and signals more clearly that we currently choose to ignore even critical applications if there are others with a review bonus. More transparency.

I disagree. You may choose to ignore critical applications, but that is a personal choice ... whereas anything put into documentation tends to get interpreted as 'policy' and/or a recommendation for all other reviewers.

We should not set a precedent that encourages reviewers to ignore anything without a review bonus. Consider that this process is often the first introduction to the Drupal community for project applicants ... the suggestion reinforces a 'we only help those who help us first' message, which is directly contrary to the image fostered everywhere else within the Drupal community.

maybe offtopic but going with the flow of comments

d34dman's picture

Personally an improvement to existing system could be like if a volunteer reviewer like me finds an application which is awesomely done.

And if the maintainer is not interested to review other application to get Pareview Review Bonus.

Then an ability to sacrifice my three reviews so that "Pareview Review bonus" could be applied to it.

I am not sure how to track the expired review links once it has been used to create a Pareview Review bonus.

Code review for security advisory coverage applications

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: