Posted by klausi on June 9, 2012 at 1:59pm
Drupal core has Issue count thresholds to keep the number of outstanding bugs and tasks under control. It might be a good idea to introduce something similar for project applications. This would mean that we do not approve RTBC applications while a certain threshold is exceeded. We reach out to the other applicants and the rest of the community in such a situation to get back under the threshold(s). Getting back means reviewing applications.
I'm proposing two thresholds:
- The number of "needs review" issues must be less than 100.
- The last updated date of all "needs review" issues must be less than 4 weeks ago.
If these thresholds are exceeded, project application review administrators stop to approve applications and we all focus on reviewing and providing feedback.
What do you think?
Comments
In general, I like the
In general, I like the concept of using thresholds to help encourage more participation in the review queue ... if it's something that can get more community members participating (as opposed to existing reviewers and applicants).
My concern with the proposal above is that it introduces yet another roadblock which can slow down an applicants progress towards full project permissions ... it takes long enough to get a review to RTBC already; as a participant I wouldn't be happy to learn that my project is ready to approve, but is being held back because the queue has grown past some arbitrary number of 'needs review' applicants.
EDIT: Now, on the other hand ... adding a 'project applications' threshold to the CORE issue queue threshold list, and preventing new features while there is a project apps backlog ... that might work if there was ever any chance getting the core developer types to buy into the idea - a long shot at best! ;)
It might look like a
It might look like a roadblock for a single applicant, but it helps to remove roadblocks from the overall application pool. Our biggest problem is to get timely feedback for all right now. We are quite fast with approving RTBC issues (at least when patrickd is in non-exam mode :-P), but I think we need to distribute our efforts more evenly on the whole queue. No applicant left behind, so to speak.
Currently it is possible for an applicant to get approved within a few days if she/he gets an RTBC from someone else fast enough. That is not fair compared to other applicants that are waiting for weeks, if not months. So this would send a clear signal if the application process is out of balance. It makes it clear that reviewing applications is the responsibility of us all, from new community members to veterans to git administrators.
I'm against coupling the state of project applications to the drupal core issue queue, I think Drupal core developers are loaded with work enough. We should maintain our own threshold system and work with applications independently of Drupal core.
Oh, and of course "review bonus" should still work independently of thresholds. If your application is RTBC and you have a review bonus then you should get approval right away.
Oh, missed this one. I agree,
Oh, missed this one. I agree, threshold is good, an also approval right away if you have a review bonus.
/* Mikke Schirén, https://digitalist/ */
I don't know whether you will...
I don't know whether you will consider my point or not but it will scare to the new contributor. I think it is not good. I am agree with jthorson it is another roadblock which can slow down an applicants progress towards full project permissions. We should make a rule for the code reviewer first he should review those applications which has pareview bonus tag. I have seen there are so many users which are reviewing those applications which doesn't have pareview bonus tag even there are applications which is having pareview bonus tag which is not good. It means some user can easily get the permission to create full project without doing any code review and someone has to work hard to get this permission. Can you guys make such kind of rules?
There has been a discussion
There has been a discussion about making review bonus mandatory: http://groups.drupal.org/node/218754
Some people said that it would be another roadblock. That argument is repeated every time we have a new idea to improve the process.
Seeing it from a different perspective: if your project is interesting and there is a demand for it you will probably get more reviews. So it will go faster to RTBC and if there is nothing wrong with the code, why should it be held back?
On the other hand, the pool of permanent reviewers is very small at the moment. Attracting new reviewers is hard, because they are buried with other Drupal community tasks already. So the most logical step is to reach out to the applicant pool to help each other in order to move their own project forward (the review bonus idea). Maybe we should think about a mandatory review bonus again...
Casual volunteers
I wasn't going to jump in on this discussion, as I've been doing very sporadic reviews and access grants lately, and I feel strongly that the people doing the work should have the most influence on the process. That said, those deciding this should know that these are roadblocks (or discouragements, if you prefer) not only for applicants but for volunteers as well.
If I have a bit of free time and I remember, I'll move some RTBC projects to fixed, because I know that's something I can do quickly. I just give the project a quick double-check, grant the permission, and post a welcome message. Adding another step to this process, to confirm the number of "needs review" projects, make me less likely to participate casually like this. The same is true of anything that adds another step to reviews. I already feel like I'm almost doing something wrong when I review a project just because I'm interested in it, even if they haven't reviewed other projects.
And maybe that's okay. Casual participation makes up a very small part of the volunteer time currently, so maybe it's not important. I just wanted to make everyone's aware of this effect, as most here are not casual volunteers.