✍️ @Jesse's Blog

[JesseKagumu]

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

[JesseKagumu]

Title: "Getting Started with GitHub Actions: Automate Your Workflows with Ease"

Introduction

• Briefly introduce GitHub Actions as a powerful tool for automation.
• Explain why automation is essential in development workflows.
• Highlight how GitHub Actions can simplify repetitive tasks, CI/CD processes, and overall DevOps.

Section 1: What is GitHub Actions?

• Define GitHub Actions and its purpose.
• Discuss how it fits within the GitHub ecosystem.
• Mention typical use cases, like automated testing, deployment, code quality checks, etc.

Section 2: Key Concepts in GitHub Actions

• Workflows: Define workflows, explaining how they are the main unit of automation.
• Events: Describe events as triggers that start workflows (e.g. opening a pull request).
• Jobs: Discuss how jobs run within workflows, specifying dependencies.
• Steps: Explain steps as the sequence of actions within jobs.
• Actions: Define actions as reusable code components.

Section 3: Setting Up Your First Workflow

• Walk readers through creating a basic GitHub Actions workflow.
  • Choose a sample use case (e.g., welcoming new contributors).
  • Show how to create a .yml file for workflow configuration.
  • Break down each part of the configuration with code snippets and explanations.

Section 4: Using Marketplace Actions

• Introduce the GitHub Marketplace as a resource for finding reusable actions.
• Show how to include a pre-made action.
• Mention best practices for verifying and choosing reliable actions.

Conclusion

• Summarize the power of GitHub Actions for automating workflows.
• Encourage readers to experiment and build custom workflows for their projects.