Skip to content
Draft
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
112 changes: 76 additions & 36 deletions docs/governance/decisions/929-move-repository.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# Decision Record: [#929 Move or fork to independent organization](https://github.com/nsidc/earthaccess/issues/929)

- Status: Ready for Review <!-- optional -->
- Deciders: @jhkennedy, @chuckwondo, @mfisher87, @Sherwin-14, @asteiker, @itcarroll
- Date: 2025-07-08
- Deciders: @jhkennedy, @chuckwondo, @mfisher87, @Sherwin-14, @asteiker, @itcarroll, @danielfromearth
- Date: 2025-07-08; modified 2025-09-30
<!-- - Tags: [space and/or comma separated list of tags] optional -->

Technical Story: [#929 Move or fork to independent organization](https://github.com/nsidc/earthaccess/issues/929)
Expand All @@ -16,7 +16,7 @@ organization, GitHub's design prevents us from administrating our project
independently.
For example, we require organization owner permission for certain actions, teams are managed at the organization level, and our project is mixed with a large number of other projects (making it less discoverable).

Moving the `earthaccess` repo to another GitHub organization will:
In order to strengthen the community engagement of earthaccess and lower participation barriers, moving the `earthaccess` repo to another GitHub organization will:

* Reduce friction to collaboration by allowing us to self-determine our
community members' access and privileges.
Expand All @@ -27,51 +27,91 @@ Moving the `earthaccess` repo to another GitHub organization will:
* Preserve community's ability to make its own decisions independent of
institutional structure and policy.

Overall: enhance collaboration, efficiency, and longevity
In order to strengthen the community engagement of earthaccess and lower participation barriers, moving to a

Bullets from presentation to ESDIS on 2/11/2025:
- Accelerate development via broader participation
- Lower the cost:value even further for ESDIS
- Promote NASA’s partners

* Co-location with other similar projects (including similar resources in other languages, e.g. R and Julia)
* Meeting users where they are
* Increase visibility, ability to promote, bring awareness to a broader community (e.g. Pangeo showcase)
* Meets NASA Open Source Science goals
* Leveraging NUMFocus sponsorship could allow for Google Summer of Code mentorship and other funding/effort contributions
* Promotes NASA’s partnerships with other community members based on shared goals, by actively recognizing the critical * contributions of those members.
* From some Googling:
* Flexibility
* Rapid innovation
* Improved security through rapid bug fixes
* Transparency and trust
* Cost efficiency
* Development driver by the user community
* While inter-community support reduces ESDIS/NASA required support, we acknowledge that increased ESDIS funding will also help us sustain the library
hips with other community members based on shared goals
- Increase sustainability
### Historical Context

A presentation by several earthaccess maintainers to NASA ESDIS on 11 February 2025 provided additional context and benefits of "repotting" the earthaccess repository, in order to learn more about their stance on moving and how this might impact future funding opportunities. This presentation highlighted other key benefits of repotting the repository, including:

* Accelerating development via broader participation.
* Lowering the cost:value even further for NASA ESDIS by enabling rapid innovation and improved security through rapid bug fixes.
* Promoting NASA’s partnerships with other community members based on shared goals, by actively recognizing the critical contributions of those members and increasing transparency and trust.
* Meeting NASA Open Source Science goals.

Subsequent discussion included positive feedback from ESDIS on the value of earthaccess, and the desire to not disrupt the existing community development and engagement. An outcome of this meeting was to pursue a cross-DAAC proposal for sustained ESDIS funding, retaining the existing community ownership model while enhancing the communication of feature development across the earthaccess community and ESDIS. While inter-community support reduces ESDIS/NASA required support, we acknowledged in the proposal that increased ESDIS funding will also help us sustain the library. Although a proposal draft was developed, ESDIS asked for this effort to be paused in summer 2025. earthaccess is currently listed by ESDIS as an approved, operational Enterprise Solution, and was considered out of scope in broader tool and service convergence activities across other enterprise components. Regardless of the repository migration approach we choose, we will continue acknowledging ESDIS support through our ESDIS-funded contributors and the valuable facilitation role of NASA Openscapes.

### Migration effort tasks

Options 2 and 3 below would involve the movement of the existing earthaccess repository into another GitHub organization.

This transfer would be transparent to the earthaccess community in the following ways:

1. Repository URL (https://github.com/nsidc/earthaccess):
* While the repository's URL will change to reflect the new organization, GitHub provides redirects from the old URL. Users who bookmark the old URL should not be negatively impacted.
2. Readthedocs URL (https://earthaccess.readthedocs.io/en/stable/):
* This URL will not change even if the repository is migrated to a new GitHub organization.
3. Issues, Pull Requests, and Discussions:
* All existing issues, pull requests, and other project details (e.g., commit history, branches) will be transferred with the repository and remain intact.
4. Forks:
* According to GitHub [Transferring a repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository#whats-transferred-with-a-repository) documentation, "If the transferred repository has any forks, then those forks will remain associated with the repository after the transfer is complete."
* In the above documentation, there is also mention of "Single repositories forked from a private upstream network cannot be transferred." but this may not apply to us(?).
5. PyPI and conda-forge releases:
* earthaccess publication to both PyPI and conda-forge package managers should continue as expected without any breaking changes.

This transfer would lead to the following administrative changes:

1. Local Clones:
* According to GitHub [Transferring a repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository#whats-transferred-with-a-repository) documentation, "All links to the previous repository location are automatically redirected to the new location. When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL. However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL. You can do this by using git remote on the command line: `git remote set-url origin NEW_URL`
* We may want to consider if/how to provide guidance to our community on this recommended update, though we expect this update would cause minimal disruption.
3. Permissions and Access to the new organization:
* earthaccess maintainers would need to consider updating/reconfiguring permissions and access settings for team members within the new organization.
* We may need to consider updates to our existing contributor documentation to reflect any applicable changes to our access processes.
3. Integrations and Third-Party Tools:
* This may not apply to earthaccess, but we ought to consider whether any existing integrations in the NSIDC GitHub organization apply and would need to be re-connected to the migrated repository.
4. GitHub Project configuration
* Classic GitHub Projects tied to the repository will not transfer and references to issues/PRs within them may break. We need to identify whether we are utilizing classic vs new (beta) projects. For the latter option, project configuration may remain but may need manual re-association.


## Considered Options

?
### Option 1: Don't move; stay within `nsidc` org.

Pros:
* No migration effort (and associated disruption) needed

## Decision Outcome
Cons:
* No clear path to extend organizational ownership permissions to earthaccess maintainers outside of NSIDC

?
### Option 2: Move to an independent org, e.g. `earthaccess-dev`.

Pros:
* Overall benefits described above
* Full / flexible community governance
* Custom branding?

### Option 1
Cons:
* Migration effort
* Potential for reduced visibility without institutional org backing?

Don't move; stay within `nsidc` org.

### Option 2
### Option 3: Move to a sponsor / incubator org, e.g. `pangeo`, `openscapes`.

Pros:
* Overall benefits described above
* Built-in open source credibility and visibility
* Leverage existing communities, increased contributor base?
* Leverage existing software infrastructure?,
* Leverage existing governance models?
* Potential funding opportunities?
Comment on lines +99 to +103
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we get all of the above from e.g. going through pyopensci review without being in a special org. I wouldn't describe these benefits as unique to being in a specific org.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great point, @mfisher87 ! Should I rework this to incorporate pyopensci review as a new process we would incorporate as part of either/both Option 2 and 3? If you have more details on how this could work, please let me know.

Copy link
Collaborator

@mfisher87 mfisher87 Oct 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's hard to decide how to organize this information... it's not really tied to option 2 or 3. It could apply to any of options 1, 2, or 3, and it confers the same pros from option 3. So I think this is an independent variable that should not be documented as part of this decision record, and perhaps should be another decision. I.e. remove the unique pros from option 3 as they are not conferred solely by joining a third-party org and can be conferred through other processes.

What do you think?


Cons:
* Migration effort
* Less control over organizationl decisions/policies/memership?
* May need to align with existing organization's priorities and processes



## Decision Outcome

TBD

Move to an independent org, e.g. `earthaccess-dev`.

### Option 3

Move to a sponsor / incubator org, e.g. `pangeo`.