GitHub Projects

Automation between GitHub Projects and Issues is incomplete. Webhooks don't support project field changes, forcing teams to run expensive scheduled jobs for synchronization. For example, automatically updating labels when issues move between project fields has no native support.

When a subissue is created and added to the main ticket, it automatically inherits all parent project assignments by default. This breaks QA workflows where subissues shouldn't be included in the QA project until QA review, but Slack alerts are still triggered for the unwanted assignments.

GitHub Projects uses static fields across all issue types within a project, making semantic modeling difficult. Some fields (e.g., 'Effort') only apply to Tasks; others ('Impact Area') only to Bugs. This creates clutter and confusion when managing Tasks, Stories, and Bugs in a single project view.

With the expanded 50,000 item limit in GitHub Projects, duplicate naming becomes a real problem. Multiple issues named 'UI' across different issue types (Tasks, Stories, Bugs) appear in the same view without clear differentiation, causing confusion and reducing project clarity.