2025-09-16 ACCESS EC Meeting Agenda & Summary

(v) indicates a voting member

Decisions made during the meeting:

Agenda

1. Consent Agenda @Shelley Knuth (5 mins)

   1. Approval of summaries from prior EC meeting -

      1. https://access-ci.atlassian.net/wiki/spaces/ACP/pages/1601175553

   2. Informational Items

2. Allocations @Stephen Deems (Unlicensed)

   1. Progress Updates on Security Changes

      1. Actions (Add User requests, Exchanges, Extensions, Transfers, Supplements, Renewals) on allocations are locked-down in both ACCESS and NAIRR pilot until modifications are made to profile information to reflect new eligibility criteria

      2. Working on proactive communications strategy (targeted communications to affected projects)

      3. User Enrollment Lifecycle work expected to start after meeting on Sep 24, 2025

         1. Need to prevent accounts from being created (and modified) that do no meet eligibility criteria.

      4. Jermey - still seeing category unknown - factored into the user life cycle - this will help with fixing the academic status - it is required before they can leave that screen

Open

Open

Open

3. MATCH @Shelley Knuth /Alana/Jim

4. CONECT @Tim Boerner /Leslie

5. MMS @Tom Furlani @Tom Furlani (Unlicensed)

6. RP - @Jeremy Fischer / @Eric Adams (RCAC)

7. EAB @Chuck P

   1. Waiting on EAB report from Sept 4th meeting.

   2. Need to schedule 1-1 meetings with the last three service teams and the RP

   3. SC/WG report forms coming soon with confirmation of RACI framework for each (will have simple form for each lead to fill out)

   4. SC/WG schedule for Oct-Dec reports back to EC coming soon

8. OpenCI @John Towns

   1. Workspace license sorted out

   2. Overview of Quarterly Meeting last week

      1. Meeting Summary - https://access-ci.atlassian.net/wiki/spaces/ACP/pages/1623326722

      2. Trend Analysis Information - past 20 years - https://access-ci.atlassian.net/wiki/spaces/ACP/pages/1623851010

      3. Data Informed Decisions List - https://access-ci.atlassian.net/wiki/spaces/ACP/pages/1623457796

      4. Lessons Learned (hand written notes)

         • it does work best to have a central computer with all the power points in one spot instead of swapping laptops at the presenter podium (would have been easier if we had access to our regular Google Drive)

         • Hosting center should provide either a spare laptop or have AV technicians who operate a primary computer and control the presentations

         • Aim for more interactive sessions and demos if we can

         Actions: (hand written notes) need target dates - EC will collate action items

         • Should we survey each institution and find out what is approved - and make a list of the approved tools and find out where we intersect and use that to make the policy.

         • How should we make the data we create (data exercise) and have on individual teams available to all teams

           • make a catalog of this data: September 2025 Quarterly Meeting NotesPreview

         • make sure all action items are captured from the

         Cindy - agenda planning committee

         • Call for new members

         • Current team has been involved for many meetings - we need new people

         Laura H - starting new form of RAC

         • New people will be starting this fall

         • Looking for topics for the agenda - what would you like to know from the researcher perspective- you would have about 20 mins with Q&A

9. NSF Sharon and Ed

10. Milestone Review
    
    

11. EC Meeting To Do / Follow Ups
    
    

12. Reminders

13. Upcoming Meetings & Events (ACCESS Engagement TrackerPreview )

Additional Agenda Items

2. Spring Quarterly Meeting - Shelley in absentia

   1. Will it be in person?

   2. Shelley would like to offer up Boulder as an option.

   3. John - it is planned to be in person - we also have an in person EAB slated for the same time - there is also a planned RP workshop at the same time - we might consider “ACCESS Palooza” as an option for that week - we do need to figure this out soon

   4. Tim - talking with Operations team last week - it might be interesting to expand the scope of the topics of the meeting and expand the time to be more time for PIs and SC/WG to work more in person - add a Day or 1.5 days might be nice

   5. Sharon - The NAIRR pilot annual event will week of March 9 - will be relevant to some of the same audience

3. Revisions to the RP Forum ByLaws - Jeremy

   1. Most are formatting but we've added some language for succession, notably in having the Vice-chair be chair-elect to keep a stream of succession and continuity. We've also established term limits.

   2. The bulk of changes are Section 5, Article 1 -- while it all appears as entirely changed, much is just formatting fixes. The present ByLaws are linked here: https://access-ci.atlassian.net/wiki/spaces/ACP/pages/27066393/ACCESS+Resource+Provider+Forum as RP Forum Bylaws v2.0.pdf for comparison.

   3. For the EC, Section 3 "Charter – Resource Provider-ACCESS Interface" is of importance as we are more specific on how ACCESS (i.e. the EC) will respond to RP Forum recommendations. This is in:

      1. "ACCESS makes the following commitments to the RP Forum regarding RP Forum activities:", article 2.

   4. The last item of note for the EC is:

      1. Article 3. Procedure for Resource Providers to Join the Resource Provider Forum 

      2. where I've included a definition using much of the language determined by the EC to determine the resources that automatically become EC members. There is no real change here other than using specific language to describe membership for ACSS resources. 

   5. Recommend Change: Comment “Should to the extent possible” follow procedures for fully integrating into ACCESS as a RP

   6. Satisfactory at this point - will be back for final approval once RP forum approval

   7. Wrap up before he leaves the chair position

4. Researcher Advisory Committee agenda available - Stephen

   1. https://access-ci.atlassian.net/wiki/spaces/ACP/pages/1590591489

   2. Looking for topics that ACCESS teams could present on…

      1. Support MCP servers were recommended. Could Andrew lead this?

         1. Alana will carry this back to their team and get back to Stephen

   3. Intro to ACCESS materials

      1. How do we orient new members? (EAB/RAC/etc.)

      2. Start of information here: https://access-ci.atlassian.net/wiki/spaces/ACP/pages/854786051

5. Who is ACCESS - (30 minutes) Team (Alana to lead)

   1. two parts to this effort:

      1. (1) agreeing on a statement about who we are supporting, and

      2. (2) creating a way to surface projects across ACCESS teams that may impact user support, with a check/coordination point built in

   2. The goals are to:

      1. a) avoid duplicating efforts,

      2. b) prevent harmful or negatively impactful outcomes for end users, and

      3. c) ensure alignment with our user statement.

Discussion:

Part 1 of this conversation:

The statement is:

"Our user audience includes researchers and educators who rely on ACSS-supported resources, with active support prioritized for those directly using these resources. At the same time, ACCESS passively supports prospective users and broader communities who may benefit from our services, training materials, documentation, and outreach. To meet diverse needs, we tailor support and materials to users at novice, intermediate, and advanced levels of experience."

Outcome of Part 1: Ideally, we agree on this statement (or a revised version) to share with our teams. If not, we should identify what needs to change and outline next steps to address it.

Sharon’s comments:

For part 1 of the conversation: The RPs definition from NSF is slightly broader than just ACSS resources, as is highlighted below (“ … and other …”), so the wording for the user audience definition for active support would optimally mirror that definition for ACCESS-integrated resources, rather than just “… researchers and educators who rely on ACSS-supported resources":

“ The focus of ACCESS should be the exemplary support, allocation, monitoring and measurement, and integration of national-scale resources awarded through the ACSS program and other NSF approved programs where resource providers are funded to deploy and support national-scale resources.”

Jeremy - hearing talks of anyone who is a US based and wants to use it - we want to bring people in - outreach

Tim - who is user vs who is a prospective user - and this doesn’t talk about perspective users

John - confusion on language - is this part a discussion of current community we support - or the broader one that includes perspective. This may be who is ACCESS support - not just who is ACCESS - are we talking current, prospective or both.

Stephen - confusing a user with someone who is a eligible to be PIs - primary users are students and this is what it will likely be going forward - ACCESS encompasses this and it open to more - people doing research, teaching, and learning those methods - what about people who code - people who can lead a project not just users

Tim - rather than define our users by those with allocations on ACSS resources, we define them as those with allocations on ACCESS Integrated and Allocated Resource Providers.

Dave - what happens with this statement? these exact words? how much is just internal vs what is external - does this statement exclude anyone we are currently supporting? It is reasonable - if we are not cutting anyone out it should be ok

Tim - user community stakeholders - define sum of allocated active users and possible users - there is another component - active support element is key - perhaps if we say our user is the sum total - but active support goes to active allocated users

John - this puts another constraint on those who can be a user - those who can get an ACCESS ID - does this overly restrict us? Will it change anything?

Alana - this should be both internal and external - for us but there would be some inclusion in documentation or said verbally - we should probably start here

Dave - is this an eligibility statement? We don’t want to get into all that - would take a legal look as well

Stephen - but is that the answer to our question? If you are eligible to use ACCESS resources you are our audience - are we going there?

John - we might describe those as eligible would be our community

Jeremy - that might be the best definition

Dave - if we do put it on the website - we should go cautiously - this is not a communications winning statement - it gets more into legalese and not very friendly - this wouldn't' be a good marketing piece

Alana - if this is internal - Dave was comfortable - Tim had a couple possible changes - could this be sent out in 2 versions for review and decisions? yes

Part 2:

A second item for discussion is how we can better surface projects that impact user support. Right now, each ACCESS track and RP undertakes initiatives that affect user support, but these efforts aren’t always coordinated. To maximize impact and avoid duplication, we need stronger cross-team alignment on priorities, segmentation, and outreach strategies. Without this, individual projects risk creating parallel efforts that fragment the user experience. Here are some suggestions for how we might address this:

These are AI generated - much of this may already be covered in our current processes - probably focus on 1 and 2

1. Shared Project Intake / Notification Process

• Simple “pre-launch” form or template: Before starting a new project, each team fills out a short form (1–2 pages) with project goals, expected user impacts, timelines, and dependencies.

• Central repository: Store these in a shared project tracker (e.g., Confluence, Teams, or an ACCESS GitHub repo) so all teams — especially Support — can see upcoming efforts in one place.

2. Standing Cross-Team Coordination Touchpoints

• Monthly “user impact check-in”: A brief call where each track highlights new initiatives that might touch users; Support can flag potential overlaps or concerns.

• Rotating spotlight: Dedicate 10 minutes in regular EC meetings for one team to present new initiatives before they roll out.

3. Lightweight Review & Guidance Mechanism

• “User Impact Review” checkpoint: Any new project with user-facing elements has a quick review by Support (could be asynchronous review of a 1-page summary).

• Traffic light system: Support tags projects as “green” (no concerns), “yellow” (coordinate further), or “red” (significant risk to user experience).

4. Cultural / Process Norms

• “No surprises” principle: Explicit expectation that any initiative likely to touch users gets previewed with Support.

• Shared language: Agree that “user audience” segmentation (novice, intermediate, advanced; active vs prospective) will be the common lens for evaluating new efforts.

Outcome of Part 2:  The EC discusses these approaches to see if one or more makes sense.  Support can engage in the implementation/set up if so.  If the team cannot agree on these, then other suggestions should be made.

John - two we are trying to do anyway - number 1 we do thru the milestone tracker - are we fixing something that may not be broken? Is this being discussed in alignment with what we are already doing?

Tim - we do have milestone process - in governance sense it should be the EC evaluating and implementing and evaluating impact - this should be implemented at the EC level and not just Support - use the governance we already have

Tom - what have we done badly - and what went wrong with them - how do we fix that - recommender model - we don’t want to implement something we won’t follow

Stephen - what is the problem overall - if we need to look further into the future and coordinate better - but throwing forward solutions without saying what is going on that is the problem - what are the issues and what can we do about it - we have tools and how can we get people to use them

John - example - chat bot development - we had 3 being developed at the same time - there have not been a lot - what are we trying to accomplish - sufficient awareness across the program to avoid duplication of effort - if we use milestone tracker to fix this - are we not using the milestone tracker enough to address the problem? adding another form might not fix the problem - we don’t want more overhead

Alana - she is fine with the milestone tracker - but it is difficult if you are not a member of the EC to know how to use it - are there norms around what is expected for entering things into the tracker? - are others reading it correctly?

Tim - is there a different approach we can take for planning together as a program rather than planning in individual awards - could we get on the same page before things from the beginning

John - support a fully integrated PY5 process

Alana will take things back to Shelley

Tom - make a list of things that could have gone better - discuss what went wrong - and find out what we could have done differently with our existing structure

John - we are at 3.5 years in project - hate to institute a heavy weight process before the end - lesson learned that we did not initially create a process to make sure all teams are aware of plans and decisions going on.

LINKS
Program Milestones

EC Meeting Task Tracking + Quarterly and Annual Meetings To Do Follow Ups

Misc Topics:

Next EC Meeting: Sept 23 is CASC meeting - next meeting Sep 30, 2025

Reference:

Risk Register:

Project Change Request: