Skip to end of metadata
Go to start of metadata



Action Items:

SummaryDescriptionResponsibleDue Date
Create a checklist for off-boarding that includes the staff person responsible for removing access to a resource (or changing privileges for a resource) QMA-162 - Getting issue details... STATUS We need a system to make sure that people who are no longer a part of XSEDE.  
Generate a process to make sure that Chris H and Kelly are notified when someone leaves XSEDE QMA-163 - Getting issue details... STATUS    


  • There should be a checklist that has all the things and who is responsible for those things. 
    • Basically there needs to be a system of checks of balances including who is responsible for doing what
    • Checklist should be categorized based on high-level WBS areas. 
  • What are the current missteps that need to be addressed?
    • Currently Victor keeps a list of things that have previously been forgotten and adds them into the list of things he checks. 
  • Staff should work through their PM to get things for their area that should be included in an off-boarding checklist and PM move those things
  • When a person is leaving responsible, who initiates the off-boarding process? 
    • Currently it's chaotic and no one knows who is responsible for it. 
    • Would it be worth it to do a point in time inventory? 
  • We need to make sure locally that the manager of the person who is leaving notifies Chris H and Kelly.
    • Institutional PIs begin the process? 
  • Other things to check
    • Financial information to see who hasn't been charging anymore. However, sometimes people are not being funded for a few months then they come back. So going just by the financial documentation isn't completely reliable. 
  • At SDSC and NCSA, the lead PI at the institution who triggers the off-boarding process at the particular institution. This one person should be aware of all on-boarding and off-boarding. 
  • How do we catch people who we haven't off-boarded but should have been off boarded?
    • Did this check when XSEDE1 transitioned to XSEDE 2. 
    • There was some privilege checks that were not done, so this may still be an issue. 
  • Whatever is the way of keeping the checklist should be easily editable since there are so many new resources coming on board. 
    • This checklist could be held in Confluence
  • Annual audit of XSEDE staff?
  • Is there are separate set of things for people who may not be staff memebers but are regular XSEDE users? 
    • IE: we want wiki access for NSF reviewers. 
      • Incidence check: have a set of things for this particular situation 
    • Checklist should have a logical process
      • IE if they're not staff, they automatically should be checked to make sure they do not have access to XYZ 
  • No labels