As a dev, I want the user to be able to report an issue on github

[SamuelPelletierEvraire]

Description

As a dev, I want the user to be able to report an issue on GitHub through a new button in the side menu. The goal is to create a new issue that explain how to integrate a popup that allows the user to fill in a short description of the encountered issue.

Task

• Create a new issue on Github for dev purpose.

• In this task include how to Modify the reporting process to include the path to follow in this context. What information should be sent and automatically filled when submitting the issue on our GitHub?

Acceptance Criteria:

The user should not be redirected to the GitHub website, as this may create confusion in the application's process flow.

[Francois-Werbrouck]

I'm not a Github guru, however;

The user should not be redirected to the GitHub website, as this may create confusion in the application's process flow.

Seems to me like it might cause problems. How will we know who opened the Issue, how will we be able to contact them? This also means we need to have an automatic way to create github issues based on a form from the application. Having our tests-users opening the issues on Github allow for back and forth conversation. There is also a distinction between handeling ticket issues and Github issues.

Currently our product is not in prod, so tickets wont be necessary. However, a ticket issue is something that isn't solved directly in the build and should not impact all users. Ex: Permission issues, User not connecting to certain services properly, etc. This does not need to leave traces on Github. However we aren't there yet in the life cycle of the tool but I see the report issue feature being used for those type of tickets.

Github issues, on the other hand are issues which are fundamentally intertwined with the build of our tool. These type of issues are what we will mostly be having during the current life cycle of our tool (development/prototyping). These issues contain major blockage in the workflow and impact all users. Ex: page not working, data not going through/ not displaying, Exceptions in certain requests, etc.
Github issues are what our test-users should interact with imo since those are completely different from actual issues on a live/production build.

---

Test-user open issues concerning their experience with newly added features to the tool or problem they face in the core features of our application.

Currently we do not have a huge crowd of users on our tool. The only users we have are trusted people which we personally know and meet on a weekly bases. Requesting them to invest into our Github workflow could be something we request the client. This will tremendously help for communication with the user who opened the issue and the dev team, while still leaving traces of our work. The user will also be able to see improvement in the issues they opened since they will have an account & email linked with to the issues and its notifications.

If the user is not the one to open an issue on github, how will they be notified that their issue as been correctly open and sent to us? How will they know when there are updates on their issues? How will they know it has been solved? How will we be able to contact a user regarding his issue (we do not save emails, nor name of our users, therefore it seems to be very hard to get in touch with them only based on the current tool's knowledge of a user)?

We are still in a prototyping phase. I think it is correct to request to the low amount of users we have to use Github for issues since it will lead to us being able to focus our resources on improving the prototype.

We do not have a current interface to manage issues, nor have an architecture in place to contact the user (by email) to notify them on their issues. This could be done, but will lead to alot of work, which also brings a low amount of value to our prototype. Building a ticket system atm doesn't seem like a priority to me, but this is a discussion for the entire team to have.