Parking Lot

[whatupfoo]

Post any questions you may have here during the training.

Topics

• [x] Overview of GitHub
• [x] README file
• [x] GitHub Flow
• [x] Markdown syntax
  • checkbox
  • emojis
  • table
    • @ mention team and person
• [x] Issues
  • Labels
  • Link to PRs and Projects
  • Linking to commit in issues and PR
• [x] PRs
  • Keywords: closes, fixes, resolves
  • General Link to issues
  • Currently not fully using code review, PR makes it easy
  • Draft PR/ WIP Probot
• [x] Projects
• [x] Wiki/ GH Pages
• [x] Milestones
• [x] Branch protection settings & CODEOWNERS file
  • Similar to branch permissions in Bitbucket
• [x] Tags and releases
• [x] Link JIRA tickets
• [x] Manage access by teams
• [ ] GitHub Apps
• [ ] Status API

[rkzm]

:wave: @rwnfoo here is a list of example repositories with READMEs. The wikis are also really nice ❤️

Examples

snowplow/snowplow An example of a readme with flow diagrams and project status tags thinkaurelius/titan An example of a downloadable release d3/d3 An example with document navigation Netflix/Hystrix/wiki Complex wiki drawings

[harrison-pham]

Some members on my team are curious on the different Merge options. What's the difference between Merge, Squash and Merge, Rebase and Merge?

Could you also explain about Reset and Cherry-pick?

[richard-morris]

How does one have a more structured issue management process that is guided and controlled by the system?

Here is a typical issue handling example.

Let's assume there are the following roles and responsibilities:

• Tech Support: submits issues, edits issues, no source access
• Developer: submits issues, edits issues, fixes issues, source RW access, can’t close issues marked as bugs, closes issues others than bugs
• Test Engineer: submits issues, edits issues, assigns issues, source RO access, closes issues marked as bugs
• Administrator: assigns and schedules issue resolution, keeps track of issue/work backlog, manages issue system

An issue is created with the following attributes:

• Required:

  • Project
  • Issue Type: bug, feature request, improvement, ...
  • Priority
  • Fix Version(s)
  • Summary
  • Description

• Optional:

  • Affected Version(s)
  • Assignee (automatic if not specified)
  • Environment in which occurred
  • Acceptance Criteria
  • Work estimate (hours, days, weeks, etc.)
  • Attachments (can be extremely large log or data files)
  • Dependencies

Use Case:

1. Tech support Bob: assists customer. finds a misspelling in instrument screen dialog.
2. Tech support Bob: creates issue #767 with the required and optional information leaving assignee automatic
3. Administrator Alice: assigns issue #767 to UI developer Felicia with estimated work
4. Developer Felicia: investigates checks out appropriate source tag, branches, investigates and resolves issue, tests locally, commits fix, assigns Test Engineer Alex to test.
5. CI system builds test release from branch
6. Test Engineer Alex: sets up test environments and tests that issue has been resolved and marks as fixed
7. Test Engineer Alex: assigns issue back to Felicia who submits a pull request for merging as appropriate
8. Developer Felicia: submits a pull request into master or branch as appropriate. Assigns issue back to Alex.
9. CI builds release package
10. Test Engineer Alex: tests release build to confirm issue is resolved
11. Test Engineer Alex: closes issue

[whatupfoo]

Some members on my team are curious on the different Merge options. What's the difference between Merge, Squash and Merge, Rebase and Merge?

Could you also explain about Reset and Cherry-pick?

@harrison-pham - 🗒️ We took this offline. I love this discussion and if time allows, I'd love to go into it with developers who are already comfortable with git.

How does one have a more structured issue management process that is guided and controlled by the system?

@richard-morris - Great question and thanks for sharing this in detail. Ideally, it'd be great if we can spend time going through a workflow consultation, with white boarding sessions and everything. But what I can do here is provide some high level, rough ideas:

• When Tech Support Bob 👷‍♂️ identifies an issue, he would create an issue using issue templates that specifies the required and optional items.
  • He would add issue labels: bug and priority: high
  • Issues can be automatically assigned when they are created; or Administrator Alice 👩‍🏫 can assign it manually to Developer Felicia 👩‍💻
  • Tech Support Bob 👷‍♂️or Administrator Alice 👩‍🏫 can add this to the project board
• Developer Felicia 👩‍💻gets to work
  • She would create a branch to work on fixing the bug. This can also be done automatically if that workflow makes sense.
  • A draft Pull Request can be created at this time to signal to other folks on the team that she's on it. Or use the WIP Probot. This blocks the reviewer from merging her branch.
  • Test Engineer Alex 🕵🏻‍♂️ can be assigned to this draft PR if needed, that way he knows work is coming down the pipeline soon. He can also be assigned automatically.
    • Developer Felicia 👩‍💻 pushes work to GitHub and is ready. She publishes the PR and CI kicks in to build, test, deploy. CI system comes back with the green light, all tests passed ✅. Test Engineer Alex 🕵🏻‍♂️ also completed his testing and gave the green light ✅ . Branch protection testing dictates that these steps need to be completed for merging to be allowed.
  • Developer Felicia 👩‍💻merges PR to master branch. CI release build can either happen before or after but I won't go into where it should be until we understand the details. This step can occur automatically as well.
• There are many ways Test Engineer Alex 🕵🏻‍♂️ can give his approval after he tests release build but let's stick to your use case. He can add his comment on the issue and close out the issue. Issue will be moved to Done on project board.
• Publish the release. You can take advantage of this action too.

⚠️ The actions listed here are just suggested ones, I have not tested some of them. If third-party actions are not allowed, you can certainly build your own. Also, I wouldn't say this is the way to go, just some ideas on how your workflow translates to GitHub Features. We should definitely refine it.

I hope this helps! 😃

[richard-morris]

Thanks Rowena. I followed some of the guides you reference above and experimented around a bit.

The issue tracking use case I presented above is just an example and not formal nor part of Thermo Fisher processes. I wanted to get a sense of how the built-in GitHub issue tracking functionality could work.

The issue templates seem to be guides which do not enforce required fields, abilities of a given user based on their role, etc. Because there would be such a diverse audience using the tool, more rigorous enforcement would provide for consistency and adhering to documented processes.

On another note, somewhat strangely when I attempt to preview this comment the Preview tab says: Error rendering preview