There was a discussion on #20293 ( http://core.trac.wordpress.org/ticket/20293#comment:33 ) about starting to use the defunct design repository ( http://design.svn.wordpress.org ) to keep trac of design source files.
We often end up waiting on people who have the working PSDs/Fireworks PNGs/etc for graphics or icons, or redrawing things (this happened for the admin bar icons that were made for retina displays) because the source files got lost of the persan can’t be contacted. For graphic elements we should make it a point to upload the working files as well as the production files. That way, if the original creator isn’t available someone else can pick it up with as many resources as possible.
There’s more discussion on the ticket about having a page on this blog vs. a repository. I think the main advantages of a repository over trac or uploading to make/ui are:
- I like uploading graphic files to tickets, but Trac has a very low file size limit. A lot of the heavier PSDs won’t be able to be uploaded to Trac.
- By using a repository, we can not only have the resources, but we can track how they’ve changed over time.
If we started using the repository we would have to come up with a good organization scheme. Some ideas:
- A scheme based on where the corresponding production files live within WordPress (ex wp-admin/images/admin-bar.psd would correspond to wp-admin/images/admin-bay.png). This would make it harder to keep track of sketches, full page layouts, or design resources that don’t have an explicit tie to a production file.
- A scheme based on the type of graphic (screen layouts, icons, graphics, etc).
- A scheme based on feature
If anyone has any more ideas on this, please comment 
I’m not super confident in any of the ones I presented above, so a good discussion about this is welcome.
cc @jane
Helen Hou-Sandi 4:15 pm on May 26, 2012 Permalink
I think a scheme based on where the corresponding production files are located would work well, although that sort of begs the question of where things go once they’re no longer used (could probably just stay there for reference). There could also be directories for sketches, full layouts, and other resources, if that would make sense, with further subdirectories if needed.
Ipstenu 1:46 pm on May 29, 2012 Permalink
I think keeping them forever would be a good idea, since sometimes you go down a design track and wind up wanting to go back a little. Past reference is always good
I’d order them by feature, and under feature have the subfolders.
Helen Hou-Sandi 1:26 pm on May 30, 2012 Permalink
The issue I have with ordering by feature is the subjective nature of it, and the learn-ability for other contributors. Organizing production files by directory would make more sense and makes it easy to find a file you need for a patch, at least to me.
As for “old” files, I wasn’t thinking delete so much as moving into another folder, but it’s probably not necessary anyway.
Chelsea 3:14 pm on June 17, 2012 Permalink
Unless anyone has any further objection, I’m going to this up today with a structure based on where the production files live + other subdirectories for pre-production files such as sketches, mockups, and general resources.
Shane 4:22 am on May 28, 2012 Permalink
We used svn as a source of document control for our design team for a couple years and finally decided to move to dropbox. We moved for the following reasons:
I know that the team prefers open source solutions and wonder if there is some comparable alternative to dropbox. It provided us instant access to changes, almost no education required for our design team. The downside was the over 2GB required financial outlay and there is the risk of deletion (although there is version history).