GitHub Process Videos for POs

[sohilpandya]

We've talked a lot about the process that a PO has to follow on GitHub and usually someone (mainly @iteles) has to walk the client through GitHub and the processes we have in place.

Have we thought about breaking it up into a few bite sized videos that we can just hand over to everyone? I have some spare time coming up soon and if we can come up with a few videos and some structure around what is important for a PO to be aware of before getting involved then maybe we can create something more visual?

Thoughts?

[iteles]

Hi @sohilpandya
This is a really interesting point, I'm glad you raised it!

A couple of times now I have attempted to record videos of the training that we do with Product Owners, both as a 30 minute block and as smaller, more topical blocks. This has come about to date in teams where a few people need to be aware of the processes but have been unable to attend the training, rather than a whole client team being trained solely by the videos.

What I have observed in both cases is that no one on the client team makes time to watch these videos. They read through https://github.com/dwyl/github-reference and even skim through https://github.com/dwyl/contributing but not the videos. They somehow seem more time consuming to them.

I think however, that done right, this could be a wonderful resource for the charity community on working with developers and with dwyl in particular.

Whereas the videos themselves might have to wait until a less slow month (as you know, September is particularly quiet for us) for us to reinvest some client project profit into the video production, I think it's absolutely worthwhile spending a day of time storyboarding and scripting this right now, whilst it's still fresh coming off the back of your current project.

Are you up for it?

[sohilpandya]

I'd love to have a go at this, can we have a 30 min initial chat and discuss some ideas before I head off on one? 😆

[iteles]

@sohilpandya thanks for the call this morning! As discussed, where we'd like to get to today:

• Quick (30 min) review of open issues in https://github.com/dwyl/github-reference & https://github.com/dwyl/contributing
• List of videos that we want to produce
• Clear content checklist for each one
• Full script for first video
• Time estimates for remaining scripts and get cracking with as many as you can
• Time estimates for full production of each video

Thanks!
Ines

[sohilpandya]

Rough layout of the videos we want to produce

Github Training for Product Owners

Introduction to the series #58 (comment)

• What we will cover in the videos?
• Who these videos are for?
• Why is this video series worth looking at?

What is GitHub #58 (comment)

• Explanation and walkthrough of the website.
• Why we use it? SSOT (single source of truth)
• Organisation
• Repos
• Readme / Documentation
• Code / Commit / PR (technical but worth knowing the jargon)

GitHub Issues

• Issues (PO's main interactions will take place here and this is where the rest of the time in the course will be spent)
• Explain it in the form of tasks as issues can be a seen as a negative term
• Mention SSOT again and explain why we work off of GitHub issues
• How to create issues? (simple issue nothing extra)

GitHub Labels

• What are labels and why they are useful.
  • Explain awaiting-review
  • please-test
  • bug very briefly
• Why we organise issues using labels

Demo Issues and Labels together

• brand new issue
• issue with awaiting review
• issue with please-test
• scenario where issue is completed (close it)
• scenario where issue needs more work (bug)
• scenario where issue is completed but you've thought of a brilliant idea or extension (new issue in backlog)

Managing Issues via Notifications

• They'll have email notifications on by default so worth talking about that
• bell for managing issues you are participating in
• Issues tab at the top level with assigned issues.

Review

• Walk through all the things we've covered in the tutorial

[sohilpandya]

Video 1

A Guide to Product Ownership using GitHub (30/45 seconds video)

script
Hey! We are dwyl and welcome to the video series on product ownership using GitHub. In this series, we'll take a comprehensive look at GitHub from a project owners perspective. We hope to answer the following question by the end of the series:

• What is GitHub?
• Why you as a product owner should be using GitHub?
• How do you maximise the potential of GitHub as a product owner?

We hope by the end of the series you can take away all the important points and implement them to improve your team's productivity and workflow. // this line is a bit sketchy, need some help with it. //

[sohilpandya]

Video 2

Intro to GitHub (3 min)
script

In this video, we'll explore GitHub in detail.

Single Source of Truth

You might be wondering why we use GitHub to manage all of our projects, well the reason is quite simple, it allows us to have a single source of truth. This means we know exactly where to look for information on any given project in the organisation, communications are transparent to the whole team and there is a full history which anyone can access. There are a whole load more reasons why we believe in having a single source of truth, I'll leave a link down below for you to find out more https://github.com/dwyl/github-reference#why

Organisation & Repositories

An organisation represents a group of people who collaborate on projects together, the example you are looking at is dwyl, Repos, which is short for repositories can be thought of as directories which hold information about individual projects. We can search for a repo using the search bar. (type in GitHub-reference)

Readme

Once we've searched and entered a repo, the first thing you'll look at is a readme file. this document will contain some of the more important information about the project, From the simple what, why, who and how to run the individual program that is being worked on. (we can be scrolling the GitHub-reference repo whilst talking)

Commits

Commits show a history of all the work that has been committed by the developers and is a source of history for what the work was and when it was committed. (for the demo, go to one of the repos where we have hundreds of commits and talk through it by giving a specific example)
@iteles what repo should be used for this?

Branch

Branching the code allows multiple people to work on the same project without having worry about overwriting another developers code. (show branches on a repo)

Pull Requests

Pull requests is another one of the more technical terms, a pull request (pr for short) allows new code to be merged from one branch to another. (show open and closed pull requests)

We've now covered the majority of what GitHub has to offer, feel free to browse repos if you don't have many repos to browse then we'll leave a few links down below for you to visit. It'll be good to get used to everything before we move onto the next video.

[Cleop]

Hey @sohilpandya - just noticed this issue, sounds great! One thing yet to be covered is milestones, probably worth going into how to create, how to add to, how to order issues within one (drag and drop). Might be relevant in the issues section or Managing Issues via Notifications as you can manage issues via the milestone view.

Where you said - How to create issues? (simple issue nothing extra) - I would make sure to include a user story, wireframes/designs and acceptance criteria

GitHub Labels - I would go through priority labels too and explain they should add them. If you feel there is time probably also worth briefly mentioning external dependency, technical and time estimates. For most labels I would clarify who adds them ie. the PO or the dev or someone else...

😍 scenario where issue is completed but you've thought of a brilliant idea or extension (new issue in backlog) 💓 💓 💓 💓 💓 💓

I think we have agreed to have a consistent intro format to our videos at dwyl - see: dwyl/video#34 (comment) This was my format for the first lines of the tachyons bootstrap videos:

(WELCOME)- Hello, my name is Cleo and I'm a developer at dwyl. This is an introduction to tachyons-bootstrap.
---followed by dwyl title slides---
Into the main video content...

This was my outro format but I don't know if it fits with a client tutorial:

(CONCLUSION)- We hope you enjoyed this video please subscribe and check out our other resources on github using the link below.

Single Source of Truth - could add "save time searching for conversations across multiple means of communication", might appeal to the client for efficiency.

[sohilpandya]

@Cleop ❤️ all the feedback! will try to incorporate all of it when I spend some more time later on in the week. 👍

[nelsonic]

@sohilpandya have you recorded/uploaded the first video?

[sohilpandya]

Hey @nelsonic,

funny you mention this, I had the voice recordings and the screens for it on my old laptop, which is now with someone. 😢 😢 😢 😢

I need to redo it. I'd done a couple of them too. 😢

[nelsonic]

@sohilpandya sad times. 😞
which GitHub "workflow" are you following? 💭

[sohilpandya]

I know.

Usually tend to follow the process that we have at dwyl, can cut some corners sometimes. But dwylbot helps that process when new people are involved.

[Cleop]

@iteles - should this be moved to the PO repo as this is designed for POs?

[iteles]

@Cleop Agreed!