{"id":78746,"date":"2026-09-26T05:22:47","date_gmt":"2026-09-26T05:22:47","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=78746"},"modified":"2026-09-26T05:22:52","modified_gmt":"2026-09-26T05:22:52","slug":"github-projects-essentials-2-hour-tutorial-hands-on-guide","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/github-projects-essentials-2-hour-tutorial-hands-on-guide\/","title":{"rendered":"GitHub Projects Essentials \u2014 2-Hour Tutorial & Hands-On Guide"},"content":{"rendered":"\n
\n

Scope:<\/strong> Current GitHub Projects \/ Projects v2<\/strong>, not Projects (classic).
Audience:<\/strong> Developers, DevOps engineers, engineering managers, product managers, project administrators, and GitHub organization members.
Training duration:<\/strong> Approximately 2 hours<\/strong>, including guided practice.
Prerequisite:<\/strong> Basic familiarity with GitHub repositories, issues, and pull requests.
Learning style:<\/strong> Concept -> Why it matters -> See it -> Practice it -> Remember it.<\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

1. What You Will Learn in 2 Hours<\/h1>\n\n\n\n

By the end of this tutorial, you should be able to:<\/p>\n\n\n\n

    \n
  • Explain what GitHub Projects is and how it differs from Issues, Pull Requests, and Milestones.<\/li>\n\n\n\n
  • Create an organization-level project.<\/li>\n\n\n\n
  • Add issues, pull requests, and draft issues.<\/li>\n\n\n\n
  • Create useful project fields such as Priority, Sprint, Estimate, Team, and dates.<\/li>\n\n\n\n
  • Build Table, Board, and Roadmap views.<\/li>\n\n\n\n
  • Filter, sort, group, and slice project data.<\/li>\n\n\n\n
  • Use iterations for sprint planning.<\/li>\n\n\n\n
  • Understand the difference between Project Status and Issue\/PR state.<\/li>\n\n\n\n
  • Configure essential built-in workflows.<\/li>\n\n\n\n
  • Use auto-add and auto-archive safely.<\/li>\n\n\n\n
  • Apply basic access and visibility rules.<\/li>\n\n\n\n
  • Build a small but production-ready GitHub Project.<\/li>\n<\/ul>\n\n\n\n

    This guide intentionally leaves deep API, GraphQL, REST, GitHub App, enterprise governance, and portfolio architecture topics for the full reference guide.<\/p>\n\n\n\n

    \n\n\n\n

    2. Two-Hour Learning Plan<\/h1>\n\n\n\n
    Time<\/th>Topic<\/th>Outcome<\/th><\/tr><\/thead>
    0-10 min<\/td>Foundations<\/td>Understand the GitHub Projects mental model<\/td><\/tr>
    10-20 min<\/td>Create a Project<\/td>Build the project shell<\/td><\/tr>
    20-40 min<\/td>Items and Fields<\/td>Add work and structured metadata<\/td><\/tr>
    40-65 min<\/td>Table, Board, Roadmap<\/td>Build three useful views<\/td><\/tr>
    65-80 min<\/td>Filter, Sort, Group, Slice<\/td>Turn one dataset into focused views<\/td><\/tr>
    80-95 min<\/td>Sprint and Status<\/td>Plan an iteration and execution flow<\/td><\/tr>
    95-110 min<\/td>Built-In Automation<\/td>Reduce manual project maintenance<\/td><\/tr>
    110-120 min<\/td>Final Lab and Checklist<\/td>Validate the complete workflow<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n

    3. Running Example<\/h1>\n\n\n\n

    Throughout the tutorial, imagine an organization named:<\/p>\n\n\n

    acme-corp\n<\/code><\/span><\/pre>\n\n\n
    with three repositories:<\/p>\n\n\n
    acme-corp\/web\nacme-corp\/api\nacme-corp\/infra\n<\/code><\/span><\/pre>\n\n\n
    We will create one organization project:<\/p>\n\n\n
    Acme Platform Delivery\n<\/code><\/span><\/pre>\n\n\n
    and use it to manage work across all three repositories.<\/p>\n\n\n\n
    Recommended fields:<\/p>\n\n\n\n
    Field<\/th>Type<\/th>Example Values<\/th>Why We Need It<\/th><\/tr><\/thead>
    Status<\/td>Single select<\/td>Backlog, Ready, In Progress, In Review, Done<\/td>Workflow state<\/td><\/tr>
    Priority<\/td>Single select<\/td>P0, P1, P2, P3<\/td>Importance<\/td><\/tr>
    Sprint<\/td>Iteration<\/td>Sprint 24, Sprint 25<\/td>Time-boxed planning<\/td><\/tr>
    Estimate<\/td>Number<\/td>1, 2, 3, 5, 8<\/td>Capacity planning<\/td><\/tr>
    Team<\/td>Single select<\/td>Web, API, Platform<\/td>Ownership<\/td><\/tr>
    Start Date<\/td>Date<\/td>2026-10-01<\/td>Roadmap start<\/td><\/tr>
    Target Date<\/td>Date<\/td>2026-10-15<\/td>Roadmap target<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n
    4. GitHub Projects Mental Model<\/h1>\n\n\n\n
    GitHub Projects is a planning layer over GitHub work.<\/p>\n\n\n
    flowchart<\/span> LR<\/span>\n    A<\/span>[Repositories]<\/span> --<\/span>> B<\/span>[Issues and Pull Requests]<\/span>\n    B<\/span> --<\/span>> C<\/span>[GitHub Project]<\/span>\n    D<\/span>[Draft Issues]<\/span> --<\/span>> C<\/span>\n    C<\/span> --<\/span>> E<\/span>[Fields]<\/span>\n    C<\/span> --<\/span>> F<\/span>[Views]<\/span>\n    C<\/span> --<\/span>> G<\/span>[Workflows]<\/span>\n    F<\/span> --<\/span>> H<\/span>[Table]<\/span>\n    F<\/span> --<\/span>> I<\/span>[Board]<\/span>\n    F<\/span> --<\/span>> J<\/span>[Roadmap]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    The most important idea:<\/p>\n\n\n\n
    \n
    GitHub Projects does not replace Issues or Pull Requests. It organizes them for planning.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    4.1 Projects vs Issues vs Pull Requests vs Milestones<\/h2>\n\n\n\n
    GitHub Object<\/th>What It Represents<\/th>Typical Use<\/th><\/tr><\/thead>
    Issue<\/td>A unit of work or discussion<\/td>Bug, feature, task<\/td><\/tr>
    Pull Request<\/td>A code change<\/td>Review and merge<\/td><\/tr>
    Milestone<\/td>A repository-level target<\/td>Release or phase<\/td><\/tr>
    Project<\/td>Planning across many items<\/td>Backlog, sprint, roadmap<\/td><\/tr>
    Draft Issue<\/td>A planning idea not yet assigned to a repository<\/td>Early backlog\/discovery<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Example:<\/p>\n\n\n
    Issue:\n\"Add passkey authentication\"<\/span>\n\nPull Request:\n\"Implement WebAuthn challenge endpoint\"<\/span>\n\nMilestone<\/span>:\n\"v3.2 Release\"<\/span>\n\nProject<\/span>:\n\"Acme Platform Delivery\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
    4.2 One Project, Many Views<\/h2>\n\n\n\n
    A Project stores items and metadata once.<\/p>\n\n\n\n
    Different views show the same data differently.<\/p>\n\n\n
    flowchart<\/span> TD<\/span>\n    A<\/span>[One Project Dataset]<\/span> --<\/span>> B<\/span>[Backlog Table]<\/span>\n    A<\/span> --<\/span>> C<\/span>[Current Sprint Board]<\/span>\n    A<\/span> --<\/span>> D<\/span>[Product Roadmap]<\/span>\n    A<\/span> --<\/span>> E<\/span>[My Work View]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    This is why you usually do not<\/strong> need separate Projects just because different people want different views.<\/p>\n\n\n\n
    \n\n\n\n
    5. Create Your First GitHub Project<\/h1>\n\n\n\n
    For shared company work, prefer an organization-owned project<\/strong>.<\/p>\n\n\n\n
    5.1 UI Flow<\/h2>\n\n\n
    flowchart<\/span> LR<\/span>\n    A<\/span>[Organization]<\/span> --<\/span>> B<\/span>[Projects]<\/span>\n    B<\/span> --<\/span>> C<\/span>[New Project]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Blank Project]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Table]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Name Project]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Configure Fields]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    5.2 Hands-On Steps<\/h2>\n\n\n\n
      \n
    1. Open your GitHub organization.<\/li>\n\n\n\n
    2. Select\u00a0Projects<\/strong>.<\/li>\n\n\n\n
    3. Select\u00a0New project<\/strong>.<\/li>\n\n\n\n
    4. Start with a blank\u00a0Table<\/strong>.<\/li>\n\n\n\n
    5. Name it:<\/li>\n<\/ol>\n\n\n
      Acme Platform Delivery\n<\/code><\/span><\/pre>\n\n\n
        \n
      1. Keep it\u00a0Private<\/strong>\u00a0while configuring it.<\/li>\n\n\n\n
      2. Add a short description.<\/li>\n<\/ol>\n\n\n\n
        Example:<\/p>\n\n\n
        Cross-repository delivery planning for the Web, API, and Platform teams.\n<\/code><\/span><\/pre>\n\n\n
        5.3 Why Start with Table?<\/h2>\n\n\n\n
        The Table layout is the easiest place to:<\/p>\n\n\n\n
          \n
        • add fields;<\/li>\n\n\n\n
        • inspect metadata;<\/li>\n\n\n\n
        • bulk edit items;<\/li>\n\n\n\n
        • group work;<\/li>\n\n\n\n
        • clean up a backlog.<\/li>\n<\/ul>\n\n\n\n
          Board and Roadmap views can be added afterward.<\/p>\n\n\n\n
          \n\n\n\n
          6. Project Items<\/h1>\n\n\n\n
          GitHub Projects supports three important item types.<\/p>\n\n\n\n
          Item Type<\/th>Use It When<\/th><\/tr><\/thead>
          Issue<\/td>Work belongs in a repository<\/td><\/tr>
          Pull Request<\/td>The code change itself must be tracked<\/td><\/tr>
          Draft Issue<\/td>The idea is not ready for a repository<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          6.1 Add an Existing Issue<\/h2>\n\n\n\n
          From the project:<\/p>\n\n\n
          Add item -> Search repository -> Select issue\n<\/code><\/span><\/pre>\n\n\n
          You can also paste an issue URL:<\/p>\n\n\n
          https:\/\/github.com\/acme-corp\/api\/issues\/201<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          6.2 Add a Pull Request<\/h2>\n\n\n\n
          A PR can also be a project item.<\/p>\n\n\n\n
          Example:<\/p>\n\n\n
          https:\/\/github.com\/acme-corp\/api\/pull\/88<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          Track PRs directly when review or merge state is part of the project workflow.<\/p>\n\n\n\n
          6.3 Create a Draft Issue<\/h2>\n\n\n\n
          Example:<\/p>\n\n\n
          Title<\/span>: Add regional failover runbook\n\nBody:\nDocument RTO, RPO, traffic cutover, database recovery, and rollback.\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
          Draft issue lifecycle:<\/p>\n\n\n
          flowchart<\/span> LR<\/span>\n    A<\/span>[Idea]<\/span> --<\/span>> B<\/span>[Draft Issue]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Refine]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Ready for Engineering]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Convert to Issue]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Choose Repository]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          6.4 Important Rule<\/h2>\n\n\n\n
          Use:<\/p>\n\n\n
          Draft Issue -> when repository ownership is not decided\nIssue       -> when work is real and should live in a repository\nPR          -> when the code change itself is the tracking object\n<\/code><\/span><\/pre>\n\n\n
          \n\n\n\n
          7. Project Fields<\/h1>\n\n\n\n
          Fields turn a simple list of issues into a real planning system.<\/p>\n\n\n\n
          There are two categories.<\/p>\n\n\n\n
          7.1 GitHub Metadata<\/h2>\n\n\n\n
          Examples:<\/p>\n\n\n
          Title\nAssignees\nLabels\nMilestone\nRepository\nIssue Type\nIssue State\nPR State\nReviewers\n<\/code><\/span><\/pre>\n\n\n
          These come from GitHub Issues and Pull Requests.<\/p>\n\n\n\n
          7.2 Project Custom Fields<\/h2>\n\n\n\n
          Common field types:<\/p>\n\n\n
          Text\nNumber<\/span>\nDate<\/span>\nSingle select\nIteration\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          7.3 Field Selection Rule<\/h2>\n\n\n\n
          Create a field only if you expect to:<\/p>\n\n\n
          Filter\nSort\nGroup\nSlice\nAggregate\nAutomate\nReport\n<\/code><\/span><\/pre>\n\n\n
          Do not create a field just because someone mentioned a piece of information in a meeting.<\/p>\n\n\n\n
          \n\n\n\n
          8. Essential Fields to Create<\/h1>\n\n\n\n
          For this tutorial, create the following fields.<\/p>\n\n\n\n
          8.1 Priority<\/h2>\n\n\n\n
          Type:<\/p>\n\n\n
          Single select\n<\/code><\/span><\/pre>\n\n\n
          Values:<\/p>\n\n\n\n
          Priority<\/th>Meaning<\/th><\/tr><\/thead>
          P0<\/td>Critical\/immediate<\/td><\/tr>
          P1<\/td>High<\/td><\/tr>
          P2<\/td>Normal<\/td><\/tr>
          P3<\/td>Low<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          Example:<\/p>\n\n\n
          Priority = P1\n<\/code><\/span><\/pre>\n\n\n
          8.2 Team<\/h2>\n\n\n\n
          Type:<\/p>\n\n\n
          Single select\n<\/code><\/span><\/pre>\n\n\n
          Values:<\/p>\n\n\n
          Web\nAPI\nPlatform\n<\/code><\/span><\/pre>\n\n\n
          8.3 Estimate<\/h2>\n\n\n\n
          Type:<\/p>\n\n\n
          Number<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          Example scale:<\/p>\n\n\n
          1, 2, 3, 5, 8\n<\/code><\/span><\/pre>\n\n\n
          Do not mix hours and story points in the same field.<\/p>\n\n\n\n
          8.4 Start Date and Target Date<\/h2>\n\n\n\n
          Type:<\/p>\n\n\n
          Date<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          Use these for Roadmap planning.<\/p>\n\n\n\n
          Example:<\/p>\n\n\n
          Start Date<\/span>  = 2026<\/span>-10<\/span>-01<\/span>\nTarget Date<\/span> = 2026<\/span>-10<\/span>-15<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          8.5 Sprint<\/h2>\n\n\n\n
          Type:<\/p>\n\n\n
          Iteration\n<\/code><\/span><\/pre>\n\n\n
          Example:<\/p>\n\n\n
          Sprint 24\nSprint 25\nSprint 26\n<\/code><\/span><\/pre>\n\n\n
          An Iteration field is better than a text field named Sprint<\/code> because GitHub understands concepts such as:<\/p>\n\n\n
          @previous<\/span>\n@current\n@next\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          8.6 Status<\/h2>\n\n\n\n
          A useful simple workflow:<\/p>\n\n\n
          Backlog\nReady\nIn Progress\nIn Review\nDone\n<\/code><\/span><\/pre>\n\n
          flowchart<\/span> LR<\/span>\n    A<\/span>[Backlog]<\/span> --<\/span>> B<\/span>[Ready]<\/span>\n    B<\/span> --<\/span>> C<\/span>[In Progress]<\/span>\n    C<\/span> --<\/span>> D<\/span>[In Review]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Done]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          Keep Status simple.<\/p>\n\n\n\n
          Too many statuses usually create confusion.<\/p>\n\n\n\n
          \n\n\n\n
          9. Practice: Add Sample Work<\/h1>\n\n\n\n
          Add at least six issues or draft issues.<\/p>\n\n\n
          web<\/span>   #101<\/span> Add<\/span> passkey<\/span> enrollment<\/span> screen<\/span>\nweb<\/span>   #102<\/span> Add<\/span> account<\/span> recovery<\/span> UX<\/span>\n\napi<\/span>   #201<\/span> Add<\/span> WebAuthn<\/span> challenge<\/span> endpoint<\/span>\napi<\/span>   #202<\/span> Add<\/span> recovery<\/span> token<\/span> endpoint<\/span>\n\ninfra<\/span> #301<\/span> Add<\/span> authentication<\/span> audit<\/span> dashboard<\/span>\ninfra<\/span> #302<\/span> Rotate<\/span> production<\/span> signing<\/span> keys<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          Assign fields such as:<\/p>\n\n\n\n
          Item<\/th>Priority<\/th>Team<\/th>Estimate<\/th><\/tr><\/thead>
          Passkey screen<\/td>P1<\/td>Web<\/td>5<\/td><\/tr>
          Recovery UX<\/td>P2<\/td>Web<\/td>3<\/td><\/tr>
          WebAuthn endpoint<\/td>P1<\/td>API<\/td>5<\/td><\/tr>
          Recovery API<\/td>P2<\/td>API<\/td>3<\/td><\/tr>
          Audit dashboard<\/td>P2<\/td>Platform<\/td>3<\/td><\/tr>
          Rotate signing keys<\/td>P0<\/td>Platform<\/td>2<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          At this stage, you already have enough data to build useful views.<\/p>\n\n\n\n
          \n\n\n\n
          10. Project Views<\/h1>\n\n\n\n
          A View<\/strong> is a saved way to look at the project.<\/p>\n\n\n\n
          A view can define its own:<\/p>\n\n\n
          Layout\nFilter\nSort\nGrouping\nSlicing\nVisible fields\n<\/code><\/span><\/pre>\n\n\n
          We will create three essential views.<\/p>\n\n\n
          flowchart<\/span> TD<\/span>\n    A<\/span>[Acme Platform Delivery]<\/span> --<\/span>> B<\/span>[Backlog - Table]<\/span>\n    A<\/span> --<\/span>> C<\/span>[Current Sprint - Board]<\/span>\n    A<\/span> --<\/span>> D<\/span>[Roadmap - Timeline]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          \n\n\n\n
          11. View 1 \u2014 Backlog Table<\/h1>\n\n\n\n
          The Table layout is ideal for backlog management.<\/p>\n\n\n\n
          11.1 Configure the View<\/h2>\n\n\n\n
          Name:<\/p>\n\n\n
          Backlog\n<\/code><\/span><\/pre>\n\n\n
          Layout:<\/p>\n\n\n
          Table\n<\/code><\/span><\/pre>\n\n\n
          Show fields:<\/p>\n\n\n
          Title\nStatus\nPriority\nTeam\nSprint\nEstimate\nAssignees\nRepository\n<\/code><\/span><\/pre>\n\n\n
          Group by:<\/p>\n\n\n
          Priority\n<\/code><\/span><\/pre>\n\n\n
          Sort:<\/p>\n\n\n
          Priority\nTarget Date<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          11.2 Why This Works<\/h2>\n\n\n\n
          The backlog answers:<\/p>\n\n\n
          What work exists?\nWhat is most important?\nWho owns it?\nHow large is it?\nHas it been scheduled?\n<\/code><\/span><\/pre>\n\n\n
          11.3 Dragging Between Groups<\/h2>\n\n\n\n
          If your table is grouped by Priority:<\/p>\n\n\n
          P2 -> P1\n<\/code><\/span><\/pre>\n\n\n
          Dragging an item between groups can update its Priority value.<\/p>\n\n\n\n
          The view becomes an editing interface, not just a report.<\/p>\n\n\n\n
          \n\n\n\n
          12. View 2 \u2014 Current Sprint Board<\/h1>\n\n\n\n
          Boards are ideal for execution.<\/p>\n\n\n\n
          Create another view:<\/p>\n\n\n
          Current Sprint\n<\/code><\/span><\/pre>\n\n\n
          Layout:<\/p>\n\n\n
          Board\n<\/code><\/span><\/pre>\n\n\n
          Columns:<\/p>\n\n\n
          Status\n<\/code><\/span><\/pre>\n\n\n
          Filter:<\/p>\n\n\n
          sprint<\/span>:@current<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          Optional horizontal grouping:<\/p>\n\n\n
          Team\n<\/code><\/span><\/pre>\n\n\n
          Show card fields:<\/p>\n\n\n
          Priority\nEstimate\nAssignees\n<\/code><\/span><\/pre>\n\n\n
          Conceptually:<\/p>\n\n\n\n
                       Ready | In Progress | In Review | Done\nWeb\nAPI\nPlatform\n<\/code><\/pre>\n\n\n\n
          12.1 Card Movement Updates Data<\/h2>\n\n\n\n
          When Status drives the columns:<\/p>\n\n\n
          Ready -> In Progress\n<\/code><\/span><\/pre>\n\n\n
          means:<\/p>\n\n\n
          Status = In Progress\n<\/code><\/span><\/pre>\n\n\n
          The board is directly editing the Project field.<\/p>\n\n\n\n
          12.2 Work-in-Progress Limits<\/h2>\n\n\n\n
          A board column can have an item limit.<\/p>\n\n\n\n
          Example:<\/p>\n\n\n
          In Progress limit = 5\n<\/code><\/span><\/pre>\n\n\n
          Important:<\/p>\n\n\n\n
          \n
          A GitHub Projects WIP limit is a warning\/signal<\/strong>, not a hard enforcement rule.<\/p>\n<\/blockquote>\n\n\n\n
          \n\n\n\n
          13. View 3 \u2014 Roadmap<\/h1>\n\n\n\n
          Use Roadmap for timeline planning.<\/p>\n\n\n\n
          Create:<\/p>\n\n\n
          Roadmap\n<\/code><\/span><\/pre>\n\n\n
          Layout:<\/p>\n\n\n
          Roadmap\n<\/code><\/span><\/pre>\n\n\n
          Configure:<\/p>\n\n\n
          Start field: Start Date<\/span>\nTarget field: Target Date<\/span>\nGroup by: Team\nZoom<\/span>: Quarter\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          Example:<\/p>\n\n\n
          flowchart<\/span> LR<\/span>\n    A<\/span>[Web Work]<\/span> --<\/span>> B<\/span>[October]<\/span>\n    C<\/span>[API Work]<\/span> --<\/span>> B<\/span>\n    D<\/span>[Platform Work]<\/span> --<\/span>> E<\/span>[November]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          A real GitHub Roadmap renders these as timeline bars rather than flowchart nodes.<\/p>\n\n\n\n
          Use Roadmap for:<\/p>\n\n\n\n
            \n
          • quarterly planning;<\/li>\n\n\n\n
          • releases;<\/li>\n\n\n\n
          • multi-team coordination;<\/li>\n\n\n\n
          • major delivery windows.<\/li>\n<\/ul>\n\n\n\n
            Do not put every tiny engineering task on a long-term roadmap.<\/p>\n\n\n\n
            \n\n\n\n
            14. Filtering \u2014 The Most Important Daily Skill<\/h1>\n\n\n\n
            A good saved view is mostly:<\/p>\n\n\n
            Useful data\n+\nGood filter\n+\nRight layout\n<\/code><\/span><\/pre>\n\n\n
            14.1 Basic Filters<\/h2>\n\n\n\n
            Status:<\/p>\n\n\n
            status<\/span>:Done<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Not Done:<\/p>\n\n\n
            -status<\/span>:Done<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Repository:<\/p>\n\n\n
            repo:acme-corp\/api\n<\/code><\/span><\/pre>\n\n\n
            My work:<\/p>\n\n\n
            assignee<\/span>:@me<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Missing assignee:<\/p>\n\n\n
            no<\/span>:assignee<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Missing priority:<\/p>\n\n\n
            no<\/span>:priority<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            14.2 Combine Filters<\/h2>\n\n\n\n
            Current sprint bugs:<\/p>\n\n\n
            sprint<\/span>:@current<\/span> type:<\/span>bug\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            My unfinished work:<\/p>\n\n\n
            assignee<\/span>:@me<\/span> -status:<\/span>Done\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            High-priority incomplete work:<\/p>\n\n\n
            priority<\/span>:P0<\/span>,P1<\/span> -status<\/span>:Done<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            API work still open:<\/p>\n\n\n
            repo:acme-corp\/api -status:Done\n<\/code><\/span><\/pre>\n\n\n
            14.3 Date Filters<\/h2>\n\n\n\n
            Today:<\/p>\n\n\n
            target-date<\/span>:@today<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Next seven days:<\/p>\n\n\n
            target-date<\/span>:@today<\/span>..@today<\/span>+7\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            14.4 Iteration Filters<\/h2>\n\n\n
            sprint<\/span>:@previous<\/span>\nsprint:<\/span>@current\nsprint:<\/span>@next\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            This is one reason Iteration fields are so useful.<\/p>\n\n\n\n
            \n\n\n\n
            15. Sort vs Group vs Slice<\/h1>\n\n\n\n
            These concepts are often confused.<\/p>\n\n\n\n
            Feature<\/th>Meaning<\/th>Example<\/th><\/tr><\/thead>
            Filter<\/td>Reduce what is visible<\/td>Only current sprint<\/td><\/tr>
            Sort<\/td>Order visible items<\/td>Priority first<\/td><\/tr>
            Group<\/td>Divide into sections<\/td>Group by Team<\/td><\/tr>
            Slice<\/td>Temporarily focus on one value<\/td>Show only API team<\/td><\/tr>
            Field Sum<\/td>Add numeric values<\/td>Sum Estimate<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Simple mental model:<\/p>\n\n\n
            Filter = What should I see?\nSort   = In what order?\nGroup  = In what sections?\nSlice  = Which section\/value do<\/span> I want to focus on now?\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Example:<\/p>\n\n\n
            Filter<\/span>: sprint<\/span>:@current<\/span>\nGroup:<\/span> Team\nSort:<\/span> Priority\nSum:<\/span> Estimate\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            This gives a very useful sprint planning table.<\/p>\n\n\n\n
            \n\n\n\n
            16. Sprint Planning with Iterations<\/h1>\n\n\n\n
            A simple sprint setup needs only:<\/p>\n\n\n
            Sprint\nEstimate\nStatus\nAssignee or Team\n<\/code><\/span><\/pre>\n\n\n
            16.1 Sprint Planning Flow<\/h2>\n\n\n
            flowchart<\/span> LR<\/span>\n    A<\/span>[Prioritized Backlog]<\/span> --<\/span>> B<\/span>[Choose Sprint]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Confirm Estimates]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Check Capacity]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Commit Work]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Execute on Board]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Review Result]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            16.2 Configure the Sprint<\/h2>\n\n\n\n
            Example:<\/p>\n\n\n
            Duration<\/span>: 2 weeks\nField<\/span>: Sprint\nCurrent<\/span>: Sprint 24\nNext<\/span>: Sprint 25\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
            Recommended saved views:<\/p>\n\n\n
            Current<\/span> Sprint<\/span> -<\/span>> sprint<\/span>:@current<\/span>\nNext Sprint    -> sprint:<\/span>@next\nPrevious       -> sprint:<\/span>@previous\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            16.3 Capacity<\/h2>\n\n\n\n
            Suppose:<\/p>\n\n\n
            API capacity      = 20 points\nCommitted Estimate = 22\n<\/code><\/span><\/pre>\n\n\n
            Signal:<\/p>\n\n\n
            Potential overcommitment\n<\/code><\/span><\/pre>\n\n\n
            Projects can sum Estimate values.<\/p>\n\n\n\n
            Your team still decides what the capacity number means.<\/p>\n\n\n\n
            Never use story-point totals to score individual engineers.<\/p>\n\n\n\n
            \n\n\n\n
            17. Project Status vs Issue State<\/h1>\n\n\n\n
            This distinction matters.<\/p>\n\n\n\n
            Example:<\/p>\n\n\n
            Issue state     = Open\nProject Status  = In Review\n<\/code><\/span><\/pre>\n\n\n
            That is completely valid.<\/p>\n\n\n\n
            Why?<\/p>\n\n\n\n
            Because:<\/p>\n\n\n
            Issue state = GitHub object lifecycle\nStatus      = Planning workflow state\n<\/code><\/span><\/pre>\n\n\n
            Another example:<\/p>\n\n\n
            PR state = Open\nProject Status = In Review\n<\/code><\/span><\/pre>\n\n\n
            When the PR merges:<\/p>\n\n\n
            PR state = Merged\nProject Status = Done\n<\/code><\/span><\/pre>\n\n\n
            can be automated.<\/p>\n\n\n\n
            \n\n\n\n
            18. Built-In Project Workflows<\/h1>\n\n\n\n
            Before writing GitHub Actions or API scripts, check whether GitHub’s built-in workflows already solve the problem.<\/p>\n\n\n
            flowchart TD\n    A[Need Automation] --> B{Built-In Workflow Enough}\n    B -->|Yes| C[Use<\/span> Built<\/span>-In<\/span> Workflow<\/span>]\n    B<\/span> -->|No<\/span>| D<\/span>[Use<\/span> Actions<\/span> CLI<\/span> or<\/span> API<\/span>]\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            Built-in workflows are easier to maintain because they do not require custom code or credentials.<\/p>\n\n\n\n
            18.1 Set Initial Status<\/h2>\n\n\n\n
            Example:<\/p>\n\n\n
            When item is added\nSet<\/span> Status = Backlog\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            or:<\/p>\n\n\n
            Set<\/span> Status = Todo\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            depending on your workflow.<\/p>\n\n\n\n
            18.2 Set Done When an Issue Closes<\/h2>\n\n\n\n
            Example:<\/p>\n\n\n
            Issue closed -> Status = Done\n<\/code><\/span><\/pre>\n\n\n
            18.3 Set Done When a PR Merges<\/h2>\n\n\n\n
            Example:<\/p>\n\n\n
            PR merged -> Status = Done\n<\/code><\/span><\/pre>\n\n\n
            18.4 Reopened Work<\/h2>\n\n\n\n
            Example:<\/p>\n\n\n
            Issue reopened -> Status = Ready\n<\/code><\/span><\/pre>\n\n\n
            Use this only if that matches your team’s workflow semantics.<\/p>\n\n\n\n
            \n\n\n\n
            19. Auto-Add to Project<\/h1>\n\n\n\n
            Auto-add lets GitHub add matching repository items to a Project.<\/p>\n\n\n\n
            Example requirement:<\/p>\n\n\n
            Add every open issue with<\/span> label platform.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Example filter:<\/p>\n\n\n
            is<\/span>:issue<\/span> is<\/span>:open<\/span> label<\/span>:platform<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Workflow:<\/p>\n\n\n
            flowchart LR\n    A[Issue Created or Updated] --> B{Matches Filter}\n    B -->|Yes| C[Add to Project]\n    B -->|No| D[Ignore]\n<\/code><\/span><\/pre>\n\n\n
            19.1 Important Limitation<\/h2>\n\n\n\n
            Auto-add is not the same as historical backfill.<\/p>\n\n\n\n
            If you enable a rule today, existing items that already matched earlier may still need to be bulk-added manually.<\/p>\n\n\n\n
            19.2 Good Uses<\/h2>\n\n\n
            label<\/span>:roadmap<\/span>\nlabel<\/span>:platform<\/span>\nlabel<\/span>:security<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Use clear labels or deterministic rules.<\/p>\n\n\n\n
            Avoid building dozens of fragile auto-add rules.<\/p>\n\n\n\n
            \n\n\n\n
            20. Auto-Archive<\/h1>\n\n\n\n
            Completed work eventually clutters active views.<\/p>\n\n\n\n
            Auto-archive keeps the Project useful.<\/p>\n\n\n\n
            Typical lifecycle:<\/p>\n\n\n
            flowchart<\/span> LR<\/span>\n    A<\/span>[Active]<\/span> --<\/span>> B<\/span>[Done]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Retention Period]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Archived]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Example policy:<\/p>\n\n\n
            Completed work stays visible for 30 days.\nThen it is archived.\n<\/code><\/span><\/pre>\n\n\n
            Archive is usually better than delete because archived items can be restored and keep their Project context.<\/p>\n\n\n\n
            \n\n\n\n
            21. Insights \u2014 What Students Should Know<\/h1>\n\n\n\n
            Insights create charts from Project data.<\/p>\n\n\n\n
            Useful examples:<\/p>\n\n\n
            Items by Status\nItems by Priority\nEstimate by Team\nWork by Repository\n<\/code><\/span><\/pre>\n\n\n
            Example:<\/p>\n\n\n
            Filter<\/span>: sprint<\/span>:@current<\/span>\nX-axis:<\/span> Status\nGroup by:<\/span> Team\nY-axis:<\/span> Sum of Estimate\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Do not overbuild dashboards.<\/p>\n\n\n\n
            For a 2-hour course, remember:<\/p>\n\n\n\n
            \n
            Charts are only as good as the fields behind them.<\/p>\n<\/blockquote>\n\n\n\n
            If half the project has no Priority, a Priority chart is incomplete.<\/p>\n\n\n\n
            \n\n\n\n
            22. Permissions and Visibility \u2014 Essential Safety<\/h1>\n\n\n\n
            Projects can be:<\/p>\n\n\n
            Private<\/span>\nPublic<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            For internal company work:<\/p>\n\n\n
            Private<\/span> = safest default<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            Typical access model:<\/p>\n\n\n\n
            User Type<\/th>Project Role<\/th><\/tr><\/thead>
            Stakeholder<\/td>Read<\/td><\/tr>
            Delivery team<\/td>Write<\/td><\/tr>
            Project maintainers<\/td>Admin<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Important:<\/p>\n\n\n\n
            \n
            Project permission does not automatically grant access to private repository content.<\/p>\n<\/blockquote>\n\n\n\n
            Also remember that a public Project can expose planning metadata even when linked repository content remains private.<\/p>\n\n\n\n
            Potentially sensitive information includes:<\/p>\n\n\n
            Roadmap dates\nInternal priorities\nProduct codenames\nSecurity remediation work\nCustomer names\nRelease plans\n<\/code><\/span><\/pre>\n\n\n
            \n\n\n\n
            23. Minimal Production-Ready Project<\/h1>\n\n\n\n
            A good starting configuration:<\/p>\n\n\n
            Project:\n  Acme Platform Delivery\n\nOwner:\n  Organization\n\nVisibility:\n  Private<\/span>\n\nAdmins:\n  At least 2<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            Fields:<\/p>\n\n\n
            Status\nPriority\nSprint\nEstimate\nTeam\nStart Date<\/span>\nTarget Date<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Views:<\/p>\n\n\n
            Backlog\nCurrent Sprint\nRoadmap\nMy Work\nRisks\n<\/code><\/span><\/pre>\n\n\n
            Workflows:<\/p>\n\n\n
            Set<\/span> initial Status\nSet<\/span> Done when issue closes\nSet<\/span> Done when PR merges\nAuto-add deterministic work\nAuto-archive old completed work\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Documentation:<\/p>\n\n\n
            Purpose\nScope\nField definitions\nStatus definitions\nView definitions\nAutomation rules\nOwnership\n<\/code><\/span><\/pre>\n\n\n
            \n\n\n\n
            24. Final 10-Minute Hands-On Lab<\/h1>\n\n\n\n
            Build the complete flow.<\/p>\n\n\n\n
            Step 1 \u2014 Create Project<\/h2>\n\n\n
            Acme Platform Delivery\n<\/code><\/span><\/pre>\n\n\n
            Step 2 \u2014 Add Fields<\/h2>\n\n\n
            Status\nPriority\nSprint\nEstimate\nTeam\nStart Date<\/span>\nTarget Date<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Step 3 \u2014 Add Six Items<\/h2>\n\n\n\n
            Use the sample work from this guide.<\/p>\n\n\n\n
            Step 4 \u2014 Configure Backlog<\/h2>\n\n\n
            Layout<\/span>: Table\nGroup<\/span>: Priority\nFields<\/span>: Status, Priority, Team, Estimate, Sprint\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
            Step 5 \u2014 Configure Sprint Board<\/h2>\n\n\n
            Layout<\/span>: Board\nColumns<\/span>: Status\nFilter<\/span>: sprint:@current\nGroup<\/span>: Team\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
            Step 6 \u2014 Configure Roadmap<\/h2>\n\n\n
            Layout<\/span>: Roadmap\nStart<\/span>: Start Date\nTarget<\/span>: Target Date\nGroup<\/span>: Team\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
            Step 7 \u2014 Enable Workflows<\/h2>\n\n\n
            Item added -> Initial Status\nIssue closed -> Done\nPR merged -> Done\n<\/code><\/span><\/pre>\n\n\n
            Step 8 \u2014 Test the Complete Lifecycle<\/h2>\n\n\n
            flowchart<\/span> LR<\/span>\n    A<\/span>[Create Issue]<\/span> --<\/span>> B<\/span>[Add to Project]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Set Priority and Team]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Assign Sprint]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Move Through Board]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Close Issue or Merge PR]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Status Done]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Archive Later]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Validation:<\/p>\n\n\n
            [ ]<\/span> Item<\/span> appears<\/span> in<\/span> the<\/span> Project<\/span>\n[ ]<\/span> Required<\/span> fields<\/span> are<\/span> visible<\/span>\n[ ]<\/span> Backlog<\/span> grouping<\/span> works<\/span>\n[ ]<\/span> Sprint<\/span> filter<\/span> works<\/span>\n[ ]<\/span> Board<\/span> movement<\/span> updates<\/span> Status<\/span>\n[ ]<\/span> Roadmap<\/span> displays<\/span> planning<\/span> dates<\/span>\n[ ]<\/span> Close<\/span> or<\/span> merge<\/span> updates<\/span> Status<\/span>\n[ ]<\/span> Permissions<\/span> are<\/span> appropriate<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            \n\n\n\n
            25. Essential Filter Cheat Sheet<\/h1>\n\n\n\n
            Goal<\/th>Filter<\/th><\/tr><\/thead>
            My unfinished work<\/td>assignee:@me -status:Done<\/code><\/td><\/tr>
            Current sprint<\/td>sprint:@current<\/code><\/td><\/tr>
            Next sprint<\/td>sprint:@next<\/code><\/td><\/tr>
            Previous sprint<\/td>sprint:@previous<\/code><\/td><\/tr>
            P0\/P1 incomplete<\/td>priority:P0,P1 -status:Done<\/code><\/td><\/tr>
            API work<\/td>repo:acme-corp\/api<\/code><\/td><\/tr>
            API open work<\/td>repo:acme-corp\/api -status:Done<\/code><\/td><\/tr>
            Missing assignee<\/td>no:assignee<\/code><\/td><\/tr>
            Missing priority<\/td>no:priority<\/code><\/td><\/tr>
            Target today<\/td>target-date:@today<\/code><\/td><\/tr>
            Target in next 7 days<\/td>target-date:@today..@today+7<\/code><\/td><\/tr>
            Open issues<\/td>is:issue is:open<\/code><\/td><\/tr>
            Pull requests<\/td>is:pr<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            \n\n\n\n
            26. Essential Design Rules<\/h1>\n\n\n\n
            Remember these ten rules.<\/p>\n\n\n\n
              \n
            1. Use Issues for real repository work.<\/strong><\/li>\n\n\n\n
            2. Use Draft Issues for ideas not ready for a repository.<\/strong><\/li>\n\n\n\n
            3. Create one Project when multiple views can solve the audience problem.<\/strong><\/li>\n\n\n\n
            4. Keep custom fields minimal.<\/strong><\/li>\n\n\n\n
            5. Keep Status simple.<\/strong><\/li>\n\n\n\n
            6. Use Iteration for sprints instead of free-text sprint names.<\/strong><\/li>\n\n\n\n
            7. Use Table for planning and bulk editing.<\/strong><\/li>\n\n\n\n
            8. Use Board for execution flow.<\/strong><\/li>\n\n\n\n
            9. Use Roadmap for timeline communication.<\/strong><\/li>\n\n\n\n
            10. Automate deterministic bookkeeping before building custom Actions or APIs.<\/strong><\/li>\n<\/ol>\n\n\n\n
              \n\n\n\n
              27. Common Mistakes<\/h1>\n\n\n\n
              Mistake 1 \u2014 Too Many Fields<\/h2>\n\n\n\n
              Bad:<\/p>\n\n\n
              Priority\nBusiness Priority\nEngineering Priority\nPM Priority\nCustomer Priority\n<\/code><\/span><\/pre>\n\n\n
              Better:<\/p>\n\n\n
              One clearly defined Priority field\n<\/code><\/span><\/pre>\n\n\n
              Mistake 2 \u2014 Too Many Statuses<\/h2>\n\n\n\n
              Bad:<\/p>\n\n\n
              Todo\nReady\nReady for Dev\nDevelopment\nDev Complete\nQA\nQA Complete\nReview\nReady for Release\nReleased\nClosed\n<\/code><\/span><\/pre>\n\n\n
              Use only the states that change a real operational decision.<\/p>\n\n\n\n
              Mistake 3 \u2014 Separate Project for Every Repository<\/h2>\n\n\n\n
              Do not automatically create:<\/p>\n\n\n
              Web Project\nAPI Project\nInfra Project\n<\/code><\/span><\/pre>\n\n\n
              when one shared delivery Project with repository filters would work better.<\/p>\n\n\n\n
              Mistake 4 \u2014 Manual Done Updates<\/h2>\n\n\n\n
              If closing an issue always means the Project should show Done, automate it.<\/p>\n\n\n\n
              Mistake 5 \u2014 No Archive Policy<\/h2>\n\n\n\n
              Years of completed work mixed with active work makes the Project harder to use.<\/p>\n\n\n\n
              Mistake 6 \u2014 Public by Accident<\/h2>\n\n\n\n
              A public Project can reveal planning metadata.<\/p>\n\n\n\n
              Use Private unless public planning is intentional.<\/p>\n\n\n\n
              \n\n\n\n
              28. Optional 5-Minute Advanced Preview \u2014 CLI and Actions<\/h1>\n\n\n\n
              This section is not required for the core 2-hour learning objective<\/strong>, but it helps students understand where Projects can go next.<\/p>\n\n\n\n
              28.1 GitHub CLI<\/h2>\n\n\n\n
              List Projects:<\/p>\n\n\n
              gh project list<\/span> --owner acme-corp\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
              List fields:<\/p>\n\n\n
              gh project field-list<\/span> 7<\/span> --owner acme-corp\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
              List items:<\/p>\n\n\n
              gh project item-list<\/span> 7<\/span> --owner acme-corp\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
              Add an issue:<\/p>\n\n\n
              gh project item-add 7<\/span> \\\n  --owner acme-corp \\\n  --url 'https:\/\/github.com\/acme-corp\/api\/issues\/201'<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              28.2 GitHub Actions Example<\/h2>\n\n\n\n
              If built-in auto-add cannot express your rule, GitHub Actions can add items.<\/p>\n\n\n
              name: Add roadmap issues to project\n\non<\/span>:\n  issues:\n    types: [opened, labeled]\n\njobs<\/span>:\n  add-to-project:\n    if<\/span>: contains(github.event.issue.labels.*.name, 'roadmap'<\/span>)\n    runs-on: ubuntu-latest\n\n    steps<\/span>:\n      - name: Add issue to project\n        uses<\/span>: actions\/add-to-project@v2\n        with<\/span>:\n          project-url: https:\/\/github.com\/orgs\/acme-corp\/projects\/7<\/span>\n          github-token: ${{ secrets.PROJECT_TOKEN }}\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              Use custom automation only when built-in workflows are not enough.<\/p>\n\n\n\n
              \n\n\n\n
              29. What to Learn Next<\/h1>\n\n\n\n
              After completing this 2-hour Essentials tutorial, continue with the full reference guide for:<\/p>\n\n\n
              GitHub Actions + Projects\ngh project CLI\nGraphQL ProjectV2\nREST Projects API\nGitHub Apps\nSecurity architecture\nOrganization governance\nEnterprise governance\nAdvanced field architecture\nParent and sub-issues\nDependencies\nCapacity planning\nPortfolio management\nAdvanced roadmaps\nAdvanced Kanban\nCross-repository architecture\nTemplates at scale\nAPI authentication\nLimits and constraints\nMigration from<\/span> Projects Classic\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              \n\n\n\n
              30. Final Mental Model<\/h1>\n\n\n\n
              If students remember only one diagram, make it this one:<\/p>\n\n\n
              flowchart<\/span> LR<\/span>\n    A<\/span>[Issues PRs Drafts]<\/span> --<\/span>> B<\/span>[Project]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Fields]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Views]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Table Board Roadmap]<\/span>\n    B<\/span> --<\/span>> F<\/span>[Workflows]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Less Manual Work]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
              And one sentence:<\/p>\n\n\n\n
              \n
              GitHub Projects is a structured planning layer over GitHub Issues, Pull Requests, and Draft Issues, using fields, views, and automation to turn repository work into a manageable delivery system.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
              \n\n\n\n
              31. Student Revision Checklist<\/h1>\n\n\n\n
              A student who can answer all of these is ready to use GitHub Projects effectively.<\/p>\n\n\n
              [ ]<\/span> What<\/span> is<\/span> the<\/span> difference<\/span> between<\/span> an<\/span> Issue<\/span> and<\/span> a<\/span> Project<\/span>?\n[ ]<\/span> What<\/span> are<\/span> the<\/span> three<\/span> Project<\/span> item<\/span> types<\/span>?\n[ ]<\/span> When<\/span> should<\/span> I<\/span> use<\/span> a<\/span> Draft<\/span> Issue<\/span>?\n[ ]<\/span> What<\/span> is<\/span> a<\/span> Project<\/span> custom<\/span> field<\/span>?\n[ ]<\/span> Why<\/span> use<\/span> Iteration<\/span> for<\/span> Sprint<\/span>?\n[ ]<\/span> What<\/span> is<\/span> the<\/span> difference<\/span> between<\/span> Table<\/span>, Board<\/span>, and<\/span> Roadmap<\/span>?\n[ ]<\/span> What<\/span> does<\/span> filtering<\/span> do<\/span>?\n[ ]<\/span> What<\/span> is<\/span> the<\/span> difference<\/span> between<\/span> filter<\/span>, sort<\/span>, group<\/span>, and<\/span> slice<\/span>?\n[ ]<\/span> What<\/span> does<\/span> sprint<\/span>:@current<\/span> mean?\n[ ] What is the difference between Project Status and<\/span> Issue state?\n[ ] What should happen when an issue closes?\n[ ] What is Auto-add?\n[ ] Why is Auto-archive useful?\n[ ] What is the safest default Project visibility?\n[ ] When should I prefer built-in workflows over GitHub Actions?\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
              \n\n\n\n
              32. Trainer Delivery Notes<\/h1>\n\n\n\n
              For a live 2-hour class, do not spend equal time on every feature.<\/p>\n\n\n\n
              Recommended emphasis:<\/p>\n\n\n
              20% Concepts\n50% UI demonstration and hands-on practice\n20% Filters, sprint flow, and automation\n10% Review and troubleshooting\n<\/code><\/span><\/pre>\n\n\n
              The most valuable live demonstrations are:<\/p>\n\n\n\n
                \n
              1. Add an Issue to the Project.<\/li>\n\n\n\n
              2. Change fields inline.<\/li>\n\n\n\n
              3. Group a Table by Priority.<\/li>\n\n\n\n
              4. Drag a Board card from Ready to In Progress.<\/li>\n\n\n\n
              5. Filter using\u00a0sprint:@current<\/code>.<\/li>\n\n\n\n
              6. Create a Roadmap using Start Date and Target Date.<\/li>\n\n\n\n
              7. Close an Issue and show Status automation.<\/li>\n\n\n\n
              8. Explain why one Project can support many audiences through saved views.<\/li>\n<\/ol>\n\n\n\n
                Avoid spending core class time on GraphQL IDs, REST endpoints, or enterprise governance unless the audience specifically needs administration or automation engineering.<\/p>\n\n\n\n
                \n\n\n\n
                33. Official References<\/h1>\n\n\n\n
                GitHub Projects changes regularly. Verify behavior using the current official documentation.<\/p>\n\n\n\n
                  \n
                1. GitHub Projects documentation
                  https:\/\/docs.github.com\/en\/issues\/planning-and-tracking-with-projects<\/a><\/li>\n\n\n\n
                2. Quickstart for Projects
                  https:\/\/docs.github.com\/en\/issues\/planning-and-tracking-with-projects\/learning-about-projects\/quickstart-for-projects<\/a><\/li>\n\n\n\n
                3. Adding items to Projects
                  https:\/\/docs.github.com\/en\/issues\/planning-and-tracking-with-projects\/managing-items-in-your-project\/adding-items-to-your-project<\/a><\/li>\n\n\n\n
                4. Filtering Projects
                  https:\/\/docs.github.com\/en\/issues\/planning-and-tracking-with-projects\/customizing-views-in-your-project\/filtering-projects<\/a><\/li>\n\n\n\n
                5. Automating Projects
                  https:\/\/docs.github.com\/en\/issues\/planning-and-tracking-with-projects\/automating-your-project<\/a><\/li>\n\n\n\n
                6. GitHub CLI\u00a0gh project<\/code>
                  https:\/\/cli.github.com\/manual\/gh_project<\/a><\/li>\n\n\n\n
                7. Official\u00a0actions\/add-to-project<\/code>\u00a0action
                  https:\/\/github.com\/actions\/add-to-project<\/a><\/li>\n<\/ol>\n\n\n\n
                  \n\n\n\n
                  Final Takeaway<\/h1>\n\n\n\n
                  For an effective GitHub Projects implementation, start small:<\/p>\n\n\n
                  Issues and PRs\n      |\n      v\nSmall Field Set<\/span>\n      |\n      v\nBacklog + Sprint + Roadmap Views\n      |\n      v\nBuilt-In Automation\n      |\n      v\nSimple Governance\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Do not begin with dozens of fields, complex APIs, or a portfolio hierarchy.<\/p>\n\n\n\n
                  First make sure the team can answer:<\/p>\n\n\n
                  What work exists?\nWhat is important?\nWho owns it?\nWhat are we doing now?\nWhat is next?\nWhen is it expected?\nWhat is done?\n<\/code><\/span><\/pre>\n\n\n
                  If GitHub Projects answers those questions clearly, the Project is already doing its most important job.<\/p>\n","protected":false},"excerpt":{"rendered":"
                  Scope: Current GitHub Projects \/ Projects v2, not Projects (classic).Audience: Developers, DevOps engineers, engineering managers, product managers, project administrators, and GitHub organization members.Training duration: Approximately 2 hours, including guided practice.Prerequisite: Basic familiarity with… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[11138],"tags":[],"class_list":["post-78746","post","type-post","status-publish","format-standard","hentry","category-best-tools"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78746","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=78746"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78746\/revisions"}],"predecessor-version":[{"id":78747,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78746\/revisions\/78747"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=78746"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=78746"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=78746"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}