Merge pull request #49 from camihmerhar/revert-34-3.1-Issues-v3

Revert "3.1 issues v3"

Author: Chukslord1

learn-pr/github/github-actions-automate-tasks/1-introduction.yml

@@ -4,7 +4,7 @@ title: Introduction
 metadata:
   title: Introduction
   description: An introduction to GitHub Actions and workflows.
-  ms.date: 05/01/2025
+  ms.date: 10/08/2024
   author: juliakm
   ms.author: jukullam
   ms.topic: unit

learn-pr/github/github-actions-automate-tasks/includes/2-github-actions-automate-development-tasks.md

@@ -156,50 +156,6 @@ The last part of this workflow file sets the `MY_NAME` variable value for this w
 
 For more information on workflow syntax, see [Workflow syntax for GitHub Actions](https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions?azure-portal=true)
 
-## Referencing Actions in Workflows
-
-When creating workflows in GitHub Actions, you can reference actions from various sources. These actions can be used to automate tasks in your workflows. Below are the primary sources where workflows can reference actions:
-
-1. **A published Docker container image on Docker Hub**  
-   Workflows can reference actions that are published as Docker container images on Docker Hub. These actions are containerized and include all dependencies required to execute the action. To use such an action, you specify the Docker image in the `uses` attribute of your workflow step. For example:
-   ```yml
-   steps:
-     - name: Run a Docker action
-       uses: docker://<docker-image-name>:<tag>
-   ```
-
-This is particularly useful for actions that require a custom runtime or dependencies not available in standard runners.
-
-2. **Any public repository**  
-   Actions hosted in public repositories can be directly referenced in your workflows. These actions are accessible to anyone and can be used by specifying the repository name and version (Git ref, SHA, or tag) in the `uses` attribute. For example:
-   ```yml
-   steps:
-     - name: Use a public action
-       uses: actions/checkout@v3
-   ```
-
-3. **The same repository as your workflow file**  
-   You can reference actions stored in the same repository as your workflow file. This is useful for custom actions that are specific to your project. To reference such actions, use a relative path to the action's directory. For example:
-   ```yml
-   steps:
-     - name: Use a local action
-       uses: ./path-to-action
-   ```
-
-4. **An enterprise marketplace**  
-   If your organization uses GitHub Enterprise, you can reference actions from your enterprise's private marketplace. These actions are curated and managed by your organization, ensuring compliance with internal standards. For example:
-   ```yml
-   steps:
-     - name: Use an enterprise marketplace action
-       uses: enterprise-org/action-name@v1
-   ```
-
-### Additional Notes
-- Actions in private repositories can also be referenced, but they require proper authentication and permissions.
-- When referencing actions, always specify a version (Git ref, SHA, or tag) to ensure consistency and avoid unexpected changes.
-
-For more information, see [Referencing actions in workflows](https://docs.github.com/actions/using-workflows/referencing-actions-in-workflows?azure-portal=true).
-
 ## GitHub-hosted versus self-hosted runners
 
 We briefly mentioned runners as being associated with a job. A runner is simply a server that has the GitHub Actions runner application installed. In the previous workflow example, there was a `runs-on: ubuntu-latest` attribute within the jobs block, which told the workflow that the job is going to run using the GitHub-hosted runner that's running in the `ubuntu-latest` environment.

learn-pr/github/introduction-to-github/2-what-is-github.yml

@@ -10,4 +10,4 @@ metadata:
   ms.topic: unit
 durationInMinutes: 8
 content: |
-  [!include[](includes/2-what-is-github.md)]
+  [!include[](includes/2-what-is-github.md)]

learn-pr/github/introduction-to-github/includes/2-what-is-github.md

@@ -120,46 +120,54 @@ Congratulations, you just created a new file in your repository! You have also c
 
 Before we review branches and commits in the next unit, let’s quickly review gists, wikis, and GitHub pages because they're similar to repositories.
 
-### What are gists?
+### What are gists
 
-Gists are a GitHub feature for sharing code snippets, notes, or small pieces of information conveniently. They are Git repositories that can be cloned, forked, and version-controlled like full repositories. Gists are particularly useful for sharing quick solutions, configuration files, or examples without the need to create a full repository.
+Now that we have a good understanding of repositories, we can review gists. Similarly to repositories, gists are a simplified way to share code snippets with others.
 
-#### Key features of gists
-1. **Public and Secret Gists**:
-   - **Public Gists**: These are visible to everyone and can be discovered through GitHub's search functionality. They are ideal for sharing code snippets or solutions that you want to make available to the broader community.
-   - **Secret Gists**: These are not searchable or publicly listed, but they are not entirely private. Anyone with the URL can access them. They are useful for sharing code with a limited audience, such as collaborators or friends.
+Every gist is a Git repository, which you can fork and clone and be made either public or secret. Public gists are displayed publicly where people can browse new ones as they’re created. Public gists are also searchable. Conversely, secret gists aren't searchable, but they aren’t entirely private. If you send the URL of a secret gist to a friend, they'll be able to see it.
 
-2. **Version Control**:
-   - Every change made to a gist is tracked, allowing you to view the history of edits. This makes it easy to revert to a previous version or see how the snippet has evolved over time.
+### Forking and cloning gists
 
-3. **Forking and Cloning**:
-   - Like repositories, gists can be forked and cloned. This allows others to build upon your work or adapt it to their needs.
+You can fork a gist to create a copy of someone else's gist in your account.
 
-4. **Embedding**:
-   - Gists can be embedded into websites or blogs, making them a great tool for sharing code examples in tutorials or documentation.
+1. Navigate to the gist you want to fork.
+2. Select **Fork** at the top-right of the gist page.
 
-5. **Markdown Support**:
-   - Gists support Markdown formatting, which means you can include rich text, headings, links, and even images alongside your code. This is particularly useful for adding context or explanations to your snippets.
+To clone a gist locally:
 
-6. **Collaboration**:
-   - While gists are typically used for individual snippets, they can also be shared and collaborated on by multiple users. Forking and commenting on gists enable lightweight collaboration.
+```bash
+git clone https://gist.github.com/your-gist-id.git
+```
 
-#### Use cases for Gists
-- Sharing quick code examples or solutions.
-- Storing configuration files or scripts for personal use.
-- Creating templates for commonly used code patterns.
-- Sharing error logs or debugging information with others.
-- Embedding code snippets in blogs, forums, or documentation.
+To learn more about gists, see the linked article in our Resources section at the end of this module titled *Creating Gists*.
 
-#### Limitations of Gists
-> [!IMPORTANT]
-> Gists are not entirely private, even if marked as secret. Anyone with the URL can access them, so they should not be used for sensitive or confidential information.
-- They are best suited for small snippets or single files. For larger projects or multi-file structures, a full repository is more appropriate.
-
-To learn more about how to create and manage gists, refer to the GitHub documentation in the Resources section of this module or visit the [GitHub Gists documentation](https://docs.github.com/en/github/writing-on-github/creating-gists).
+---
 
 ### What are wikis?
 
 Every repository on GitHub.com comes equipped with a section for hosting documentation, called a wiki. You can use your repository's wiki to share long-form content about your project, such as how to use it, how you designed it, or its core principles. While a README file quickly tells what your project can do, you can use a wiki to provide additional documentation.
 
-It’s worth a reminder that if your repository is private, only people who have at least read access to your repository will have access to your wiki.
+It’s worth a reminder that if your repository is private, only people who have at least read access to your repository will have access to your wiki.
+
+### Creating, editing, and deleting wiki pages
+
+You can use the GitHub wiki to create and manage documentation for your project.
+
+**To create a wiki page:**
+
+1. Navigate to the repository.
+2. Select the **Wiki** tab.
+3. Select **Create the first page** if no pages exist, or **New Page** to add a page.
+4. Enter a title and content, then select **Save Page**.
+
+**To edit a wiki page:**
+
+1. Navigate to the wiki page you want to edit.
+2. Select **Edit** at the top-right.
+3. Make changes and select **Save Page**.
+
+**To delete a wiki page:**
+
+- Deleting a wiki page requires using Git. Clone the wiki repository, remove the file, and push the change.
+
+Learn more about managing wikis in [GitHub Docs - Adding or editing wiki pages](https://docs.github.com/en/communities/documenting-your-project-with-wikis/adding-or-editing-wiki-pages).

learn-pr/github/introduction-to-github/includes/3-components-of-github-flow.md

@@ -48,15 +48,13 @@ Once the changes have been approved (if required), the pull request's source bra
 
 :::image type="content" source="../media/2-pull-request.png" alt-text="A screenshot of a pull request and a comment within the pull request." border="false":::
 
-Unlike issues and discussions, pull requests relate specifically to proposed changes in code. Issues are used for tracking bugs, feature requests, or tasks, while Discussions are meant for broader conversations that aren’t tied directly to a specific line of code.
-
-Now that we understand all the key elements, let’s review the GitHub flow.
+Now that we know of all the ingredients, let’s review the GitHub flow.
 
 ## The GitHub flow
 
 :::image type="content" source="../media/2-branching.png" alt-text="Screenshot showing a visual representation of the GitHub Flow in a linear format that includes a new branch, commits, pull request, and merging the changes back to main in that order." border="false":::
 
-The GitHub flow can be defined as a lightweight workflow that allows for safe experimentation. You can test new ideas with your team by using branching, pull requests, and merging.
+The GitHub flow can be defined as a lightweight workflow that allows for safe experimentation. You can test new ideas and collaboration with your team by using branching, pull requests, and merging.
 
 Now that we know the basics of GitHub we can walk through the GitHub flow and its components.
 

learn-pr/github/introduction-to-github/includes/4-collaborative-platform.md

@@ -33,17 +33,22 @@ For this walkthrough, we'll go over how to create an issue from a repository. Bu
 1. If you're a project maintainer, you can assign the issue to someone, add it to a project board, associate it with a milestone, or apply a label.
 1. When you're finished, select **Submit new issue**.
 
-Some conversations are more suitable for GitHub Discussions. They are intended for open-ended conversations such as asking questions, sharing information, or gathering community feedback..
+Some conversations are more suitable for GitHub Discussions. You can use GitHub Discussions to ask and answer questions, share information, make announcements, and conduct or participate in conversations about a project.
 
 In the next section, we’ll review Discussions and how to best utilize the feature.
 
 ## Discussions
 
 Discussions are for conversations that need to be accessible to everyone and aren't related to code. Discussions enable fluid, open conversation in a public forum.
 
-Let’s review how to enable discussions in your repository.
+In this section we go over:
 
-### Enabling discussions in your repository
+- Enabling a discussion in your repository.
+- Creating a new discussion and various discussion categories.
+
+Let’s dive into enabling a discussion in your repository.
+
+### Enabling a discussion in your repository
 
 Repository owners and people with Write access can enable GitHub Discussions for a community on their public and private repositories. The visibility of a discussion is inherited from the repository the discussion is created in.
 
@@ -94,7 +99,7 @@ Each category must have a unique name, emoji pairing, and a detailed description
 
    :::image type="content" source="../media/start-a-new-discussion.png" alt-text="A screenshot of starting a new discussion page with the Discussion title box and content box empty." border="false":::
 
-1. In your repository, go to the Discussions tab and select **Start discussion**.
+1. Select **Start discussion**.
 
 That covers a little about how GitHub inspires collaboration. Now let's move to how you can manage notifications, subscribe to threads, and get started with GitHub pages.
 

learn-pr/github/manage-innersource-program-github/includes/2-manage-innersource-program.md

@@ -67,12 +67,9 @@ A README file communicates expectations for your project and helps you manage co
 - Include references to the projects on which you depend. These references are a good way to promote the work of others.
 - Use Markdown to guide readers through properly formatted content.
 
-If you put your README file in your repository's root directory, or in the hidden `.github` or `docs` directory, GitHub recognizes and automatically surfaces your README to repository visitors. If a repository contains more than one README file, then the file shown is chosen from locations in the following order: 
-1. The `.github` directory  
-2. The repository's root directory  
-3. The `docs` directory  
+If you put your README file in your repository's root directory, or in the hidden `.github` or `docs` directory, GitHub recognizes and automatically surfaces your README to repository visitors. If a repository contains more than one README file, then the file shown is chosen from locations in the following order: the `.github` directory, then the repository's root directory, and finally the `docs` directory.
 
-Check out some [Awesome README examples](https://github.com/matiassingers/awesome-readme).
+Check out some [Awesome README examples](https://github.com/matiassingers/awesome-readme?azure-portal=true).
 
 Once the project launches, use email and other networking channels to promote it. Reaching an appropriate audience could produce a significant boost in project participation.
 

learn-pr/github/search-organize-repository-history-github/5-connect-dots.yml renamed to learn-pr/github/search-organize-repository-history-github/3-connect-dots.yml

@@ -1,5 +1,5 @@
 ### YamlMime:ModuleUnit
-uid: learn.github.search-organize-repository-history-github.5-connect-dots
+uid: learn.github.search-organize-repository-history-github.3-connect-dots
 title:  Exercise - Connect the dots in a GitHub repository
 metadata:
   title:  Exercise - Connect the dots in a GitHub repository
@@ -10,4 +10,4 @@ metadata:
   ms.topic: unit
 durationInMinutes: 24
 content: |
-  [!include[](includes/5-connect-dots.md)]
+  [!include[](includes/3-connect-dots.md)]

learn-pr/github/search-organize-repository-history-github/3-manage-issues-github.yml

@@ -1,5 +1,5 @@
 ### YamlMime:ModuleUnit
-uid: learn.github.search-organize-repository-history-github.6-knowledge-check
+uid: learn.github.search-organize-repository-history-github.4-knowledge-check
 title: Module assessment
 metadata:
   title: Module assessment
@@ -11,7 +11,7 @@ metadata:
   module_assessment: true
 durationInMinutes: 3
 content: |
-  [!include[](includes/6-knowledge-check.md)]
+  [!include[](includes/4-knowledge-check.md)]
 quiz:
   title: Check your knowledge
   questions:
@@ -47,26 +47,4 @@ quiz:
       explanation: "This linking is a good practice, assuming the author is available to support the issue."
     - content: "Add a comment to the bug report that links the pull request to it using the #ID syntax."
       isCorrect: false
-      explanation: "This linking is a good practice as it provides transparency to the issue author and anyone who might end up working on it."
-  - content: "Which of the following is a valid reason to pin an issue in your repository?"
-    choices:
-    - content: "To prevent the issue from being edited by other users."
-      isCorrect: false
-      explanation: "Pinning doesn’t affect edit permissions; it simply highlights the issue."
-    - content: "To keep high-priority or frequently referenced issues at the top of the Issues tab."
-      isCorrect: true
-      explanation: "Pinning helps improve visibility for important issues."
-    - content: "To automatically assign the issue to the repository owner."
-      isCorrect: false
-      explanation: "Pinning does not assign or automate ownership."
-  - content: "Which keyword in a pull request description will automatically close a linked issue when the pull request is merged?"
-    choices:
-    - content: "`#42 linked`"
-      isCorrect: false
-      explanation: "The correct syntax includes a keyword like `Fixes` followed by the issue number."
-    - content: "`Fixes #42`"
-      isCorrect: true
-      explanation: "`Fixes #42` is one of the supported keywords that automatically closes the linked issue."
-    - content: "`Update issue 42`"
-      isCorrect: false
-      explanation: "This does not follow the recognized keyword format used by GitHub."
+      explanation: "This linking is a good practice as it provides transparency to the issue author and anyone who might end up working on it."