Improving Software Development Activity: A Call for a PR-Centric GitHub Copilot View
The Challenge of Managing Copilot-Generated PRs
In the fast-paced world of software development, tools like GitHub Copilot are designed to accelerate coding and streamline workflows. However, community discussions often reveal areas where even the most advanced tools can create friction. A recent GitHub Community discussion (#189818), initiated by marcpopMSFT, sheds light on a significant pain point for developers using Copilot: the lack of a PR-centric view and frustrating default behaviors that hinder efficient software development activity.
A Session-Focused View Hinders Developer Workflow
The core of the issue lies in GitHub Copilot's primary interface, which is heavily session-focused rather than pull request (PR) oriented. For developers who use Copilot to quickly create PRs, this session-centric view presents several challenges:
- Difficulty in Locating PRs: Users like marcpopMSFT rely on custom bookmarked queries to find Copilot-generated PRs assigned to them, as the default home page view prioritizes 'sessions'.
- Misleading 'Active' Status: The current system lists completed PRs as 'active sessions', leading to a cluttered and inaccurate representation of ongoing work. A developer might have only 10 active Copilot PRs but sees 31 'active sessions', making it hard to discern actual progress and impacting developer performance review metrics.
- Inefficient Navigation: While a hover button might offer a path to the PR from a session, the overall experience is cumbersome, requiring extra steps to get to the relevant pull request.
The Disruptive Default: No PRs by Default
Beyond the view, a major source of frustration is Copilot's default behavior regarding PR creation. The experience where "sessions no longer create pull requests by default" has been widely criticized. MarcpopMSFT explicitly states a desire to disable this feature, noting that they only use sessions when something goes wrong. For routine changes, they prefer to interact with Copilot directly within the PR or use CLI/IDE tools for more interactive planning.
This sentiment was strongly echoed by gr8codes in a reply, calling it "one of the most disruptive silent defaults I've seen shipped." The current "workaround" of explicitly prompting Copilot to create a PR every single time is not seen as a solution, but rather a "punishment" for a missing toggle.
A Simple Solution for Enhanced Productivity
The community's proposed solution is straightforward and elegant: a simple toggle in Copilot settings. Gr8codes suggests a one-line option:
Settings → Copilot → Coding Agent → Default session output: [Branch push / Pull Request]Such a setting would empower developers to tailor their Copilot experience to their preferred workflow, significantly improving the efficiency of their software development activity. It highlights how minor UI/UX decisions can have a substantial impact on daily developer productivity and overall satisfaction.
The Impact on Software Development Activity
This discussion underscores a crucial aspect of developer tooling: the importance of aligning tool behavior with user expectations and established workflows. When a tool's defaults or interface create friction, it directly impedes software development activity, leading to wasted time and increased cognitive load. Providing a PR-centric view and a configurable default for PR creation would not only address immediate frustrations but also foster a more seamless and productive environment for developers relying on GitHub Copilot.
