The review bonus program is a great way to encourage community interaction and to guarantee a faster response time for applicants that help others. We don't have many regular application reviewers at the moment and application approval can take a long time. I think the review bonus program is a major reason why the project application issue queue has not spun out of control completely in recent months.
I propose that we take this one step further: make reviews of other project applications strongly recommended for applicants in order to get their project approved. Some reasoning points:
- Applicants learn a lot while looking at others people's code. This has some sort of self-mentoring effect.
- Applicants get feedback on their project sooner, meaning they get it approved sooner.
- We make it a requirement that applicants must have code review skills. This is crucial in the whole Drupal project, as we deal with code from other people permanently in our everyday work. It is important that you can validate proposed changes to your code base from someone else before committing it. It is important to foster a culture of giving feedback and understanding what others are doing.
- The process would automatically result in a higher priority for active applicants that familiarize themselves with the community. It would also mean that applicants that are not really interested in the community would sink down in the review process. If you just want to occupy our precious project name space where you just want to dump your code without having any contact to the community, then you will not be able to get successfully through the application process.
- Veteran reviewers and Git administrators can focus more on matured RTBC issues. The review work load is better distributed and regular reviewers don't feel the pressure to deal with so many issues alone.
- This is an opportunity to channel the power of highly motivated newbies: they don't have to just wait on their application and get bored. The process encourages them to go right ahead and put their effort into engaging with others.
How this could work
Basically we keep the workflow from the current review bonus program. We should not bump applications back to "needs work" if they lack reviews in their issue summary, but we should remind them to take part in the review bonus program.
Steps necessary to implement this:
- Update the application documentation and put more emphasis on review bonus. It should be strongly recommended.
And before doing any of this we should of course discuss and build consensus if this is what we want or not.
Update 2012-03-22: I removed the suggestion to set issues back to "needs work" if they lack reviews. Better be not that strict at this point.
Update 2012-04-05: I have updated the documentation to make review bonus strongly recommended, see http://drupal.org/node/1011698
Comments
+1
Actually I don't want to force any applicant to do anything, but regarding the current count of issues and the lack of active reviewers, we should really consider to it this way. :/
A huge +1
I think review process has already started becoming viral, all we have to do is as soon as new application comes up, putting that into "needs work" right away, & unless they have any reviewed someone, every time they want their application to be reviewed.
And
even for current application if we make it required what they will end up is, doing each others review & so everyone's application will be reviewed eventually.
Sounds good, but i can
Sounds good, but i can already see the floods of "looks good, RTBC" from applicants who are not really up to the task.
Form my experience with
Form my experience with review bonus this does not happen. The number of issues that are set to RTBC is small and it is even justified in most cases.
Is this a real big deal that
Is this a real big deal that the review process is that long when you do not get involved in reviewing other projects ?
It may be a shame that some applications will never be approved (even after a long time) if the applicant doesn't review any other projects.
Translation London
Travel Clinic London
calcus david
I find it unacceptable that
I find it unacceptable that issues can be in the "needs review" state for 7 weeks without a response. We should be crystal clear to applicants that they need to help and that otherwise they do not get approved. The issue status should reflect that ("needs work").
I can understand that but I
I can understand that but I just don't like the idea to make the review process mandatory in order to get approved.
But I agree that we should promote the review process more and more to make people understand that they will be reviewed faster if they give a hand and review other applications. Not only they will learn and improve their Drupal's skills but they may also be able to improve they own application.
Translation London
Travel Clinic London
calcus david
Can't we made a autorespond
Can't we made a autorespond message on each new project posts to made a reminder about process AND recommand a lot to do reviews of other projects to get a quicker own project review?
Automated issue integration
Automated issue integration is a different topic discussed/planned here: http://groups.drupal.org/node/180444
As a current applicant, I
As a current applicant, I agree with facts that review other projects is really helpful for our own project and next ones. But the most important part for "self-mentoring effect" is to read other people review after we try do one first, not the our review itself which is sometimes really "poor".
So question is, if any applicant should made review, how could the regular application reviewers keep under control all its reviews?
We don't have to keep reviews
We don't have to keep reviews under control. If reviews are of poor quality then a followup review will reveal any errors. The final review has to be done by a git admin anyway, so that can serve as the final quality assurance.
Not Sure
I did some reviews while waiting in the queue for approval, and agree that it's a good way to learn. I'm just not sure that it should be required to do 3. Looking back if that had been a requirement I might have not even tried.
For a long time I followed the re-defining of the review process, but got pulled toward other things. Did that process ever get finalized? I would have thought I would have seen an announcement, but could have missed it.
There are plans to bring more
There are plans to bring more automation into the process, but the need for manual reviews will still be present. So we need to allocate reviewers and the most obvious resource pool are the applicants themselves.
If doing reviews scares people away they can still use the sandboxes to publish their code and come back to the approval process when they feel more ready.
Different review steps ?
Having done some reviews myself, I agree it is a good way to learn about Drupal. At the same time, I don't feel confident enough just yet to put a module status to RTBC.
Perhaps there should be more steps in the workflow, where the first step would be a review by "novice" (or first level) reviewers, catching obvious mistakes (code syntax, using git ... yes these mistakes are also revealed by running the automated scripts, but IMHO many new projects miss this anyway) and a second round of more experienced reviewers.
(I assume this workflow is already implicitly in place, with the review bonus to begin with and the git admins at the end of the review chain)
Actually the RTBC status can
Actually the RTBC status can be used by anyone, so don't be afraid to use it. I don't think we need more process overhead by classifying issues as "novice" or whatever. Experienced reviewers and git admins can look at RTBC issues and provide that second round of reviews for them.
Yes I think that's good way,
Yes I think that's good way, we can split this in two tags:
novice-review: review by people who don't have full project creation access
exp-review review by people who have full project creation access
[ naming convention of tags can be more generalized, but I think this is one good way ]
Then RTBC => fixed [ if or back to needs works ]
Two levelse?
I still think the bonus could be kept. How about 1 (or 2) mandatory reviews, and 3 (or 4) reviews in addition to get a high-priority tag?
Communication on bump back?
I've been hesitant to join in this discussion because I haven't been very active in the queue lately and I feel pretty strongly that the people who are actually doing the work should be given more deference on questions of how the work should be done. So please weight this accordingly.
I think it's very important for applicants to look at reviewers as the volunteer helpers and mentors they are, and not as some sort of elite gatekeepers. This initial contributor experience is the first impression for the whole community, and can too easily turn people away forever if we do it wrong.
Putting myself in the position of an applicant whose issue is moved to "needs work" with a message that I need to review other applications first, my first question would be: why do I need to do that before I can contribute code? I'd like to see an answer to that question that would make me want to join the Drupal community. I think there is a good answer to that, but so far the implied answer for me is "because we need your help," which doesn't make Drupal sound like a very appealing community to me.
So I'd love to see more discussion of how this might be presented to applicants in a way that encourages rather than discourages contribution. What specifically would we say when we bump it back to "needs work"?
The answer would be: Drupal
The answer would be: Drupal is so cool that everybody wants to contribute to it. We need your help to manage the flood of applications in order to get a review for your particular application. Thank you and welcome!
.
I've been in this community for 7 years and have a few published projects and I dropped out of the (then) CVS admin duties when code review became required because I don't do well reviewing code. I can write code but looking at someone else's code and trying to spot issues (especially security ones) is very difficult for me. If that had been a requirement back when I got access I doubt I would have bothered.
I recognize that there is a reviewer shortage but I think throwing up yet another roadblock to contributing is the wrong direction. Loosening things up and sticking to only what is needed to ease the burden on the security team would speed things up as well.
Yeah, thinking more of this I
Yeah, thinking more of this I agree that we should not be overly strict when requiring review bonus. I have updated the proposal to make it "strongly recommended". That should give us more attention for review bonus on one hand and not add an additional road block on the other hand.
Not all applications are equal yet the bonus is the same
Ah well.
Review scope
Hi,
are there any requirements for reviews that can be used for review bonus? I have an issue with RTBC status and I would like to speed up the process of confirmation. I have no problem with making reviews to help others, but almost all issues already have a lot of comments. So, if I involve in issues that are already reviewed a point out some problem, can it be used for bonus? Or do I have to find some fresh issue and do whole review by myself?
Thanks
There is no strict
There is no strict requirement. The link in the docs is to https://www.drupal.org/project/issues/projectapplications?order=last_com... which is all applications that Need Review.
Ideally, you would use the Review Template. If a project has been reviewed a few times already, still go through the template, and look through the code, but also make a note of whether the blocking issues have been addressed or not. It will also be handy to find some applications that have had reviews by the admins to see what they consider blocking issues and what aren't (believe it or not, the admins tend to be less strict that others over non-security related blockers).