does it make sense to create a pull request without code

Question

Background

In our start-ups documentation, we got this:

Difference between a pull request and an issue page

In a nutshell, an issue page should only include information and discussion about the issue itself (ie clarifying requirements, suggesting edits to the requirements etc) It should never include any information or data about the actual solution.

The PR page, on the other hand, should only include data/discussion about the solution. It should never include any information about the nature of the requirements, that should only be in the issue page.

Why?

b/c the issue and its solution are two different things. Issue requirements should be fixed and clear, whereas the same requirement may have many different solutions and solution paths. So a proposed solution should be hosted separately from the issue page, as we don’t want a proposed solution to influence the requirements of an issue. For example we can assign a task to an engineer, and they can spend a week and present a solution that’s absolutely not acceptable. With that solution being hosted on a separate PR page, we can cleanly reject that solution and simply assign the same task to another engineer etc.

Question

Given the above, does it make sense to be able to create a PR without having branches at all? While none of the major git based online project management tool players allow it (I checked github/gitlab and bitbucket), in theory it can be done if I fiddle with the code of gitlab.

Update (adding to answer below)

I really liked Karl Bielefeldt's answer.. I just wanted to add this: Since the project we're working on has a very aggressive release and deploy cycle, there is little tolerance for stubbed code being added to the main branch. To address that, I think it makes sense to create R&D PRs against a topic branch, where the output wouuld be a discussion, google docs etc, plus some stubbed code, and eventually when the implementation happens (which should then remove the stubbed code and replace it with actual code).. the PR for that can be done against master branch.. and everyone wins :)

Answer 1

You don't need changed code to open a pull request, but you do need a branch, because the intent is to eventually push some code, even if that intent doesn't always materialize.

Using a pull request to communicate about implementation details before you start coding has a couple of big advantages over a mailing list. It allows you to subscribe only to the bugs or features you are interested in. This is useful both for maintainers on large projects who must split up the work and for third parties who are only interested in one or two upcoming features or bug fixes. You don't have to filter through the entire mailing list just to see what interests you.

Also, your implementation discussion is forever associated with the commits in version control, so if people have questions about why it was designed that way, or what alternatives were discussed and discarded, it's easy to find the discussion to refer to.

For these two reasons, opening a pull request with an empty branch is becoming more and more common in the newer, larger open source projects, at least for the features that require extensive implementation discussion. Kubernetes is a good example. Github even has features like task lists that make this sort of work flow easier.

Answer 2

No. The main point of what you have quoted seems to be to keep the solution and problem separate. This does not require an actual pull request before code is written; any proposal discussions can be kept in a separate document (which I suspect may be what the docs mean by PR page).