🎙 @Teri Tech Talk

[Terieyenike]

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:

• 📋 Week 4: Create an outline by 3/2
• 📰 Week 7: Rough draft due by 3/16
  • Mentor reviews by 3/30
• Week 9: Final version due 4/7

📋 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

• [x] Identify your topic from one of the PRs approved
• [x] Outlining bullet points of blog roadmap
• [x] Is your blog a List, Survey, or demo?
• [x] Which Visuals or Diagram or Code snippets will you add
• [x] 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

[Terieyenike]

I hope this serves as an interest for the dev talk @unnamedrd