Pull Request Templates improvements: support .github-private and UI for picking template

[Ignigena]

Select Topic Area

Product Feedback

Body

The ability to create organization-wide Pull Request templates is fantastic -- but currently requires placing the template in a public .github repository. It does not seem to be supported with the new .github-private repository which can be used for members-only profile contents.

It would be fantastic to have the option to store a PR template in the private repository which is applied for any Private repos on the organization with a similar reasoning to the members-only profile snippet: sometimes we want a specific PR template to show for internal contributors that are different from the one shown on public repositories. Linking to internal pages and other such customizations.

Also, it appears that one can create multiple PR templates by creating one or more markdown files at PULL_REQUEST_TEMPLATE/*.md which is fantastic -- having separate templates for bug fixes vs. features for example would be great. Have used this quite frequently on the Issue templates and one of the biggest values of this is the UI that it enables which forces a user to pick the issue type and see the appropriate template ex: https://github.com/angular/angular/issues/new/choose

However, when one creates multiple pull request templates what actually happens is that none of the templates are used by default unless a special ?template= query param is added the URL. This makes the PR templates a bit less useful since it requires that users follow a specific link while creating the PR vs. being prompted to choose via the GitHub UI on the Web.

Lastly ... can we please have issue form YAML syntax for PR templates 🙏🏻

That's all for now 😄

[ARolek]

I'm also encountering this situation. This seems like a great use of the special .github-private repo.

[james-trousdale-lyb]

👍 - our company has migrated to an EMU instance, and this is a major feature gap right now as nothing public can exist in the enterprise.

[theprivileges]

Support for PULL_REQUEST_TEMPLATE.md in .github-private would be 🔥

[Spelkington]

A vocal +1 for .github-private behaving as... well, .github but private. The only mention of .github-private in the documentation is a passing mention of support for private README.md - I'd be shocked if this is where support for the .github-private repo stops.

[matthewtusker]

I'm also very keen to see this being implemented. My assumption until I started looking into it would have been that .github-private would act like .github, but only apply to private repositories. It seems that this isn't the case.

[acrogenesis]

This is still an issue

[brentsnook]

We're also looking for a way to display a public README for the org while still keeping our PR templates private. The proposed solution of supporting PR templates in .github-private would work perfectly for us - as it stands now I can't see another way to achieve this.

[nittendev]

This is very much still an issue.

[dudo]

This does seem like a nice improvement, but realistically speaking, what's sensitive about issue/pr/discussion templates that you'd want to hide from the public? I actually like having them public as a way to show how tight our process is.

[Spelkington]

Having worked at a combination of organizations requiring high compliance and low compliance, I think the issue isn't that issue/pr/discussion templates are critical data, but instead that satisfying compliance requirements is typically done in broad strokes, taking a better-safe-than-sorry approach to minimize any risk of internal information leaks.

Unfortunately, the current system creates a circumstance where satisfying internal organization best practices and internal compliance best practices are a strict trade-off, when they probably don't need to be.

[james-trousdale-lyb]

Moreover, this advice ignores that GitHub themselves provide a product wherein it's impossible to have a public .github repo.

[zrosenbauer]

Its not even wanting them to be private or public... I have very different requirements for an OSS project vs our own internal project, i.e. adding a "checkmark" for "QA team has signed off on staging" or something even just "Submit Security Vulnerabilities to our OSS Form vs our Internal Form"

[dipakparmar]

Similarly, we have some links to tools and documents, specific checks that we prefer to not be public for compliance reasons.

[hyunsu-kang]

This has been an ongoing issue and is a feature that absolutely needs to be added.
There is a recently discovered security case.
"Hackers are using unpublished GitHub and GitLab comments to generate phishing links that appear to come from legitimate open source software (OSS) projects."
source: https://www.darkreading.com/threat-intelligence/hackers-create-legit-phishing-links-with-ghost-github-gitlab-comments

Even because of these cases, this is a feature that must be added.

[0otafasd]

+1