Peer Review

This wiki page is created to keep track of vuil's Project application reviews. As a reviewer I hope to get more advice from more experienced reviewers. Please use the comment field to add your advice, corrections, and observations.

This wiki page is created to keep track of pen's Project application reviews as suggested by klausi . As a reviewer I hope to get more advice from more experienced reviewers. Please use the comment field to add your advice, corrections, and observations.

<

blockquote>People contributing modules or themes for listing on Drupal.org receive a welcome, or lack thereof, that would have driven away many of us now active in the community. With hundreds of requests moldering awaiting review, the project application process continues to be a community crisis, and it has been acknowledged as such for five years. We are casting aside the literal future of Drupal, with a likely disproportionate impact on disadvantaged contributors. Any separate process for new contributors will inherently be unequal, and will tend toward awful.

This is a placeholder for a page I'm working on offline.

Basically, it addresses several concerns.

• Reducing the slope of the learning cliff
• Making Drupal more accessible to novices
• Proposed revisions to the contributor library
• Creation of an experimental library
• Changes to the Module Review process

The idea is to propose a more comprehensive solution to the process, as well as addressing other areas of impact.

As soon as it's complete, I'll revise the page.

Paul

The peer review process is deeply flawed in that it often takes a year or more to get a module approved. A wait of 3 months for a review is typical. There are not enough people doing reviews, especially experienced module developers.

The attrition rate (people who drop out) is also unacceptably high.

see Just a Few Good Men for some numbers.

I know what it feels like to have your hard work critiqued, piles of issues to solve and to deal with some of the hardest discussions and posts we can have. I know the many hours spent, sacrificing time with our loved ones, time without sleep or the so many other things we give up to do our part.

There are several initiatives currently being discussed in the Code Review Group aimed at reducing the backlog in the full project application queue (currently approaching seven weeks). These are briefly summarized at http://groups.drupal.org/node/154509. I am very much interested in hearing from people outside the small group of individuals who regularly participate in the code review group.

For how to do code reviews and to help out by reviewing first-time project releasers, see Code Review group.

The draft policy, procedures and requirements for bringing *.drupal.org initiatives onto the live sites are published here:

Process for getting changes deployed on drupal.org
Drupal.org development guidelines

Hopefully as ideas are generated and refined through the Prairie Initiative and people start implementing solutions, implementors can be proactive rather than reactive to the process and requirements necessary for improving Drupal.org.

We have many individuals waiting to be reviewed, and few reviewers. This gives us a backlog of applications awaiting review, which makes both reviewers and applicants unhappy. So how can we improve this?

Open source, open collaboration, open feedback!

This is a group for peer review of modules, themes, installation profiles, features.... Have a new module and want some feedback? Created a new theme and would like people to look at it for suggestions? Have an installation profile you'd like others to review? This is the place to seek that out!

As I updated all the CVS applications tonight (with some great help), I couldn't help but think that its still so unwieldy. So, I was thinking about maybe organizing a code review sprint at DrupalCon Chicago next week focused on the new Full Project applications.

It would be super cool to get applicants and reviewers paired up in person.

So, I am wondering if anyone has any thoughts or suggestions, especially on logistics. Also, my bandwidth is pretty low so maybe someone is willing to help out on this.

All issues requesting peer review use the peer-review tag (with a dash, like this group). People can also optionally focus the review they are looking for with tags such as code-review, ux-review, etc.

Hello,

Just finished a module whose main purpose is to maintain a map of existing Drupal UI form elements responsible for setting or listing something that could be exported to a feature related to its particular features components. It then displays a widget in that place for selecting to which feature this component is intended to belong.

Mainly functional for selecting which variables you want to export to a feature if you don't know which strongarm component that was you changed in the form you just submitted. At this time it works only with Features, but i see possibilities of other uses and the API is capable of that. Selecting whatever in the Drupal UI for other modules.

Your feedback wanted.
Matej

I noticed that the Peer Review group is being revitalized and the mission expandedand there is a movement for a more structured peer review of modules program, which is awesome.

Code review of existing contributed modules is frequently cited as a means to improving the quality of existing contributed modules. However, the task of performing a code review falls somewhere between documentation, writing and reviewing patches, reviewing CVS applications, and creating new modules.

This is a proposal to elevate the visibility of module review, and make it easier for newcomers to perform module reviews.

I'm writing that new developers can ask for a code review quite apart from the application review process, but i don't have much i can tell them except ask in IRC and (suggested by beejeebus ask in a g.d.o group on a topic related to your module.

Should we try to create a clearinghouse?

A "code review requested" tag for issues– or projects?

Any other places that exist or ideas for what should or should not be created?

I have spent the last hours to get a first draft of FCKeditor support in Wysiwyg Editor module.
http://drupal.org/node/282717

It's still very rough and dirty, but it outlines what can be done and what needs to be done for multiple editor support in Drupal via one API module.

Now I badly need some feedback from folks that are interested in centralized Wysiwyg editor support, who know jQuery + JavaScript, and who might have ideas and suggestions on how to solve the outlined design challenges. Of course, all editor module maintainers are implicitly more than welcome.

Hello all, here I introduce you my cuentos infantiles site.
It is a site written in spanish, where I post original short stories for children, created to educate in values and ethics. It is not a commercial site that has been in production over half a year, and right now I would like to receive feedback about these points I am concerned about:
- Usability and navigation: I am not sure if they are clear and simple enough, nor even if the site's goals are well showm.
- Theming: I wonder if the selected theme is adequate for the content and structure of the site. Especifically I would like feedback regarding the usage of a 3 column layout.
- Taxonomies presentation. Taxonomies are key for this site, as taxonomy and tagadelics are the core orgonization of the site. However, I would like to receive feedack about how taxonomies are presented and displayed
Also, if someone want to provide suggestions of useful blocks and so on, I would be glad to read them

thank you very much for your feedback!

Yesterday I downloaded and played with the Drigg module. Among its features is an option to let a privileged role submit content as a different user. The list of spoof users is also an administration option. The motivation for this is clear... it lets a handful of people easily make a site look like a bustling community. This is great for jumpstarting your Drigg site (which is designed to be a Digg clone), but how ethical is it?