Navigating GitHub's 'Favorite' Labels: A UX Trade-off for Efficient Development Activity

GitHub's recent update to its label picker UI, introducing a "Favorite" labels section, has sparked considerable discussion within the developer community. While seemingly designed to boost efficiency, this change has inadvertently disrupted established workflows for many users, impacting how teams track and manage their development activity examples.

Developer encountering GitHub's
Developer encountering GitHub's "Favorite" labels, using search to navigate.

The Unexpected Friction: When "Smart" Becomes Annoying

The core of the frustration stems from the "Favorite" section's automatic and non-configurable nature. Instead of duplicating frequently used labels at the top, GitHub moves them from their traditional alphabetical positions. For developers who rely on muscle memory and spatial recognition to quickly locate labels—a common practice for managing tasks and tracking software project metrics—this introduces a significant cognitive load.

As one user aptly put it, it's "like reaching for a 10mm wrench in the row of wrenches, and instead finding a note that says 'you use this wrench a lot, so we moved it next to the water fountain for your convenience'." This analogy perfectly encapsulates the disruption: a predictable, near O(1) positional lookup is transformed into a variable-cost scan, hindering efficient workflow.

GitHub's Intent vs. User Experience

The likely intent behind the "Favorite" section is to optimize for frequency-based access, reducing the average selection time for casual users. By presenting a dynamic subset of commonly used labels, GitHub aims to create a priority partition:

Favorites (dynamic subset)
-------------------------
All labels (alphabetical)

However, for power users and those with well-established labeling conventions (e.g., prefix-based categories for types, priorities, and efforts), this "smart" sorting introduces layout instability, breaking the predictable indexing they've come to rely on.

Analogy of a misplaced tool in a toolbox, representing GitHub's moved labels.
Analogy of a misplaced tool in a toolbox, representing GitHub's moved labels.

Navigating the Change: Workarounds and Community Solutions

As of now, there is no built-in setting to disable or customize the "Favorite" section. The community has, however, identified several practical approaches:

Official Workarounds (and Best Practices):

  • Aggressive Search Box Usage: The most recommended solution. The label picker auto-focuses its search field. Typing 2-3 characters of a label name instantly collapses the "Favorites" section and provides a filtered list. This keyboard-first approach bypasses the grouping entirely.
  • Consistent Naming Conventions: Maintain short, distinctive prefixes (e.g., bug-fix, priority-high). This makes the search function even more effective and helps categorize your development activity examples.
  • Reduce Label Entropy: Consolidating rarely used labels or splitting repositories by concern can lower the overall number of labels (N), reducing scan cost regardless of UI changes.

Community-Driven (Advanced) Solutions:

For those seeking to restore the original alphabetical order, more advanced, client-side solutions have emerged:

  • Ad-blocker (Limited): While some initially suggested using tools like uBlock Origin to hide the "Favorites" header, this is only partially effective because labels are moved, not duplicated. Hiding the header doesn't bring the labels back to their original alphabetical positions.
  • User Script (Tampermonkey/Violentmonkey): A more robust solution involves a browser user script to grab all labels from both sections, re-sort them alphabetically, and display them in a single flat list. This requires some technical comfort and maintenance, as GitHub's DOM selectors might change over time.

    // ==UserScript==
    // @name GitHub: Flatten label picker
    // @match https://github.com/*
    // @run-at document-idle
    // ==/UserScript==
    const flatten = (picker) => {
      const groups = [...picker.querySelectorAll('[data-group-name]')];
      if (groups.length < 2) return; // Only flatten if there are multiple groups
      const c
      const allItems = [];
      groups.forEach(group => {
        [...group.querySelectorAll('label-picker-item')].forEach(item => allItems.push(item));
        group.remove(); // Remove original groups
      });
      allItems.sort((a, b) => a.textContent.trim().localeCompare(b.textContent.trim()));
      container.innerHTML = '';
      allItems.forEach(item => container.appendChild(item));
    };
    new MutationObserver(() => {
      const picker = document.querySelector('[data-testid="label-picker-dialog"]');
      if (picker) flatten(picker);
    }).observe(document.body, { childList: true, subtree: true });
    

The Path Forward: Advocating for User Control

The discussion highlights a classic UX trade-off between simplifying for the average user and empowering power users. Many developers are advocating for GitHub to introduce an option to disable "Favorites" grouping or allow user-defined pinning. The argument for predictable indexing and spatial memory for managing complex software project metrics and development activity examples is strong. While the GitHub roadmap repository is read-only for users, continuing to voice this feedback in community discussions is crucial for influencing future UX improvements.

Ultimately, for tools designed to enhance developer productivity, predictability and user control often outweigh "smart" heuristics that disrupt established, efficient workflows.

|

Dashboards, alerts, and review-ready summaries built on your GitHub activity.

 Install GitHub App to Start
Dashboard with engineering activity trends