Posted by klausi on October 29, 2011 at 9:15am
First, let me say that Features is great and that I think it is totally ok to have pure Features projects on drupal.org that somebody just clicked together. Yay for sharing!
But: do we approve project applications that have no self-written code at all? How can we make sure that the person has understood the security principles or the coding standards? Or do we trust those people that they will inform themselves before they later promote their first custom code module to a full project?
Outcome: Feature projects are approved on a per-project basis. A Code Review Administrator will promote the project, the user does not get the git vetted user role (unless enough addtional self-written code is provided with the feature).
Comments
Separate access?
Stepping back for a moment, I gained full project access three weeks ago with a pretty small module, and i find it somewhat illogical than now I can publish a theme, too.
Although there are security aspects to theming, and coding standards of course apply, there are issues specific or at least more important to theming, such as cross-browser compatibility, completeness and accessibility. Current project review process, although vastly improved, concentrates on module-specific issues and by no means guarantees the applicant can create a working theme, much less a decent one. I, for one, cannot.
Therefore I think theme project access should be separate from module project access, with its own vetting process. It could also improve average quality of themes published on d.o, which is a long-standing pain. I do however suspect that finding reviewers for themes might be even more difficult than finding reviewers for modules.
Now, en revenant à nos moutons, stuff 'that somebody just clicked together' falls into third broad category (I'd call it 'Exportables'). If it had an own project category with separate access and separate review process, it could well serve as an 'entry-level involvement' as the access would be [relatively] easy to gain – just pack and document it properly.
Good question
I raised this question a while ago here and we didn't really resolve it:
http://groups.drupal.org/node/142484#comment-508684
Most people at the time seemed to feel that Features exports, while okay for Drupal.org, are not something we can effectively review here. But we didn't reach a comfortable consensus. I'm personally on the fence, and would just like a clear guidelines to apply on this.
Drave Robber, I think changing the full project access on Drupal.org to be separate for different project types may be a good long-term idea, but is a far more substantial change than we can take on in the near future. The wider community needs to talk about something like that, not just our small group. And our small group is still struggling to deal with reviews on one project per contributor, so we're not quite ready to talk seriously about reviewing more than that.
Per project rather than per person?
Are we still considering a change to "per project" approval and not granting "per developer" project-promotion to new contributors?
If so, then, to me, that makes treating a Features contribution the same as other projects... just fine.
Some day
I think we have something at least approaching consensus that per-project reviews of some sort would be good. But we aren't likely to have the resources to do that for several months, at least. Until then, we should try to answer this question as it relates to the current process.
Per-project reviews
I sure hope per-project review never happens unless it's an automated review that involves no human input. I for one would never want to go through anything like the initial process more than once.
As far as Features modules it seems an inadequate offering to gain the ability to release other full projects.
Putting themes as a separate category requiring going through a separate process seems like unnecessary complications IMHO.
The idea is that once you've
The idea is that once you've gone through the process once, you should be well versed on how to get prepare a project for submission the second time. After all, that's what we expect people to be doing right now for full projects after they have done the review!! There are steps to take out most of the annoying parts of project review, such as telling people to run their module through Coder, and automated XSS checks. This will release some of the pressure of the reviewers, but the initial idea still remains; projects are meant to be as good as faultless when they come to be on the review issue queue.
So far, I've had 1 project I've reviewed that was nearly ready for RTBC when submitted, and that's what they're all meant to be like.
The review process is not meant to be this arduous process meant to **** block new submissions; it's meant to be a final check before a project/developer gets the nod having already demonstrated that they are up to the task.
WRT to features modules being per-project acceptance without 'create full project' permission being granted; That sounds like a great idea. The author has clicked a few buttons from known modules and clicked export. There is no indication of how effective that person would be at creating future normal full projects.
Might I also expand that to incredibly simple modules that do not give an adequate indication of the developers skills? eg. a module with a single or even 3 functions in it. I have seen one which was incredibly simple and had been cleaned up to the point of release, but there were also a number more modules in the sandbox, creating during the review process, that are nowhere near ready and have not learned any of the lessons from getting the first project ready for release.
Themes and module should also be split out, but I might be a bit of ass to say that if you get module creation permission, you might as well get theme too, but not the other way around. Creating a theme and then suddenly being able to create any modules seems extreme considering some of the most horrible things I have seen in themes (hard coded menus, hard coded views!!!, manipulating data in theme layer). Simply creating themes does not give you a good enough idea to know how the rest of Drupal is functioning. IME.
Add a new status to the Project Review queue - "Ready to be Promoted" - which when the author replies that they would like their project to be promoted now, gets the project promoted, but does not grant 'git vetted status'.
This discussion will be
This discussion will be affecting one of my project applications amongst others. So, here is what I think about the issue:
I am a non-coder. For the last 5 years, I have been actively involved with Drupal. I have contributed to Drupal Localisation and marketing efforts in India. Within those 5 years, I spent 3 years with an open source company that deployed Drupal amongst a range of other open source projects. And during that period I have worked with various communities - students, developers, themers, administrators etc who have been using Drupal for various effects. I also regularly mentor students on getting involved with open source projects. Why is this background relevant? Simply, because it exhibits that as a member of the community I have always wanted to contribute in every possible way back to Drupal and that I will totally work with the community consensus.
The challenge I face with contributing modules is that I dont code. And I have limited understanding of programming paradigms and concepts. So, no I dont understand the Drupal Security Principles and the Coding Standards. Not right now. But I will spend more time understanding it and will be asking friends to help me understand it as well. Though I doubt about its effectiveness, given I dont code.
Yet, when I build a functionality on a site I administer and export it through the Features module, primarily, to help with deployment of the functionality - it is good to use. How can that Feature have a security loophole, when:
a) it is made out of objects being exposed within drupal (nodes, taxonomy, fields, views, rules, etc). These elements and the Feature only does what Drupal allows you to do. Custom Modules might have insecurity since they are being written from scratch, but the feature was made out of Drupal. Its like using Drupal to extend Drupal.
b) for a module to be accepted, it has to pass the review process. So will the features-exported module have to pass the review as well.
c) if i write a custom module, it will still have to pass the review process, it will not be approved without it. Any security or standards concern will be taken care of during the process of review itself. And during that I will face the mistakes I made in the module, understand how it was lacking and evolve into a more drupal-compliant developer.
I am not able to understand how approving a Features exported module will create loopholes in the review process. While allowing it will open the way forward for people like me (non-coders) to be able to make another form of contribution.
The only question I am left with on this issue is:
Should Features exported modules not be approved because the development effort involved in developing them is trivial compared to the effort involved in writing custom modules?
Is it demeaning in any way to the developers out there contributing precious time writing and maintaining modules?
kinshuksunil, The reason this
kinshuksunil,
The reason this is raised as a concern, is that once an applicant has passed through the review process with their first project, they are granted access to create any future contrib projects (of any type), without review. That applicant can create unlimited numbers of future modules and projects without restriction.
This illustrates one of the flaws in the current process, which is that we do not have seperate approvals for the 'applicant' and their 'code'. If this seperation was in place, it would be trivial to approve a features module and still ask that the applicant bring future modules through the review process ... unfortunately, our current process does not support this case; and features/installation profiles do not fit well into the current process.
So the question we are struggling with is not "should a Features exported module not be approved" ... it's "How do we approve a Features exported module under the current system". One option that springs to mind is having an existing maintainer with "create full projects" access create the project for you, make you a co-maintainer, and then remove themself from the project ... but this is obviously not an ideal long-term solution.
In the meantime, I believe that the 'Modules versus Themes versus Features versus Installation Profiles' question is a debate which will need to be discussed with the greater community ... personally, I'd like to see a different content type for each 'project type', as one possible solution.
Proposal: per-project reviews of Features exports
I was just trying to think through how it might work to create projects for Features export contributors without granting full access on all future project when I saw jthorson's message. I think his proposed solution of someone who already has access creating the full project is good. It would limit full project access to contributors whose code we can actually review, but would not restrict the ability to share useful Features exports with the wider community.
It looks like we wouldn't even need to do this in separate projects. I seem to have access to promote kinshuksunil's project to a full project without even making myself a maintainer. I'm not sure how many people have this access, but my guess is it's tied to the access to grant full project access, so everyone currently moving applications from RTBC to fixed could do it. This may not be a long-term solution, but I think enough of us have this access and we get few enough Features export applications that this could be a workable medium-term solution.
So here's a more formal proposal:
We treat Features export applications as per-project approval rather than per-applicant approval. They go through the normal review process, which should be much quicker since Features creates clean code automatically. Once they're RTBC, instead of granting full project access, we just promote the specific sandbox to a full project. To more easily distinguish Features exports, we add a new category.
Thoughts?
Excellent idea, that should
Excellent idea, that should do it for now. You mean we should create a new component "Features export" in the project applications issue queue? Then we would have module, theme, Features export and other.
I agree. A separate Feature
I agree. A separate Feature category should be created. A few Features include custom coding and require enough work to be Projects (http://drupal.org/project/views_gallery for example), but the majority should be separate. Projects are building material, Features are pre-fab constructions; they should be distinct.
I agree with this comment as
I agree with this comment as well.
Let's wait a few more days to allow more folks to chime in before we agree the full idea is a confirmed part of our process. However, I think it's reasonable to add "feature" as a category sooner than that.
knaddison blog | Morris Animal Foundation
Added "feature" as a
Added "feature" as a component in the issue queue settings.
Any registered user should be able to create a Feature
Any registered user should be able to create a Feature. The account confirmation, git upload, and an automated review would be sufficient as the entire review process. The important difference is Features should have a separate URL, such as: http://drupal.org/feature/feature_name. Perhaps just http://drupal.org/feature/[nid] since I expect there would be competing/differing implementations, in which case votingapi would be beneficial.
D.O hosted Features would provide prebuilt functionality helpful for newer Drupal users, and small website builds. I generally use Features to transfer Views/Panels/Content Types between dev and live site installs, so most Features I create are too specific for general use. There are a few Features I'd build today for small sites, if they were separate from Projects; Company News(with a Recent News Block), and About - Staff Profiles instantly come to mind.
Yes, I know, this is a lot of d.o. infrastructure work.
strange side-effects
There can be strange side-effects with features, since you can export permissions as well, so if you create a feature that assigns liberal permission, the person using your feature will end up with the same liberal permissions, and if not paying attention adds up with visitors being able to do more then expected.
Yes, it is. But the approval
True. But the approval process is not removed at all, and features projects must be revised.
The issue is that being able of doing a great feature doesn't mean that the contributor can make a great module following d.o guidelines.
I'm +1 to the features approval process without promoting to vetted git user permission.
--
Christian López Espínola (@penyaskito)
Also in favor for a separate
Also in favor for a separate 'feature' category
Feature Server on D.O
Can't we have a feature server on D.O?
Maybe, but not soon
That's another potential solution that would require a much wider discussion outside this group, and would likely take a long time to implement. If you're interested in pursuing that, http://drupal.org/community-initiatives/drupalorg is probably the best place to start.
Meanwhile, we still need to work out how we want to deal with this in the short term, given our current tools.