As of today (October 31st 2014) we can use KDE's very own ownCloud instance to host our files centrally, instead of spreading them all over a dozen different file hosting sites.
This is not meant for anything that is directly used by KDE software (such as icons or background images), but for pretty much everything else (mockups, idea documents, etc.).

The instance can be reached at https://share.kde.org/ . It uses identity.kde.org accounts (i.e. the same with which you also log into this forum) for logging in, but since giving every Identity account access could overburden the server, access is only given to the members of a specific group on Identity.
Currently, each user gets a 100MB quota. If we find that this is not sufficient, we can ask for the quota to be increased.
If you cannot access and upload files from your Identity account (try it out first, chances are you are already in the group), just send me a message and I will ask the admins to add you to the group.
You can also use the visual-design group for sharing with everyone.
For including the mockups in the forum, use the "share link" function.

So in order for us to keep our stuff in one please, please use https://share.kde.org/ for your mockups and other documents from now on.

Great idea, and I'd recommend to have clear and common labels from the start. Right now we have VDG/svg, and I read it as if I have to place my Balsamiq mockups into VDG/bmml. This makes not sense to me.

File name:
Two files are in the svg folder, e.g. present_windows_grid-123481-kdeuserk-1.svg. Its hard to figure out where this mockup belongs to, in a year or so. And the sorting order is weird when we start with the project. I suggest to have it like this: <yyyymmdd>_<kidenty>_<project>_<version>.<filetype> (e.g. 20141031_kdeuserk_present_windows_grid_1.svg) - if we keep the folder structure.

Folder structure:
About the structure I'd say we have "ideas" instead of svg and "prototypes" for the final versions. Furthermore "tools" (or the like) that contains the svg toolkit, Axure masters and Balsamiq symbols, if we have it once. I don't like to sync all idea but tools and final versions would be nice.

Opinions?

Heiko Tietze wrote:File name:
Two files are in the svg folder, e.g. present_windows_grid-123481-kdeuserk-1.svg. Its hard to figure out where this mockup belongs to, in a year or so. And the sorting order is weird when we start with the project. I suggest to have it like this: <yyyymmdd>_<kidenty>_<project>_<version>.<filetype> (e.g. 20141031_kdeuserk_present_windows_grid_1.svg) - if we keep the folder structure.

I guess you have read the README that I silently added?
I have also thought about adding the date, to the filename, but imho this is not necessary as this attribute is stored by owncloud anyway (about the sortin: it should be possible to automatically sort after the upload date). To solve the problem where the mockup belongs to I integrated the thread id in the file name (123481), so that it is easy to find the thread where the subject is discussed, using the url scheme "https://forum.kde.org/viewtopic.php?f=285&t=<thread_id>", in this case that would be "https://forum.kde.org/viewtopic.php?f=285&t=123481".

I think svg mockups should not be mixed with raster graphics. If we have a dedicated folder for all svg mockups this would certainly help others that want to start mocking things up by downloading the svg's and reusing elements.
About final versions: Yeah, maybe a we should introduce a field in the file name to make it easy to filter final versions, otherwise on has to find the highest version number of the file and if there are multiple variants of one version find out which one was the final.

kdeuserk wrote:I guess you have read the README that I silently added?

Now I did

kdeuserk wrote:Current naming scheme to keep things organized:

<title>-<thread_num>-<nickname>-<revision>

Ideally none of the fields contains a "-" to keep that pattern easy to recognize.
Spaces may be replaced with "_".

The <title> field should give a short hint what the mockup is about.
The <thread_num> field helps to associate the mockup files with the forum thread the mockup is discussed. A forum url looks like this: viewtopic.php?f=285&t=123481 where <thread_num> is the number after "t=". Using that pattern one can quickly find the design discussion associated with the svg mockup.
The <nickname> field should be present, to associate who did the mockup, even if not everything has been created by the author himself. If one copies and modifies a mockup, he should leave the <title> and the <thread_num> fields the same, but modify <nickname> and <revision> fields.
The <revision> field helps to denoting multiple version and variants of a mockup. Ideally you begin enumerating the revision by 1, regardless of the state of the mockups and denote versions with a letter (beginning with "a").

Two ideas, ideal for discussion.

Heiko Tietze wrote:

kdeuserk wrote:The <revision> field helps to denoting multiple version and variants of a mockup. Ideally you begin enumerating the revision by 1, regardless of the state of the mockups and denote versions with a letter (beginning with "a").

Should be:

The <revision> field helps denoting multiple version and variants of a mockup. Ideally you begin enumerating the revision by 1, regardless of the state of the mockups and denote variants with a letter (beginning with "a").

I will correct that together with other typos.

Great to see some brainstorming on file organization!
Personally, I agree with Heiko that an organization on the top level by file type isn't ideal.
I'd prefer to put the projects at the top level, then we can of course create subfolders for different file types for each project.

In the end, it depends on the usecase: If someone is just looking for inspiration and elements to re-use, then having e.g. all SVGs in one place does make sense. However, I assume it's more common to look for the files related to a specific project because one is working on that project.

If we still want to be able to access all SVGs in one place, we could achieve that using symlinks.

Once we have settled on a hierarchy and naming scheme, we can move things over to a new centrally shared folder which the admins will create for us (as everything in the current shared folder will be counted towards Sogatori's quota, which would run out quite quickly if we put everything we create in there).

So, what do others think?

In or company or file name convention is:
- project name-running number-Version

the svg and png selection isn't that good for separating into different file types the filemanager is used for.

The forum thread is unique but it doesn't say anything. so for the folder name you can't use it. my structure proposal is:
App Name/Thread Number-user-Version-if necessary title

App Name: Plasma, Dolphin, System Settings, ...
Thread Number: it's t= in the url isn't it?
user: how made the file
Version: Could be 01, 02, 03 or Date (problem when you make more files a day) I prefere 01, 02, 03
Title: what the file show or is used for (humans are not computers)

Hrm, How I would do it, maybe (going by folder level);

• public; polished work meant for public sharing, read-only of course. Meant for most work we'll be doing; we shoudl expect anything in this folder to wind up in the public eye.
  
  • software; for everything to do with UI.
    
    • Project; name formatted "(desktop|app)-(applicationType)-(camelCaseProjectName)", I.e. "desktop-plasmoid-dateTimeFlipClock" or "app-productivity-kOffice"
      
      • Filename; name formatted "(camelCaseProjectName)-(camelCaseDescription)-(someRevisionNumber)-(identity)", I.e. "kOffice-newIcons-2.3-uri"
    
    
  • promo; Anything people will use to promote KDE; from websites to videos.
    
    • Project; name formatted "(mediaType)-(camelCaseProjectName)", I.e. "website-okular" or "video-coolPromoVideos"
      
      • Filename; name formatted "(camelCaseProjectName)-(camelCaseDescription)-(someRevisionNumber)-(identity)", I.e. "coolPromoVideos-kde5.1Release-4.1.2-vdgvictim"
    
    
  • brainstorming; When it's unofficial; as in, the project hasn't even asked us to work on it. Either that, or it just doesn't fit either software or promo
    
    • Project; name formatted "(camelCaseProjectName)", I.e. "kdeComputerStickers"
      
      • Filename; name formatted "(camelCaseProjectName)-(someDescription)-(someRevisionNumber)-(identity)", I.e. "kdeComputerStickers-monoTone-1.1-mrmagoo"
      
      
• private; the designs may be too early, developers might want designs kept quiet for some reason, but we need to wait before moving any of these to the public folders. Folders are mirrored with public. This way we can just move things to their same spots in the relevant folders.
  
  • software; for everything to do with UI.
    
    • Project; name formatted "(desktop|app)-(applicationType)-(camelCaseProjectName)", I.e. "desktop-plasmoid-dateTimeFlipClock" or "app-productivity-kOffice"
      
      • Filename; name formatted "(camelCaseProjectName)-(camelCaseDescription)-(someRevisionNumber)-(identity)", I.e. "kOffice-newIcons-2.3-uri"
    
    
  • promo; Anything people will use to promote KDE; from websites to videos.
    
    • Project; name formatted "(mediaType)-(camelCaseProjectName)", I.e. "website-okular" or "video-coolPromoVideos"
      
      • Filename; name formatted "(camelCaseProjectName)-(camelCaseDescription)-(someRevisionNumber)-(identity)", I.e. "coolPromoVideos-kde5.1Release-4.1.2-vdgvictim"
    
    
  • brainstorming; The crack the VDG is smoking
    
    • Project; name formatted "(camelCaseProjectName)", I.e. "kdeComputerStickers"
      
      • Filename; name formatted "(camelCaseProjectName)-(someDescription)-(someRevisionNumber)-(identity)", I.e. "kdeComputerStickers-monoTone-1.1-mrmagoo"

public/brainstorming/whatIf/whatIf-accessibilityVoiceControl-1.0-kvermette
public/brainstorming/guidelinesSamples/guidelinesSamples-calendarConcept-1.0-alake

Just some notes behind my madness - MuahHahAaHhAAhAa;

• I'd try to get away from ultra-complex and formal file-names; I'd put any complexity into the basic folder structure.
• Using folders to group things makes moving groups of stuff easier.
• I wouldn't put dates into the filenames; it's a lot of extra work, and owncloud tracks it for us. Generally, if the filesystem can do it, let the filesystem do it.
• I wouldn't put formal structure on naming conventions. I'd just say "keep it sane, and format it so people can increment the last digit". That way others can jump in.
• Put names last. That way nothing else is sorted after the name - like version.
• On actual organised things I try camelCase with numbers and dots, regardless of wether or not the origional topic used spaces. That way it's easy to know how to search, as search is caseless and always one word. Is it blueDevil, blue_devil, dragon_player, or Dragonplayer?
• Couple-clicking camelcase selects names inside hypens perfecly. YAY OCD!

Anyway, superfantastic work on Owncloud! It'll be so *pimp* to get using this!

I think of all the ideas I prefer Kver's proposal so far. Especially because it utilizes the folder structure much more than the others.

I also like Kver's proposal a lot.

Btw: We have a new shared folder now (Visual Design Group Share), which was created for us by the admins and therefor doesn't count towards any of our quotas.
So please put or move your mockups there.

We can also already put stuff there even though we have not decided on the structure yet. We can still move/rename them later, but that way they are already in a central place.

As soon as we have something firm and ready, we will need to publish it somewhere, because it is already making my head spin. hehe

Thanks

Please consider that if we use public|private > software > files it will be hard to synchronize folders. Or I share and link only my private folder.

I agree, Kver once again killed it, kudos! Though I would like to consider making the thread number part of the filename to make association with threads easily possible for anyone.

Okay, so since most of us seem to agree with KVer's suggestion, we should go with it.
I'll "de-sticky" this thread and create a new one with only the official solution.
Any ideas where we should publish this additionally to make it even more "official"?

IMHO it would make sense to also extend the Pastebin (or whatever it’s called in KDE 5) plasmoid to upload pictures to KDE’s (or custom other) ownCloud.