GitHub API Discrepancy: Issue Templates and Your Application Development Project Plan

The Hidden Discrepancy: GitHub UI vs. API for Issue Templates

In the world of application development project plan execution, reliable data is paramount. A recent GitHub Community discussion, initiated by user jmrplens, brought to light a significant inconsistency in how GitHub reports the presence of issue templates. While the repository's community profile page might proudly display a green checkmark and a 100% completion score for issue templates, the underlying REST and GraphQL APIs tell a different story, often reporting these templates as non-existent or incomplete. This disconnect poses a challenge for automated tools and workflows that rely on accurate API data to assess project health and guide an application development project plan.

The Problem Unveiled: UI Green, API Null

The core of the issue lies in how GitHub's APIs interpret modern issue template formats, particularly YAML issue forms and directory-based Markdown templates. Jmrplens demonstrated this with their jmrplens/gitlab-mcp-server repository, which uses YAML issue forms under .github/ISSUE_TEMPLATE/. Despite the community page showing 'Issue templates' as added and a 100% health score, the APIs returned:

• REST API (GET /repos/{owner}/{repo}/community/profile): "files": { "issue_template": null }
• GraphQL API (Repository.issueTemplates): []

This means that any tool programmatically checking the repository's community health via these APIs would incorrectly conclude that no issue templates are present, directly contradicting the visual representation on the GitHub website. This can severely impact the ability to automate checks for community readiness as part of an overarching application development project plan.

API Specifics: What's Missing Where?

Jmrplens provided a detailed breakdown of how different template layouts behave across the APIs:

• REST files.issue_template: This field is only non-null for the legacy single file .github/ISSUE_TEMPLATE.md. It returns null for directories of Markdown or YAML templates, even when the community page counts them.
• GraphQL issueTemplates: This API lists Markdown templates within a directory (e.g., cli/cli), but crucially, it does not include YAML issue forms (the recommended modern format) nor the legacy single file (e.g., github/gh-ost).

Here's the REST API example provided in the discussion:

curl -s -H "Authorization: Bearer $TOKEN" -H "X-GitHub-Api-Version: 2022-11-28" \
 https://api.github.com/repos/jmrplens/gitlab-mcp-server/community/profile \
 | jq '{health_percentage, issue_template: .files.issue_template}'

{
  "health_percentage": 100,
  "issue_template": null
}

And the GraphQL example:

{
  repository(owner: "jmrplens", name: "gitlab-mcp-server") {
    issueTemplates {
      name
      filename
    }
  }
}

{
  "data": {
    "repository": {
      "issueTemplates": []
    }
  }
}

Why This Matters for Your Project Plan

The implications are significant for developer productivity and the integrity of an application development project plan. Tools designed to monitor repository health, onboard new contributors, or automate checks for best practices would receive misleading information from GitHub's APIs. This forces developers to implement cumbersome workarounds, such as directly listing directory contents via the contents API or GraphQL Tree, to get accurate template information.

Jmrplens's 'Ask' was clear: either make the REST API's files.issue_template reflect the same detection logic as the community page, or document its limitations. For GraphQL, the request was to include YAML issue forms and the legacy single file for consistency.

Community Experience: A Closed Discussion

Adding another layer to this community insight, the discussion itself was closed by github-actions shortly after creation, citing that it was not submitted through the expected format. While this is an automated response, it highlights potential friction points for community members trying to report detailed technical issues and contribute to platform improvements.

Conclusion

Reliable and consistent API data is crucial for fostering healthy open-source communities and enabling robust automation in any application development project plan. The discrepancy between GitHub's UI and its APIs regarding issue template detection is a notable challenge that, if addressed, would significantly enhance developer productivity and the accuracy of programmatic community health assessments.