Uploading more than 6400 photos from a single event is already a challenge in itself. Once those images also come from multiple rooms, over several days, and from nearly 20 photographers, things quickly become difficult to manage. At that point, simply exporting and uploading images is no longer enough. You need a workflow that scales properly.
That was exactly the situation we had at WordCamp Europe 2025 in Basel. Contributor Day took place on June 5, followed by the main conference on June 6 and 7. The goal was to publish all images as quickly as possible while still making sure that credits were correct and every session was labelled properly.
To make that possible, I developed a workflow based on Photo Mechanic that was built specifically for those requirements. I had already used the basic idea in a similar form at the 3v3 Floorball World Championships. There, we had fewer photographers, but we had to cover four courts as well as parallel men’s and women’s world championships. So the setup was similarly complex, just in a different context.
Starting point: who took which photo?
The first step was to make every photographer uniquely identifiable. To do that, we asked everyone to send us sample images in advance and, whenever possible, noted down the camera serial number. If a camera did not provide that information reliably, we instead assigned a fixed letter code derived from the photographer’s first and last name, which had to appear in the filename.
This meant that later on, we could identify who had taken a photo either through the serial number in the image metadata or through the filename. We collected all of that information in the Google Sheet WCEU - Photographers, exported it as a TSV file, and then imported it into Photo Mechanic.
This is exactly where so called Hot Codes came into play. Put simply, Hot Codes in Photo Mechanic are a very powerful form of Code Replacements. While classic Code Replacements are often used for individual events or simple abbreviations, in our case they allowed us to connect entire tables of rules and metadata.
You can see that clearly in the screenshot of the photographers sheet. The first few lines define what Photo Mechanic should actually look at. On the one hand, that is the camera serial number, and on the other hand, parts of the filename can also be evaluated. After that comes the actual mapping: on the left is the detected code, and on the right the name of the photographer. So whenever a certain serial number or a certain abbreviation appeared, Photo Mechanic could automatically insert the correct name.
That was the crucial building block for the credits. Instead of having to add them manually later, the attribution could be derived directly from the image data.
The second building block: sessions as IDs
The next step was to make the individual sessions uniquely identifiable as well. For that, we built an ID from the time, track, and speaker. A session could look like this:
0930_track1_Noel
For photos outside the actual tracks, such as general scenes or event related images, we used generic IDs like this:
0000_D1_MOR_misc
We then created folders for all of those IDs. The structure was prepared in the document WCEU - Events, exported as a TSV file, and then imported into Photo Mechanic as well.
In the Hot Code screenshot for the events, you can see how this principle worked. The basis there is not the serial number or the filename, but the folder name. That means that as soon as images were placed inside a folder with a certain session ID, Photo Mechanic could look up and apply the matching information for that folder.
Each event ID contained several fields, for example:
- EventName
- EventSubject
- SpeakerName
- EventDescription
So if images were placed in the folder 0930_track1_Noel, Photo Mechanic would not only know which session this referred to, but could also automatically pull in the title of the talk, the speaker, and the description. That is what made it possible to keep the tagging consistent, even when very large numbers of sessions had to be processed in parallel or one after another.
Hot Codes as the bridge between folder structure and IPTC metadata
The real key was the interaction between those two layers. On the one hand, there was the information about who had taken an image. On the other hand, there was the information about where and in what context it had been taken.
To make sure that information ended up cleanly in the IPTC metadata, the metadata template had to be prepared accordingly. That is exactly what we used the Hot Codes for. When applying the template, Photo Mechanic could resolve the values from the imported tables and write them into the correct fields.
In practical terms, that meant:
- The correct photographer was identified via serial number or filename abbreviation
- The correct session was identified via the folder name
- Both sets of information were automatically written into the metadata through the IPTC template
This turned a large amount of unstructured images into a properly labelled, correctly credited, and quickly publishable archive.
Tested and refined in advance
Before the workflow was used in production at WordCamp Europe 2025 in Basel, Nilo Vélez had already tested it extensively at several smaller WordCamps, including Bilbao, Lisbon, Logroño, and Málaga. A few smaller adjustments were made along the way, and the workflow was refined further.
That was incredibly valuable, because it meant the workflow was not first exposed to an event of this scale without prior testing. Instead, a lot had already been proven in practice and could be further improved under real world conditions.
How it worked on site
On Contributor Day and on both conference days, the core process was always the same. The photographers handed in their images, and those images were then distributed into the corresponding session folders. Because we could read the serial numbers from the image metadata, or alternatively use the abbreviation in the filename, we were able to assign the correct credit automatically.
At the same time, the folder names also carried the session information, in other words during which talk or in which slot the images had been taken. That is exactly what made the workflow so robust: attribution to the photographer and attribution to the session worked independently from each other, but came together cleanly in the end.
Why the effort was worth it
The preparation beforehand was not small. Collecting serial numbers, defining abbreviations, preparing tables, building the folder logic, configuring Hot Codes, aligning the templates, and testing everything all took time. But that preparation was precisely the reason why the whole system worked during the event itself.
In the end, we were able to upload more than 6400 photos with correct credits and proper tagging. But something else was even more important: the images went online quickly. And that made a visible difference. By June 30, the images had reached almost 1.55 million views on Flickr, accounting for roughly 16 percent of all views across the entire account.
It became very clear that when images are available quickly, they get viewed, shared, and actually used. And when the workflow is right, even credit and metadata can be carried along at a level of quality that in previous years often could not be achieved reliably.
For me, this was one of the most interesting parts of the entire project. Not only because I was photographing, but because it showed that in the end, a good workflow can be almost as important as the image itself.