✍️ @Aliu's Blog

[badex-ai]

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