Please add your name to the authors document...
We will walk you through the steps on the big screen...

Add, if it is not already there, a place where the students submit a pull request that does not have anything to do with code.

The benefit of this is that they get to submit a pull request earlier in the day and can do so without having to wrap their head around any code, etc.

Each of the Major Section Pages has a time-box section that is generally unnecessary due to the very short amount of material to cover. These pages are affected:

environment_overview.md
pre_req_overview.md
git_overview.md
github_overview.md

Remove the time box.

git_common_operations.md does not have a green sticky at the end

@seawolf42

In our git lesson, we don't have
git pull
as a precursor to
git merge
so that users can compare changes to the upstream against their changes.

Do we want to include this?
OR
Leave that as a learning curve experience for the student?

Please advise.

Will want to do this item pretty close to last, in prep for Saturday, so that we capture all the right steps, with the right links, right verbiage, etc.

Why do we need this change? The current workflow pattern won't work, as intended...

every lesson asks the students to work on one project (generic) during the lecture AND a separate project during the hands-on (rpncalc).

this involves potentially switching virtualenvs back and forth, back and forth and if students are in the wrong folder/virtualenv they will mix codes bases and chaos will ensue.

SO:
move all hands-on material to one of the later lessons >> i.e lesson 7 OR 8 so that once the students have gone through the lessons/demo...
they can then start on doing all the hands on steps can be seen at once and in rapid sequence.

Add some steps for users to follow to get their virtual env set up.

Change the authors.md listing to be a list.

* author 1
* author 2

provide a summary list of example functions for students to possibly work on
having a ready made list of example functions available when we kick off the last big hands-on section will shorten the talk track and give students something to jump into right away.

Confirm that the bottom navigation on every page really does go to the right place.

Sections

• Up should go to table of contents
• Prev should go to last lesson of previous section
• Next should go to first lesson of this section

Lessons

• Up should go to section page
• Prev should go to previous lesson (or section page if first lesson in section)
• Next should go to next lesson (or next section page if last lesson in section)

I would like to use a slightly different green sticky.
Suggest some green stickies and we can find one that looks a bit better.

It should be possible to suggest links OR attach files to this thread until we come up with one that looks cool.

The ideal solution will be to rename the file so it can be a drop-in replacement requiring no changes to any of the files.

Looking for files/graphics that are creative commons OR licensed for open source use.

Right now the TOC is missing at least a few pages that can be reached from the bottom navigation (for example, Pull Request Tips and Tricks is not referenced in the TOC).

Merge the Calculator and Lesson Content into a single repo.
This should:

• reduce some confusion
• eliminate some of the talk track
• speed things up so we can get to the hands-on sooner

Right now, the github overview covers two factors of the github workflow:

• forks
• pull requests

The git overview then covers the git workflow of:

• cloning
• pushing

I suggest that we break the github workflow into two parts and bookend the git overview, so that the attendees get a smoother view of how a real workflow works:

github overview, part 1

• forks

git

• cloning
• pushing

github overview, part 2

• pull requests

Add some steps on installing conda in the virtual environment section

Add a final section/file (i.e. section 6).

Include some commentary about the reality of supporting sprints:

this blog article has some very good ideas... https://treyhunner.com/2019/04/making-the-most-of-the-pycon-sprints/

Some ideas include:

• leaving a group to work on a different sprint is OK
• approaching a group and asking them to describe their project is OK
• asking the project developer is OK >>> in fact, more than OK. In most cases, they have allocated their time to welcoming and helping new sprinters ... you aren't bothering them... you are giving them something to do.

Suggest conclusion.md as a filename

The general idea is to leave the attendee with:

• a nice conclusion to the workshop
• some encouraging words
• sage advice

NOTE: this will also require an edit to the table of contents file: toc.py

Add concrete examples of steps to take using git - the point is less about full explanations of each step and more about giving someone a quick and dirty look at the totality of the process.
things like:
config your git
add upstream
create branch
checkout branch
pull changes to master
add files
commit changes
merge branch
push to github
issue pull request

In Windows 7 under PowerShell, git doesn't appear to like this filename as shown below. What do you think about renaming this to "random_thoughts..." to see if that fixes it?

C:...\sprintintro\intro_to_sprinting>git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add/rm ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)

    deleted:    random thoughts...

Untracked files:
(use "git add ..." to include in what will be committed)

    random thoughts

no changes added to commit (use "git add" and/or "git commit -a")

On the overhaul branch:
on this page the note/warning comes after the steps to perform. Move the note about ensuring that you change the name of the repo in the path to match your own repo to a place before the step.

It might be clearer to start with a clone rather than a fork..

We could perhaps then talk about setting the upstream as different from the origin THEN talk about making forks in github

No sticky note on the Branching and Merging section.

add some short commentary to parallel the sections in the virtual environment page about git:
include section headers and highlevel overview, etc.

Add examples of using git diff to the lesson.
Also, add if not already present, some examples of using git status to see the changes to the repo

UPDATE:
provide multiple instances in the material where git status can help the attendees begin to better understand the status of their repo.

• before the make any changes
• after they make changes to a file
• after they add a file to the repo
• after they commit a file to the repo
• etc

Also identify places where git diff can be beneficial i.e. when attempting to understand how your material conflicts with a change to the upstream repo material.

After changing the upper 'B' to lower 'b', there are no instructions for the user to move fwd with this update after 'git diff.' Suggest that either you tell the user to "git checkout" to wipe the change, or ask them to review their commit skills from the previous lesson to submit it (then later revert back to the correct version with the upper 'B').

The Deep Dive section of github_submit_pull_request.md is currently empty.

Some ideas for content include:

• why to do a pull req from a given branch versus master
• formatting of pull req messages
• the importance of trying to do a fetch/pull prior to submitting your pull request so that your PR is as close to clean and merge-able as possible.
• etc

Add a link to a basic "command line tools" tutorial or two (*nix and Windows) for the prerequisites section of the README.md
cd
mkdir
ls / dir
etc

Typo (update) from Python 3.5 to 3.6.

We need to find a place to elaborate for the student on the typical purpose of README.md files.

In that file, we need to add a sentence OR three on why projects have README.md files and how projects displayed on github benefit (i.e. github auto displays the file as the project summary on the main page of any given project).

This pages seems like a good candidate:
https://github.com/chalmerlowe/intro_to_sprinting/blob/dd81d26f9f5a029f7207df7654d9643228f5e2e0/class_materials/github_concepts.md

Add appropriate links.
Provide summary statements for any links without such statements.

Each of the resources sections should have good resources and each resource should have a link and a brief summary of what students should expect to find when they click on the link.

Several examples:
in the git_config.md file there are two incomplete resources:

• Cheatsheet for Windows command-line commands:
• Cheatsheet for Mac command-line commands:

NOTE: there are two links to cmd/terminal commands included in
prereq_student.md

Ensure that we point students to the right direction and either duplicate the links here OR find some way to deconflict.

in the [git_overview.md] (https://github.com/chalmerlowe/intro_to_sprinting/blob/master/class_materials/git_overview.md) file there appear to be links that do not have a description.

There are assuredly more examples of incomplete resources.

Please make sure all hyperlinked items open a new window.

The screen capture images for lesson_06 refer to merges to the intro to sprinting repo. They should instead be screen caps that show references to the codeless project.

the size, etc of the screen captures is fine. Would just prefer that they point to the codeless project.

The main README.md file should be revised to more fully explain the project:

• There are sections that are not complete
• There are sections that need to be revised
• There may be material that needs to be added, deleted, etc
• IF not present, add more detail on what a "sprint" is.

Suggest the following changes and renaming to the broad layout/structure:

• lesson one: introduction (ie. welcome students, help them understand the workshop and what we will accomplish) - lesson_01_workshop_intro.md
• lesson two: tools for sprinting (introduce the tools to be used and install them) - lesson_02_tool_installation.md
• lesson three: virtual environments overview - lesson_03_venv_overview.md
• lesson four: github overview - lesson_04_github_overview.md
• lesson five: git overview - lesson_05_git_overview.md
• lesson six: project overview - lesson_06_intro_to_the_project.md
• lesson seven: contributing hands-on - lesson_07_hands_on.md

Add pic of dependencies to highlight why virtual envs are import.

py 2.7 <- library 2.3 <- other_library 2.4

py 3.6 <- library 1.7 <- different_library 1.3

py 3.6 <- random_library 1.5 <- different_library 1.2

Right now, the table of contents has two links on the overhaul branch related to github, that need some work:

https://github.com/chalmerlowe/intro_to_sprinting/blob/overhaul/class_materials/github_setup.md
https://github.com/chalmerlowe/intro_to_sprinting/blob/overhaul/class_materials/fork_a_repo.md

Right now, the github setup page has the content needed in the fork_a_repo page.

ACTION: decide on whether we need two pages OR not.
IF yes, then migrate the right materials to each page.

feel free to discuss here.

On the overhaul branch, this page talks about setting up git.
Add some verbiage to describe the fact that the git config, in this case is a global config for all git projects on your machine as opposed to a git config for this project.

There are already some good roadmaps for aspiring Python developers including:

• Google's Technical Development Guide
• The Open-Source Computer Science Degree
• The Open Source Data Science Masters - Curriculum for Data Science

I would like to develop a roadmap for the "DevOps" track and am looking for input. Any ideas/suggestions welcome to jamesrsmalloutlookcom.

Edit this sentence in prereq_student.md

"In the hands-on practice session, you will be using command-line tools to contribute to a practice project, namely a calculator."

Include a reference to a practice project that has no code and a programming oriented project...

create a bare-bones menu framework that future students will use.

MAJOR REWORK:

We are gonna revise all the content from top to bottom to fit a new delivery model and template based loosely on this layout:

For each lesson:

Title

• Short Intro
• Objectives
• Hands-on steps <<< this is the crux of this approach.
• Detailed explanation of each step
• Resources to learn more

Why this change?

It takes too long to get students to the last lesson of the day: the lesson where we give them free reign to contribute to a software package based on a calculator.

We spend too much time talking about each step, each instruction, answering off-topic questions, sometimes diving too deeply into topics to the detriment of getting them to the place where they can actually practice the steps, etc.

This approach allows us to deliver the content in a way that focuses more on getting their system set up fast and easy AND control the amount of time spent on each lesson:

For example:

OLD WAY:

1. talk about topic...
2. answer questions (sometimes questions that deviate from the topic OR that dive too deeply into the minutiae)
3. talk about topic until the explanation has been completed.
4. execute the command line steps waiting until everyone is complete
5. mentors help those who struggle >> but those folks then fall behind on the next explanation

NEW WAY:

1. execute the command line steps
2. talk about the topic WHILE mentors help those who struggle
3. answer questions
4. talk about the topic
5. move on at a SET TIME (regardless of whether the full explanation has been completed >> the full explanation is in the write-up with resources to learn more)

Advantages:

• The mentors can get started sooner on helping folks resolve issues to help folks keep pace
• The content can be delivered in windows that are better controlled
• IF time runs out before a topic has been fully explored, at least the attendees are at the right place: their virtualenv is set up OR the software is installed OR their repo has been cloned and they can always go back and refresh themselves on the concepts at their leisure.

The students will end up using pytest to learn some simple testing.
Add a step regarding installing pytest... possible locations might be in the virtual env docs...
Right now, the virtualenv doc has the student install ipython as a sample... in the mentoring session
I suggest, that we have them install pytest during the steps in the HANDS-ON section.

Replace the image in lesson_04:
images/fork-repo-link.png
with a similar image that shows a link pointing to the codeless project at:
https://github.com/chalmerlowe/intro_to_sprinting_codeless_project

Add to the virtual environment page some details in the resources section:
i.e. links to pages with more details on conda, virtual environments in conda, etc

In the Intro to the project (lesson 7, although that number may change)...

There is a long list of functions that could be added to the calculator.

Please convert this list to a table format.

Thanks.

https://github.com/chalmerlowe/intro_to_sprinting/blob/master/class_materials/github_submit_pull_request.md:
Confirm that the base fork is your fork
Confirm that the head fork is the original author's fork

Should be vice versa:
Confirm that the base fork is the original author's fork
Confirm that the head fork is your fork

P.S. Screenshot at the documentation page displays correct information.

The Windows installer for git asks things like which CA store it should use for SSL certificates and how to do line-ending conversion, which causes some bafflement.

No green sticky on page - https://github.com/chalmerlowe/intro_to_sprinting/blob/master/class_materials/git_branch_merge.md

It might be useful to provide some more context on the opening page (README.md)