Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate flow and services for user feedback #621

Open
saihaj opened this issue Oct 31, 2020 · 0 comments
Open

Investigate flow and services for user feedback #621

saihaj opened this issue Oct 31, 2020 · 0 comments
Labels
⧬ Type Spike Knowledge exploration for investigating/prototyping a technical approach to some requirement.

Comments

@saihaj
Copy link
Member

saihaj commented Oct 31, 2020

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?

Additional context

@saihaj 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
@saihaj saihaj moved this to Triage in Project Management Oct 24, 2021
@bhajneet 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
@bhajneet bhajneet moved this from Triage to Requirements Analysis in Project Management Nov 16, 2021
@bhajneet bhajneet changed the title RFC: Ability to report issues from settings Investigate flow and services for user feedback Nov 16, 2021
@Harjot1Singh Harjot1Singh removed the □ Type Story Feature or requirement written from the user's perspective using non-technical language. label May 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⧬ Type Spike Knowledge exploration for investigating/prototyping a technical approach to some requirement.
Projects
Status: Requirements Analysis
Development

No branches or pull requests

3 participants