Reviews and Mentoring for naveenvalecha

Thank you for your reviews! The security issue mentioned does not seem to be a XSS issue because the value is then used in an arithmetic operation ("+" and "-"), so PHP will just cast it to a number. Make sure to actually try to exploit XSS issues by inserting/sending script tags and then observe any alert() popups for example.

When you finish a review you should always come to a conclusion: are there blocking issues that have to be resolved (such as security issues)? Then the application should be set to "needs work". Are there no serious issues left in the code? Then the application should be set to "reviewed and tested by the community". Could you go back to all your reviews, check again and flip the status into one direction or the other? In some reviews there were only very minor issues such as usage of hook_form_FORM_ID_alter() vs hook_form_alter(), which does not justify "needs work". See also my comment on not being too strict: https://groups.drupal.org/node/434943#comment-1051778

Quoting one of your reviews: "ixi.install : Set these values of the variables a default value instead of setting on the hook_install." This is quite cryptic. What do you mean here? You should always be specific what people should actually change, so if I read this correctly: "Do not set variables in hook_install() with variable_set(), you can just use default values with any variable_get() call".

Adding this here, instead of on the issue.

The main application blockers are security problems, licensing issues, and third-party code. The fourth are "major API problems". To quote @klausi from my mentoring:

Project application reviews are basically sanity checks, so while providing all details what can be improved is very valuable we have to consider what issues are really blocking approval. If we are confident that the people basically know what they are doing then we should not hold them back. With the exception of security issues and licensing issues.

I personally set applications to needs work if the API usage is so painfully wrong or the spaghetti code issues just keep piling up. Fortunately people fix all the things from pareview.sh, so at least we don't have to complain about coding standards anymore.

So, a few missing t() here and there are fine. Total disregard for translation isn't. A few bad indents, OK? Not following any Drupal coding standard, blocker. Not doing something quite the Drupal way, probably OK? Bypassing the API in a big way (like accessing $POST instead of $form_state['values']), blocker.

I would suggest looking at the feedback on the mentoring for the last few admins (me, heddn, and er.pushpinderrana) for more advice from klausi. Also go through the recently approved applications, and look for reviews from the admins to see what they did block on, and what they didn't.

As your guidance regarding promote to full project, review project, creating own wikipage in drupal. I can able to promoted my own project from sandbox. Also I can able to review other projects.Thanks @naveenvalecha for your kind help. I appreciate your efforts.

Naveen has just been made a git admin at https://www.drupal.org/node/2445643

I think he has a good understanding of the project application process and has also the necessary skills to identify problems with applications (like security issues).

Therefore I'd like to welcome you to the review admin team and feel free to use your new powers to review and approve RTBC applications! (instructions at https://www.drupal.org/node/1125818 )