You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
If end user is reporting an issue it usually is done via Slack or WhatsApp. Then someone from teams needs to get that issue on Github. It would be nice to have the users report issues directly from the app.
Describe the solution you'd like
Having in-app feature that can let users file issues.
Some challenges
GitHub requires the users to be authenticated and not all of our users have GitHub accounts.
We can try make two bots one isShabadOS-Issue-Bot which can be used in our apps to file issues on behalf of users. This bot will not be part of organization because of security concerns. We give it access to specific repo instead (see next point). Other one is ShabadOS-Triage-Bot whose purpose will be to move around issues in various repos.
How to avoid spam in issue trackers?
I suggest that we create a new repository and all the issues are opened by the ShabadOS-Issue-Bot. We can have some fields in issues that will be filled automatically by the Bot before filing the issue. Then ShabadOS-Triage-Bot who has Triage rights will put specific labels which will help us in automation tasks.
How to avoid duplicate issues?
ShabadOS-Issue-Bot can query GH API so we can do some logic to on client before they can file issue. This will work better if all our issues in one repo as I suggested. But there will be times when issue has be triaged to designated project repo by the ShabadOS-Triage-Bot in those cases it will require us to run 2 queries, one in issue tracker repo and other in project related repo. GitHub puts rate limits on
public API and this can be expensive if we get so many users trying to spam. But then how likely is this?
Automating Triage Process
ShabadOS-Triage-Bot should have triage rights in organization and this bot is just for is just for automation purposes similar to @shabados-bot . @bhajneet and I tried working on SOS Bot Triage action for database to automate review process and one of the many issue we faced was - not having the ability to run GH actions for multi repos read this slack thread for more issues. I think with this approach we can handle many issues I listed in that thread.
Other ways to solve this?
We can also make a service (serverless function) using Azure function/AWS Lambda/GCP that will be more secure than this way and we have many other benefits like we don't reaching GH api rate limits because we can hook up to our own DB (Azure Cosmo's, Firebase's or FaunaDB's free tier should suffice our needs) to store issues as references and then we can search in that instead of calling GH API. I think with this approach we can scale very well compared to if we just use GH api approach. But do we need a micro service handling all this or GH API is sufficient for us?
The text was updated successfully, but these errors were encountered:
saihaj
added
□ Type Story
Feature or requirement written from the user's perspective using non-technical language.
ϟ Type Epic
Describing a big goal. A collection of issues. Should never end up in an iteration.
labels
Oct 31, 2020
bhajneet
added
⧬ Type Spike
Knowledge exploration for investigating/prototyping a technical approach to some requirement.
and removed
ϟ Type Epic
Describing a big goal. A collection of issues. Should never end up in an iteration.
labels
Nov 16, 2021
Is your feature request related to a problem? Please describe.
If end user is reporting an issue it usually is done via Slack or WhatsApp. Then someone from teams needs to get that issue on Github. It would be nice to have the users report issues directly from the app.
Describe the solution you'd like
Having in-app feature that can let users file issues.
Some challenges
We can try make two bots one is
ShabadOS-Issue-Bot
which can be used in our apps to file issues on behalf of users. This bot will not be part of organization because of security concerns. We give it access to specific repo instead (see next point). Other one isShabadOS-Triage-Bot
whose purpose will be to move around issues in various repos.I suggest that we create a new repository and all the issues are opened by the
ShabadOS-Issue-Bot
. We can have some fields in issues that will be filled automatically by the Bot before filing the issue. ThenShabadOS-Triage-Bot
who has Triage rights will put specific labels which will help us in automation tasks.ShabadOS-Issue-Bot
can query GH API so we can do some logic to on client before they can file issue. This will work better if all our issues in one repo as I suggested. But there will be times when issue has be triaged to designated project repo by theShabadOS-Triage-Bot
in those cases it will require us to run 2 queries, one in issue tracker repo and other in project related repo. GitHub puts rate limits onpublic API and this can be expensive if we get so many users trying to spam. But then how likely is this?
ShabadOS-Triage-Bot
should have triage rights in organization and this bot is just for is just for automation purposes similar to @shabados-bot . @bhajneet and I tried working on SOS Bot Triage action for database to automate review process and one of the many issue we faced was - not having the ability to run GH actions for multi repos read this slack thread for more issues. I think with this approach we can handle many issues I listed in that thread.We can also make a service (serverless function) using Azure function/AWS Lambda/GCP that will be more secure than this way and we have many other benefits like we don't reaching GH api rate limits because we can hook up to our own DB (Azure Cosmo's, Firebase's or FaunaDB's free tier should suffice our needs) to store issues as references and then we can search in that instead of calling GH API. I think with this approach we can scale very well compared to if we just use GH api approach. But do we need a micro service handling all this or GH API is sufficient for us?
Additional context
The text was updated successfully, but these errors were encountered: