Deliver Better is seeking reference style content to be featured on the Deliver Better website. We are seeking submissions from software delivery stakeholders, established technologists, and technology leaders. For any questions not addressed on this page regarding the contribution process, please email email@example.com.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
DevOps Agile Methodologies and Practices Agile Tools and Resources
General Topics we’re looking to feature include:
Open Source - Best practices - Case studies, and stories Site Reliability Engineering Analytics/DataTesting and Test Automation Deployment Automation and Configuration Management Containers Developer Frameworks Programming/Scripting Languages Databases Operating Systems and Distributions
Our editorial style
Please read these thoroughly before submitting a content piece for consideration.
What We Look For
Concise Content The most successful content on Deliver Better offers a concise viewpoint with strong takeaways that align with the topics that matter to tech leaders, managers, DevOps engineers, and developers. The goal is to curate and summarize written reference content that anyone with software delivery stakes can read to learn the skills needed to work in modern technology enterprise. The content caters to readers in IT leadership, DevOps, Cloud environments, and all application architectures. Content often features tips and resources in the form of bulleted or numbered lists.
The People Perspective We give a strong preference to authors with a DevOps, Developer, leader title (CTO, VP of IT, etc), or Product Manager title in order to offer readers a learning perspective based on personas. Example: A Manager's Guide to DevOps
Word Count 500-1200 words is the recommended length for reference content on Deliver Better. There is no firm word count requirement. Consider splitting content into two pieces or editing content that is longer than 1300 words.
Before you submit an article draft for our consideration, please do the following: Proof Your Article Our community managers will peer review and proofread your contribution before publication. Content with excessive typos or poor quality may be returned or rejected. Link to Sources If your material references a document, site, book, or quote please hyperlink the sources and any additional recommended resources within the content. Create Subheadings If your article is longer than 500 words, consider adding subheads to break up the text and make your article easier to read. Subheadings should be consistent (e.g. if the first subhead starts with a verb, all should start with a verb). Check our Editorial Style Guideline See below. First-Time Authors If you are submitting your first article, please include your bio, headshot, full name, title, company, and Twitter handle.
Editorial Style Guideline
Please follow the editorial style guidelines listed below: Write in the active voice. Keep the introduction to 1-3 sentences. Let readers get to the how-to portion of the story. Use serial commas (i.e. cat, dog, and mouse). Write out numbers below 10 (i.e. nine, eight, and seven). Use bullet points or numbering when describing processes or providing a tutorial Place periods and commas inside quotation marks. Avoid random acts of capitalization (i.e. agile vs. Agile, big data vs. Big Data, etc). Use a single space after the period. Only use single quotation marks around quotes within quotes. Spell out the word “percent” vs using %. Spell out abbreviations and acronyms upon the first reference. Provide captions for any screenshots, figures, and tables.
Sample Content Outline
Before you submit an article draft for our consideration, please do the following:
Paragraph 1 Define the reference topic. What are the pain points and challenges this content will address in relation to software delivery?
Paragraphs 2, 3, 4 Offer reference material and content on how to solve the pain points in an informative way. Cite credible sources or resources and use examples when possible.
Final Paragraph Conclude with a summary, why should the reader care? Share some takeaways like resources and advice that ties back to the introduction.