Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Possible Schema Inaccuracy] multiple PR fields have odd description

Open
#691 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Tech stack
openapi
Domain
api, documentation

Research direction

Start by locating the "pull-request" response/schema and inspect the definitions of mergeable, draft, rebaseable, and mergeable_state. Compare their optional and nullable behavior with the GraphQL API's MergeStateStatus enum; done means the schema either documents these behaviors clearly or represents the fields and enum values accurately.

Written by the indexing model from the issue text.

Description

feature fundamentals-and-support inaccuracy P4 shield waiting for review

I'm not entirely sure that these are schema inaccuracies but multiple fields of PRs (specifically the "pull-request" response / schema) have an odd definition:

  • mergeable is a nullable boolean field,it is not otherwise documented, it's hard to fathom why a PR would be something other than "mergeable" and "not mergeable". Either the field should be marked required, or the behaviour should be explained (I guess "we don't know if it's mergeable yet" is possible but in that case why not just set it to non-mergeable?).
  • draft is somewhat similarly an optional boolean, it's not clear when it would be absent (possibly projects which don't support / allow draft PRs? still why have that in the response rather than just false?)
  • rebaseable is both nullable and optional, same remarks as above.
  • mergeable_state is completely undocumented aside from knowing it's a string. Looking at the GraphQL API, it the example value ("clean") matches the MergeStateStatus enum. If this is the right conversion, mergeable_state should be defined as an enum with those values provided (and documented as they are in the graphql schema, maybe).
Dominant language
No language data
Stars
1.6k
Forks
342
Avg merge
2h 23m
Merged PRs (30d)
57

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/rest-api-description

All issues in github/rest-api-description

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.