How to contribute to Docker Blog
Thank you for your interest in contributing to the Docker Blog. The Docker blog is the place to get the latest on Docker news, technical insights and best practices, community updates and more. It is used to reveal new and updated versions of Docker products, announce major company milestones, hear from our industry friends and partners and act as an educational source for our global community of developers. The Docker Blog has an estimated 340,000 page views per month representing 300,000 unique visitors. The most popular content that we see is nearly always technical in nature and targeted at developers, often written by developers!
Once published your content will reach our community of our developers, employees, media, analysts and lookie-loos. Your content should focus on subjects that matter to the Docker community and ecosystem.
Docker reserves the right to edit and modify any content you submit. We will do our best to communicate any substantive changes, but in the interest of time and expediency, our editorial team will not contact you to correct grammatical mistakes, stylistic errors and/or other minor modifications.
Here’s a list of general guidelines, policies and contacts.
Blog posts should aim to be 500-1000 words. But in reality, we don’t have a hard stop. Write just long enough to engage and enrich readers. No more. No less. If your topic needs to be covered in more detail then a multi-part blog series is the way to go (see example here).
Topics we like to see covered include: Docker, containers, container security, product updates, software development trends, how-tos, tutorials, event announcements (including recaps of industry happenings), containers, cloud, cloud platforms (AWS, Google Cloud, Microsoft Azure, etc.), Kubernetes, engineering, product roadmap, community, developer tools, and open source. This list is not exhaustive so feel free to suggest another topic related to Docker.
Style and Formatting
We don’t have a detailed style guide we require you to follow. However, we do have a handful of basic formatting requests that will make your post easier to read. Write your post with Google Docs. See this template on how you should submit your draft. Include suggested headline, author, social media account and expected publish date. This is the easiest way for us to convert your content into a WordPress post (using our Google Docs and WordPress integrations). Stick to H2 and H3 sub header levels. This helps keep formatting clear and simple. Make all screenshots 1360 pixels wide. Embed all images into the document or provide a link to a ZIP folder.
Graphics and images
Good use of images will draw readers into your blog posts. Include them. A good rule of thumb is to include at least one graphic per page/post. Be sure to cite the source of your image.
If this is your first time blogging on Docker, please submit a picture of yourself. Send it as a JPEG file. As a general rule, WordPress image sizes should be no bigger than 150kb except for large photos. Our platform only shows your name and photo. No bios or links will be included.
When writing code, use the Courier New font to let us know that your text must appear as code as we transfer your content to our blog platform.
This is harder than you think. Make it catchy, compelling and clickable. Headlines should help people instantly understand why they should read your article just from the title. Stuck? Don’t worry, go ahead and submit your blog and our crack team of editors can help with headline selection.
Use Headers and Sub headers
Headers and sub headers will break up long blog posts, help people scan your blog and convince them to read the post.
When warranted, numbered lists or bullet-pointed lists help people scan blog posts quickly and find information they’re looking for fast.
We aren’t re-writing Windows OS so write in short sentences, break up large blocks of text with bold headings, and bullet your major points.
Docker tags content. Please suggest keyword tags that should accompany your post.
Content review process
Quality content takes time to edit and prepare, so please allow at least a week for the Docker editorial team review. Note that your content is also being juggled along with Docker-sourced blog content and we are constantly shifting publishing dates of our content to have the maximum impact with our readers. The more lead time you give us on a publishing, the better we can meet your date to push your content.
We prefer our content to be original and first run. However, if we deem a piece compelling and important, we are happy to repost existing content with links back to original content. We ask that you wait one week before reposting any content submitted to Docker’s blog. When reposting, please cite and link to Docker as the original source.
Promotional link policy
We are here to promote benefits to the Docker community. Please refrain from having any personal or affiliated promotional links in your posts. If the promotion is related to an event that needs to be promoted on the topic being discussed in your blog (webinar, event, talk, etc.), feel free to promote away. The point is to avoid self-promotion in the article. If you don’t know what we mean, click here.
All blog posts on Docker will get a social media promotion on at least one of our three main networks Twitter, Facebook and LinkedIn. Be sure to include your social media profile in your draft post if you’d like us to highlight your handle. Please feel free to amplify as you see fit. If you’d like us to also amplify your personal social media accounts based on the content you submitted please contact our editorial team and we’ll do our best to retweet, share or update any social media you push.
Examples of Successful Content
Here is a list of popular blog posts that performed well. All these blogs have elements of what we outlined above.
- Containerized Python Development – Part 1 Note due to length, this post was broken up into three parts. See Part 2 and Part 3
- How To Use the Official NGINX Docker Image
- Docker Desktop: WSL 2 Best practices
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.