Should features be allowed as projects on drupal.org?

Features != modules. Allowing them as modules will lead to confusion in namesapce and instructions. If we host them then I think they should be their 'own' type. Existing abuse of the system should not be a legitiamte example of 'allowed' use.

Drupal is confusing enough without intermixing 'modules' and 'features' in one download namespace of just 'modules'. If they have a seperate area then we can set seperate expectations for them.

It's code, it's Drupal, so yes, we host it.

I don't think it is initially neccessary to create another variety of download, let them create them as modules and and tag them as features. Later we can move stuff around if we should cross a critical threshold.

As for a CVS application, CVS applications review, what to expect reports that:

Your module or theme should demonstrate ingenuity and originality by the author.

I am not in favor of something that is automatically generated from software, and then put back on CVS. I think it's rather preferable to join forces with other maintainers, rather than creating a feature that takes code from existing modules.

I don't think it's necessary to create a new type of download either. All features are modules. Not all modules are features. To me, it's no different than saying extensions to views are modules. Or new cck extensions are modules.

@kiamlaluno: A complete feature will usually have a fair amount of custom code that goes with the automatically generated part. Usually, the parts that are autogenerated are defining default views, content types, cck fields, etc. Sometimes, it is not feasible to add things to modules you depend on (for example: software_projects integrates project module with Open Atrium. It would not be a good idea to add atrium specific code to project module). Also, a feature should not be taking code from existing modules. It should simply use the available hooks. If it's duplicating code without a good reason, then there's some issues with that. I don't think I've seen any features that do this, though.

My concern is that if we force features away from d.o, we'll end up with a bunch of little sub-communities around distributed feature servers. I think that it would be a better idea to try to keep all drupal-related things in a central location (d.o).

My vote: leave them as modules.

A complete feature will usually have a fair amount of custom code that goes with the automatically generated part.

Fair amount could mean that most of the code comes from the automatically generated part.

I think that the question that should be replied is: what does the code generator do that cannot be done from a user? If the difference is that a user doesn't need to know the details of the API to write a good module, then I don't think that is a difference that would raise the quality of the code.
Is the difference the speed at which a module is created? So far, none of the most important Drupal modules have been created in a night; Views has not been created in a week, and that is true for Project, CCK, and many other projects that are now used from many Drupal sites. Do we need to speed up the development of modules? Then why instead of developing a module using generated code doesn't a user help joining an existing project? If the purpose of using a code generator is to avoid to write code the user is not able to write, then joining an existing module does the opportunity to contribute without the need to be able to write a module from scratch.

I am against generated code because it is easier to generate modules that differ from each other for little details; in particular, I am worried that accepting features in a CVS application would have the effect to make more slower the process of approval of a CVS account.
At the end, to avoid to force features away from d.o, we would push away all the possible contributors, including who would create a normal module / theme.

A feature is just an extension of the Features Module. They install as module and utilize hooks to implement several customizations through the drupal system.

Even the most simple case of a "Feature" sets up content types, import / sets up views, import / sets up permissions, set system variables, integrate to other modules (open atrium / spaces / features / CCK), have custom .css, have custom menu and icons, etc... These "Features" do produce new / unique functions that are instantly usable by the Drupal community.

These features offer significant value to Drupal and need a place to be distributed.

As far as I'm concerned, the decision whether to host "Features" inside /projects or to create a new content type is irrelevant. I'm mostly concerned that CVS application are denied solely based on the fact that the module(s) is a "Feature".

Greg

Re: My CVS application http://drupal.org/node/711812

I think that Features should be distributed on drupal.org but in a separate area from modules.

Considerable configuration work goes into creating the views, content types, taxonomy, etc. that are behind a useful feature. The code is auto-generated (at least mostly?) from the configuration, but they do require significant work to create, and could save someone a lot of time when creating a new web site (and make it less necessary for them to have the configuration knowledge to have set the site up from scratch).

Ideally, they could eventually be packaged up with all of their module dependencies, the way that install profiles are|will be.

I do think that they should be kept separate from modules, because of (a) how they're generated (b) how they're used (c) how they could/should be packaged.

Having created a large amount of features for clients, I can tell you that any good feature requires a good amount of custom code. No one is going to use a feature that just adds view/ctyps. It has to actually solve a problem or produce a product.

I am for features being included. Producing a working solution to a problem is much more valuable to a new user then a walk through or how to.

Features become very useful with packaged with drush make. All dependent modules downloaded, installed and configured to a generic settings.

I've never seen a useful feature created in a day. The crappy ones will be not used and weeded out, or even better, improved.

@tomhung: Your CVS application doesn't follow the requirements, which clearly states that proposed projects should not duplicate existing works; in the project you proposed there are many (if not all) files that are taken from http://drupal.org/project/links.

If this is the case for almost all the other projects classified as features, then I think it's not what we want to find in Drupal.org CVS.

What said from jhodgdon makes sense to me, but still it makes me wonder what the difference is between an installation profile, and a feature. We already have installation profiles, and having also features would confuse users. Then, could not an installation profile do what a feature does?

There are other types of 'projects' we might want to consider here as well. Fusion, for example, has the concept of 'design packs' which are essentially color css and image files. When the bugs around sub-sub-theming are removed it's entirely possible that there will be a collection of "Themes" that are variants in color and background images of an existing theme. Would we want these listed as themes or a separate sort of entry.

Another angle for consideration is as we try to reduce duplication and get modules to work together does the inclusion of features in the module space mean more difficulty if someone wishes to implement the same functionality in a standalone module. Take for example a collection of user-management functionality that could be a stand-alone module. However upon coming to Drupal.org one finds a module with a dependency on the features module.

In looking at a couple of 'features' modules it seems there is very little, if any, logic in them:

http://drupalcode.org/viewvc/drupal/contributions/modules/atrium_invoices/
http://drupalcode.org/viewvc/drupal/contributions/modules/software_proje...

Maybe these are atypical but it would be useful to have links here for this discussion if so.

Unlike a helper module like modules that add functionality to views or some other module it seems features are more akin to a packaging of patterns data, or a collection of exported views. Not that these are necessarily bad things to have, and even to have on Drupal.org but the complexity for people trying to get started is multiplied. Do I download the hypothetical oa_reports module (a collection of exported views) or the hypothetical atrium_reports (a feature module of exported views)?

It would be nice to have a central place to collect these collections of configuration information. Whether that deserves equal billing with full-fledged modules is less clear to me.

A couple of unrelated nice-to-have items here would be consistency in namespace. i.e. if a features module is being built then using features_invoice might be a good convention. And as always it would be great if module pages clearly stated the dependencies on them.

I was asked to chime in here.

I really don't get the resistance to hosting 'auto-generated' functional code on Drupal.org. At all. We host install profiles, which are exactly the same thing: bottling up configuration work someone already did into a re-usable chunk to save others lots and lots of time. Seriously, what's with the big resistance to this?

Artisteer themes are totally different ballpark, because the only difference between those are minor stuff like fonts and colours: not fundamental functionality of your site.

I would say just chuck them in with modules, since that's what they are. The fact that they have dependencies makes them absolutely no different than any other module (OG Panels, Advanced Forum, Views Bulk Operations, et al). And making them something separate and somehow "special" just plays into this whole "Feature server" concept, which I remain yet to be convinced is in drupal.org's best interest.

I've already ranted separately about how I feel our CVS requirements are draconian, discourage new contributors, and directly harm the community. But any comments about how Feature modules do or do not fit into our CVS requirements should go over there, not here. In the end, this issue is pretty simple. Quoting Gerhard:

It's code, it's Drupal, so yes, we host it.

It's code, it's Drupal, so yes, we host it.

That is true also for any module that duplicates another existing module. I don't get why for other modules is valid the principle join forces, which is then not valid for features.

There are already install profiles, but when developers creates an installation profile, they don't commit the files coming from the modules the profile require. Why should not the same system be used for features?
Not committing duplicate files solve also a major issue; there is no need to keep synchronized files that are committed in different directories. Why do not we adopt the system that allows to obtain the same result with less effort?

That is true also for any module that duplicates another existing module. I don't get why for other modules is valid the principle "join forces", which is then not valid for features.

But what makes you think people won't "join forces" on feature modules? As pointed out above, they're just regular old modules, just with a crap-load of dependencies. If someone comes up with a really nice event management feature, it certainly doesn't make it any less in the best interest of others to collaborate with that person and make it even more nice. If anything, such colloaboration is easier because even non-developers can get involved: "Hey, I just added a sweet section to do iCal imports of Facebook events with Views and Facebook module. Here's my export. What do you think?"

There are already install profiles, but when developers creates an installation profile, they don't commit the files coming from the modules the profile require. Why should not the same system be used for features?

Hm? Sorry, but I totally don't understand what you're saying here. :( Exactly what duplicate files are you concerned about committing? A feature doesn't include a copy of Views module, just a dependencies line in the .info file; no different than what any other module would do. It includes *exports* of views, but those are all completely unique, based on exactly what configuration options were chosen.

The same system (install profiles) can't be used for features, because install profiles are only for install time. Features are modules, which can be turned on/off at any time (as all modules can).

Not committing duplicate files solve also a major issue; there is no need to keep synchronized files that are committed in different directories. Why do not we adopt the system that allows to obtain the same result with less effort?

And now you really lost me. :( What files in different directories need to be kept synchronized..? What system would we be adopting that would be better than what Features module already does right now, today, and has already been tested by thousands of people all over the world..?

If I export a view and a content type and include those in my module, did I just author a "feature"? I mean, who would write hooks to create content types now that you can just click together your content type and export/import it? Features automates stuff that modules already do to a degree. Its another step on the CCK + Views road. CCK made you (mostly) abandon writing node type hooks. Views made you (mostly) abandon writing SQL queries. Features generalizes this by making you (mostly) abandon writing and maintaining custom code for stuff where you can just configure generic tools to do the job for you. We do not reject modules for using exported views or content types. Why would we reject modules reliant on the Features module?

Exactly what duplicate files are you concerned about committing?

I think I may see the source of some confusion here. This thread seems to have been prompted by a specific CVS application here, cross-linked earlier:

http://drupal.org/node/711812

In that particular feature module, there is an existing module's code (links) duplicated entirely within the submitted feature module. And because this thread came from that thread, I suspect there are different understandings of which statements here apply to features in general (which don't necessarily duplicate other modules) and which statements apply to that particular feature (which does, in fact, duplicate a module).

I'm also not sure why some think there's some kind of dichotomy between features and modules-- to a user, a feature module is just a module. Sometimes they have a lot of dependencies, sometimes not. Sometimes non feature modules have many dependencies. A module is a module-- what difference does it make how it was created? Are module builder modules somehow different also?

Also, I totally don't get the duplication argument. imo if anything, i think features have the potential to reduce duplication. Instead of coding new modules that duplicate this or that module with some minor differences, I think it's more likely people will contribute features that just preconfigure existing mainstream modules. For example, I foresee a lot of custom views/cck configurations like the views_gallery module which has the potential to make totally unnecessary many of the plethora of gallery modules.

As sreynen pointed out, this seems just be a problem of terminology.

In #711812: tomhung [tomhung] the files I see in the file links.tar_.gz are file coming from an existing project, plus four other files (links.feature.inc, links.feature.node.inc, links.feature.views.inc, and links.inc); none of the additional files are a module, nor a file .info.
When I pointed out there were files coming from another project, for three time I have been replied that it was a feature; therefore, I took that what I was considering a feature was not what other users consider a feature. I also considered about reviewing just the additional files, but it doesn't make sense to review parts of a module without the module.

All my comments were referred to the specific CVS application, which I understood it should be the standard CVS application we would get for any features. I apologize for my misunderstanding, and the confusion I created.

If we are talking of accepting a module where some files are generated by feature.module, and the module file is created by the user, I am not against features; the module code should still be something more the just two lines to include the files generated by feature.module, IMO.

Ahhh... Got it, that makes much more sense. Yes, absolutely we don't want 2 copies of links module hanging around. :)

But all the "Feature" part of that module is, is the include files. A .module generated by Feature module is actually blank.

I think there's enough agreement here now to close this issue with a "Yes."

I'm sorry to confuse everyone. The original links.tar.gz upload was a mistake. The correct "Feature" was reposted.

However this issue is not what is being discussed here. The issue is a general case of IF / Where should "Features" be posted on d.o.

Greg

http://drupal.org/node/711812

Features as modules on d.o requires git or whatever.

Anyone can create a new feature that may even have some value for someone else. By pointing and clicking.

But to host this feature module on d.o, we need to grant CVS access to the author, who in turn will be able to create new projects/modules without ever going through at least one code and security review of "own code".

Should the features module even exist? Many in the Drupal community will agree that in many instances it actually breaks the basic concept of keeping data in the database and logic in the codebase. I agree that a view maybe described as logic (sometimes), but since when could content be described as logic? Content belongs in the database. See http://groups.drupal.org/node/24753