Code Monkey home page Code Monkey logo

open-source-mentorship's Introduction

Next Cohort: October 15th-Dec 10th

What is an Open Source Mentor?

ProgramEquity is fostering the next generation in open source and climatetech!

Meet our fellows

Sign up to mentor here

View Our 2022 Impact Report

Open source mentors provide student fellows first hand open source experience through working on ProgramEquityโ€™s project Amplify via pair hours, career-related and technical workshops, and content labs

Is this for me?

This might be for you if you ...

  • Have patience for folks from extensive backgrounds learning curve around open source and webapps
  • Enjoy or would like to expand your knowledge of VueJS
  • Would like to contribute to open source projects impacting sustainability

Every hour of volunteeering is equivalent too 40$ in donation credits after matching. Choose a volunteer event and then choose your favorite cause you'd like to give to in Benevity.

How it Works: Volunteer with your dev, storytelling, or teaching skills

Mentors run 10 week long sessions for MLH Fellows with weekly Workshops on various engineering topics and Pair Hours where students work with mentors on the Amplify app

Choose to mentor when it fits your schedule:

  • once in a while (๐ŸŽWorkshops)
  • weekly (๐Ÿ’ปPair hours)
  • monthly (๐ŸŽฅContent Lab)
Volunteer Activity Who has done this in the past? Where can I follow up

๐ŸŽฅ Content Labs:

Help review content as fellows work on their blogs, video shorts, and developer conference talk tracks.

โฐ 2 hours a month nonrecurring
๐Ÿ—“Async or over zoom (Project board for dates)

Hubbers typically join us from Revenue, L&D, DevRel, and other parts of the org that love storytelling. Slack: #advocats-content
ladykerr
@ladykerr

๐Ÿ’ป Pair Hours:

Get on a mob zoom and help fellows navigate copilot to break down and debug tasks for fullstack and architecture like GitHub Actions. Stack: Working with APIs such as Twilio, Lob, Cicero, languages such as VueJS, Node, Express, PostgreSQL.

โฐ 1-2 hours weekly for 1 month. ๐Ÿ—“ Async or zoom Wednesdays 12-1 pm pt (Project board)

Folks join us from Engineering, Support, and Field services.
All engineering levels are welcome.
Slack: #pair-hour-mentors
wallace
@wallace
thyeggman
@thyeggman

๐ŸŽ Workshops:

Give a 1 hour presentation or demo on a technical or Career-Dev topic

โฐ 1-2 hours one-off
๐Ÿ—“ Speak on a Thursday or Friday

Check out this google drive folder for past workshop recordings and materials

Folks join us from TA, Revenue, SE, Security, and Eng.

If theres a topic on software development you've been working on or want to practice public speaking - this is a great testing ground
Slack: #advocats-enablement
therzka
@therzka

How do I get involved?

Sign up to mentor here

  1. Check out the workshops and/or pair hours schedule and reach out to the person listed in the DRI column if you have any questions.
  2. Sign up and reference the workshop or pair hour in the google form. (Youโ€™re welcome to submit a workshop you didnโ€™t see listed)
  3. (1-2 hours) Youโ€™ll be added to our #advocats-enablement channel to coordinate content and presentation partners.
  4. (30 mins) Schedule with DRI to finalize content async or via dress rehearsal
  5. (60 mins) Present day of to students

open-source-mentorship's People

Contributors

manishapriya94 avatar therzka avatar unnamedrd avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

open-source-mentorship's Issues

[Workshop] CI/CD | March 9th 12-1 pm pt

๐ŸŽค Speaker Info

Name:
GitHub Handle:
Bio:
LinkedIn:


For Speakers:

Presentation Overview

  • Demo user stories to see whats popular for reference architecture Hack Pod

Presentation Materials

  • Link to slides:
  • Link to additional resources (optional)
  • Link to post-session feedback survey (optional)

Operations

๐Ÿ”— Workshop Links

Zoom Link: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09
Eventbrite link:
Notion Card Link:


For Organizers:

Pre-workshop

  • By Feb 15th: Confirm your participation via this repo
  • Feb 20-28th: Collaborate and decide reference architecture to demo
  • Feb 28-March 5th: Finalize Deck Content
  • March 8th: Dress Rehearsal (optional)
  • March 9th: Present

Post-workshop

[Workshop] Securing Open Source Workflows feat. Snyk | March 16th, 2023

image

๐ŸŽค Speaker Info

Name:
GitHub Handle:
Bio:
LinkedIn:

๐Ÿ”— Workshop Links

Zoom Link: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09
Eventbrite link:
Notion Card Link: https://programequity.notion.site/Securing-Your-Open-Source-Workflow-with-GitHub-Security-Lab-and-Snyk-36173ea5919c4922be0ac11f16fff56f


For Speakers:

Presentation Overview

Presentation Materials

  • Link to slides:
  • Link to additional resources (optional)
  • Link to post-session feedback survey (optional)

Operations


For Organizers:

Pre-workshop

  • Speaker confirmed for the date and time with calendar invite
  • Slide content in shared drive
  • (optional) zoom poll set up
  • (optional) dress rehearsal if requested

Post-workshop

โœ๏ธ @Konny's Blog

Timeline:

๐Ÿ“‹ Adding Authentication to Amplify with Passport.js

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?
    This post is mainly for developers with Node.js and Express experience who are looking to add authentication to an application. Some understanding with sessions, encryption and authentication concepts would help.

  • If people could leave with just one action, what would it be?
    Implementing authentication is a crucial task for any application. Using Passport.js gives a balance of security, simplicity and scalability. The local strategy delivers secure password login flow, and allows the flexibility to extend authentication features for the future.

  • Were there surprises or alternative problem solving you want to give a heads up to?
    There are many other Passport.js strategies that we could have implemented. But we chose the local strategy for its flexibility, simplicity and scalability for the future. An auth middleware file was also implemented to help redirect admins to the correct pages when they are logged in. If admins are not logged in, the middleware is used to redirect them to the login page to sign in so that certain pages can be accessed.

Outline Structure:
Why is security important for any application and what do we consider when implementing it?

  • Discuss the issue and solution
  • Talk about different Passport.js strategies and why local strategy was chosen
  • Talk about middleware and why it is used with security
  • Mention issues that came with implementing the solutions

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

Hack Pod Template request

Form to fill out

Do we want this internal to org, customer or pair with fellows?
How many hours? 2-4
How many participants? We typically recommend 1 maintainer to 5 participants
What are project areas?

  • GHAS
  • Features (Copilot)
  • Actions Automations
  • Wednesday or Thursday?

What is a HackPod?
A 2-3 hour hacking session with open source fellows for customers or partners to embody the full GitHub experience and create reference architectures

[ Add picture ]
Event Roadmap

  • Set up on codespaces
  • Intro to Maintainers + Project
  • Breakout into rooms
  • Debug and Merge
  • Finalize any documentation and celebrate!

Operations:

  • Collect GitHub Handles
  • Create Copilot trials
  • Have issue tasks
  • Project Board
  • Create a repo for:
    • project board triaged by level
    • Readme with resources: maintainers, getting started with codespaces, their impact, any speakers

[๐Ÿ’ป Hack Pod] Hack on Documentation with Blacktocats 12/15?

Screen Shot 2023-02-06 at 6 52 48 AM

When

Wednesday, February 15th, 11:30 -1 pm pt
https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09
Event Details: 40-80$ of Benevity donations

What are we hacking on?

Goal: Improve Amplify's documentation and use it to provide a good model of documentation and OSS maintainership for MLH fellows

Background

As part of our ongoing Open Source Mentorship program, fellows have been working on Amplify. We'd like to clean up and organize the documentation, add some things to improve the contributor workflow, and start working on documenting the app's API endpoints and third party API usage using OpenAPI

Project Board

Project Documentation

API Documentation with OpenAPI

Issues

Draft PRs

Contributor Workflow Improvements

Resources:

โœ๏ธ @Nancy's Blog

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:

๐Ÿ“‹ 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

[Hack Pod] Documentation with Copilot with Communities Team

What is a Hack Pod?
Day of: Nov 8th 11:30-1:00 pm pt
Zoom: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09

Description
Theres always more documentation that can be added, how can new comers help any open source project and how can Copilot accelerate that? What to expect during a Hack Pod

Spec
User story: what functions, tests, or even workflows could use more explaining.

Prompt Engineering:
"what does this do" while highlighting the code
"refactor to make more readable" will add comments to the code

Resources:

  • Tests live in serve/tests
  • Frontend components live in src
  • API functions live in server/routes/apis
  • Our current workflows

Tasks: https://github.com/orgs/ProgramEquity/projects/8/views/19

โœ๏ธ @Kendall's Blog : Learning PostgreSQL on the Fly: Building and Integrating Tables, Models, and Migrations Using Knex

๐Ÿ“‹ Title: Learning PostgreSQL on the Fly: Building and Integrating Tables, Models, and Migrations Using Knex

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?
    Developers that are beginners to using/working with Postgres, those who are interested in working on Open Source projects but feel intimidated, those looking to learn new technologies but feel overwhelmed or daunted by it.
  • If people could leave with just one action, what would it be?
    It's good to put yourself in challenging situations, as sometimes that's the best way to learn and grow. Also, most things aren't as difficult as they seem. Sometimes we stop ourselves from taking on something new because we think it will be too difficult or hard, but in reality it never is that bad.
  • Were there surprises or alternative problem solving you want to give a heads up to?
    My surprise laid in the fact that the task I completed was not as difficult as I anticipated and I learned a great deal from completing it. It gave me the confidence moving forward knowing that if I want to learn a new technology, it is not so bad and it is helpful to learn by doing.

Outline

  1. Introduction
  • Brief overview of the open source project and the specific issue/task undertaken.
  • Mention the unfamiliarity with PostgreSQL and the need to learn on the go.
  1. Getting Started with PostgreSQL
  • Experience delving into PostgreSQL documentation for the first time.
  • Discuss initial challenges and key takeaways from the documentation.
  1. Navigating the Codebase
  • Exploring the existing codebase to understand the context of the project.
  • How studying other tables in the codebase helped in guiding the process.
  1. Utilizing Knex for Database Migrations
  • Introduction to Knex and its role in managing database migrations.
  • Learning how to set up and use Knex to create tables and schema.
  1. Collaboration and Feedback
  • The importance of collaboration in an open source environment.
  • Working alongside other developers, seeking feedback on pull requests.
  • It's OK to ask for help!
  1. Lessons for First-Time Contributors
  • Encouraging other first-time contributors with practical advice.
  • Sharing insights gained from the learning process.
  1. Conclusion
  • Sometimes the best growth and learning comes from throwing yourself in unfamiliar waters.
  • Most things are not as difficult as we make them out to be.
  • Reinforcing the importance of continuous learning and adaptability in open source contributions.
  1. References
  • Postgres documentation
  • Knex documentation
  • Amplify github repo

๐Ÿ“ฐ 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

[Workshop] Mock Behavioral Interviews | March 30th, 2023

We're looking for 12-15 volunteers part of the larger OSS Mentorship | Sign up by leaving a comment below:

When: Thursday, April 6th 2023
Time: 1-2 pm pt
Zoom Link: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09

Outline of session:

  • 10 mins - Advocat outlines the session and creates breakouts
  • (2) 25 min sessions between MLH Fellow and GitHub mentor
    • List of questions will be provided
    • Resume will be provided a week before

Hi Hubbers ๐Ÿ‘‹

I want to extend an opportunity for you to take part in our Git Mentored session from Advocats and Program Equity. ๐ŸŽ‰ As part of our ongoing commitment to enabling open source maintainers from all backgrounds - especially early careers - we're excited to offer an hour 1:1 micro-mentoring session. This is an opportunity for attendees and our community partners to engage with industry experts (aka Hubbers :MLH: ) on career pathing and feedback. Please note, that this is open to all Hubbers and does not require a technical background.

Who: OSS Mentors and MLH students
What: Provide attendees with an informal opportunity for mentoring via Zoom ๐Ÿ’ป

Topics Discussion Notes
Career Pathing Mentors/Mentees share their personal and professional journeys and discuss areas of interest. Provide resume feedback, ask the mentee their 3-5 year planning goals, plans to achieve their goals, and discuss skills necessary to achieve these goals; what type of training should your mentee receive to grow in this field? ย Be specific and give specific resources.

image
image

[๐Ÿ’ป ๐Ÿ” Hack Pod] Secure workflows with Security Lab + JPMC

What is a Hack Pod?

A Hack Pod is a 1-2 hour engagement between our GitHub teams and a customer/partner as we uncover places we can create reference architectures that act as starting points for customer adoption. Open source fellows (maintainers of this repo) drive the projects to completion/maintain them.

๐Ÿ—“ This Hack Pod is planned for mid-April from 12-1:30 pm PT.

What is expected of me as a participant?
On Game Day of the Hack Pod we'll convene on Zoom and then fan out in breakout rooms. Each track will have its own breakout and a few additional rooms will be available for areas customers feel passionate about.

  • Agenda:

    • Set up and intro Hack Pod
    • Hack Pod track leads go into breakouts and drive 1-2 examples based on those provided and surface others
    • Encourage and enable customers to take turns with additional examples to find the best scope for those present
  • How we hack: Each track breakout room (e.g., SCA/Dependabot) will consist of 2 leads, 2 maintainers and 6-8 customers. Maintainers are there to go 1:1 as needed in extra rooms.

  • Roles:

    • Leads:
      • We will pick a track from what we are hacking on to enable customers. Role: Write out answer keys for 1-2 tasks below before Hack Pod. Drive the examples Game Day of the Hack Pod.
    • Customer: JPMC
      • Adds questions to issues which help us make a robust starterkit asset post Hack Pod

What are we hacking on?
This Hack Pod focuses on jumpstarting JPMC's understanding of security through the following:

Diagram of context for customers

image

Resources:

159093687-6fc90733-0599-445c-b08b-a6378d988e4b.mov

Timeline:

  • Confirm which tracks we'd like (March 8)
  • Rep + AppSec specialist confirm use cases (March 15)
  • Build out keys for a few use cases in issues (March 15th-April until 1-2 weeks prior to Game Day Hack Pod)
  • Put it together into an enablement deck for Hack Pod participants (First half of April)
  • Hack Pod Game Day off! (TBD last half of April)

โœ๏ธ @Naj's Blog

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:

๐Ÿ“‹ 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

โœ๏ธ @Teri's Blog

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:

๐Ÿ“‹ 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

[Workshop] Resume Review | Feb 29th, 2024

We're looking for 12-15 volunteers part of the larger OSS Mentorship | Sign up by leaving a comment below:

When: Thursday, Feb 29th, 2024
Time: 12:15 - 1pm PST
Zoom Link: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09

Outline of session:

  • 10 mins - Recruiter outlines the session and creates breakouts
  • 35 min breakout sessions between MLH Fellow and GitHub mentor
    • List of questions will be provided (see below)

Hi Mentors๐Ÿ‘‹

I want to extend an opportunity for you to take part in our Git Mentored session from Advocats and Program Equity. ๐ŸŽ‰ As part of our ongoing commitment to enabling open source maintainers from all backgrounds - especially early careers - we're excited to offer an hour 1:1 micro-mentoring session. This is an opportunity for attendees and our community partners to engage with industry experts (aka Hubbers) on career pathing and feedback. Please note, that this is open to all Hubbers and does not require a technical background.

Workflow:

  • ProgramEquity mentor gives quick intro about resume best practices and sets up breakout rooms
  • Fellows are matched with mentors in breakout rooms:
    • Mentors/Mentees share their personal and professional journeys and discuss areas of interest.
    • Provide resume feedback, ask the mentee their 3-5 year planning goals, plans to achieve their goals, and discuss skills necessary to achieve these goals; what type of training should your mentee receive to grow in this field? ย Be specific and give specific resources if you can.

image

โœ๏ธ @beverand's Blog

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:

๐Ÿ“‹ 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?

Topic for blog post
Adding Auth0 to the Amplify app

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
  • paragraph compare your solution
  • paragraph impact your solution
  • Less than 600 words
  • Drop link to your google doc (with permissions for edits) in review issue

https://docs.google.com/document/d/e/2PACX-1vS9YHEBTmadiFZCLAp8OvkYw6HC8gk3nbe3VdYbM8cDKLZRpBYofUGkM7EQZVrM_0h8QrouzduSKRgs/pub

โœ๏ธ @Tenicka's Blog

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:

๐Ÿ“‹ 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

โœ๏ธ @Alex-is-Gonzalez Blog

Outline Below Ready For Review

Title: How to Welcome first-time contributors to your repo and why it is important to do so

  • What is a Welcome Message?
  • Why use Welcome Messages?
  • How to create Welcome Message?
  • What is Github App?
  • Configure yml
  • Testing
  • Summary and call to action

To Do: when you complete the requirements, add "outline ready" label on your issue

  • [ X] Identify your topic from one of the PRs approved (Getting started with Actions #457)
  • [X ] Outlining bullet points of blog roadmap
  • [ X]s your blog a List, Survey, or demo? (Demo)
  • [ X] Which Visuals or Diagram or Code snippets will you add (yml code snippets )
  • [ X] References to resources (ref to GitHub actions, maybe additional resources to learn yml?)

Timeline:

To Do: when you complete the requirements, add "outline ready" label on your issue

  • [ X] Identify your topic from one of the PRs approved (Getting started with Actions #457)
  • [X ] Outlining bullet points of blog roadmap
  • [ ]X Is your blog a List, Survey, or demo? (Demo)
  • [ X] Which Visuals or Diagram or Code snippets will you add (yml code snippets )
  • [ X] References to resources (ref to GitHub actions, maybe additional resources to learn yml?)

๐Ÿ“ฐ 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

[Hack Pod] Copilot for getting started with Actions

Spec

User story: what kind of Action would make people more welcome to this project with either

  • helpful prompts or reminders
  • help us communicate better
  • coordinate some of the project's details

Resources:

Tasks:

Collaboration : Including communication and engagement tools


Target Date:

2022-02-22
Maintainers for reference are assigned
Pair Hour Mentors: assign yourself in each task when its ready to review

Resume Review 3/30

Hi Hubbers,

We're asking your participation in an hour workshop. We are looking for 12-16 volunteers who can give actionable feedback to our early career open source fellows - count towards volunteer hours in Benevity!

Day of event: Thursday 12-1 pm pt

  • 15 mins: TA covers a checklist of 'haves' and have nots for Engineering resumes
  • 45 mins: GitHub mentors have breakout with Open source fellows to provide feedback (15 minutes with each fellow
    image

Please sign up by dropping your name in comments, if you'd like to be part of additional workshops or pair hours - fill out this form

What to expect once you sign up (by mid March):

  • We'll confirm you with a calendar invite
  • Resumes of fellows will be provided
  • A small guide for conversations

Join slack channel #octo7-advocats and make sure to watch this repo! Here's how to log hours in Benevity to get donation credits

โœ๏ธ @Eduardo's Blog

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:

๐Ÿ“‹ 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

[Workshop] Documentation For Open Source Projects | February 9th, 2023

โœ๏ธ @_joey_ma's Blog

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

This is a draft to be worked on further.*

Resources:

Timeline:

๐Ÿ“‹ Blog Outline:

I think I'm going to go with Idea No. 2 and save Idea No. 1 for another day, but just keeping it here as notes (it was the first idea that came up).

Idea No. 1:

Topic: What makes good documentation?

Inspired by Documentation for Open Source Projects

Start

Intro paragraph:

Middle

Helpful examples/concepts:

End

Summary:

  • Know your personal preference
  • Knowing the different types of documentations could help you approach different styles of docs more effectively
  • When writing your own documentation, help create clear, helpful documentation for your audience

Additional Resources:

Idea No. 2:

Topic: TDD: Creating tests for Stripe

Inspired by Test Driven Development with Stripe
Also this is an issue that I'm working on and what I'm hoping to be more familiar with

Start

Intro paragraph:

  • What is TDD? (short intro)
  • What is Stripe?
  • Let's write some tests for Stripe!

Middle

End

Summary

  • As a best practice in testing, we want to test our code, not necessarily imported code. Ideally, test cases written by the vendor should cover testing for their code. In this case, Stripe as our payment processing platform allows us to rest assured that we only need to test our implementation/integration.

Additional Resources:

Hashtags?

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?
    • Someone who may be in similar situation as myself: any developer who is open and eager to learn new technologies, but I'd love to help make the process easier for others.
    • Ideally I'd like to be article to be friendly to those who are new to the SWE journey, but I also like to write concisely, and they can always continue reading the additional resources if there are specific things they don't understand.
  • If people could leave with just one action, what would it be?
    • Good question... Go and incorporate this in your current project?
  • Were there surprises or alternative problem solving you want to give a heads up to?
    • To be determined? Maybe include versioning for how I am setting things up and remind readers that official docs should be the most up-to-date resource, but hopefully this article helps them to get started

Sample Topics for your blog post

  • Creating tests for Stripe
  • 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 I'm still working on the PR
  • Outlining bullet points of blog roadmap
  • Is your blog a List, Survey, or demo? Demo
  • Which Visuals or Diagram or Code snippets will you add? All the above ๐Ÿ˜‰
  • References to resources

Draft: How to test a Stripe API (with permissions to comment)

๐Ÿ“ฐ 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

โœ๏ธ @Maye's Blog

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:

๐Ÿ“‹ 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

โœ๏ธ @Julie's Blog

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:

๐Ÿ“‹ 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

[Workshop] Feature Management for your App's Deployments feat. LaunchDarkly | March 9th, 2023

March 9th 1-1:30 pm pt | March 10th 8-8:30 am au

Screen Shot 2023-03-06 at 8 19 47 PM

๐ŸŽค Speaker Info

Name: Chitra Kapoor
GitHub Handle:
Bio: Solutions Engineering at LaunchDarkly
LinkedIn: https://www.linkedin.com/in/chitra-k

๐Ÿ”— Workshop Links

Zoom Link: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09
Notion Card Link: https://programequity.notion.site/Feature-Management-with-Deployments-with-LaunchDarkly-061fc508716144cbb6587c7776343c33


For Speakers:

Presentation Overview

  • Why is product testing or monitoring important?
  • Feature management
  • Feature flags
  • Setting up layered environments

Presentation Materials

Operations


For Organizers:

Pre-workshop

  • Speaker confirmed for the date and time with calendar invite
  • Slide content in shared drive
  • (optional) zoom poll set up
  • (optional) dress rehearsal if requested

Post-workshop

โœ๏ธ @Mason's Blog

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:

๐Ÿ“‹ 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

โœ๏ธ @Jimmy's Blog

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:

๐Ÿ“‹ 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

3/10 Content Lab: Give feedback on Shorts

We need 10 volunteers total ๐Ÿ’ฅ (Comment below to sign up)

Collaborate via zoom breakouts with fellows in a live workshop https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09
Screen Shot 2023-02-28 at 10 06 16 AM

  • What responsibilities do volunteers have?: Provide feedback to fellows new to open source and DevRel and ship a 30 second storyboard
  • Who should participate?: Great for Hubbers across Revenue, Documentation, Enablement, DevRel, Solutions Engineering, and other storytellling roles
  • Why participate?: Volunteer as a mentor. Earn 20$for Benevity donation credits for GitHub Gives!

Live Workshop with Fellows ๐Ÿ—“ 3/10 Friday from 9-10 am pt

Once you sign up by commenting below, we'll confirm you with a calendar invite and add you to #advocats-content

Program Agenda

  • 15 min overview byย @blackgirlbytesย andย @LadyKerr
  • 30-45 mins to review and provide feedback in breakout rooms with fellows. Proposed Conversation Flow:
    • Introduce yourself and background, ask fellow to do the same

    • Ask about what has been exciting to contribute to? (Potential topic)

    • Goal: create aย 30 second story board. Here's a checklist:

      • ย Intro hook or call-to-action happens in first 3 seconds
      • ย Background audio or music (reels jingle, trend, or narration)
      • ย Props or green screen usage
      • ย Transitions between scenes in storyboard
      • ย Dialogue or captions to provide context for what's happening in a scene

2/1: Developing better with Copilot

image

Overview

  • (first 5) Manisha intros Mashrur and how to think through a problem flow
  • Feature - GitHub Copilot, what is it? - GitHub Copilot is an AI based pair programmer. It comes as an extension in Visual Studio code, Visual Studio, Neovim, JetBrains IDEs.
  • Advantage - what does Copilot do? Help us think through problems with side by side suggestions. Perhaps talk about how people would look through a problem on Stack Overall. The user has to start writing code or write comments describing what they want the code to do to engage Copilot.
  • Benefit- How AI Copilot can help facilitate writing cleaner code faster. Since it draws context from comments and code, it can "learn" the users ways and suggest anything from individual lines to whole functions instantly.

[Presentation Content ]

// function to generate a random number
// start typing 
function randomNum() // to see copilot jump into action
// You can hover over the suggested code to accept the solution or seek more solutions if available.
// That's one way, you can also start typing comments directly
// write a function to multiply 2 numbers
function multi // and it should come up with auto suggestions
// Let's say we want to accept the suggestion and also write the output to console:
console.log // And it'll auto complete it for me, you can run it from the terminal node index
// We can switch to something a little more fun. There is always a need to work with dates:
// create a function to get current date
function getData() { // accept and wait a bit after hitting return
// it gets a nice output format for us too with additional information
// let's log it by starting to type 'console.log' or comment write output to console 
// Now letโ€™s say we wanted to get yesterdayโ€™s date, start writing the comment // output 
// the current date
// The completed sequence would look like below:
// create a function to get the current date
function getDate() {
    var date = new Date();
    var day = date.getDate();
    var month = date.getMonth() + 1;
    var year = date.getFullYear();
    return day + "/" + month + "/" + year;
} 

// output the current date
console.log(getDate());
// run it from the terminal by typing node index
// Let's improve on this. Now we want a function to get yesterday's date
// type: //create a function to get yesterday's date
// Accept 'tab' through each line
// Now after output of current date just start the comment with // and it'll automatically
// write out the comment to get yesterday's date. This is an example of Copilot
// learning the context and synthesizing the suggestions based on context
// Now let's try updating the format of the output for current date
// output the current date
console.log("Today's date: " + getDate());
// output the yesterday's date
console.log("Yesterday's date: " + getYesterday());
// Notice the only code I have written so far is this, rest were all generated by Copilot
// Including format of the dates
// Ok so what if we wanted to update the format, but I don't want to look up
// JavaScript syntax?
// Start typing: // print the date in format or just // after console.log to see the magic
// Then perhaps output yesterday's date in different format, just type //. What happens?
// Magic, it seems like Copilot knows what I want as soon as I start thinking about it
// Completed sequence looks like below:
// output the current date
console.log("Today's date: " + getDate());
// output the yesterday's date
console.log("Yesterday's date: " + getYesterday());
// output the current date in a different format
console.log("Today's date: " + getDate().split("/").reverse().join("-"));
// output the yesterday's date in a different format
console.log("Yesterday's date: " + getYesterday().split("/").reverse().join("-"));
// Ok let's try something different
// Story: I returned from a trip to Europe recently and the temperatures there were
// all in degrees celsius. So I'd hear 34 degrees today, or 36 degrees today
// but to me all it meant was hot, I didn't know exactly how hot. I could use a temperature
// converter to convert celsius to Fahrenheit and then I'd know.
// So let's build it, start typing the comment below:
// convert celcius to fahrenheit
// Accept the suggestions, then write another comment to output the result
// Accept the suggestion and run it to see it in action
// Wow 34 degrees is 93.2 and it was humid, no wonder I was melting
// Let's try 37 which was the max I faced.
// Yup, pretty hot.
// Let's try something different. Let's say I wanted to generate some data, but I didn't
// know what to start with, and I don't want to think. I want to be guided
// just to get it going, let's try, write the comment below:
// Generate some random data
// Accept the way through
// Write a comment to output the data
// Aah, I see I have an array of 100 random numbers. Interesting
// So this gives me an idea
// What if I wanted to create an array of names? Maybe I want to work with strings
// Let's try create an array of names, accept the change
// Great! 
// output a random name from the array? Try it
// run node index from the terminal to see results
// Ok, that's just 4 names, ok I'm running out of ideas, so if I want to remain 
// in this coding mode, maybe a function? 
// Let's see what Copilot thinks I would want to do next?
// Start typing // create a function in the next line
// Wow nice, it's formalizing the process for me. It seems the next logical
// step given I'd want this process to be repeatable to package this 
// in a function, let's try, nice!
// Now let's create an array of numbers
var numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
// create an array of colors
// Ok now what's interesting here, is notice it's choosing var by default for me.
// Let's say I want to use const instead of var. Let me go ahead and make that 
// change. Now let's create another array of words.
// Notice what happened, Copilot changed it's suggestion and came up with
// const, instead of var. It's learning my style on the fly, based on the context 
//Let's try again with numbers, the suggested response should 
// be as below:
// create an array of numbers
const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
// You can extend this to classes as well. For simplicity let's create a calculator
// class, accept through a few methods, when you want to stop, start typing class
// create a calculator class
// add a method to add two numbers
// add a method to subtract two numbers
// add a method to multiply two numbers
// add a method to divide two numbers
// Now you see the suggestion has the 4 methods that my comment specified
// You can use it
// The completed sequence looks like below:
// create a calculator class
// add a method to add two numbers
// add a method to subtract two numbers
// add a method to multiply two numbers
// add a method to divide two numbers
class Calculator {
  constructor() {
    this.value = 0;
  }
  add(num) {
    this.value += num;
  }
  subtract(num) {
    this.value -= num;
  }
  multiply(num) {
    this.value *= num;
  }
  divide(num) {
    this.value /= num;
  }
}

// create a new instance of the calculator class
const calc = new Calculator();
// add two to the calculator
calc.add(2);
// output the result
console.log(calc.value);
// subtract 5 from the result
calc.subtract(5);
// output the result
console.log(calc.value);
// checkout action from marketplace autolabel
// build workflow and fill in auth pieces 
So that concludes our first look at GitHub Copilot. Any questions?

References:

Copilot docs - includes getting started
Copilot feature page
Copilot GA post


Are we workshop ready?

  • Speakers confirmed for the date and time with calendar invite:
  • Slide content
  • Poll in zoom
  • (optional) dress rehearsal if requested

[Hack Pod]: Actions for Dependabot

Day of

Time: November 15th 1:30-2:30 pm pt
Zoom: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09

Description

Open source maintainers try the best they can, actions are automations that can add workflows that bring us together in our collaboration. Thats the theme as we ramp with the tasks below.

Spec

User story: what kind of Action would make people more welcome to this project with either

  • helpful prompts or reminders
  • help us communicate better
  • coordinate some of the project's details

Resources:

Tasks:

Collaboration : Including communication and engagement tools


Day of Logistics

[Content Lab] Async Review Fellow's Blogs - Review between 4/5-4/14

Screen Shot 2023-03-01 at 7 51 11 AM

We are looking for 10 Hubbers to give async reviews on fellow's first blog drafts. (comment below)

  • What: Read less than 500 words, fill out a google form, and leave a min of 2-3 comments.
  • Who: Great for Hubbers across Revenue, Documentation, Enablement, DevRel, Solutions Engineering, and other storytellling roles
  • Why: Earn 20$ for Benevity donation credits for GitHub Gives while providing feedback to fellows who are finding their voice for the first time in open source

โžก๏ธ Sign up flow:

  • Sign up commenting on this issue
  • We'll confirm By adding you to the table below + calendar invite and reminder in #advocats-content

๐Ÿ’ป Async: Volunteer at your pace(๐Ÿ—“๏ธ Drafts released 3/17, Review by 4/10)

How to review async

1. Rough Draft

  • Go to their draft based on the table's link you're tagged in
  • Point out any grammatical or conceptual additions via a minimum of 2-3 comments.
  • After reading - submit your overall thoughts via google form

Mentor sign up table

Fellow & Topic Reviewer 1 Reviewer 2
@rsensenig brainstorm

Rough Draft

@lclindeman @ktravers
@SAUMILDHANKAR brainstorm

Rough Draft

@ghostinhershell @mscoutermarsh
@yoyoyojoe brainstorm

Rough Draft

@lclindeman @mscoutermarsh
@Alex-is-Gonzalez brainstorm

Rough Draft

@UnicodeRogue @GreCodes
@beverand brainstorm

Rough Draft

@ghostinhershell @ktravers
@masmei brainstorm

Rough Draft

@UnicodeRogue @GreCodes

Resources:
Onboarding Deck

[Workshop] APIs 101 feat. Postman | February 16th, 2023

โœ๏ธ @Rachel's Blog

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:

๐Ÿ“‹ 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
  • paragraph compare your solution
  • paragraph impact your solution
  • Less than 600 words
  • Drop link to your google doc (with permissions for edits) in review issue

[Workshop] Test Driven Development feat. Stripe | February 23rd, 2023

โœ๏ธ @Christy's Blog

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:

๐Ÿ“‹ 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

[Workshop] CI and CD with GitHub Actions Across Clouds | April 13, 2023

image

๐ŸŽค Speaker Info

Name:
GitHub Handle:
Bio:
LinkedIn:

๐Ÿ”— Workshop Links

Zoom Link: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09
Eventbrite link:
Notion Card Link: https://programequity.notion.site/CI-and-CD-with-GitHub-Actions-across-Clouds-b01a7ce28ef34e2cbbe110d23ff456cc


For Speakers:

Presentation Overview

  • Demo user stories to see whats popular for reference architecture Hack Pod

Presentation + Demo Materials

  • Link to slides:
  • Link to slides:
  • Link to additional resources (optional)
    • Demo materials #15
  • Link to post-session feedback survey (optional)

Operations


For Organizers:

Pre-workshop

  • Speaker confirmed for the date and time with calendar invite
  • Slide content in shared drive
  • (optional) zoom poll set up
  • (optional) dress rehearsal if requested

Post-workshop

[Workshop] HIPAA: Oauth and Access Controls | March 23rd, 2023

๐ŸŽค Speaker Info

Name:
GitHub Handle: @joenicastro @teakopp
Bio:
LinkedIn:

๐Ÿ”— Workshop Links

Zoom Link: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09
Eventbrite link: https://www.eventbrite.com/e/hipaa-oauth-access-controls-tickets-532731964647?aff=ebdsoporgprofile
Notion Card Link: https://programequity.notion.site/HIPAA-Oauth-Access-Controls-af5b1b94be174bafa661817a76c14bd7


For Speakers:

Presentation Overview

Presentation Materials

  • Link to slides:
  • Link to additional resources (optional)
  • Link to post-session feedback survey (optional)

Operations


For Organizers:

Pre-workshop

  • Speaker confirmed for the date and time with calendar invite
  • Slide content in shared drive
  • (optional) zoom poll set up
  • (optional) dress rehearsal if requested

Post-workshop

โœ๏ธ @Naj's Blog

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:

๐Ÿ“‹ 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

[Hack Pod]: CD with GitHub Actions to AWS (drop a comment to sign up)

Sign up by dropping a comment

Goal:

Create reference architecture with potential workflows with AWS

Screen Shot 2023-04-13 at 1 31 08 PM

Teams that are scoping issues and weighing in on implementation guides:

Will ship from scoped issues

Problem statement expanded:

  • To connect developer experience to the right compliance supported cloud - we are modeling deployment strategies for both single and multi-cloud structures. The end vision will be similar to stacks in the ProgramEquity open source repo.

Admin items:

  • Mid Feb: Finalize SAs (2-3 from each org) and any standup cadence
  • End of Feb: Finalize Deployment Actions for Workshop (Ask FSI customers common workflow user stories)
  • Till mid March Build out keys for Actions for fellows to implement
  • April 13th: Collect any additional user stories from webinar workshop

[Workshop] Securing Your Open Source Workflow with GitHub Security Lab, Sonatype and Snyk | March 16th, 2023

For Speaker(s):

Speaker info

Liran Tal

Name: Liran Tal
GitHub Handle: @lirantal
Bio:

Liran Tal is an award-winning software developer, security researcher, and open source champion in the JavaScript community. He's an internationally recognized GitHub Star, acknowledged for his open source advocacy, and has received the OpenJS Foundation's Pathfinder for Security for his work on Node.js security. His contributions to developer security education include leading OWASP projects, building supply chain security tools, participation in CNCF and OpenSSF initiatives, and authoring books such as O'Reilly's Serverless Security. He leads the developer advocacy team at Snyk.io and is on a mission to empower developers with better application security skills.

LinkedIn: https://www.linkedin.com/in/talliran/

Speaker Name

Name:
GitHub Handle:
Bio:
LinkedIn:

Workshop Links

Zoom Link: https://github.zoom.us/j/97013759503?pwd=aDd5NmNKQTNsbGlLQWhuSm4vVEFGdz09
Eventbrite link: https://www.eventbrite.com/e/securing-your-open-source-workflow-with-github-security-lab-and-snyk-tickets-532730861347?aff=ebdsoporgprofile
Notion Card Link: https://programequity.notion.site/Securing-Your-Open-Source-Workflow-with-GitHub-Security-Lab-and-Snyk-36173ea5919c4922be0ac11f16fff56f

Presentation Overview

Presentation Materials

  • Link to slides:
  • Link to additional resources (optional)
  • Link to post-session feedback survey (optional)

Operations


For Organizers:

Pre-workshop

  • Speaker confirmed for the date and time with calendar invite
  • Slide content in shared drive
  • (optional) zoom poll set up
  • (optional) dress rehearsal if requested

Post-workshop

Mock Interview workshop 4/6

We're looking for 12-15 volunteers part of the larger OSS Mentorship | Sign up by leaving a comment below:

When: Thursday, April 6th 2023
Time: 1-2 pm pt

Outline of session:

  • 10 mins - Advocat outlines the session and creates breakouts
  • (2) 25 min sessions between MLH Fellow and GitHub mentor
    • List of questions will be provided
    • Resume will be provided a week before

Hi Hubbers ๐Ÿ‘‹

I want to extend an opportunity for you to take part in our Git Mentored session from Advocats and Program Equity. ๐ŸŽ‰ As part of our ongoing commitment to enabling open source maintainers from all backgrounds - especially early careers - we're excited to offer an hour 1:1 micro-mentoring session. This is an opportunity for attendees and our community partners to engage with industry experts (aka Hubbers :MLH: ) on career pathing and feedback. Please note, that this is open to all Hubbers and does not require a technical background.

Who: OSS Mentors and MLH students
What: Provide attendees with an informal opportunity for mentoring via Zoom ๐Ÿ’ป

Topics Discussion Notes
Career Pathing Mentors/Mentees share their personal and professional journeys and discuss areas of interest. Provide resume feedback, ask the mentee their 3-5 year planning goals, plans to achieve their goals, and discuss skills necessary to achieve these goals; what type of training should your mentee receive to grow in this field? ย Be specific and give specific resources.

image
image

Comment below to sign up

๐ŸŽ™ @Teri Tech Talk

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:

๐Ÿ“‹ 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

โœ๏ธ @Brian Segura's Blog

  • ๐Ÿ“ฐ Dec 8th have rough draft in
    • Mentor reviews by 12/15
  • Dec 15th-20th turn in final draft

Title: Passport.js, a security solution for small startups and large enterprises alike.

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?

    • People interested in security or working/learning with Passport.js.
    • They can be anywhere in their journey because security can always be used. From your first full-stack app to enterprise-level software
    • They need to understand why I am writing about Passport.js and what it's even used for.
  • If people could leave with just one action, what would it be?

    • The one action I would encourage them to take is to watch the massively long 12 hour video (maybe I wouldnt tell em its 12 hours lol) that dives deeply into passport.js and user sessions. I would do this because the mentor (Go Glenn!!) for this epic recommended it and it is where I believe the answers lay.
  • Were there surprises or alternative problem-solving you want to give a heads up to?

    • This whole experience has been surprising and full of problem-solving and I love it lol.

Outline

Talking points

Why does software need security/authentication/authorization?

  • Establish the specific problem the team at Amplify faced at the top of the blog and then show the solution at the bottom of the blog
  • List some other security options and why Passport came out on top
  • Give a TLDR of the moving parts involved
  • List off a couple of the Strategies that can be easily integrated from Passport
  • Mention how this was your first time contributing to open source and the pressure was on
  • Explain how pressure is what makes us grow
  • Reference issue/PR for photos
  • Add some cool media
  • Consider using text to voice. Use table of contents.

To Do: when you complete the requirements, add "outline ready" label on your issue

๐Ÿ“ฐ 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

โœ๏ธ @Saumil's Blog

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:

๐Ÿ“‹ 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

[๐Ÿ’ป Hack Pod]: Actions for CD with LaunchDarkly

Goal: Demo how to build feature flags and GitHub Actions that deploy with LaunchDarkly

Date: Wednesday, 6/15 12-1:30 pm pt

Resources:

Use cases for reference architecture

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.