2i2c Access - Iteration & Documentation

[jules32]

Hi Andy!

We can use this issue to help overall progress/coordination. This will start off by reading and getting familiar with the following documentation and Issues, with an eye towards having all updated policies and process documented in the Cloud Cookbook (likely in the Leading Workshops section). We can track specific issues in the NASA-Openscapes GitHub organization.

Policy documentation and issues:

• [x] https://github.com/NASA-Openscapes/2i2cAccessPolicies
  • [x] Also: FYI we have Discussions in this repo: https://github.com/NASA-Openscapes/2i2cAccessPolicies/discussions
• [x] Cookbook: Leading Workshops and how to add people to 2i2c
  • [x] Note new process with nasa-openscapes-workshops repo where we will have a separate GitHub Team for each workshop. We can bulk-add GitHub usernames with kyber; note this is something that Stef/Julie/Erin currently do for Champions and we're just starting to use for NASA JupyterHub; but hasn't been taught/established as practice for Mentors
  • [x] https://github.com/NASA-Openscapes/workshop-planning/issues/9#issuecomment-1988968323
  • [x] https://github.com/orgs/NASA-Openscapes/projects/7/views/1?pane=issue&itemId=50591614 - also relevant for organization/design: this Leading Workshops section will ultimately have other pages than 2i2c Access
• [x] 2i2c Hackday conversations/notes

Moving towards automating more workshop processes:

• [x] NASA-OpenscapesCloudWorkshopsRegistry is where we're starting to track all workshops. The idea is that we can follow a similar process we've developed for our Champions Cohorts, using the kyber R package.
• [x] Review kyber: https://openscapes.github.io/kyber/. You'll get a sense of this in the "How We Work" calls starting next week too. We already use kyber to bulk-add github usernames to the GitHub API

[jules32]

We've scheduled a 2 hour coworking for April 10 where we can tackle some of these things together once you're a bit more familiar with the things above

[ateucher]

This issue also seems relevant here: https://github.com/NASA-Openscapes/earthdata-cloud-cookbook/issues/316

[ateucher]

A thought about the ChampionsAccess-2i2c team... is the intention to have one team, and on-board and off-board members at the start/end of each cohort? Or do we want a team for each cohort? I wonder where the cost/benefit falls of administering multiple teams vs potential overlap in access between one team and the next?

[jules32]

Progress today: @ateucher created a draft PR to 2i2c/infrastructure to update the teams access: https://github.com/2i2c-org/infrastructure/pull/3930

We stopped before adding mentors (using kyber) to nasa-openscapes-workshops:: AdminTeam, thinking that we will do that for upcoming workshops when we onboard specific mentors to this process (with some of this documentation in the Cookbook)

Next steps for Andy:

• [ ] ​​update documentation to match current status in https://github.com/NASA-Openscapes/2i2cAccessPolicies. This will eventually be a section/chapter in the cookbook under: https://github.com/NASA-Openscapes/earthdata-cloud-cookbook/tree/main/policies-usage

[ateucher]

We also created a new (empty) team for the 2024 champions cohort nasa-openscapes-workshops:champions-access-2i2c-2024

[jules32]

Hi Andy! Great job today with presenting these slides with the Champions Cohort. I think we're ready to add to Cookbook:

Could you please:

• [ ] Move 2i2cAccess policies to Cookbook Policies and Usage page
  • [ ] delete README text and point to Cookbook page
  • [ ] move the current "AWS Cost Explorer" stuff to a new page (maybe exploring-costs.md) and include a link to your slides from today up at the top?