✍️ @Jiachun's Blog #82
Description
Hi and welcome to Content Lab! Here is a self paced guide to ensure you get feedback as you publish your technical blog.
Resources:
Timeline:
- 📋 Dec 1st have an outline and open up issue
- 📰 Dec 8th have rough draft in
- Mentor reviews by 12/15
- Dec 15th-20th turn in final draft
📋 Blog Outline: Write your outline in the issue directly
Requirements
Questions to consider:
- Who’s reading this? Where are they in your dev journey? What do they need to know before they can dive into this story?
- If people could leave with just one action, what would it be?
- Were there surprises or alternative problem solving you want to give a heads up to?
Sample Topics for your blog post
- Creating tests for Stripe/Cicero/Twilio
- Using Vuetify and V-cards
- Debugging a PR test failure affecting entire codebase and creating an issue for it
- System Design/Architecture design for caching capability
- Implementing Text to Speech
- Configuring secrets for APIs in codespaces
- Building Actions for [security|community|CI| etc]
Example Outlines
What makes good documentation on open source?
- Could this be a list? (3 pieces of documentation thats easy to check for and add to the project to add immediate value?
- What inspired you from the Tech documentation workshop?
- What would you help encourage other first time contributors to do?
- Is a learning curve for everyone? And whats the balance between good documentation and too much documentation? Choice architecture
- What is each space used for? Wiki vs Discussion vs Pages
- How do we search and find?
Reference: https://blackgirlbytes.dev/conquering-the-fear-of-contributing-to-open-source
Reference issue/PR for photos
Conclusion: Documentation is always changing, will always be needed`
To Do: when you complete the requirements, add "outline ready" label on your issue
- Identify your topic from one of the PRs approved
- Outlining bullet points of blog roadmap
- Is your blog a List, Survey, or demo?
- Which Visuals or Diagram or Code snippets will you add
- References to resources
📰 Blog Rough draft: Format into a google doc
Questions to answer across draft
- Why is this helpful for a reader?
- What problem does this help them solve?
- What kind of experience should the reader have or that you will provide so they’re up to speed
- What larger problem is this solving?
- Were there other ways of solving this problem - what made you choose the one that you did?
- What were the positive tradeoffs? (Did it save time? Save hours? Was more secure?)
- What is the best way to present the content (i.e. code snippets, graphics) ?
- What additional resources can they provide the reader if they want more information?
- Is there a call to action?
To do: when you complete the requirements, add "draft ready" label on your issue
- intro paragraph
- context of Amplify
- paragraph on problem
- paragrph compare your solution
- paragraph impact your solution
- Less than 600 words
- Drop link to your google doc (with permissions for edits) in review issue