RP Forum Meeting - 2024-09-26

Attendees: Nicole Wolter, Jeremy Fischer, Tom Maiden, Gregory Bauer, Sergiu Sanielevici, Virginia Trueheart, Anthony Bellantuono, Carol song, Yu Ma, Lisa Perez, Rajesh Kalyanam, Georgia Stuart, Aaron, Weeden, Kenton McHenry, Le Mai Weakley, Stephen Deems, Dave Wheeler, David Hancock, Daniel Howard

  1. Dave Hart expressed interest in RP participation on his metrics gathering requirement team - we need one person - if interested, contact me directly via jeremy@iu.edu!

  2. Update from quarterly meeting (9/25 - 9/26) (Sept 2024 ACCESS Quarterly Meeting )

    1. What is everyone developing, metrics, cloudbank, jupyterhub, evaluation, STEP program opportunities for RPs, ACCESS diversity metrics, democratization plan, infrastructure badges

      1. Metrics: integration of Path, NAIRR and cloudbank metrics into XDMOD

      2. Jupyterhub: hosted juyperhub with access to XDMOD to share notebooks to analyze data

      3. Allocations: New resource catalog → expected production by SC, OnRamps feature in Beta, Variable Marketplace Beta(Production) release Jan 1 2025.

      4. Operations: Incorporating regional networks, Internet2

  3. Discuss results from RP Forum/Support meeting in Boston (see below the agenda)

  4. Discuss Item 8 - Ticketing System

    1. If you have constructive criticism of the ticketing system or needs/wants, I’ve started a Google Doc here: JSM Ticketing Issues/Grievances

    2. This may get carried over to future calls if needed and the doc may be contributed to before or after the call

  5. Brief allocations update (Standing agenda item - if needed)

  6. Brief operations update (Standing agenda item - if needed)

  7. Brief support update (Standing agenda item - if needed)

  8. Brief metrics updated (Standing agenda item - if needed)

  9. Open floor RP Q&A or issue discussion


Outcomes from ACCESS Support meeting in Boston:

  1. Invite RPs to the next quarterly meeting (September 25 and 26, 2024) and future meetings. 

    1. Link to agenda with Zoom coodinates shared in RP-ACCESS Communications Slack as well as via rp-forum mailing list. 

    2. Future meetings will be shared with details TBD

  2. Communication continuance between the RPs and ACCESS

    1. Awareness for the RPs of upcoming tools being developed or services being provided by ACCESS

    2. Awareness of trainings, offerings, pain points, etc. by the RPs

    3. Next step 1:  Make sure agenda for the RP Forum/Coordination meetings are put out at least two days in advance and populated with topic items. 

    4. Next step 2: RPs are encouraged to join Slack to make contributions to the Forum agendas

    5. Next step 3: ACCESS should have a dedicated attendee(s) at these meetings.  

  3. System alerts for RPs on changes/planned outages

    1. A conceptual plan will be developed by Operations and brought to an upcoming RP Forum meeting

  4. Better integration of ACCESS IDs, training, calendar & registration

    1. Put the registration process behind an ACCESS login

    2. Filter training based on what’s successful

    3. Next step: Allocations and Support can have a conceptual conversation, then show to RPs, likely at an upcoming RP Forum meeting

  5. ACCESS Support asked for RPs to populate trainings on the ACCESS website page

    1. **This is an RP action item**

    2. Webpage: https://support.access-ci.org/events

  6. In-person meetings 2X/year

    1. coinciding with community in-person events (such as PEARC)

    2. It was desired to have a meeting this spring and another at PEARC.  A suggestion was brought up to coincide with in-person Maximize allocation events, although it was pointed out this may not be feasible

    3. Next step: Support will take the lead to organize a spring RP Workshop.  Will report out plans to RPs.

  7. Metrics/XDMoD

    1. People were unsure how to harness the data

    2. Next step:  We’ll have the Metrics team talk about ways to condense the information and relay it to the RPs.

  8. Ticketing system

    1. This was a contentious topic: 

    2. Issues noted:

      1. Too many places to enter the ticket system (Support, Allocations, Operations) – different options for each!

      2. Too many options to click through (~15 different Ops buckets)

      3. Users could be confused by the terms/jargon

      4. Tickets living in multiple buckets

      5. Ops ticket options don’t make sense, they refer to integration which is not always the case

      6. Can’t move tickets to another queue as an RP

      7. No notifications if a ticket is submitted somewhere, then moved into a new queue

      8. No longer immediate updates to status due to the JSM limits

      9. Not enough ticket agents due to JSM limits

      10. Not enough eyeballs on the queues

    3. Next step: Support and Operations will need to connect on this issue.  As you can imagine this one is a bit more intricate.  You will receive a report out on next steps after the quarterly.