Student Ticketing Proposal

--- tags: TA, Student_Ticketing --- # Student Ticketing Proposal ## Summary The purpose of this proposal is to introduce a new student facing resource. Right now there is lack of consistency among PT TAs when providing help and following the Hierachy of Help [HoH] leading students to become frustrated. TAs are also at the sole discretion of their TAB ticketing and sparse TA feedback submissions via students which can lead to insufficient data or skewed data. The goal of this proposal is two fold. To mitigate further frustrations of too many options students can use to reach out to TAs by creating a more uniform path for students to follow in tandem with posting issues on Discord. And increase TA feedback by including TA links in the student facing ticketing process to provide a more accurate standard deviation of TA performance. ## Problem Students can interact with multiple TAs in any given day and will naturally receive assistance variably regardless of a HoH. Students will then feel frustrated with variations, "Well, this TA helped me immediately", "This TA won't help me at all", "I didn't have to post to Discord before". TAs are at sole discretion on submitting tickets on TAB2 as well as posting survey feedback forms where students may and or may not know where to find the form. This leads to the inevitability of inaccurate data in regards to actual TA performance and activity. ## Proposed Solution(s) Creating a Student facing ticketing system when reaching out for help, assuming the student has exhausted the 20 minute rule. - The student will go to a student website (maybe something like studentTAB) - This website will track the number of tickets the student submits and show on the Instruction side (TAB2)? - Student will submit a ticket for TA time. - ticket will require student to formulate a question on the issue they are working on and will be required to share discord link for TA review as well as what they have tried to resolve the issue. - TAs scheduled to studentTab coverage would review tickets as they come in and either approve/deny/answered the ticket. - "denied" ticket would include explanation by TA as to why. i.e. question not formulated sufficiently. would be encouraged to submit again - "answered" would be if the question were an easy answer due to simplicity of question and sufficiency in posed questions - "approved" would add student into a queue - this would assume that Dojo Hall could be automated by Thomas' DH bot and exist SOLELY as a collaboration resource. - "approved" student tickets will wait until a TA with that stack experience is available to assist and will be required to follow up on their post on discord. - after student is assisted, TA will close studentTicket (student to receive email/discord? summary of interaction with TA with feedback form included) ## Challenges - This is another process for TAs to learn and manage - Ticketing would inevitably lead to 1-on-1 time with TAs - Trying to think of ways to create this process into a more collaborative process beyond having student share their solution on discord. - "Denied" tickets would not keep a student from submitted the same ticket over again leading to more work for TAs to filter (find some way to manage tickets, tickets cannot be created more than once in a 5 min period of time?) - How would the ticketing system work for out of TA hours. - Include a disclaimer for response time upon creation of a ticket outside of TA hours? ## Deliverables & Goals Deliverables - Increased comprehensive TA feedback - comparable data with studentTab and TAB2 for the big picture on TA performance and activity - Students forced to practice formulating questions at the risk of being denied assistance until they improve their question - Students given one option when requiring TA attention beyond Discord posts Goals - Remove student expectations of the variety of ways TAs can be reached. - Streamline a process for students to receive help vs sitting around dojo hall with expectations only for that TA to go on break. - Expectation set for students to wait their turn without context (maybe provide an estimated waiting time) - This would be dependent on TA coverage... ie. if there are more python TAs available at that time. ## Required Resources Required resources would include: - Creation of student facing website to submit tickets. - Implementation of LP3 and TAB2 to ease TA use. - Email/discord follow up templates ## Conclusion The goal for this proposal is to better define and obtain accurate TA interactions with students while building student skills in the process. ## Peter Feedback >- Do we need someone assigned to these to approve, deny, etc? I like the idea of being able to more quickly approve or deny to tell the student that they need to submit a better question, but Im thinking that this will introduce too many extra logistics/variables versus trying to create better expectations for students as they utilize this tool in order to minimize issues from having to be vetted as much. I know the messaging isn't the perfect solution, but I'd rather roll this out in a way that minimally affects TA workflow to start, if possible. >- Ideally, we can probably have this just be a student/public facing section of the TAB2 site that anyone can visit >>- We can potentially utilize LP3's login, just with a student level credentials >>- I think public-facing would be easiest as an immediate start, but also leaves it open to spam or old students >>- Not that this is ideal/quick, but we'd almost definitely want the sheet requiring a sign-in of sorts/validation for the email to ensure the student is submitting with their CD email to avoid email mix ups and the like (which would allow these tickets to have the student pulled up automatically when a TA grabs their ticket) >- In terms of the answered status, I'm hoping that the system of claiming these tickets would just open it up into a proper TAB2 ticket so it can fit into the existing system and not generate extra/side work or tickets to maintain/track. Is that the idea here, or do you think it should/would be separate? >>- I see that the intention here would be to answer it without even having to meet, but I think it can still justify a ticket open and close anyways >>- Only trick here is if we want that student ticket completion system where the student gets emailed or discord messaged, we'd need a "student facing comment" of sorts that might be separate/a marked version of the current comments. When thinking about it, it might be good to have a "final solution" be asked for when closing a ticket :thinking_face: That can be student-facing (or at least attached to the student's ticket on their side) in addition to helpful to TAs running into similar issues once we get some ticket searching up n running. Thoughts? >- We can/should definitely rate limit student ticket creation, although they'd have to go pretty out of their way to do that if we have some validations for spots that are required >- A big blocker here would be submission of screenshots, but that's likely where the discord post comes in >- On the note of discord, how do we want to blend this with discord? Don't want students feeling like they have to fill out the same info multiple times, as that can result in frustration ### For the challenges: >- If we can move away from the approval process, while it might allow some lackluster asks to get through, it'd almost entirely get rid of extra logistics for TAs. It'd be as simple as tickets in a queue that can be claimed. >- The 1-on-1 time with TAs is something that we already do with Dojo Hall anyways and I would say we'll want to move away from slowly, if that's the direction this ends up taking us. Eg. I don't want this ticket system to entirely lock down Dojo Hall for specific access/only collaboration or TAs only jump in for tickets...not yet, at least! >>- The more collaborative stuff is tough..main thing there is encouraging discord posting and hopefully things like pods starting back up will spark more collaborative groups, too; but I feel like that's a separate thing we can work on >>- For ticket resubmissions: we can rate-limit submissions with relative ease or just have some decent validation, which I think would suffice >- Definitely can have a disclaimer or potentially just not allow it. We have a "DojoClock" component on the FE that keeps track of time in PST, so it might be as easy as disabling things based on that front end time (although we'd still need some BE validation to prevent someone from messing with it in inspector if we wanna be thorough). My thought here would be -- should we allow them to prep up a ticket or save it for later? Eg. a draft of sorts so they can submit it in the future? Overall, I love it!! I think the main sticking-point is figuring out how we want to roll this out and how this affects the student side of things. I'm thinkin for TAs, it'll almost only make our jobs easier (if we avoid having to approve tickets and such for now, because at least then it's largely business as usual); hence the focus on the student side.