How to contribute

EN DE

Process and Deadlines

A blog article should be submitted at least 48 hours before the desired time of publication, and we”d be glad to receive it significantly earlier. We want to use this time for questions and proofreading. Entries for the calender can be published after a shorter review.

Articles and calendar entries can be sent via mail to blog@events.ccc.de or submitted as merge requests to https://git.cccv.de/infra/static-pages/events.ccc.de. Please understand that sometimes it will take a few days before we can work on your submission.

Contribute events to the calendar

To have an event published in the calendar, you can send a short e-mail to blog@events.ccc.de. We ask that you provide the following information, as far as currently known:

  • title
  • location (we would also specify “online” here if applicable; for presence events we would want at least the city, but would prefer a full address)
    • We prefer non-abbreviated street names. Please check the spelling. In German, some people believe that the orthography reform has eliminated the ‘sharp s’ (ß), but that is not true (so street is still Straße, only Switzerland does not use the ß). Also, existing German names for streets and places will mostly keep their old-orthography spelling.
  • first and last day (we don’t process the time of day)
  • website
  • organisers (name – consider omitting a group’s legal status such as the much-loved German “e. V.” – and e-mail)

You can use the template below.

The criteria for including an event in the calendar are not set in stone, although the event should be somehow connected to the Chaos and it should be relevant beyond its city or region. If you’re not sure, you are welcome to write to us and we will decide together.

Please remember to inform us about any changes (such as: date changed, exact location now known, website now online, event cancelled).

We select some events for inclusion in the “upcoming events” widget at the top of the right column. The selection is mainly based on the size of an event and its proximity in time to other events, the latter because we currently display no more than two upcoming events. To potentially include your event as an upcoming event, we need one further item:

  • a square teaser image or logo (width/height 200 to max. 400 pixels – follow the advice for images below and add an alternative text)

Contribute a blog article

For blog articles we ask you to submit the text in appropriate languages and a teaser image. Please follow the advice on texts and images below.

We use hugo, a static site generator. Please start working on your article with our template below. The comments in the template will hopefully guide you. On the top of the template you will see the so-called frontmatter that contains metadata for your post – such as title, publish date, header image, category and tags.

Choosing Categories and Tags

Please do not invent new categories on your own, these are curated by the eventblog team. As a rule of thumb: You may ask for a category specific to your event once the event has taken place several times and reached relevance beyond your region. As long as there is no category for your event, please use the “friends” category and create a tag for your event. Please do not “over-tag” your post. Less fitting / descriptive tags are better than a lot of useless tags. Examples for descriptive tags: “call for papers”, “tickets”, “presale”, “fahrplan“ / “schedule”. Examples for redundant tags: “event(s)”, “veranstaltung”, “ccc”.

If you are unsure about a suitable category or tags or any other field, we are happy to help and we invite you to ask.

Texts

We ask you to submit readable and not too long texts. The text format is Markdown. Please avoid manual formatting via custom HTML or style attributes.

Language versions

The event blog technically supports the languages German, English and French. To decide in which languages you want to publish an article, you might want to consider in which languages people can participate in your event.

Proofreading

Subject to capacity, the event blog team will proofread German end English texts and possibly suggest changes. We can also translate between these two languages.

We prefer

  • Typographical punctuation marks

    • Quotation marks according to the conventions of the respective language: „Deutsch“, “English”, « français »; apostrophe: ’
    • En dash (–, U+2012) for connecting items such as two ends of a range or alternatives or connections. In more traditional English typography, interruptions or colon-like dashes are set as em dashes (—, U+2013) and without surrounding spaces (or with hair spaces, U+2009). However, the en dash with surrounding spaces is also in use for these purposes and we prefer this for reduced complexity.
    • minus sign (−, U+2212) for negative numbers and as a mathematical operator
    • multiplication sign (×, U+00D7) for areas, 2D pixel sizes etc.
    • ellipsis (…, U+2026); note that, particularly in German, these will have to be separated from the preceding word by a space – the only exception being when only parts of a word are omitted and replaced by an ellipsis. Traditions in English typography are quite varied regarding spaces around and within the ellipsis. We have chosen to follow the German style in English as it is a possible English convention, too.
    • arrow (→, U+2192).

    By the way: almost all the characters mentioned above can be entered using fairly simple [AltGr] combinations on a → German Linux keyboard. (Exceptions are: minus sign, hair space.) Also, every character can be entered in Linux via its Unicode codepoint U+wxyz (where wxyz is a placeholder for 1–6 hex digits) using the following key sequence: [Shift]+[Ctrl]+[U], [w], [x], [y], [z], [space].

  • Dates in the following formats:

    • German: 1.2.2025 / 1. Feb. 2025 / 1. Februar 2025
    • English: 1 Feb 2025 / 1 February 2025
      (never use a number for the month, as there will always be uncertainty regarding day–month order; place the day before the month because on both sides of the Atlantic this order is acceptable; do not state the day as an ordinal number such as 1st or include the words “the/of” since all these can be omitted in writing; no dots, hyphens, slashes or commas within dates)

  • When expressing date ranges (“from/to”), please use an en dash and reduce the two ends by stating equal date components only in the “to” part:

    • German: 27.–30.12.2025 / 30.1.–1.2.2025 / 30. Jan. – 1. Feb. 2025
    • English: 27–30 Dec 2025 / 30 Jan – 1 Feb 2025

  • For times of day, use the 24-hour format H:MM in all languages. For an international audience, so most importantly in the English version of an article, add the time zone (pay attention to daylight savings time [summer time], the German time zone is called CET/CEST) and/or add the UTC-Offset: 17:00 CEST (UTC+0200)

  • leading zeros are only needed for dates and times when multiple values are to appear in an aligned, vertical arrangement. In text flow, these zeros tend to distract from the significant digits and should be omitted.

Images

For each blog article, please provide a header image. Further images can of course be added.

Submit your images as files with the text, not as a URL to an external website.

Image content

At CCC we are very cautious about publishing images featuring individual people. That is an important tradition – see e.g. the policy at 38C3. The event blog team asks that no people should be visible on images. The only exception is when the people shown are the specific topic of an article.

Please do not submit images generated with AI tools, we will not publish them.

Image (file) size

TL;DR

Images that appear in the main (content) column can typically be reduced to <50 kB. For teaser images in “Upcoming Events”, it will not be difficult to end up with ca. 15 kB. The smaller, the better. A simple method is: Scale header images down to a maximum width of 1400 pixels (the height should be sigificantly less, to avoid the image taking up too much vertical space). Teaser images for “Upcoming Events” must be squares with a length of max. 400 pixels. Save your images as WebP, using lossy compression with a quality of 50–70. (Compression artifacts are much less visible in WebP than in JPEG.)

Motivation

Please remember: The event blog is not a photo blog. The images shown here are mainly for decoration and to provide a break within the text. Very few people will look at them very deeply. A further consideration is that our list pages will show 10–15 images. Our technology does not perform automatic “shrinking” of images.

So, this is not the place to publish your high-resolution originals in near-lossless quality – we need reduced image files.

This is why we ask you to take on the challenge of making your image files as small as possible. Even if you find yourself reusing an image already on our site from earlier days, consider creating a reduced version of it and including the result in your submission.

When reducing images, consider all these parameters: pixel size, colour, file format, compression.

Target file size

It will normally be quite possible to produce files of 50 kB or less for our blog articles. For the “Upcoming Events” section that is fed by our calendar data, you can target 15 kB. There will of course be exceptions – for example, the current trend of making “graphical“ images more interesting by adding a “noise” effect makes size reduction harder.

Pixel size

The theme currently used by the event blog restricts image widths to 678px in the “content” column and 168px in the “Upcoming Events” section. Rounding up and doubling this (considering retina technologies and the like), we arrive at these guidelines: Images in blog articles should be no wider than 1400 pixels (and much less in height). The square teasers for “Upcoming Events” should not exceed 400 pixels.

GIMP: Crop an image

GIMP: Scale an image

Colours

If your image only uses/needs grayscale pixels, it should be saved as such, not with RGB colours. If the image is in colour, but more like a graphical sketch than a photo, then maybe it only needs 256 colours or even much less. In that case you can try introducing a colour palette. Reducing pixel size and colours are the most effective ways to reduce file size.

GIMP: Change image mode

Image file format

For images that are more a graphical image than a photo, JPEG is not the right format. PNG is an alternative there, and if your image does not use transparency, the file will be even smaller if you remove the alpha channel.

GIMP: Remove alpha channel

Maybe you can submit “graphical” images in SVG format, which is potentially even smaller while offering perfect quality. Potentially the most simple and effective solution for raster images will be to export to WebP using appropriate settings. This format is more modern and flexible than JPEG or PNG, and all modern browsers support it.

Compression level

JPEG is known for its “lossy compression” and the artifacts that come with it. What might be less known is that WebP offers both “lossless” and “lossy” image compression. With “lossy”, compression artifacts are much less visible in WebP as they are in JPEG, which is why WebP will almost always “win” against JPEG for photos. The challenge here is: Find the lowest good compression level! A realistic approach is to save a version at level 50, inspect the result and then perhaps decrease or increase by 10 or 20. (As we said before, the event blog is not a photo blog.) In “lossless” mode, WebP will mostly “win” against PNG. In any case, a quasi-automatic approach of saving as WebP is not a complete solution. Not only will you have to decide on the compression settings, it also helps to consider all the other parameters. For example, even though WebP does not use colour palettes, a WebP file will turn out smaller if the image was reduced to a colour palette before exporting.

Image license

Please respect license rights. Use cc-by licenses as much as possible and provide a good attribution. Please mind that we cannot publish nc and its variants. If you submit an image from an external source, remember to mention that source.

Templates

Blog article

---
# Please remove blank lines and comments before submitting.

# Add a title for your blogpost. Do not add this title to the content of your post. It will appear as a first-level header.
title: 'title of your blogpost'

type: post

# Set the date for your blogpost. 
# Normally you should only set the date. There is no support for publishing posts at a certain time.
# The publishing pipeline is run on every push / merge to the main branch and by a scheduler every morning.
# A post with a date/time in the future will be published by the first run of the pipeline after the specified date/time.
# If a time needs to be specified for some reason, note that it is in UTC unless you add a time zone offset in the format +HH:MM.
# If you need to specify a time and you want the daily publishing pipeline to include your new article, set the time to 06:00:00 UTC or earlier.
# Format: yyyy-mm-ddT00:00:00
date: yyyy-mm-ddT00:00:00

# Set a cover image for your post. Choose one from /static/media/ or upload your own there.
# Omit the leading “/static” in the path in the “cover:“ line.
# If you dont want to use a cover image (not recommended), delete the “cover:” line or turn it into a comment via a leading # character.
cover: /media/mycover.jpg

# Provide an alt text for your cover image if possible. It should describe the image. 
coveralt: "A laptop in front of a bunch of LEDs. It shows an editor displaying some code. The LEDs are light up in different colors."

# Add a category for your post, most likely it will be the event your post is related to.
# See https://events.ccc.de/category/ for a list of categories.
# Examples: 37c3, camp-2023
category:
  - category1

# Optional: add one or more tags for your post.
# See https://events.ccc.de/tag/ for a list of existing tags
# Examples: cfp, angel
#
# Please only invent new tags if there is a good reason. Tags are no stickers!
#tag:
#  - tag1
#  - tag2

# Multilanguage configuration is currently available for English (.en.md) and French (.fr.md).
# After writing your post, make a renamed copy of your file and translate the content
# and frontmatter (most likely title) appropriately.
# Example:
#   /YYYY/MM/DD/mein-blog-post.md    <- (German version, default)
#   /YYYY/MM/DD/mein-blog-post.en.md <- (English version)
#   /YYYY/MM/DD/mein-blog-post.fr.md <- (French version)

---
<!-- Do not repeat the title, it will automatically appear as the first-level heading at the start of the article. The TL;DR section and the ‘more’ divider below are optional. Delete this comment. -->

## TL;DR

  * Item 1
  * Item 2
  * Item 3

<!--more-->

Your text, maybe starting with a second-level heading after a TL;DR

_Image attribution_

Calendar

- title: …
  location: …
  date_from: YYYY-MM-DD
  date_until: YYYY-MM-DD
  website: https://…
  organizer_name: …
  organizer_mail: …
  teaserimage: … (optional; delete line if not used)
  teaseralt: … (optional; delete line if not used)