Remove design.drupal.org

I'm not really in the brainspace to respond to the overall idea/plan, but I do want to flag that I am *really* concerned about single-source docs for Drupal. I would much rather have things like tutorials be in the main Drupal docs and then "outsourced" to other places that want them too. We don't have the tools to do this right now (but there was lots of exciting convo on this at the Writing Open Source conf I just attended this past weekend), so I understand that is frustrating. I'm also not necessarily opposed to topical areas having their own tuts, but if we do a design subsite with tuts, then we should do the same for other topical areas that would have tutorials, or when do people know where they should be to really find the info they need? I also think that the way D.o handles *all* snippets should be changed into a model that is more useful and easier to slice/dice, so again, I'd rather fix the way we handle that on D.o so that it is a central resource for any snippet needs, rather than outsource one topic to another site.

Now, all that said, if a site comes up that plays with ideas in these areas and can work as a proof of concept with the plan that we will eventually incorporate the best ideas (and content) back into D.o, then I'd be supportive of that.

what I really misses is a space where we can add comments to the different functions etc - so i can see what other drupal themers & developers have done with lets say the l() function.
The ultimate wish would be a comment section on the api - where we besides off adding comments to the function we could tag it so it was possible to diverse comments between developer orientated stuff and frontend stuff.

Great start, Matt. I'm very happy you're taking all of our conversations on a Drupal subdomain to another level.

I think you're right about trying to develop other channels besides CVS for getting input from designers. There are many ways that we've wanted to contribute back to the Drupal community but haven't been able to:

* We have themed installations of sites (like a full corporate site complete with a press room) that we would like to clean up and contribute back to the community -- but they depend on Views, CCK and date modules, making them useless.

* We have our internal updates to the UI of the 960 theme, but can't figure out how to contribute them via CVS.

* We'd like to contribute themed views that work like calendars, but they depend on Views and the Date module.

* We have quite a few outtakes of polished designs that we love that get rejected by clients in the creative process. Many of these are fodder for great themes.

* There's a HUGE need for icon libraries (note the plural) for user interfaces and themes. The current CVS/module-based system doesn't really work for this.

Rather than developing tools, maybe having a person or two in charge of receiving and routing submissions might not be such a bad idea.

@modulist

@mfer, I'm not saying we *have* the things (tuts, etc.) that you want right now. What I'm saying is to build that stuff out here on D.o (or really the future docs.d.o, which I hope will happen this year) and not take them off-site. Any improvements to how we do tuts and snippets here on D.o for designers will benefit *everyone*, not just designers or devs, but also end users and site builders. I'm also not against having a design subsite and all of the things that would provide the design community. I'm just concerned about spreading our *docs* out even more rather than pruning, organizing and single-sourcing here on D.o. And again, we may not be able to change the IA and toolset here on D.o fast enough for your needs, but I'd like a commitment that anything that is worked out offsite will happen with the plan that it will come back to D.o when it is a more suitable home. I'd really love for the design community to be heavily involved in the docs restructuring project, which involves not just the IA, but also the tools and processes to make supporting and using it easier for everyone.

I am starting testing of comments on API in the next few days. All the pieces, including single sign on for *.d.o are coming into place. Thanks for showing a good use for API comments, I do fear it becoming a place to post bugs that no one sees because they aren't issues.

I think all of these components are great, but they should be tackled as separate, doable projects. Many of these can fit into existing or planned places on Drupal.org.

I think we could all do with some context here as to why this is being proposed. Is the idea to have a designer-specific "welcome mat" into the larger Drupal community, or is the idea to give designers a place away from the rabble rousing of the larger, developer-centric community to have more of a "private" place to focus, or..? Basically, under what circumstances did the discussion related to this resource get raised? What are the specific problems we're trying to address, or goals we're trying to achieve?

We obviously want to see more designers in the Drupal community, and we have not so far succeeded in attracting them with the existing tools that we have. So therefore, I'm inclined, at least for now, to listen carefully to what the design community says it needs in order to become a thriving force, and consider their input very seriously, to see if we can come up with something awesome.

I would like to state some initial concerns, though.

1. I see a lot of stuff slated for this site that I also see in the todo list for the larger Drupal.org redesign. For example, ratings/reviews on all projects (not just themes), a showcase section, etc. I know "make drupal.org not suck" is an order of magnitude more effort above simply "make a website with ratings on it" but it worries me that we might see our efforts forked here. Are there ways that frustrations with the existing tools could be channeled in a way that makes them more useful to everyone, including designers?

2. The larger concern I have though is that if all of the designers are off on someothersite.com, and not kicking ass right here on Drupal.org, designers coming into the Drupal community will continue to not see people they can relate to here, and the Drupal project continues to not attract design talent on the scale that it otherwise could. design.drupal.org has the same problem as groups.drupal.org: you don't realize it even exists until you've been "entrenched" in the community for quite some time. We are currently losing designers right out of the gate. We want to be able to snap them up as soon as they load the home page, ideally.

3. I don't know of a single developer who doesn't want the Drupal community to be a richer place, with far more design talent. We want to make smart decisions with our modules' markup and Drupal core to make Drupal easier to approach for designers. The problem is, we are ignorant, so do what we think is best and usually end up fumbling around. We also don't really have experience working with designers, so sometimes make really bad social gaffes like thinking "spec work" is somehow okay.

The way to change this situation is NOT to go off into someotherwebsite.com, but to immerse yourselves in the same tools that developers use: #drupal on IRC, the project issue queues, etc. It's a very developer-centric solution to this problem, to be sure. Yet we've seen the larger development community's "IQ" regarding user experience considerations /dramatically/ increase as a direct result of UX team members reviewing patches and chiming in on issues.

So. With those concerns aside, I would like to hear from people who were at the #d4d conference to provide some background on where we're trying to go. It may indeed be that an off-site site makes the most sense, but let's talk about it. :)

@mfer: Hm. The only thing I can find is this http://drupal.markboultondesign.com/iteration11/index.html but I know there are some more up-to-date mocks around somewhere... maybe one of the infrastructure folks can chime in.

I agree with webchick here on her initial concerns. For Design to be properly supported and showcased as an integral part of the Drupal community, it is important that designers participate in the main HUB of Drupal (drupal.org). Having an offshoot site gives the perception that design is not as important... kinda like "welcome to Drupal but if you are a designer go over to that site over there."

My thoughts are that designers and developers need to play in the same sandbox... and although designers would initially immerse themselves with the current tools (which happen to be developer centric), the toolset would eventually evolve to something more design friendly... only if designers participate.

Making Drupal more design friendly (attracting good designers) starts with "welcoming" talented designers, ...Drupal.org is the welcome page for Drupal.

I agree with webchick's points mainly. A theme upload system should let you upload stuff to drupal.org/project so it can be browsed and downloaded centrally - I proposed the same thing as a summer of code project last year but no-one took it up - see A new theme upload system for Drupal.org. I still think it's needed, but don't see how a separate subdomain would help.

Less positively, I find this comment really weird and it reads like FUD to me:

The current sites like api.d.o, cvs.d.o, and the testing framework are all developer centric.

api.drupal.org mainly exists because you can't run api module on drupal.org easily - apart from possibly having comments on it soon, it's not a sub-site in the sense of having actual content - you can run api.example.com and have exactly the same content.

cvs.drupal.org - even less a subsite, it's a code repository - that's like saying that ftp://ftp.drupal.org/pub/drupal/files/projects/ is 'user centric' or 'designer centric' because they don't use CVS.

testing framework - once again, there's a testing.drupal.org site, but the primary function of the testing framework is to update drupal.org issues with testing results.

None of these are real top-level subdomains in the sense of groups.drupal.org or association.drupal.org - hence them being pretty much entirely left out of the drupal.org redesign proposals (the only reference to api.drupal.org was being able to search it from the documentation index). So they're in no way an argument for a separate subdomain for designers, if anything they're an argument against it.

Even with a redesign, the current content and culture of Drupal.org is way too developer-centric. It's like Teflon for designers.

Unfortunately, most of them would sooner move on to WordPress than let you know. In fact, you'd lose them before you could get them to join GDO and weigh in with an opinion.

I understand the concern over diluting the documentation efforts, but to most design talent, you may as well be writing in Mandarin to an American audience. And the Drupal community will continue to fail in attracting design talent.

I consider these improvements to be within the mandate of groups.drupal.org (except the theme uploader). We should offer image galleries and snippit library and so on. And Og Panels provides a good way to make the presentation your own.

I have basically burned out on groups.drupal.org webmaster duty. greggles and josh koenig are taking over. Lets talk to them about adding these features. I will help.

I'm open to design.drupal.org as well. Just throwing out another possibility.

@mfer yea, I was thinking more of a shared sandbox. The problem right now is that Drupal is strictly a developers sandbox (for the most part). The sandbox metaphor was really just a way of saying that both developers and designers need to be in a shared environment. I think I used the wrong metaphor though.

@moshe I understand that this could very well be accomplished on GDO but I think a major merit of this idea is to create a central design focused group who use Drupal to also help recruit newbies to design for Drupal. Providing them resources, examples of work, et al will go a long way to do that. I also believe a non-Drupal designer would view something at GDO for "Drupal users", while design.drupal.org may be slightly more inviting since it isn't buried inside a Drupal users area. Basically, it's a better marketing move IMO.

Hope that argument makes sense to another mammal out there....

http://drupal.org/project/simple_committer for theme uploads looks really encouraging.

I own a domain: drupaldesigners.org and I am planing to make there a designers showcase/blog/portfolio/tutorials place. But I am also willing to let it be used for this initiative, as bringing more designers to drupal and making something for designers already working with drupal is something that I really want to do...

twitter: @jojototh
drupal.org user: mogdesign
my blog: www.mogdesign.eu/blog

So, I am having a bit of difficulty reconciling some of these goals I hear stated here:

- Make Drupal.org culture less developer-centric
- Not lose designers to WordPress
- Bring more designers/attract new design talent to Drupal

...with creating a separate, off-site community for Drupal designers.

An off-site resource will definitely take strides to create a "safe haven" for existing designers to talk and collaborate amongst themselves, which may itself be a worthy goal. But that isn't the primary goal I'm hearing people in this thread say. And I'm not quite following how separating designers from the larger Drupal community helps achieve the above stated goals; in fact, on the surface, it seems to achieve exactly the opposite, by making designers an even scarcer breed here on Drupal.org.

Is my perception of your goals a misunderstanding, or is this separate site merely part of a larger, over-arching effort which will help address these important issues here on the "mother" site, or am I simply missing a big cluestick somewhere?

I agree that some of these existing sections should be called out and made more feature rich. I've been thinking about how to improve some of this, specifically snippets and tutorials, but never really thought of moving content off drupal.org. I don't think that is necessary if we are willing to give it the attention it needs.

Showcase

I think showcasing could be done on groups.drupal.org, or design4drupal.org. I'm not against it on Drupal.org, but I don't see why people can't write up case studies from a theming perspective and aim for Drupal's front page. Maybe we could come up with a case study outline for theming? I've actually wanted to do this quite a few times, but get stumped on what to write.

I think it might become hard to keep the quality of submissions good and wouldn't want to have to turn people down. I think certain people might try abuse this for SEO reasons. I could be wrong, but that's my first thought.

Snippets & Tutorials

I think Snippets/Tutorials need a real overhaul. I don't think this is specific to design/theming either. I think it would be a nice improvement for developers too. For me, Snippets were how I learned. I would literally spend days sometimes, googling for solutions that didn't exist at the time. Now, there are a lot more but they are all over the place. In addition to what Matt posted, I would like to see:

• Code for Different versions of Drupal in one Place

  I don't like that existing snippets are separated by versions. Drupal can handle this beautifully, if we set it up right, so duplicating nodes and placing them in totally separate sections of the handbook doesn't really make sense to me. It's especially frustrating when you find a snippet/tutorial that does what you need, but it's specific to an old version of Drupal. Imagine having a task and being able to attach the solution for each new version in one place. This could also help end up identifying tasks that become easier, or obsolete with each Drupal release, which is a nice side effect.

• Detailed Ratings/Reviews

  There are so many ways to accomplish a given task, and especially when learning it would be nice to have a detailed rating. See attachment.

• Flagging

  As part of the review process, it would be nice to add "flags" for some common issues with snippets, to make things easier to moderate/review.

• Promoting

  The basic gist of this idea is to enhance the existing api.drupal.org site, which is highly geared toward developers. Since Drupal is good at this stuff, why not use a system like this to feature related snippets and tutorials right there in the API? I'm sure a "real" designer could do a much better job showing what that could look like, so I wont go there.

Again, this is not even a really design/theming only improvement, and it could help toward making this information easier to navigate, and available for export, while not removing any of it from drupal.org documentation, where I think it belongs.

Anyway, attached are my thoughts, mocked up. Sorry if this was long-winded. LOL.

#1262116: Review drupal.org development site for the Design Initiative mentions adding features to Drupal.org rather than a separate subdomain.

While this is another thing to maintain on Drupal.org, the total maintenance is much less since there isn't a separate site to maintain. And the process for contributing to Drupal.org is more accessible than ever, http://drupal.org/make-drupalorg-awesome; I'd say it is much easier than coordinating a whole site. Being on Drupal.org makes cross-site integration a non-issue, for example: exposing contributions on user profiles and referencing related issues for implementation.

I propose cleaning up all infrastructure that had been provided for this project.

Per http://drupal.org/node/493154#comment-4928276, calling this reviewed.

If possible, I'd really like to give Jeff Burnz a chance to respond here before action is taken. He's in Sweden and they do this crazy thing of taking the entire month of August off, which explains the lack of movement on this issue. So my guess is he'll be back next week. If we could hold off until the end of next week, that'd be great. It was my understanding that something like http://jmburnzdev.devcloud.acquia-sites.com/ was key to the D8 design initiative.

Jeff wanted this resource on *.d.o, rather than a separate domain/user database, in order to facilitate getting more designers involved in the main Drupal community. Adding numerous contrib modules to www.drupal.org has traditionally been spurned by the infrastructure team, for good reason, since it would be a huge black eye to the project if our main site were ever compromised. It also makes major version upgrades even more challenging when there are additional module upgrade requirements. Hence the subdomain.

I meant to link to http://drupal.org/node/1262116#comment-4932618, which Jeff wrote.

Ack, nevermind. I just read #1262116: Review drupal.org development site for the Design Initiative and realize that drumm and Jeff Burnz have already been in contact. Fair enough!

I'd be really really thrilled if the development site could go through, I know everyone is busy but we need to start pushing on this as the Design Initiative starts ramping up again after the summer interlude and I would love to have something tangible for BADcamp. I really don't want to get to a situation where this is removed, and we dont have a dev site, which leaves us in no-mans land again, that would be bad for moral.

Dev sites are easy to provision, that won't be a blocker assuming we have space on the server. We are blocked on your access to it, switching from LDAP to a regular user account on stagingvm. We don't want to make a dev site until someone working on it has access since it will just get stale.

Leaving open for #24, removing the design.drupal.org infrastructure.

drumm: What needs to happen to remove that blocker? Pinging narayan?

Already done. He removed the CNAME, but I'm not sure if there are any DBs, vhosts, repositories or anything else left.

Closing old issues. Please re-open if needed.