Add saved replies per project

[kittykat]

We have a number of people in our project who triage incoming issues. I would like to be able to add saved replies to the repository which any triager would be able to use rather than asking everyone to add their own to their account.

[thiagodiniz]

That would be awsome

[binford2k]

And also to the org wide .github repository so they're available to all repos in the org.

[tupui]

I am a SciPy's maintainer. This would be extremely useful as we have similar issues requiring a similar reply all the time 👍

[mrmundt]

I am a maintainer on Pyomo, and we also expressed a desire for this. +1

[teolemon]

Same @openfoodfacts, where I have several Saved Replies to generate barcodes for buggy products, and where we have many repos where we need those.

[grafana-dee]

This would also help us at Grafana Labs, so another vote for this. Managing large triage is hard as-is.

[alexcg1]

Another upvote from me. I think this could help a lot at Jina AI

[erelinz]

Could markdown work for this? I was thinking it be done by placing a REPLIES.md in the .github folder in the repo.
The idea that replies are stored as code/markdown (instead of using the API to manage them) is appealing in many ways.

# Saved Replies

This file contains predefined replies for common issues or queries.

## Format:
Each reply starts with a title line, starting with '##'. 
The title is followed by the reply content, until the next title or end of file.

---

## Bug Report Missing Info

Thanks for your report. To help us understand and reproduce the issue, could you please provide:
- Steps to reproduce the issue
- Expected and actual results
- Your environment (OS, browser, etc.)
- Any error messages
- Screenshots, if possible

---

## Feature Request Acknowledgment

We appreciate your suggestion! It's been noted and will be discussed in our next planning meeting. Feel free to provide additional details or use cases to help us understand it better.

---

## Duplicate Issue

This seems similar to an issue we've addressed before (#issue_number). Please check that thread. If it doesn't resolve your problem, let us know so we can investigate further.

---

## Code Contribution Guidelines

Thanks for your contribution! Please ensure your submission adheres to our [contribution guidelines](link_to_guidelines). This includes style conventions, testing requirements, etc.

---

## Pull Request Review Feedback

Thanks for your pull request. We've reviewed it and found a few areas that need to be addressed. Please check the inline comments for details.

---

## Acknowledgment of Bug Reports

We appreciate your detailed bug report. We're looking into this and will update the issue when we have more information or need further details from you.

---

## Question on Usage or Functionality

Thanks for your question. It seems like you're asking about [specific feature]. You can find information about this in our [documentation/wiki](link_to_documentation). If this doesn't answer your question, please provide more details.

---

## Closing Inactive Issues

This issue has been inactive for a prolonged period. If the problem still exists, please feel free to reopen the issue with additional details.

---

## Security Issue Response

Thank you for bringing this potential security issue to our attention. To properly handle this, please do not discuss potential security issues in public. Instead, email us directly at [security email].

---
# Add more replies as needed...

There are a few benefits to this approach I think worked outlining:

1. Version Control: Storing replies within a repository means they're under version control. You can see the history of changes, who made them, and when. It also provides an opportunity for contributors to suggest changes through pull requests.

2. Simplicity: No need to learn or use an API. The Markdown syntax is simple and widely known among developers. This lowers the barrier for contribution. Building a bot to handle these responses can be time-consuming and complex, requiring knowledge of API integrations, potential cost, and constant maintenance. With a markdown file, you save on the overhead of maintaining a bot, making the process much more efficient and streamlined.

3. Transparency: All team members and contributors can easily see and understand what standard responses are being used. This openness fosters trust within the community.

4. Easy Access: The replies are just a click away when you're working on a project. You don't need to navigate away from your repository or remember API endpoints. While reviewing an issue or PR, you may find that a saved reply needs a tweak. If the replies are stored in the repo, you can easily navigate to the file and make the adjustment.

This approach keeps things simple and transparent while cutting down on unnecessary complexities and overhead.

From a security standpoint - markdown is probably a relatively safe choice as Github Flavored markdown is already safety rendered in many place in the web app.

[drupol]

I definitely support this !!!

[Rexogamer]

this would be super useful for orgs w/multiple triagers, and this approach would make it really easy to set up and update. massive +1

[chinggisod]

I am a software engineer from Japan, our team absolutely would be thankful if this feature is added.

[sfriedman-stripe]

This would be really, really useful for several of our repos here at Stripe as well, where we'd like saved replies to exist for a whole team within a given repo.

[jezdez]

Hey all, what's the status of this proposal?