Issue tracker

[petterroea]

We should have an issue tracker. The issue tracker is mainly made with tech in mind, but we should be able to enable it for other crews if it is wished. The motivation behind it, is making it easier and more streamlined to handle incoming requests for tech, abstracting away our internal issue sorting process to us, as well as avoiding issues getting lost.

Abstract

Right now, reporting issues to tech is via text or orally, and has issues with less important things being forgotten. Asking users to add tickets on github is a lot of work for them, and is hard, as they don't know the site architecture. Last, not all issues belong on github, such as replacing seatmap backgrounds(which is in the database, and does not reside on git).

I suggest a simple issue tracker as a simple way for normal users to contact tech about issues, either with the website, or other tech-related things such as the internet service we provide.

Requirements

The issue tracker should be implemented from v3 and onwards.
The issue tracker consists of a "report an issue" feature in the v3 site. It allows users to write a title and body, submit an issue. Each issue has tags, which a member of tech assigns upon being first to reading the issue. From here, the issue works as a "thread", allowing the member and tech to write back and forward until the issue is resolved.

A github ticket can be linked to an issue, should it be something which is tracked internally on git.

The issue tracker list should be fully accessible by anyone in crew, and they should be motivated to search for an issue before they decide to create a new ticket, in case of duplicates.

Implementation

It should be simple, as we don't want it to take a lot of time to develop.

I suggest a table issues, with the fields creatorId, asigneeId, creationTime, title, body, state, confidential
and a table issueComments with the fields commentType, comment, userId, time.
The table issueTags contains tagName, crewId, colorId.
The table tagBindings contains tagId, issueId.

Optional expansion might include being able to resolve an issue to a team instead of a person. By default, i think only team chiefs and crew chiefs should be able to edit tags and assignees on tickets, but with this expansion, tickets assigned to a group can be assigned by anyone in that group. This is to avoid abuse, should security wish to adopt the system

where commentType allows us to add special "this issue is now resolved" or "this issue is rejected" messages as an inline post.
The confidential flag is supposed to allow higher-ups to request things from tech without it being visible to everyone in the crew.

I believe if we keep it simple, we will avoid this becoming an overengineered issue tracker, while allowing users to report things that tech need to do in an orderly fashion

[petterroea]

Thoughts @halvors ?