My plan for expedited applications has two goals:
- To reduce the backlog in the Project Application issue queue (now up to six weeks) by getting more people involved in the Code Review process.
- To give people an incentive to get involved.
The target group is people who have projects in the application queue. Since they have submitted an application for full project status, they have some level of technical expertise, and they have a vested interest in helping to reduce the backlog. The basic idea is that if they participate in the process, their own applications will be expedited. These are my initial thoughts on how this would work.
- People can participate at the level of either Screener or Reviewer
- In order to get expedited status, they will have to complete either three screenings or two reviews.
- Expedited status will be indicated by changing the priority of their application from normal to major (and possibly critical for even more participation).
- Reviewers will be asked to review expedited applications first.
There will be a few rules that have to be followed in order to get credit for their work.
- Applicants will need to join this group.
- Reviews will have to be properly documented.
- They cannot just make a few comments and walk away, but will have to stay with the application for a reasonable time in order to resolve issues.
There will also need to be some process for signing up and getting credit for work done. I have two thoughts on this and have not yet decided what I think would be best. We could either have them create a comment in their application issue that links to the projects they reviewed, or we can set up a special page in here where they can sign up and post the links to the projects they reviewed. Actually the sign-up page would be the only real reason to require group membership.
One last thought, we probably need to restrict who can change the priority of the application, so that reviewers know its for real. I'm thinking either group admins or possibly git admins would be the only ones authorized to do this.
Comments
Great idea!
I fully support this idea. I've been doing what I can to screen and review project applications while my project is in the queue, and I have to say that it has been nothing but beneficial to me, and I intend to continue once my own project application is resolved. Not only will this help the obviously lagging backlog, but it will encourage project applicants to expand their expertise, ultimately benefiting the community in more ways than one. I say this because I believe that had I sat idly by during this period, I may have only mildly increased my sense of proper formatting and practices that exist within the scope of Drupal module development. Now, having spent time reviewing Drupal coding practices and watching applications, I can say I feel much more confident in approaching module maintainership. I have been encouraging other applicants that seem anxious about the backlog to help reduce it by reviewing project applications. While that has likely had only a minor impact, an incentive like this could be just the thing that is needed to make a significant impact, shorten the application review process, encourage participation, and promote community.
I think individual reviewers
I think individual reviewers could do this, but I wouldn't want to make it a standard practice that we force everyone to do.
knaddison blog | Morris Animal Foundation
What's the objection?
We can't force anybody to do anything, we can only ask for people to cooperate. Do you think a six week wait for a code review is acceptable?
Poor framing
This kind of framing of discussions as "agree or you're against all improvement" isn't productive. We can all agree that we need to improve the process while still disagreeing on specific proposals.
I have no objection to anyone offering preferential treatment to people willing to participate in the review process, but I'm not personally interested in doing that, and would probably review much less if that were somehow required. (I'm not even sure we could require it.) That just doesn't fit at all with my personal motivations around reviews.
???
I don't get where this is coming from. This is an incentive for people to participate in the process. I think there is general agreement that we do need to get more people involved in the process. Nobody has to do anything, but I would appreciate your cooperation.
...
That came from this:
Maybe I read that wrong, but it still reads to me like a suggestion that anyone who doesn't adopt your strategy somehow favors longer code reviews, even after trying to read it some other way.
It's a simple question, yes or no
I think most people will answer no, a six-week wait is not acceptable. In that case there is agreement that something needs to be done to improve the situation. This is a plan for a sustained effort to recruit new people to the code review process, and an incentive for them to participate. What's the problem? Does anybody have a better solution? If so then we should do both.
My solution is to just do
My solution is to just do reviews and encourage others to do them.
knaddison blog | Morris Animal Foundation
Finally. Can we shutter this
Finally. Can we shutter this entire thread and just go back to reviewing applications?
Learn Drupal is a good incentive for me
I am reviewing modules since a few weeks and I am learning some drupal skills faster than developing modules by myself.
I think it's the best incentive a developer could expect.
Kind regards.
Calm Down & Clear the Cache
Can We Shutter This?
Good idea. I'll handle this. There's no need for any of you to be concerned with it at all.
What was that in response to?
What was that in response to?
Dreamleaf Media
A blatant plea
I realize that there is simply no group consensus for expediting applications based on the applicant's pitching in on the existing queue.
That said, in the hopes of getting my own application approved sooner rather than later, I rolled up my sleeves and closed out four issues over the last few weeks:
If anyone reading this thread were to happen to stumble upon my application, http://drupal.org/node/1181742, and code review it -- well, that'd be just awesome.
If no one does, well, that's cool too. I'm still four closer to the front! :-)
Update on this...
Hey all, I'm one of those people in the queue and I'm starting to up and getting involved in this process even though I'm already a participating member of the Drupal community in other areas (including planning a Drupal camp!). I contribute a substantial amount of time to Drupal community each month.
I just want to add a note that we're not talking about "6 weeks" in the queue here. My application was submitted 15 weeks ago as of tomorrow. Yes. 15 weeks!
The last functionality/security/etc change requested for my project was in April. Since then it has been revisiting comments, line breaks, and other minor stuff.
Earlier this week I was okay with this process but the further I get reading about the review "system" the more this frustrates me. I could have posted this on github and rolled out a D7 version long ago but I've focused on compliance, which I still think is the best strategy even though it means I have not had the time to roll out a D7 version yet.
Process slow, Github okay
Yep, the process is still too slow. When we're talking about 6 weeks, we're specifically talking about how long something waits between "needs review" and actually getting a review. There's a "needs work" side of the process that we can't really speed up at all, so we're focused on the "needs review" side that we can improve. That's currently down to around 4 weeks, and with a few more regular reviewers, I think we could get that down to 1 week. Everyone doing these reviews is involved in the community in other ways. That's why we really need more volunteers to chip in. If you can help review other applications, please do.
There's no rule against posting Drupal code on Github. Many people did that before Drupal.org moved to Git and public sandboxes. Github has become less useful for Drupal projects now that we're on Git with public sandboxes on Drupal.org. But if you find it useful, there's no "compliance" problem there.
Or did you mean coding standards or legal compliance? Those are real problems on Drupal.org, so we're not likely to ever let them through the review process. You're right that those issues show up in full projects. They're no less bugs there; we just lack the resources to catch them all. If you notice a problem, filing a bug report is helpful. Or better yet, a patch.
This WILL get better ...
Currently (and unfortunately!) the process works against the more 'active' applicants, in that many reviewers like to focus on the bottom of the review queue first, in an attempt to weed out the oldest applications first ... and any applicants who are providing updates on their application issue thread tend to get stuck in the middle of the queue without ever falling down to the 4-6 weeks timeframe without a new comment in their thread. It's a serious issue ... In the last month, I've stumbled across applications which have been pending since last October.
Rest assured that this concern has been identified, and something is being done to address it. An issue has been opened in the drupal.org queue (and a patch supplied) which will add the 'created date' to the project application view; allowing reviewers to truly focus on the 'oldest' applications, and not simply the 'longest inactive'.
Feel free to lend your support to the issue, which can be found at http://drupal.org/node/1179586.
I recently counted close to
I recently counted close to seventy reviews that I've been involved in, not including the ones that have already been closed. Many of those have been full technical reviews. Yet my own application, Gnode, which was described by the reviewer as 'squeaky clean' , has been languishing at RTBC status for nearly four weeks now. Seeing how my efforts on drupal.org have been rewarded (or not) is causing me to seriously re-evaluate whether I'm going to continue using Drupal as my platform of choice. In case you haven't heard, there are alternatives. I've already stopped reviewing new applications and taking on any new technical reviews, but I haven't yet ruled out the possibility that I could be persuaded to continue. Any git admin want to take a look at my project? Going...going...
There are 4 other RTBC
There are 4 other RTBC projects ahead of you: http://drupal.org/project/issues/search/projectapplications?order=last_comment_timestamp&sort=asc&status[0]=14
Thank you for your patience.