GitHub Community
Make issue forms available on private repositories #4264
-
|
I want to be able to use issue forms within my private or internal repositories. |
Beta Was this translation helpful? Give feedback.
Replies: 212 comments 218 replies
-
|
Yes, it would be extremely useful in the enterprise cloud environment! |
Beta Was this translation helpful? Give feedback.
-
|
This would be certainly a great addition for private repos as well. I work for a fintech company, where strict audits take place. BackgroundIn strictly regulated environments, repositories are kept private, and git commits are an important part of the audit. Because GitHub's Issues and Pull Requests can gather most of the relevant information around each commit and change, auditors also take a close look at Issues, Pull Requests, and templates being used for both. As any edits to Issue description can be tracked, Issues in private repos are especially useful to discuss sensitive matters, while maintaining auditability. Use casesThere are some specific use cases I would love to use Issue Forms with:
WorkaroundFor now, I'm using simple markdown templates for 1. and 2. above - something like below: ---
name: Incident Report Template
about: Incident Report ticket
title: "INCIDENT (XX Jan 2021): Some short description about the incident"
labels: "incident"
assignees: ""
---
<!-- Do not leave any section empty. -->
# 1. Executive Summary
<!--
Executive Summary should contain about up to 3 paragraphs to clarify what
happened. Bear in mind that this is targeted for Business Users as well,
meaning technical details should be kept minimal.
This is a REQUIRED field.
-->
<!--EXAMPLE-->
Redacted
<!--EXAMPLE END-->
# 2. Business Impact
...It can have most of the information embedded in the markdown, but it tends to be wordy, lengthy and unfriendly (e.g. there is no way to do drop-down, etc.). Even if we provide all the details, we often end up with issues where some fields are not updated correctly. Other thoughtsThe data quality is especially crucial in regulated and audited environments. I'd be really keen to see Pull Request to have a similar form-based template, which can ensure better data quality in the Pull Request description as well 😉 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for all the use-case info @rytswd – it’s incredibly useful for us!!!
Some of your other points I had already thought about, but thinking about templates through this lens is new to me. Again, super helpful context. Thank you!! |
Beta Was this translation helpful? Give feedback.
-
|
We are using IssueOps for provisioning of cloud/SaaS resources to teams in our GHEC organization. The purpose makes clear why those repos cannot be public and access needs to be restricted to authorized members of the organization. Today a markdown issue template is used and the resulting issue from the template is parsed within GH Actions. Due to the fully editable template there is a lot of potential for the issue author to break things. Issue forms could be a great improvement on validation of input, ensuring completeness and and ensuring the structure contains all the match patterns that were placed in the template for regex matching. |
Beta Was this translation helpful? Give feedback.
-
|
What was the reason for restricting this feature to public repos only? We already have markdown templates stored in our |
Beta Was this translation helpful? Give feedback.
-
|
I would love to have this functionality for private repositories. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
I just spent a couple hours (ok, so maybe I'm a slow learner) learning about this feature, configuring two form templates to gather needed info for issues, and setting up the config.yml file so users can choose the right form. It wasn't until I created a new file and copied the yaml into it that i noticed this warning: "Issue form templates are not supported on private repositories." I see no mention at all of this limitation in the document I was following to learn how to do the forms (https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository). So...
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @pdelancie! I’m sorry that you wasted any time on setting up issue forms. I’ll be passing your feedback onto our docs team.
While issue forms are in public Beta we have no current plans to make them available to private repos and we are still ascertaining what future features and capabilities we might like to add to them. Hearing the feedback on this forum really helps to inform us there so any and all feedback you give us is extremely valuable!! Perhaps you could answer a few additional, specific questions for me?:
|
Beta Was this translation helpful? Give feedback.
-
|
• What is it about structured issue forms that would help your workflow(s) within your company? • Would you use the required fields function and if so, why? • Are you aware of the existing markdown issue templates (not YAML issue form templates) workflow which are available for private repos. If so, what is it about them that isn’t “enough”? Yes. As pointed out by previous posters, the markdown fields don't enforce any structure on the responses that one could rely on for (a) ensuring that all relevant information is provided (because you can't require that any fields be specified) and (b) that the information is in a form that enables it to be easily sorted, filtered, etc. (because, once again, you can't rely on it being in a consistent structure from issue to issue). The markdown approach -- essentially a big string into which users have to weave their responses -- is primitive in the level of control that it enables, it puts us at the mercy of respondents to input the info in an easily parseable way, it's not user-friendly, and it's frankly just plain ugly (in Write view, which is what users are in when adding an issue), which discourages adoption. Bottom line: If your intent is to encourage companies to look for a non-GitHub solution (e.g. Asana, which supports easy form creation) for issues that can't be public, your strategy is spot-on. But if you want us to be able to use GitHub to gather the info we need in a user-friendly, professional way, please enable issue forms for private repos ASAP. |
Beta Was this translation helpful? Give feedback.
-
|
@lukehefson ditto @pdelancie comments What is it about structured issue forms that would help your workflow(s) within your company? Would you use the required fields function and if so, why? Are you aware of the existing markdown issue templates (not YAML issue form templates) workflow which are available for private repos. If so, what is it about them that isn’t “enough”? Seem this is a standard feature that should have been there from the beginning instead of looking for other solutions like using google forms to then have data send to google sheets and then converted into an issues all to control data being submitted. Seems like something that should already be there little lone only a feature in public repo's. May I ask why was this feature created for public repo's ? Guess is the same reason people here are stating here it would be so useful in private and repos instead of looking for 3rd party solutions. Seems enterprise paying customers should see features prior to public repos. This could be a useful feature that feel would be used the same reason they are being offered for public repots. Also visually it looks 100% better then markdown templates :) |
Beta Was this translation helpful? Give feedback.
-
|
Some reasons that forms (thanks for opening them up to private repos), and for that matter required fields matter: Forms:
Required fields:
Ultimately, until something like this makes its way to Github, orgs like mine will be required to use Jira which supports this. |
Beta Was this translation helpful? Give feedback.
-
|
I would love to use issue forms in private repositories. I'm a game developer working on projects that are not open source, and issue forms would be incredibly useful for submitting bug reports, similar to the example shown in this video. |
Beta Was this translation helpful? Give feedback.
-
|
I'm software developer working on large private codebases. Issue forms would be incredibly useful for us... This features is 🔥 |
Beta Was this translation helpful? Give feedback.
-
|
After banging my head against a wall trying to figure out why it wouldn't work... at the very least it should be flagged that this won't work on Private Repos @ https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository It does say if you try to create via the web interface but not if you try to push it out via CLI. |
Beta Was this translation helpful? Give feedback.
-
|
It is called out now: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms
|
Beta Was this translation helpful? Give feedback.
-
|
what's the resistance to just opening the feature? you've got it working behind a feature flag and everyone obviously wants it |
Beta Was this translation helpful? Give feedback.
-
|
ditto what everyone else has said. This feature just make sense. It improves on template markdown in so many ways. It's important to us to keep our internal processes looking professional and producing reliable results. So disappointing this is not available for our private repos. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
+1 on all said above. We are more and more using Issues to work with our customers (Dev teams). This is becoming a support tool and having more control over how info comes in would be great. |
Beta Was this translation helpful? Give feedback.
-
|
I can understand offering this feature to public repositories first, but I don't understand why it wouldn't be offered for private repositories. All of the structure/features the new YAML format provides would be useful for any repository, public or private. Our company has hundreds of private repositories which will never be open-source. We would love the ability to track issues in GitHub for some of those projects. Though we aren't blocked from doing that, only having access to the limited feature set up the markdown templates will hinder adoption. I do not see this on the public roadmap as a feature request, is it being considered? |
Beta Was this translation helpful? Give feedback.
-
|
Echoing what many above have said:
|
Beta Was this translation helpful? Give feedback.
-
|
Hey @lukehefson, just wanted to see if there was a status update on this feature. Since the original question was posted in Jun and your last update was Sep 1. Our company transitioned over to using Github projects and issues as our sole means of Agile development and project management company wide for both developers and sales, marketing, etc etc back in July. While developers can handle the markdown some of our sales and marketing teams could really benefit from the straightforward forms. I've been really looking forward to this feature coming to private repositories for a long time now and I'm hoping to at least get an estimate on when that might be. Cheers! |
Beta Was this translation helpful? Give feedback.
-
|
Will do thanks so much @lukehefson :) |
Beta Was this translation helpful? Give feedback.
-
|
One thing to flag is that a lot of the frustration with this on this particular thread is driven by people having tried to get it setup on Private and the documentation not being clear that this is limited to public only. Clearing up the documentation to idiot proof the wording would probably mean you get fewer responses to this thread in future... |
Beta Was this translation helpful? Give feedback.
-
I agree! The wonderful @Maximisch recently opened a PR to help address this on our public docs which has now been merged!: github/docs#11822 |
Beta Was this translation helpful? Give feedback.
-
|
Hi @CTOverton, Basically, I'm looking for a lowest-friction solution that allows an internal employee in the company to fill out a report (web page, email, or some other solution?). The ones I have are:
|
Beta Was this translation helpful? Give feedback.
-
|
@719media I'm not too sure honestly. We have a smaller team and so all our members are on our GitHub org. We do use Zenhub as a way to interface with github issues. So I'm not sure if they are able to have zenhub accounts without github accounts. But from my understanding you only need to pay for the users that collaborate in specific repos. So you might be able to have a lot of free tier users that just interact with issues. |
Beta Was this translation helpful? Give feedback.
-
Just wanted to add my voice to the choir here that I would really love to see forms opened up to private repos, and this reason highlighted by @CTOverton is one I share as well - having a more user-friendly form to act as an intake for feedback from less technical audiences, which I can then turn into/link directly to engineering work is a primary use-case for me. It means I don't have to maintain some sort of intermediate layer (e.g. using Google forms or Airtable forms, etc. to collect feedback/bugs/feature requests) to intake feedback, followed by linking that feedback to actual engineering work, and then manually maintaining that link over time. Instead it all can sit in the same layer. The form nature of this makes it great for less technical audiences. |
Beta Was this translation helpful? Give feedback.
-
|
Same here inside our company, we would love to use issue forms on private repositories. |
Beta Was this translation helpful? Give feedback.
-
|
Please enable this feature for the below organization. https://github.com/foredev Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Been following this thread for quite some time...my organization is finally in a great place to adopt. Would love to have this feature enabled for https://github.com/modern-doc Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Please enable for https://github.com/outsideorbit Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @2percentsilk , @emmaviolet Please enable this feature for the below organization. https://github.com/finixio Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @2percentsilk, @emmaviolet, Please enable this feature for the below organization. https://github.com/orgs/productiquequebec Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Please enable this feature for the below organization. https://github.com/stacc Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
HI @2percentsilk, @emmaviolet, Please enable this feature for the below orgs: https://github.com/azurefoundation Thank you very much! |
Beta Was this translation helpful? Give feedback.
-
|
For those that haven't seen it - the public beta has been extended to all private repos, with the caveat that required fields are still turned off: |
Beta Was this translation helpful? Give feedback.
-
|
@azenMatt The missing validation is one issue. Here one can observe all the three things I mentioned above which are missing from private repositories:
One of the very important use case for me is this:
Obviously, the parsing step would greatly benefit from the validation built into the issue forms - an invalid or incomplete issue would not be even created. |
Beta Was this translation helpful? Give feedback.
-
|
I've just noticed a funny thing about the red star markers of required fields which clearly suggests some of the required fields mechanics is already in place, but hidden :-) 1. If I submit my issue form via pull request and go "Files changed" > "View file", then all required fields get the red
|
Beta Was this translation helpful? Give feedback.
-
|
Do we have an ETA on enforcing required fields in private repos? This would help us a lot! |
Beta Was this translation helpful? Give feedback.
-
|
Here to add my support for required fields in private repositories. Exactly the same reason as @ffissore here. We have various levels of support and triage, and we'd ideally like to use these forms to limit the amount of triage and back-and-forth between teams that is required. If a form field always needs to be added before the next team can even act on it, it's way easier to just make it mandatory and handle edge cases separately, than to have the mainline use case always require a back-and-forth between teams just to get the information that should have been populated in the first place. I understand that after submission, the markdown is entirely editable anyway by an organisation member, but forcing us to populate a field correctly the first time will really streamline our organisations processes. |
Beta Was this translation helpful? Give feedback.
-
|
100% agree with @twisterdotcom. While required fields don't make the forms bulletproof, the number of invalid submissions would greatly decrease if we had the ability to require fields on private repositories. Currently it's just to easy to just submit a completely empty form by accident. |
Beta Was this translation helpful? Give feedback.
-
|
Is this available for Github Enterprise Cloud? |
Beta Was this translation helpful? Give feedback.
-
|
Yes |
Beta Was this translation helpful? Give feedback.
-
|
Just checked it now, and works like a charm 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps a dumb question, will there be an API available to use for automation purposes? |
Beta Was this translation helpful? Give feedback.
-
|
@azenMatt With all due respect, asking us over and over why we would want to require a field seems like game playing; it is extremely obvious (and has been stated here many times) that if you need the value of a given field in order to effectively/efficiently respond to input from a user then you need the ability to make that field required. So if we're going to be honest about this then we can only conclude that the reasoning behind preventing fields from being required is that your team thinks you know better than us how we should interact with our own users. In other words, you don't trust us -- your customers -- to make good decisions in form design to avoid alienating users. If you do trust us, then you'll enable us to do what we have explained over and over that we need to do: include required fields in forms for private repos. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
@azenMatt for the record please note that the above comment was in response to your question (Jan 27, 2023) "Would you be able to share the use case of the validated form you are trying to create?." That question has already been answered in this thread numerous times by numerous GH customers; here is one take that I provided back in October: The entire point of using a structured form is to ensure that all needed information is gathered in a parseable way. This allows the recipient of the information to efficiently determine what actions should be taken in response to submission of a form, so actionable responses can be prepared as rapidly as possible to help the users of the repo. A required field helps these users by letting them know that unless they provide the requested information the manager of the repo likely won't be able to help them, or at least not as quickly or effectively. If a manager can't make fields required then processing a form will take more time/resources for the repo owner, and responses to users will be slower. It's difficult to see how that helps anyone. |
Beta Was this translation helpful? Give feedback.
-
|
For those of you who'd like to see the issue forms capability available via API (i.e. submit an issues form using GH's Issues REST API), here's a link to a feature request for that (made by geromegrignon Jun 30, 2021 and not yet responded to by anyone from GH): |
Beta Was this translation helpful? Give feedback.
-
|
When I attempted to set up a YAML form in our private GHE repository, I kept receiving a "Issue form templates are not supported on private repositories." message in the file. Could that be specific to the implementation of GHE and not to the public capabilities? |
Beta Was this translation helpful? Give feedback.
-
|
Yes - this is going out in the next version of GHES - 3.9. So you will have to wait a little longer for this. |
Beta Was this translation helpful? Give feedback.
-
|
Good News: "required" is now working in Internal Repos! |
Beta Was this translation helpful? Give feedback.
-
|
Any news in this regard? |
Beta Was this translation helpful? Give feedback.
and others
For those that haven't seen it - the public beta has been extended to all private repos, with the caveat that required fields are still turned off:
https://github.blog/changelog/2023-01-12-github-issues-january-12th-update/#%F0%9F%93%9D-issue-forms-for-private-repositories-public-beta