Really, this is just chaff:

http://drupal.org/user/391740/track

They should be dumped - if only because they are not properly using the CVS/Project repository - but mostly because they have no real merit IMO.
Anyone who knew how to use Drupal would use that framework to create one theme with configurable options to give the required variations. Pressing buttons on a GUI app (it's a good app) is no good.

Comments

gerhard killesreiter’s picture

Urgh, indeed, somebody should talk to the author.

dave reid’s picture

Another reason that I'm all for http://drupal.org/node/484034

WorldFallz’s picture

And more crap:

http://drupal.org/node/522282
http://drupal.org/node/522270

These are book pages (which I've already unpublished). And 27 junk themes which I'm in the process of unpublishing.

I'm happy to contact the user-- but what should I say? Is there any official policy about mass produced themes I can point them to? Some how I don't think my gut answer, "Come on now-- who do you think you are you kidding with this crap?" is appropriate, lol.

dman’s picture

Without a pre-existing policy, it's probably not necessary to be too hard on them.
Looks like they put a lot of effort into uploading them (a few hours at least) without anything to really gain :-/
It's not like it's spam, or even self-promotion.
It's just odd really. Assuming good faith, maybe they thought they were actually being helpful??!

It's not that any individual theme was terrible, it's just that en mass they were pretty pointless noise.
Now, it may be that there is a place and a market for cookie-cutter variations like that ... it's just that we feel that Drupal.org is not that place.
MAYBE certain of those themes may have even been what someone else would be looking for one day. Are we reaching a point where it's no good to have too many Drupal themes? I'm conflicted.

Hm.

WorldFallz’s picture

3 things pushed me into the spammer camp:

The first was ok-- 5, maybe even 10 cookie cutter themes, might be harmless overload. But 27?

Second, the two spam handbook pages.

And third, there were no proper releases-- no commits to cvs. The project pages were merely pointers to another website where the themes were to be downloaded. I know I've seen other themes unpublished for that reason alone.

Nope-- I don't think this was just misguided enthusiasm.

dave reid’s picture

I agree with WorldFallz. 27 themes + no releases + offsite links = spam

dman’s picture

Totally agreed on point 1 that improper use of the repository is reason to unpublish.

But what's all this lot? http://drupal.org/user/391740/track/code
?? Perplexing.

And the sheer flood is certainly enough to put the brakes on today.
I'm just considering - in the long view - What is the difference between 27 "adequate" themes contributed individually over 27 weeks, and the same things uploaded over one day?
Duplication in modules we hate, but near-duplication in themes?

michelle’s picture

I would be +1 of a policy of not allowing generated themes in the repository. Possibly make exceptions for ones that are significantly modified, but then we get into a "who judges" situation.

Michelle

WorldFallz’s picture

I should have made clear I didn't check ALL the themes for cvs commits-- I would say I checked about 10. I didn't even think of the code tracker-- big 'duh' on my part there.

Also worth noting is the fact that the offsite direct download link is the first sentence on the project page-- which iirc I've also seen previously sited as a "violation" though I can't find the link atm.

What is the difference between 27 "adequate" themes contributed individually over 27 weeks, and the same things uploaded over one day?

That's a very good question that I don't have an answer to. Also a factor is the single source and naming convention. When browsing, someone will encounter roughly 5 pages of these themes in a row whereas if they came from different sources and/or were named differently they wouldn't. That's also a consideration.

And what about support? Is there any chance at all that the issue queue of these 27 themes will even be tangentially attended to?

imo this sets a really bad precedent-- do we really want to become a distribution hub for artiseer drupal themes? If we let one person do it, then anyone can. We could conceivably overwhelm our infrastructure with people turning out hundreds of artiseer themes and spamming them to d.o.

This is one of those occasions where I say "I know it when I see it" -- imo this is not acceptable. I just don't know how to quantify it for an official policy.

dman’s picture

I went through the same process, looked at a few, saw no CVS release and thought WTF?
And the offsite homepage is an undesirable start too. And yes, the naming scheme and total lack of description.
Yes, I can't see how those could be 'supported' and that's a problem.
I raised attention to this in the first place because I too "know it when I see it" ... although in this case I can't say what "it" is.

I'm just wondering about guidelines we can use to handle this development.

I would be +1 of a policy of not allowing generated themes in the repository.

Artisteer themes in themselves are not bad, but there is something clunky about pre-generating a bunch and republishing them. I'm thinking as long as the themes themselves are stable, the fact that they are auto-generated shouldn't neccessarily count against them - objectively. There are worse hand-made themes existing in the repo. Artisteer result are (AFAIK) technically pretty OK.

Although I feel icky about them in some ways, if the results are good enough, then logically a themes provenance shouldn't be held against it. Criticize them on individual merit, but not on the brand of editor the 'creator' used to make them.

Basically, the problem is d.o infrastructure is not set up (nor should it be) to handle this type of upload. And opening up the marketplace to these things is sure to have a bad effect on the community.

The fact that it's unsuitable for d.o doesn't make the collection of themes themselves bad though. That's what I'm saying

michelle’s picture

Artiseer themes themselves aren't bad. If I had ended up doing freelancing for "mom an pop" businesses like I originally planned, I would have bought a license in a heartbeat and been using it for them. The problem, as I see it, is that someone who just pushes some buttons and generates a theme is unlikely to do any sort of long term support of that theme. While one could argue that there are plenty of unsupported projects there already, I don't think it's something we want to encourage. I guess I take back what I said about even modified ones... If someone starts with a generated theme but puts in the time to really make it unique and is willing to be a long term maintainer, that's fine. Otherwise, there are plenty of other theme sites where you can dump a theme you just want to share and not support. I think the drupal.org repoistory should be reserved for themes with ongoing development and support as much as we possibly can.

Michelle

WorldFallz’s picture

Agreed-- I'm not passing any judgement on the themes themselves. I've played around with artiseer itself and it definitely has a place.

But, what the artiseer product, and others that will inevitably follow, has enabled is clickable theming-- which opens up drupal theming to the masses. A good thing in itself. However, imo the question then becomes, do we want d.o to become a repository for mass produced themes that take little or no effort on the part of the creator to create. I would think the answer is no, but that's me.

dave reid’s picture

If the theme creator doesn't understand how theming works in Drupal and just uses a p-n-click program, they are not going to be able to fully support the theme(s). +1 to not allowing these kinds of themes to be hosted on d.org.

WorldFallz’s picture

dave reid’s picture

Unpublished http://drupal.org/project/idt012 which had links to yet another 7 yet-to-be-created sub themes. The poster has finally take notice that his projects have been unpublished (#526564: "My projects" list is empty though projects exist) and I directed him to this issue. I also find it *interesting* that his user pages says:

IDThemes is an implementation of innovative methods in the development of qualitative themes and templates for Drupal content management system.

Innovative methods = using artiseer to do all the hard work and waste all of our time.

algalochkin’s picture

Excellently!

Still it is possible to forbid themes which are created with use Photoshop, Dreamweaver or still any tools.
By the way, for creation of sites different themes, including such which personally do not approach you, are necessary to users.
I suggest to close on d.o sections "modules" and "themes". To leave only "CORE".

Thanks!

dave reid’s picture

Policy discussion can followup in http://groups.drupal.org/node/24465

WorldFallz’s picture

Don't be disingenuous-- there's a difference between creating themes with photoshop and using artiseer, claiming it's "an implementation of innovative methods in the development of qualitative themes and templates for Drupal content management system", and pushing 27 themes you can't possibly support to drupal.org in a single day-- and you know it.

Thanks for the post-- your attitude has removed any lingering doubt I may have had that you were merely "misguided".

avpaderno’s picture

I suggest to close on d.o sections "modules" and "themes".

If you have been caught doing something that the webmasters think it should not allowed doesn't mean other people are not able to follow the rules.
I think that is different to use Photoshop to create the theme images than to use a program that completely generates all the code (HTML, CSS, JavaScript); using such program, you could create 1000 of themes that would differ from each other for details.

algalochkin’s picture

@WorldFallz
... can't possibly support ...

It is possible to support more than 27 themes

algalochkin’s picture

@KiamLaLuno
... you could create 1000 of themes ...

Probably you had in view of, that 1000 more people will use Drupal. Tastes and preferences at all people the different.

... that would differ from each other for details.

Any themes differ from each other details which consist of graphic elements and colours.

merlinofchaos’s picture

It is absolutely possible to support 27 themes.

However, you don't start off supporting 27 themes. You start off supporting a couple of really good themes so you understand the kinds of issues you will face. Then you add to that. And if you're creating themes with Artisteer you *are* going to run into some issues. I ran into half a dozen just playing with it for a few hours. When you get a thousand different people using it in a thousand different configurations...

WorldFallz’s picture

Merlin captured what I was trying to say but obviously failed to make clear. It's 27 themes released all at once that's going to be nigh impossible to support.

Besides, as Michelle already pointed out, there are themes that are essentially unsupported-- this was only one of my points.

The main point is still, do we want d.o to become the dumping ground for artiseer or other point-and-click themes-- imo we don't. If we do, then fine, lets put up a policy stating what the requirements are for creating themes at d.o and I'll be happy to abide by it.

And you'll probably want to warn the infrastructure team as well-- I'm sure they'll want to prepare for the flood of themes that will likely result.

WorldFallz’s picture

We'll also have to straighten out the naming policy over at dave's groups.drupal.org thread because I'm sure just about all of them will want to be named "!!!!00001111aaaa X Theme"

algalochkin’s picture

I have a steady opinion, that only system administrators with natural for sysadmin's desire "all it here have gathered to forbid".

Somebody from you has looked on IDThemes Project on SF? One of the project purposes is creation of universal themes which will facilitate to D-users transition from D5 -> D6 -> D7. In D7 as you know there are considerable changes at work to themes. If the user passes from D5 to D6 or D7 (that is to more advanced version D) appearance of its site will not be broken. How you think, there is in it an advantage for users?

As to the name for themes in your recommendation there is no "life truth". It to name similar to "good advice" to developers "Lotus 1-2-3" is simple "lotus" and "Audi Q5" is simple "audi" and "Porsche 911" is simple "porsche". If you have created the one and only theme, you can name original it but if at you them will be much you will not leave from sequence of figures or to anybody except you not clear letters in the name.

chx’s picture

I disagree with the existence of these themes. If there is a bug, if there is a problem are you going to regenerate all? If you drift from the project which eventually happens, it happens to everyone, who will do for all of them? My vote is on removal of them.

WorldFallz’s picture

Regarding #25--

What are you talking about? What does any of that have to do with the fact that your first "contribution" to drupal was to spam 27 nearly identical artiseer themes to drupal.org in a few hours? To pretend you don't understand why that could possibly be interpreted as spam is disingenuous at best. The more foo you post about how great what you did was the more like a spammer you appear.

I really dread throwing the baby out with the bathwater, but I'm starting to think the only solution to this type of nonsense is going to be a theme posting limit. Modules take actual work and effort to produce so I doubt you'll ever see 27 of them posted to d.o in a single day-- point-and-click themes are too easy to create and therefore spam.

avpaderno’s picture

If the user passes from D5 to D6 or D7 (that is to more advanced version D) appearance of its site will not be broken.

That can be said for the other Drupal themes too. The IDThemes themes for Drupal don't adopt any particular technique that make them less prone to that kind of problems.

avpaderno’s picture

Category: support » task

There are still the images that should be deleted. May I do that?

EDIT: Actually, they should be unpublished, as the themes.

avpaderno’s picture

Component: Project ownership » Content moderation
Status: Active » Fixed

Also the images have been unpublished.
I think the task is terminated, now.

danielhonrade’s picture

I like artisteer, totally for newbies, I don't see the point of blocking or deleting such themes in the repo. We can learn from them as much as they did learn from you. Have you closed your minds to such different approach of auto generation of themes.

I only see the great effect of this type to companies who are selling individual themes, they might have to change their approach also, because a lot of buyers are not really into drupal configuration, everything now is being auto generated. Just take a look at Acquia, they have installers of drupal for windows and mac, simply made easy. Members are also creating profile installers for what? The principle is auto generation is not bad. You just have to classify them. Up to now there's no theme classifications in Drupal. Are you waiting for sponsors for it or your sponsors are not willing to have you do it. Please see joomla or dotnetnuke community websites. You can just imagine how backward drupal is in terms of a lot of things.

I hope you can open you minds on this and not just kick me out because I made these comments.

gerhard killesreiter’s picture

I don't know about others, but I see the main point about the themes that are available for download in their instructional value. If I set up a website for a client, the theme they'll use is custom made anyway (using something like zen as a start of course). If I set up a site for myself, I can just use Garland and adjust the colours...

So, in my opinion, we sure do not need themes that are auto-generated. What might be interesting to have would be a theme generator instead. To some degree, you could call the colourpicker a theme generator. So instead of wasting our diskspace with a huge number of similar themes, how about a proper one with colour-picker integration?

michelle’s picture

@Gerhard: Actually, many people who have hobby sites or poor clients use downloaded themes either as is or with minor modifications. It's important to have a good selection of quality themes because many people will judge Drupal based on that.

But overwhelming the repro with a bunch of cookie cutter generated themes does not help that cause. If someone takes an Artisteer theme and takes the time to clean up the code it generates and customize it and make it look distinct, that's fine as far as I'm concerned. But spending 5 minutes pushing some buttons and then uploading the result to drupal.org is not. A bored person with CVS access could generate thousands of them and overwhelm all the themes that folks have spent many hours crafting by hand. We need to draw the line somewhere.

Michelle

avpaderno’s picture

I agree with Michelle. There should be some work more than to click here and there, and blindly accept what the application gives back.

It is also true for who creates a sub-theme starting from Zen (just to make an example), but don't clean up the code (and leave there commented functions that don't even have the correct name).

WorldFallz’s picture

A bored person with CVS access could generate thousands of them and overwhelm all the themes that folks have spent many hours crafting by hand. We need to draw the line somewhere.

I wish it were only bored people we had to concern ourselves with. Unfortunately, with all the additional attention drupal has garnered lately, what will happen (and we all know it will) is unscrupulous people will use artiseer (or any other similar product) to overwhelm the themes section with their themes in order to drive traffic to their site. Instead of people gaming the alpha ordering with a theme or two they will simply seek create enough themes so that theirs (containing a 'convenient' link to their site) will be the most commonly viewed.

With all the antics I've seen lately trying to ninja spam d.o this is only a matter of time. In fact, an argument could be made that that's exactly what happened here.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.