Skip to end of metadata
Go to start of metadata

Decisions:

N/A

Action Items:

Summary
Description
Responsible
Due Date

ECSS and Training discuss requirements (assuming groups would want something like this) QMA-231 - Getting issue details... STATUS

Interact with XCI to define requirements ECSS MGMT, Susan (later) , 

Notes/ Discussion items:

  • Discussion re: different mechanisms to help users prior to submitting a proposal (not restricted to ECSS) 
    • Chat support
      • Discussion
        • Training has been also looking for some sort of support for users trying to find guidance re: how to navigate XSEDE
          • Need
            • We need to bridge the gap between XSEDE offerings and users not contacting XSEDE Help for help figuring out what area they need to contact
            • What motivates/demotivates our user community to reach out? 
            • The website/help buttons can come off as intimidating for new users 
              • Some people may think it's not okay to ask questions about certain topics (ie: using the Helpdesk to get more information about Bridging Participation) 
            • To some users, help ticket= something broken.
              • And if there's nothing broken (and are asking a question) then they think that reflects negatively on themselves
        • Things to think about
          • Logistics (how would we handle this) 
            • Who
              • Maytal's group
                • Would do the execution, not the requirements
                • ECSS training and Helpdesk come up requirements (and pull in XCI) 
            • When: 24/7? 
            • What: 
              • Starting off with ECSS and Training 
              • We need to capture the questions that people aren't asking
            • How
              • How does this fit into the data management plan? 
              • Would this be something that's logged? Archived?
              • Do we need to get metrics for this? 
            • Alternatives
              • Is there some sort of in-between method that's not instant like chat, but more than sending an e-mail?
                • What if there were a hand off between the chat and scheduling an appointment with a person 
              • Customizing the different pages that help users feel supported in asking questions
                • IE a form on a page inviting the user to ask questions about a certain topic relevant to the page their seeing, that may break down some of the barriers 
          • We would have to figure out what's the end goal
            • If we do Slack, then that opens a different set of issues w/o dedicated staff 
            • How do we distinguish the different modes of interaction w/ users? When do we use the Helpdesk, Slack, etc.? 
          • Is the goal to create 1-to-1 interactions? This determines how you want to implement it 
        • Currently, there are not a lot of tickets being submitted asking for direction. People have these questions but there is an energy barrier keeping people from asking the questions
        • Would there be value in having chat as a way for people to connect 
        • There wouldn't be much value added to the chat if there wasn't more training for the people responding 
          • If someone were to start a chat, they're expecting information during the chat. Not 6, 12 hours later. 
        • If the goal is to streamline access for people, we can guide them along via the website and on the back end, it still creates a ticket
          • This could help the Helpdesk figure out to whom the ticket should be sent 
      • Issues
        • We've found it's tough to integrate chat because of the constant interruptions present in XSEDE. Chat requires dedicated attention which doesn't always work with XSEDE.
          • Would chat be different than receiving phone calls
            • Yes, it's different and didn't quite work 
            • Works better if you have someone dedicated to the chat 
        • If we're talking about a chat built into the website, that requires a lot of time and built in AI.
          • Don't ignore how much staff time required to set this up and maintain it. 
        • What if people monitoring the Helpdesk monitored this chat and move things along that way?
          • Could the person that's on the operations side of the chat create the ticket
            • It would create an additional burden on the ops people, but offers another way of ticket creation
              • Could help mitigate the hesitance towards sending e-mails to Helpdesks 
            • The Helpdesk already operates without much extra time to deal with something that requires as much attention as chat
              • Would need a PIF
        • If you have this open, you're going to get all sorts of questions, so the Helpdesk has to be a part of this effort. 
          • The Helpdesk would need a policy stating what needs to be a ticket vs what can be answered (without a record)
        • If we create a model that the Helpdesk answers chat and hands off, if the secondary connection isn't as responsive as the primary, then the system loses utility  
      • Walk away items
        • We would need to define a scope for the new type of support and gather requirements
        • Need to come up with use cases and determine a modality to meet the goal 
        • What would be needed in requirements
          • XCI can help to structure the thinking 
  • No labels