Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix the sidebar #7

Open
github-learning-lab bot opened this issue Jan 19, 2022 · 6 comments
Open

Fix the sidebar #7

github-learning-lab bot opened this issue Jan 19, 2022 · 6 comments
Projects

Comments

@github-learning-lab
Copy link
Contributor

Note: the content of this comment simulates common usage of issues as a way to request features of report bugs. Scroll down to the next comment in this issue for your instructions.

There's no sidebar! Is this user error or is it actually missing?

@github-learning-lab
Copy link
Contributor Author

Finding relevant history

When you're working in a repository, you might want to find other issues or pull requests. Maybe someone has told you about a conversation, but they didn't send you a direct link. Or, maybe you remember an issue from the past but you don't know exactly where it is.

In this case, we want to see if there's another reference to the broken sidebar somewhere on this repository, and track down any work that's been attempted related to this. Let's see what we can find out!

Finding issues and pull requests

You can search for issues and pull requests in many ways, like by author, title, or even the most recently updated. You can also search closed issues. You can read all about the different ways to search in the Searching Issues or Pull Requests article.

Creating references

When you link to another issue, a reference within GitHub is automatically created. In fact, you don't even need to include the full link. If you were to type #5 within a comment, that would turn into a link to issue or pull request number 5.

When you want to create a crosslink, try typing the title of an issue or pull request directly after you type the # symbol. GitHub will suggest issues or pull requests that will link to the right place. To learn even more, check out the Autolinked References and URLs article.

Step 2: Create crosslinks

⌨️ Activity: Find and link to a related issue

  1. Please find the issue that is similar to this one
    • This does not mean that the issue is referenced, like in the last step. This time, we're looking for a related issue that hasn't been connected to this one in any way.
    • Try looking in the Issues tab to find an issue with a similar title to this one.
  2. Comment in this issue with a reference to the related issue and a short description, something along the lines of "this is a duplicate of issue #(number)".

I'll respond when you comment on this issue.

@github-learning-lab github-learning-lab bot added this to Done in v1.0.0 Jan 19, 2022
This was referenced Jan 19, 2022
@JSilvaLabs
Copy link
Owner

this is a duplicate of issue #8

@github-learning-lab
Copy link
Contributor Author

Great job finding the duplicate issue! Feel free to close the other issue as a duplicate of this one, but I'll leave it up to you. Let's move on to finding out if these issues ever led to a sidebar being added to our project!

Finding commits

An important part of version control is the ability to look into the past. By using git blame, and finding the story behind a commit, we're able to do more than blame people for code. We're able to see the story around why a commit was made - what is the associated pull request? Who approved the pull request? What tests were run on that commit before it was merged?

The obvious reason to find things in history is to know about history. With issues and pull requests, we see a more complete story about history - not just the bare minimum.

What's git blame?

git blame is a Git functionality that shows what revision and author last modified each line of a file. Information like who made a commit, when, and even why can be found this way. If you aren't sure who introduced certain changes to a file, you can use git blame to find out. While git blame sounds rather accusatory, this can be used to understand the context around decisions.

What's a SHA?

A SHA is a reference to a specific object. In this case, it's a reference to a commit. On GitHub, you can look at a specific commit to see the changes introduced, by whom, and if they were a part of a pull request.

Step 3: Find the commit

⌨️ Activity: Find and reference the navigation commit

  1. Navigate to the Code tab of this repository
    • Tip: start this process in a new tab, since you will need it later
  2. Click docs to navigate into the /docs directory
  3. Click _sidebar.md to view the file
  4. On the top right side of the file, click Blame to see the details of the most recent revision
  5. Click the commit message, add sidebar to documentation to see the commit details
  6. Copy some part of the SHA (at least the first 6 characters of the 40 character hexadecimal string listed after commit)
  7. Comment (at least the first 6 characters of) the SHA in this issue

@JSilvaLabs
Copy link
Owner

312f872

@github-learning-lab
Copy link
Contributor Author

Thanks for finding that commit! We now know that the sidebar was indeed added, and it was done in that commit. Let's see if we can dig a little deeper to find out if any planning or conversation occurred around this change.

Context

As we've already seen, conversations in issues and pull requests can reference other work.

But the amount of context goes much further than crosslinks - Remember, Git is version control! For example, the commit that you found in the last step is connected with much more information:

  • Who made the commit
  • What other changes were included
  • When the commit was made
  • Which pull request the commit was a part of

The pull request is important because it goes beyond knowing when a commit happened - you can know why a commit happened. Finding history is not about blaming anyone, but about seeing the bigger picture. Why were decisions made? Who was involved? What were the build outputs and test results for each commit? Who requested changes, and who approved them?

A story about finding experts

Imagine you find an internal white-paper on a really exciting topic. You're looking for experts to help you research this topic for an upcoming project. When you find this article, you're ecstatic! But, there's no author referenced in the plain text.

You can see that it's written in markdown, and it's versioned in GitHub. It's already a part of the main branch, but you want to know who was involved in creating this. You use git blame to see the author(s), and you can find the pull request associated with that branch. Now, you can see who all of the authors were, who the reviewers were, and if there are any other issues or conversations related to this topic.

Just like that, you've found the people at your company who can help move your project forward. 🎉

Finding a pull request from a commit

When you're looking at a commit on GitHub, you can see a lot of information. From this view, you can also find a link to the pull request in which the commit was created. We'll use this in the next step.

screenshot of a view of a commit on GitHub, highlighting the link to the pull request

Step 4: Give more context

To help others find relevant context, we want to collate the information that you found in the prior steps.

a screenshot of this issue with the projects section highlighted on the right, and a second screenshot of v1.0.0 project

One way we can do this, is by using GitHub Projects. You'll notice that this issue is part of Project v1.0.0, which tells us that the sidebar is part of the work related to our version 1.0.0 release. Let's add the related pull request to the same project so that the two artifacts can be tracked in tandem.

⌨️ Activity: Use a project to track related efforts

  1. Go back to 312f872.
  2. Click the link to the related pull request.
  3. In the pull request, click on Projects on the right side, and choose the v1.0.0 project from the list.
  4. When the PR is added to the project, you'll see it's Awaiting triage, let's triage it! Click on the project drop down, and place it into the Done column.

I'll respond in this issue when you've added the pull request to the Done column of the v1.0.0 project.

@github-learning-lab
Copy link
Contributor Author

Great! Now that both this issue and the associated pull request are in the same project, it will be easier to track and organize the related work.

More commit context

Historical context of development includes references to other related work, like tests.

Real life examples

If you'd like to see what this looks like in active repositories, take a look at Electron or Visual Studio Code. You can look through pull requests, see pull request statuses, and maybe even see the log outputs.

Step 5: Find the broken build

There's an open pull request in this repository with a failing status. Before we fix it, let's find it!

⌨️ Activity:

  1. In the Pull requests tab, find the pull request with the failing build
  2. Using the Assignees section on the right side, assign yourself to the pull request

I will respond with your next steps in that pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

1 participant