Posted by zzolo on April 15, 2011 at 12:02am Last updated by zzolo on Fri, 2011-04-15 00:02
This page is dedicated for reviewees (users that have had a review) to tell their story. If you have been through a review, comment on this page to tell your story.
Yeah, that is a shameless self-promotion, and really not fair to the other 215 modules sitting in the 'full project status' queue. But if it works, maybe it reinforces the message that you need to become a squeaky wheel before you get any grease. In the meantime, here's some input from a 'newbie' in the queue; for what it's worth ... apologies in advance for the novel!
Background
First, a bit of background to help frame where my comments are coming from.
My role in the Drupal community for the last four years can really only be described as 'experienced lurker'. Other than the occasional evening lurking on IRC (jert), I was strictly a Drupal 'consumer'. Then, in early 2010, I had the opportunity to develop a new website to manage a local amateur sports league. In researching available Drupal modules, I realized that Drupal didn't have much in the 'league management' space (LeagueSite module didn't exist yet) ... so I set out to develop a solution that would help out the local sports group, and maybe fill a gap for the greater drupal community as well.
16 months, three production deployments, and a complete rewrite later, and I finally felt that I had something that was 'mature' enough to contribute back to the community ... so I waited a month (for the Git Migration to complete), threw my code up as a sandbox project, and began reading up on what was needed to apply for full project status.
The Sandbox Concept
When I read about the 'new process' being introduced with the Git Migration, I figured this was going to be the greatest thing since sliced bread. After having had a chance to actually work in the sandbox environment, my enthusiasm has been somewhat tempered.
On the positive side, I still support the basic sandbox concept. Being able to point someone using my code to an official-looking page on Drupal (and one which has an official 'Drupal' issue queue) is miles better than trying to get feedback via a personal webserver or an unfamiliar (overwhelming?) Redmine/TRACS issue queue. Having this hosted within the official Drupal ecosystem during my development and testing phases helps lend an additional sense of legitimacy to my project, and allows me to interact with my users/beta testers within a familiar (to them) enviroment. Being able to do this without having to stand in line in a queue, waiting for CVS access, is a huge step forward relative to the previous process ... I delayed posting my module for a month, just to bypass the CVS access request process (and avoid adding yet another module to the massive conversion just weeks later).
In practice, however, I've found that my average module user is tech-savvy enough to download and install a module, and use the issue queue ... but that's it. As soon as they see 'Git' on my project page, they get scared off and send me a direct email asking for the code. As a result, I end up maintaining an off-site 'download' link in addition to the sandbox page, which takes away from my available 'productive' coding time.
The other issue I've found is that, without 'packaging' capabilities, it becomes very difficult to track which version/patch level of my code a particular client/tester has installed ... which results in a significant amount of time spent tracking whether they're actually using the latest code. This is partially due to me having two download sources (Git and off-site) ... and I realize that I could still use Git branches and tags to track this ... but all of this just adds noise and potential confusion for my end-users/testers.
Now I realize that these complexities are somewhat intentional, in that we don't want the 'un-educated' user stumbling across the page and downloading what they think is a 'sanitized' module. However, consider the developer who's promoting Drupal by developing a solution for a less technical customer (or alternatively, as in my case, beta testers). Having end-user testers participate in an iterative design/review process during module development ultimately results in a better final product ... but telling non-programmer clients/testers that they need to learn Git and the patching process to update their code is not workable.
As an alternative, I would propose that the packaging and direct download capabilities need to be added to sandbox projects ... but change the page layout and make the links a little bit harder to find than for a 'full project'. Bury the links in a seperate tab or menu item under the 'development' block if needed, and add a great big flashing 'THIS CODE HAS NOT BEEN REVIEWED' warning if you like ... but don't make me train my beta testers in how to use Git, or teach them a new and unfamiliar process; I'd rather have them spend their time testing/evaluating/providing feedback on my module. In addition, as a new contributor, I have no sense of confidence that the way I'm currently using branches or tags is 'correct' ... enabling packaging in the sandbox would let me learn the packaging 'best practices' and common mistakes, so that I know I'm doing it right when I'm finally promoted to full project access/status.
Code Review
I recognizing the need for solid, secure, and consistent code, and support the need for some form of code review before modules reach full project status. As a contributor, I held off on submitting a 'full project' application until I felt I had a 'finished' product, as recommended in the documentation. To now hear that the backlog is in the order of a 5 weeks as opposed to 5 days is extremely frustrating, and a very serious de-motivator.
At the end of the day, if the sandbox provided for packaging and direct download capabilities, I'd have no problem with this wait ... but for my specific situation, another 5 weeks means that my 'league management' tool doesn't even get looked at until June; and given that we're talking a large package (12 sub-modules, some exceeding 10k loc), I know the review process isn't going to be quick. As a result, the module remains unavailable for the start of the summer sports season; which renders it more or less redundant until next spring ... at which point D6 itself starts to become more or less redundant; and I miss out on a year of feedback that could go into improving a D7 version. I don't write this to whine, complain, or guilt someone into providing a review ... rather, my intent is to provide some insight into how seriously the current code review backlog affects my motivation as a potential future contributor.
Some have suggested that a 'pay it back' solution would help the code-review process ... and to some extent, it would. However, the code review process recommends sticking with a code review from start to finish (for valid reasons), and as a contributor, I hesitate to take on this responsibility.
Why? Well, as a first-time contributor, I don't know what I don't know. I could easily provide some assistance evaluating formatting, syntax, and running things through Coder; but until I've received validation that my own code is secure and follows best practices, I'm not prepared to comment on these other aspects of someone else's code ... maybe it's personal pride, but if I set out to suggest how to improve someone's module, I want to first confirm that my own understanding is solid. And perhaps it's this same pride that prevents me from stepping up to do some partial reviews now ... the only thing more demotivating than a 5 week wait for feedback would be for someone to post and tell me to run through Coder, and then a 5 week wait for someone more knowledgeable to come along and provide additional feedback once that was done.
In the end, I've been on the Drupal sidelines for long enough that this delay won't affect my overall opinion of the Drupal platform ... but had I just now stumbled upon Drupal, and had this been a smaller project, any significant delay in the code review process would have me looking elsewhere for a more 'responsive' community. (I don't suggest that the community is NOT responsive ... but if the code review were my first experience with Drupal, I could easily see myself reaching such a conclusion.) With this in mind, I strongly echo the sentiments of MGParisi and others in the Module Approval Process thread ... simplify the process for new contributors (and their users!); don't force them to jump through additional hoops and restrictions.
Hi @jthorson. Thanks for the in depth write up. It really helps to get the reviewee sides of the story.
I'll try to get to your app tomorrow, as we are having a Code Review Sprint in Portland tomorrow. http://groups.drupal.org/node/144359 If you are online during that time, we could maybe do it via IRC?
I saw the Portland review sprint post earlier today, and was about to second the request for a remote channel ... but then realized that tommorrow is also the inaugural meeting of our local Drupal User's Group. Depending on how long our meeting runs, I may be on IRC later on in the evening; but if it's wildly successful, I won't be around on IRC until Friday.
Btw ... sorry if I spammed anyone with notification of my post edits ... didn't realize that each one was triggering an email until I opened my own inbox. Ooops!
I just wanted to post my story to provide some personal feedback on what it is like to be the reviewee.
Before attempting to apply for a CVS account I had posted some decently complicated patches to a couple of modules and gotten a good response. I had just been to Drupalcon, and I was fired up about Drupal and ready to get my own code out there. This was probably some time in 2008.
I applied for CVS access, my code got a positive response in terms of quality and applying standards, but I ultimately had my application rejected because it was relatively easy to recreate what I was doing with cck and views rather than a custom module. At the time this made me really frustrated, and it was quite a while before I regained that 'ready to contribute' spirit.
A couple years later I got a contracting job that involved customizations to a contrib module and got brought on as a co-maintainer with full CVS access with little more than a +1 from the current maintainer. I am glad to see that Git has closed this loophole, but the combination of the two experiences left me feeling the whole process was really arbitrary. In the intervening years I didn't really end up doing much contribution besides an odd patch or comment here or there.
Now that I am on the other side of the wall, I have watched some really good developer friends of mine get extremely frustrated with the process and have even seen a couple give up and keep all their contributions to themselves. I've attempted to help with project reviews, but even from the reviewer side the whole process is so filled with emotion and opinion that I realized I wasn't really helping that much (I felt more like a troll than a reviewer) and gave up.
I love Drupal and want to see a lot more good people involved with it. For me it has been a huge motivating factor to have real users using your code on production sites. I worry that there are hundreds of potential great contributors that are being scared off and or burnt out by this process outside of the couple that I know personally.
As a side note I am SUPER excited to see the progress over at http://groups.drupal.org/node/180444. It is way easier to get feedback from a bot than a person, especially if its not face to face.
Thanks for sharing your perspective and anecdotes - they are very helpful.
I ultimately had my application rejected because it was relatively easy to recreate what I was doing with cck and views rather than a custom module. At the time this made me really frustrated, and it was quite a while before I regained that 'ready to contribute' spirit.
It's interesting to note that your review, and this in particular, wouldn't be helped by any of the automation proposed now.
I agree it's hard to maintain an unbiased review process that is constructive rather than feeling trollish. Definitely automating some steps will help us.
"it was relatively easy to recreate what I was doing with cck and views"
"this in particular, wouldn't be helped by any of the automation"
Indeed not. What would help that in particular would be: Getting rid of the criterion.
As has been discussed elsewhere, "your code was fine but your feature is redundant" isn't a matter of code review, it's an editorial matter.
It's my opinion that, as such, this isn't a criterion which should bar approval. I grant that for a long time there has been a community value to "avoid duplication", but with regard to project applications, it's ruinous for getting new developers engaged, and it generally quadruples the communication cycles in a review.
Contributions which duplicate functionality haven't harmed other popular open-source communities. A kind word on the part of application reviewers and/or approvers is suitable, in my opinion. Not a project rejection.
It's possible to eliminate this as a blocking criterion while preserving it as a community value. Particularly if ratings and reviews winds up getting implemented - then, the entire community (including non-developers) would have input, regarding choosing among overlapping contributions.
The main thing the duplication check helps with is keeping it easy to find good modules. "Difficult to finding modules" has been in the top 3 complaints about Drupal.org since at least 2007. So until there are better tools for finding good modules I'm not willing to completely give up on it.
I will say that I personally only believe we should ask someone to document their duplication. As long as they do that then their project page is a beacon of hope in the fight to find the right module and that's good enough for me.
Comments
An 'Old Rookie's thoughts
Earlier today, I stumbled on this interesting discussion, and a timely one for me, while I sit waiting on my own full project applcation.
Yeah, that is a shameless self-promotion, and really not fair to the other 215 modules sitting in the 'full project status' queue. But if it works, maybe it reinforces the message that you need to become a squeaky wheel before you get any grease. In the meantime, here's some input from a 'newbie' in the queue; for what it's worth ... apologies in advance for the novel!
Background
First, a bit of background to help frame where my comments are coming from.
My role in the Drupal community for the last four years can really only be described as 'experienced lurker'. Other than the occasional evening lurking on IRC (jert), I was strictly a Drupal 'consumer'. Then, in early 2010, I had the opportunity to develop a new website to manage a local amateur sports league. In researching available Drupal modules, I realized that Drupal didn't have much in the 'league management' space (LeagueSite module didn't exist yet) ... so I set out to develop a solution that would help out the local sports group, and maybe fill a gap for the greater drupal community as well.
16 months, three production deployments, and a complete rewrite later, and I finally felt that I had something that was 'mature' enough to contribute back to the community ... so I waited a month (for the Git Migration to complete), threw my code up as a sandbox project, and began reading up on what was needed to apply for full project status.
The Sandbox Concept
When I read about the 'new process' being introduced with the Git Migration, I figured this was going to be the greatest thing since sliced bread. After having had a chance to actually work in the sandbox environment, my enthusiasm has been somewhat tempered.
On the positive side, I still support the basic sandbox concept. Being able to point someone using my code to an official-looking page on Drupal (and one which has an official 'Drupal' issue queue) is miles better than trying to get feedback via a personal webserver or an unfamiliar (overwhelming?) Redmine/TRACS issue queue. Having this hosted within the official Drupal ecosystem during my development and testing phases helps lend an additional sense of legitimacy to my project, and allows me to interact with my users/beta testers within a familiar (to them) enviroment. Being able to do this without having to stand in line in a queue, waiting for CVS access, is a huge step forward relative to the previous process ... I delayed posting my module for a month, just to bypass the CVS access request process (and avoid adding yet another module to the massive conversion just weeks later).
In practice, however, I've found that my average module user is tech-savvy enough to download and install a module, and use the issue queue ... but that's it. As soon as they see 'Git' on my project page, they get scared off and send me a direct email asking for the code. As a result, I end up maintaining an off-site 'download' link in addition to the sandbox page, which takes away from my available 'productive' coding time.
The other issue I've found is that, without 'packaging' capabilities, it becomes very difficult to track which version/patch level of my code a particular client/tester has installed ... which results in a significant amount of time spent tracking whether they're actually using the latest code. This is partially due to me having two download sources (Git and off-site) ... and I realize that I could still use Git branches and tags to track this ... but all of this just adds noise and potential confusion for my end-users/testers.
Now I realize that these complexities are somewhat intentional, in that we don't want the 'un-educated' user stumbling across the page and downloading what they think is a 'sanitized' module. However, consider the developer who's promoting Drupal by developing a solution for a less technical customer (or alternatively, as in my case, beta testers). Having end-user testers participate in an iterative design/review process during module development ultimately results in a better final product ... but telling non-programmer clients/testers that they need to learn Git and the patching process to update their code is not workable.
As an alternative, I would propose that the packaging and direct download capabilities need to be added to sandbox projects ... but change the page layout and make the links a little bit harder to find than for a 'full project'. Bury the links in a seperate tab or menu item under the 'development' block if needed, and add a great big flashing 'THIS CODE HAS NOT BEEN REVIEWED' warning if you like ... but don't make me train my beta testers in how to use Git, or teach them a new and unfamiliar process; I'd rather have them spend their time testing/evaluating/providing feedback on my module. In addition, as a new contributor, I have no sense of confidence that the way I'm currently using branches or tags is 'correct' ... enabling packaging in the sandbox would let me learn the packaging 'best practices' and common mistakes, so that I know I'm doing it right when I'm finally promoted to full project access/status.
Code Review
I recognizing the need for solid, secure, and consistent code, and support the need for some form of code review before modules reach full project status. As a contributor, I held off on submitting a 'full project' application until I felt I had a 'finished' product, as recommended in the documentation. To now hear that the backlog is in the order of a 5 weeks as opposed to 5 days is extremely frustrating, and a very serious de-motivator.
At the end of the day, if the sandbox provided for packaging and direct download capabilities, I'd have no problem with this wait ... but for my specific situation, another 5 weeks means that my 'league management' tool doesn't even get looked at until June; and given that we're talking a large package (12 sub-modules, some exceeding 10k loc), I know the review process isn't going to be quick. As a result, the module remains unavailable for the start of the summer sports season; which renders it more or less redundant until next spring ... at which point D6 itself starts to become more or less redundant; and I miss out on a year of feedback that could go into improving a D7 version. I don't write this to whine, complain, or guilt someone into providing a review ... rather, my intent is to provide some insight into how seriously the current code review backlog affects my motivation as a potential future contributor.
Some have suggested that a 'pay it back' solution would help the code-review process ... and to some extent, it would. However, the code review process recommends sticking with a code review from start to finish (for valid reasons), and as a contributor, I hesitate to take on this responsibility.
Why? Well, as a first-time contributor, I don't know what I don't know. I could easily provide some assistance evaluating formatting, syntax, and running things through Coder; but until I've received validation that my own code is secure and follows best practices, I'm not prepared to comment on these other aspects of someone else's code ... maybe it's personal pride, but if I set out to suggest how to improve someone's module, I want to first confirm that my own understanding is solid. And perhaps it's this same pride that prevents me from stepping up to do some partial reviews now ... the only thing more demotivating than a 5 week wait for feedback would be for someone to post and tell me to run through Coder, and then a 5 week wait for someone more knowledgeable to come along and provide additional feedback once that was done.
In the end, I've been on the Drupal sidelines for long enough that this delay won't affect my overall opinion of the Drupal platform ... but had I just now stumbled upon Drupal, and had this been a smaller project, any significant delay in the code review process would have me looking elsewhere for a more 'responsive' community. (I don't suggest that the community is NOT responsive ... but if the code review were my first experience with Drupal, I could easily see myself reaching such a conclusion.) With this in mind, I strongly echo the sentiments of MGParisi and others in the Module Approval Process thread ... simplify the process for new contributors (and their users!); don't force them to jump through additional hoops and restrictions.
thanks
Hi @jthorson. Thanks for the in depth write up. It really helps to get the reviewee sides of the story.
I'll try to get to your app tomorrow, as we are having a Code Review Sprint in Portland tomorrow. http://groups.drupal.org/node/144359 If you are online during that time, we could maybe do it via IRC?
--
zzolo
I saw the Portland review
I saw the Portland review sprint post earlier today, and was about to second the request for a remote channel ... but then realized that tommorrow is also the inaugural meeting of our local Drupal User's Group. Depending on how long our meeting runs, I may be on IRC later on in the evening; but if it's wildly successful, I won't be around on IRC until Friday.
Btw ... sorry if I spammed anyone with notification of my post edits ... didn't realize that each one was triggering an email until I opened my own inbox. Ooops!
How it can feel to be a reviewed
I just wanted to post my story to provide some personal feedback on what it is like to be the reviewee.
Before attempting to apply for a CVS account I had posted some decently complicated patches to a couple of modules and gotten a good response. I had just been to Drupalcon, and I was fired up about Drupal and ready to get my own code out there. This was probably some time in 2008.
I applied for CVS access, my code got a positive response in terms of quality and applying standards, but I ultimately had my application rejected because it was relatively easy to recreate what I was doing with cck and views rather than a custom module. At the time this made me really frustrated, and it was quite a while before I regained that 'ready to contribute' spirit.
A couple years later I got a contracting job that involved customizations to a contrib module and got brought on as a co-maintainer with full CVS access with little more than a +1 from the current maintainer. I am glad to see that Git has closed this loophole, but the combination of the two experiences left me feeling the whole process was really arbitrary. In the intervening years I didn't really end up doing much contribution besides an odd patch or comment here or there.
Now that I am on the other side of the wall, I have watched some really good developer friends of mine get extremely frustrated with the process and have even seen a couple give up and keep all their contributions to themselves. I've attempted to help with project reviews, but even from the reviewer side the whole process is so filled with emotion and opinion that I realized I wasn't really helping that much (I felt more like a troll than a reviewer) and gave up.
I love Drupal and want to see a lot more good people involved with it. For me it has been a huge motivating factor to have real users using your code on production sites. I worry that there are hundreds of potential great contributors that are being scared off and or burnt out by this process outside of the couple that I know personally.
As a side note I am SUPER excited to see the progress over at http://groups.drupal.org/node/180444. It is way easier to get feedback from a bot than a person, especially if its not face to face.
Thanks for sharing your
Thanks for sharing your perspective and anecdotes - they are very helpful.
It's interesting to note that your review, and this in particular, wouldn't be helped by any of the automation proposed now.
I agree it's hard to maintain an unbiased review process that is constructive rather than feeling trollish. Definitely automating some steps will help us.
knaddison blog | Morris Animal Foundation
Discouraging criterion
"it was relatively easy to recreate what I was doing with cck and views"
Indeed not. What would help that in particular would be: Getting rid of the criterion.
As has been discussed elsewhere, "your code was fine but your feature is redundant" isn't a matter of code review, it's an editorial matter.
It's my opinion that, as such, this isn't a criterion which should bar approval. I grant that for a long time there has been a community value to "avoid duplication", but with regard to project applications, it's ruinous for getting new developers engaged, and it generally quadruples the communication cycles in a review.
Contributions which duplicate functionality haven't harmed other popular open-source communities. A kind word on the part of application reviewers and/or approvers is suitable, in my opinion. Not a project rejection.
It's possible to eliminate this as a blocking criterion while preserving it as a community value. Particularly if ratings and reviews winds up getting implemented - then, the entire community (including non-developers) would have input, regarding choosing among overlapping contributions.
The main thing the
The main thing the duplication check helps with is keeping it easy to find good modules. "Difficult to finding modules" has been in the top 3 complaints about Drupal.org since at least 2007. So until there are better tools for finding good modules I'm not willing to completely give up on it.
I will say that I personally only believe we should ask someone to document their duplication. As long as they do that then their project page is a beacon of hope in the fight to find the right module and that's good enough for me.
So, if you want to drop that you should work on the tools for it. http://drupal.org/node/1301634 is an issue for it.
knaddison blog | Morris Animal Foundation
blog post about getting reviewed
Thanks Paul!
http://www.paulrowell.com/my-thoughts/things-ive-learnt-drupal-project-i...