Posted by kscheirer on April 19, 2014 at 7:50pm
Project Application queue, current state:
- Needs Review: 83
- RTBC: 58
- Needs Work: 118
I know I haven't contributed in a while, but I'd like to go to con with an almost-clean slate. I'll do what I can to get those numbers down :) And if you're planning on being at DrupalCon, I'm sure there will be a sprint on this topic.
Comments
Welcome back! We had a clean
Welcome back! We had a clean slate last time in November 2011 so this would be really cool to see again :-)
In order to get there I think it would be a good idea to do some admin team building. We are really running low on active code review administrators, that's why we should expand our list of admins. I tried to encourage people to become administratos, but they don't seem to get anywhere on their own when they simply collect their reviews in wiki pages. I guess we need a better mentoring workflow and a better team identity to make progress there.
It would also be cool to bring some admins back that have been inactive. I guess we could just open a discussion where all admins that want to be active can leave a comment how they are involved or how they plan to be involved. Then we could just contact them and point them to the discussion. After one month or whatever we could remove the inactive admins from the list to get a clearer picture of the actual size of the team and who we can count on.
more availability
I'm starting to have more time to review applications. Point me to the issue and I'll sign-up.
No signup needed, anyone can
No signup needed, anyone can do reviews. If you would like to become a code review administrator you can create your own wiki page here where you collect your review comments, example: https://groups.drupal.org/node/393378 . Bonus points for finding security issues :-)
After some time of contributing reviews we can then promote you to a code review admin.
Free-Time
I'd be willing to review a couple projects per day, providing I have some free time.
Exposure?
OK, I am one of the losers who said he would help out with code reviews, and just made a wiki page. In fact, I just made a wiki page and didn't even add my past reviews (just a search to reviews I had done...). I then promptly forgot about it.
I think the biggest problem with the review process is general exposure. The queue is rather buried on DO. What would it take to get https://drupal.org/project/issues/search/projectapplications?status[]=8&status[]=14&issue_tags=PAReview%3A+review+bonus to be a block that can be added to user dashboard? We can add the whole issue queue as a block, but non-admins don't get notifications of activity, and have to search/filter to see Needs Review and RTBC w/ the review bonus tag.
This way, when we visit DO, we would at least see a snapshot of everything, and it would also server as a reminder that there are a lot of applications.
I would like to review as
I would like to review as well. I can not guarantee, but will try to review over the weekend. And if the list is good enough will also create a wiki page.
Yogesh
yogeshchaugule8@gmail.com || +91 98197 18464
There have been zero
There have been zero approvals in the last 3 weeks. It seems like this is almost a waste of effort to try and get project permission, might as well just wait for Drupal 8.
It's really a big turn off to see projects that have been in RTBC for years or even several months.
I completely agree.It's both
I completely agree.
It's both frustrating and discouraging to submit a module for review that has automated test coverage and test results available marked as RTBC for several months. It's even more discouraging when it's the third application you've made (first disappeared, second was ninja'd by someone who already had full access).
I'll just keep releasing on Github. At least with D8, we won't have to worry about this nonsense.
Out of curiosity, why do you
Out of curiosity, why do you think anything will change with Drupal 8?
Project application approvals on drupal.org are a process/workflow issue, so why would anything change if the code that's up for approval happens to be written for Drupal 8 rather than Drupal 6/7?
Packagist. Currently, the
Packagist.
Currently, the primary reason to release on Drupal.org is update notifications. The ability for site owners to be informed of an available upgrade seems to be important to some auditors when evaluating the ablility of software to be updated in a reasonably timely manner. No reasonable devops team would allow software to be run that didn't have immediate visibility on whether that software should be updated.
With D8, using Composer to manage dependencies becomes an option. With Composer, package update notifications can be handled via other tools such as Packagist or Versioneye.
That means the primary advantages of releasing on Drupal.org would be visibility (arguably moot) and coordinated security releases.
Of course, if one wants to maintain their own update feed, they could implement hook_update_projects_alter(), but that requires maintenance of another piece of infrastructure.
I agree it's a frustrating
I agree it's a frustrating situation to have RTBC applications waiting around for so long. I am wondering what people in the Drupal community can do to help with it?
I donate my time to Drupal in other ways and therefore don't have much time to work on project reviews, but wondering if going in and re-reviewing a few already-RTBC applications (to double check for any serious problems like security issues) and then giving them a "+1" if they look OK would help Git administrators have more confidence that the application is actually RTBC? I know in the Drupal core issue queue those kinds of re-reviews help a lot, but they also have the unfortunate side effect of bumping the issue in the queue so that it's no longer clear to the maintainers how long it's actually been RTBC for (see https://drupal.org/node/2242183) so I wouldn't want to go in and do that if the +1 comment is actually going to cause more harm than good.
Just a note (and for the sake
Just a note (and for the sake of transparency), the Technical Working Group, which is a governance body focused on 'technical policies' within the community, dedicated their last monthly meeting to discussing the Project Applications queue process. We will be looking to propose some draft recommendations to the community, hopefully sometime around DC Austin (after consultation with the Drupal.org Software Working Group).
@David: Sure, any help is
@David: Sure, any help is appreciated. I assume you have proper rights on drupal.org to assign the git vetted user role? Then I think it is not necessary to post +1, just approve RTBC applications right away if they pass your code sanity check. This is simply done by setting the git vetted checkbox on the user account, setting the application issue to fixed and posting the text from https://groups.drupal.org/node/184389#promote
I have seen some contributors
I have seen some contributors to help review(New/Need review) the project applications. However, there's no one or effort to review the RTBC applications.
A few of the reviewers have
A few of the reviewers have pretty much cleared out Needs Review projects that had a review bonus. Most of the ones that I did, and I think most of the other reviews that I read, got pushed back to Needs Work.
Tomorrow morning, I am going to reassign priorities based on the wait time, and start to go through them.
@klausi, is there anything special that should be done for RBTC projects have had one or more additional reviews that keep it at RBTC?
And, as I started to go
And, as I started to go through RBTC applications with a review bonus to reset status based on the wait times, I noticed a whole bunch that look like they entered RBTC w/o a proper review, or at least someone explicitly saying "I did a manual review of this and don't see any major issues." I will start working from the bottom up on these.
Thanks for looking at the
Thanks for looking at the review bonus applications! I appreciate the help so that applications that I look at have been sanity checked already and are RTBC. I work my way up from the oldest created date, but I have limited time these days.
What I see from you and heddn looks very promising, so making you git administrators in the next weeks seems to be in order. Then you can approve RTBC applications yourself :-)
Needs Review reduced
We are also nearly down to only one page of Needs Review.
An interesting item to consider:
For a while, I went through the needs review queue sorted by oldest, but what I found is that very few of the stuff over a few weeks old see much activity from the original requester. I would go through and provide feedback and only 1 out of 10 would get much response. The stuff in the bonus review queue got feedback daily. What this tells me is that people who are motivated get the bonus review and are likely to respond to feedback.
The quality of the code between bonus and non-bonus review projects was fairly similar. Some really good, some needed minimal work and some had some drastic issues, including security issues. The only difference is the responsiveness of module owners between these two types of project applications.
Not sure what conclusions I should draw from this, but there you have it.