✍️ @Zedd's Blog

[zchisholm]

Hi and welcome to Content Lab! Here is a self paced guide to ensure you get feedback as you publish your technical blog.

Resources:

• Previous workshop recording
• Previous blog posts

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

[zchisholm]

Outline placeholder

Choose Your Topic Start by identifying the main topic of your blog. It should be specific and relevant to your audience. For example: "Introduction to APIs," "Getting Started with React," or "Understanding Big O Notation." Title of the Blog Create a compelling title for your blog that grabs the reader’s attention. Keep it concise and reflective of the content. Example: “An Introduction to REST APIs for Beginners” Outline Sections with Titles Organize your blog into sections. Each section should cover a key point or subtopic related to your main theme. Here are common sections to include: a. Introduction Title: “What is [Topic]?” This section introduces the main topic and its relevance to the reader. Explain why it’s important to know or learn about this. b. Background or Context Title: “Why [Topic] Matters in [Industry/Field]” Give a brief history or context for the topic. If it's technical, explain how it relates to real-world applications or trends. c. Key Concepts or Features Title: “Understanding the Key Features of [Topic]” Break down the topic into major concepts, features, or ideas. This section often has multiple subheadings to explain each key point. d. Practical Application / How-To Title: “How to Use [Topic] in Your Projects” If it's a tutorial or technical walkthrough, this section should cover step-by-step instructions on how to implement or use the technology. e. Common Pitfalls or FAQs Title: “Common Mistakes to Avoid with [Topic]” Address common issues or questions people might have about the topic, and provide solutions or tips. f. Conclusion Title: “Wrapping Up: Final Thoughts on [Topic]” Summarize the blog’s key points. You can also provide resources for further reading or encourage the reader to apply what they’ve learned. Call to Action Title: “Where to Learn More or Get Started” Encourage readers to take action by pointing them to more resources, tutorials, or next steps. Maybe even encourage them to contribute to open source!