This is a guide for writing blog posts for the Glitch org on Dev.to. Testing.
Basic standards:
- short (150-750 words)
- for a developer audience
- mention Glitch
Some potential topics include1:
- tutorials
- introductory articles
- roundups
- observations/trends
- editorials
- lessons learned
- annoucements/new features
Ideas1:
- Have you ever found a workaround for a common barrier or issue in a piece of open-source software you use?
- How do you use Glitch?
- New Glitch features
- If you had to make a choice about a tool or framework recently, how did you decide?
- Editor: Melissa McEwen
- Copyeditors: Ryan Khosravi
- Advisor: Margarita Noriega
- Tech reviewers: members of the engineering team as needed
Create a Clubhouse story using the Dev.to template. Assign to Melissa. We'll work with you on topic and due date.
If you already have a process that works for you, go for it! Otherwise I strongly recommend writing a post outline and submitting it to Melissa for review. You can do this on the Clubhouse story.
You're welcome to use whatever tools work for you. I strongly recommend using a tool like Hemingway, which encourages concise engaging writing. Make sure you follow the checklist in the Appendix.
Submit drafts as Markdown via pull request at 🔒devto-posts and make sure it's associated with the Clubhouse ticket.. For example my post about Testing I would create a new file called test.md, add my post draft, and create a branch. Then submit a pull request for that branch to master. If you're new to GitHub, Melissa can help you with a personalized tutorial.
At this point don't worry about embeds, pictures or any other formatting.
After your draft is ready assign the PR to Melissa to review.
When you submit a pull request on 🔒devto-posts you'll get some automated checks via GitHub Actions. You can see the results in the "checks" area of the Pull Request.
- Vale looks for common mistakes and gives some optional writing advice.
- Link Checker visits the links in your post to make sure they work.
For the feedback process we'll give you big picture pointers on the structure and content of your piece. We will not directly edit your piece at this stage. After preparing feedback the editor will reassign the Pull Request and story to you. When you incorporate the feedback, please reassign to Melissa for review.
The editor may add a reviewer for highly technical subjects if they are outside their experitise.
At this stage, put your post into Dev.to in the Glitch org (see appendix) and add any formatting and code blocks you'd like. Assign back to the editor.
We'll add UTM params to your links, and add images if you haven't. We'll also update the post in the devto-posts repo to make sure the link checker runs.
Next we'll workshop Tweets and social media images. Feel free to leave this to us. When we publish we'll promote on our Dev Twitter and the homepage.
Most Dev.to posts involve code in the form of:
- Embedded Glitch apps
- Code snippets in Markdown
We do not have a strict code review process or standards, but we like to see:
- well-commented code
- a README.md in all Glitch apps
- files named in a way that will make sense I.E. "feedparser.js" rather than "file1.js"
- a license (MIT for now, more info TBD)
To add posts to the Glitch org on Dev.to you'll need to join it. Sign up for the Dev.to account if you don't have one and DM Melissa on Slack to join.
- Introduction
- a clear "what's this post about" thesis sentence that tells the reader what they'll learn if they read on.
- a link to Glitch
- keep it short!
- Subheaders (H2s)
- if it's a tutorial, these should be the steps, otherwise these should be the main points
- first sentence under subhead should introduce the section, connect it to main thesis
- we love links, make sure to link whenever possible
- no sub subheads (like h3s, h4s)
- Conclusion
- A good conclusion should "conclude" the "what's this post about sentence". For example if the "what's this post about" sentence is "Learning how to automate email can make your life easier" it should conclude with a sentence about how the post did make the reader's life easier.
- A CTA (call to action) sentence like "remix this and tweet us what you made"
- Glitch boilerplate (see section in appendix)
This publishing checklist is intended for use in pull requests
### Pre-publishing
- [ ] Outline
- [ ] Schedule on Shared Content Calendar
- [ ] Feedback
- [ ] Copy editing
- [ ] Images
- [ ] Tags
- [ ] Add UTM tags to links
- [ ] Post to the #editorial channel in Slack the day before publishing
### Post-publishing
- [ ] Schedule Tweet and notify #community
- [ ] Post to #marketing-all and #social-content
- [ ] Update Shared Content Calendar
- [ ] Post to forum (optional)
_[Give your Glitch apps superpowers - keep them awake, lift rate limits, and get more memory and disk space.](https://glitch.com/pricing?utm_medium=weblink&utm_source=dev.to&utm_campaign=handbook&utm_content=dev)_
Credits: 1: The Developer's Guide to Content Creation
made on glitch
ヽ༼ຈل͜ຈ༽ﾉ