You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<!-- - Tags: [space and/or comma separated list of tags] optional -->
7
7
8
8
Technical Story: [#929 Move or fork to independent organization](https://github.com/nsidc/earthaccess/issues/929)
@@ -16,62 +16,98 @@ organization, GitHub's design prevents us from administrating our project
16
16
independently.
17
17
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).
18
18
19
-
Moving the `earthaccess` repo to another GitHub organization will:
19
+
In order to strengthen the community engagement of earthaccess and lower participation barriers, moving the `earthaccess` repo to another GitHub organization will:
20
20
21
-
* Reduce friction to collaboration by allowing us to self-determine our
22
-
community members' access and privileges.
21
+
* Reduce friction to collaboration by allowing the community to self-determine its
22
+
members' access and privileges.
23
23
* Improve discoverability by reducing the amount of irrelevant items
24
24
when browsing for related projects.
25
25
* Enable bundling related repositories (e.g. the R earthdatalogin project, other
26
26
dependency libraries) under the same org, for example to cross-document project.
27
-
* Preserve community's ability to make its own decisions independent of
28
-
institutional structure and policy.
29
-
30
-
Overall: enhance collaboration, efficiency, and longevity
31
-
In order to strengthen the community engagement of earthaccess and lower participation barriers, moving to a
32
-
33
-
Bullets from presentation to ESDIS on 2/11/2025:
34
-
- Accelerate development via broader participation
35
-
- Lower the cost:value even further for ESDIS
36
-
- Promote NASA’s partners
37
-
38
-
* Co-location with other similar projects (including similar resources in other languages, e.g. R and Julia)
39
-
* Meeting users where they are
40
-
* Increase visibility, ability to promote, bring awareness to a broader community (e.g. Pangeo showcase)
41
-
* Meets NASA Open Source Science goals
42
-
* Leveraging NUMFocus sponsorship could allow for Google Summer of Code mentorship and other funding/effort contributions
43
-
* Promotes NASA’s partnerships with other community members based on shared goals, by actively recognizing the critical * contributions of those members.
44
-
* From some Googling:
45
-
* Flexibility
46
-
* Rapid innovation
47
-
* Improved security through rapid bug fixes
48
-
* Transparency and trust
49
-
* Cost efficiency
50
-
* Development driver by the user community
51
-
* While inter-community support reduces ESDIS/NASA required support, we acknowledge that increased ESDIS funding will also help us sustain the library
52
-
hips with other community members based on shared goals
53
-
- Increase sustainability
27
+
* Preserve community's ability to make decisions based on the interests and needs of users,
28
+
independent of institutional structure and policy.
54
29
30
+
### Historical Context
31
+
32
+
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:
33
+
34
+
* Accelerating development via broader participation.
35
+
* Lowering the cost:value even further for NASA ESDIS by enabling rapid innovation and improved security through rapid bug fixes.
36
+
* 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.
37
+
* Meeting NASA Open Source Science goals.
38
+
39
+
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.
40
+
41
+
### Migration effort tasks
42
+
43
+
Options 2 and 3 below would involve the movement of the existing earthaccess repository into another GitHub organization.
44
+
45
+
This transfer would be transparent to the earthaccess community in the following ways:
* 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.
* This URL will not change even if the repository is migrated to a new GitHub organization.
51
+
3. Issues, Pull Requests, and Discussions:
52
+
* All existing issues, pull requests, and other project details (e.g., commit history, branches) will be transferred with the repository and remain intact.
53
+
4. Forks:
54
+
* 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."
55
+
5. PyPI and conda-forge releases:
56
+
* earthaccess publication to both PyPI and conda-forge package managers will continue as expected without any breaking changes.
57
+
58
+
This transfer would lead to the following administrative changes:
59
+
60
+
1. Local Clones:
61
+
* 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`
62
+
* We will create an "explanation" page in our docs as a historical record and include instructions for updating local clones.
63
+
3. Permissions and Access to the new organization:
64
+
* earthaccess maintainers would need to update permissions and access settings for team members within the new organization, as people who have access solely via NSIDC organization teams would lose access.
65
+
* We may need to consider updates to our existing contributor documentation to reflect any applicable changes to our access processes.
66
+
3. Integrations and Third-Party Tools:
67
+
* 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.
68
+
4. GitHub Project configuration
69
+
* 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.
55
70
56
71
57
72
## Considered Options
58
73
59
-
?
74
+
### Option 1: Don't move; stay within `nsidc` org.
60
75
76
+
Pros:
77
+
* No migration effort (and associated disruption) needed
61
78
62
-
## Decision Outcome
79
+
Cons:
80
+
* No clear path to extend organizational ownership permissions to earthaccess maintainers outside of NSIDC
81
+
* Vulnerability to disruption by changes within the federal government, including shutdowns, funding changes, or dissolution of organizations.
63
82
64
-
?
83
+
### Option 2: Move to an independent org, e.g. `earthaccess-dev`.
65
84
85
+
Pros:
86
+
* Overall benefits described above
87
+
* Full / flexible community governance
88
+
* Custom branding?
66
89
67
-
### Option 1
90
+
Cons:
91
+
* Migration effort
92
+
* Potential for reduced visibility without institutional org backing?
68
93
69
-
Don't move; stay within `nsidc` org.
70
94
71
-
### Option 2
95
+
### Option 3: Move to a sponsor / incubator org, e.g. `pangeo`, `openscapes`.
72
96
73
-
Move to an independent org, e.g. `earthaccess-dev`.
0 commit comments