- 
                Notifications
    
You must be signed in to change notification settings  - Fork 131
 
Move repo decision record - updates from 9-30 hackday! #1104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: move-repo-decision-record
Are you sure you want to change the base?
Move repo decision record - updates from 9-30 hackday! #1104
Conversation
| 
           
 I will automatically update this comment whenever this PR is modified 
 
 
  | 
    
| * Built-in open source credibility and visibility | ||
| * Leverage existing communities, increased contributor base? | ||
| * Leverage existing software infrastructure?, | ||
| * Leverage existing governance models? | ||
| * Potential funding opportunities? | 
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
Co-authored-by: Matt Fisher <3608264+mfisher87@users.noreply.github.com>
| 
           pre-commit.ci autofix  | 
    
for more information, see https://pre-commit.ci
@danielfromearth and I co-worked during the earthaccess hackday today on this decision record, including expansion of the context, migration impacts, and pros/cons of the options outlined. This would be an update to the existing draft PR #1047
Pull Request (PR) draft checklist - click to expand
contributing documentation
before getting started.
title such as "Add testing details to the contributor section of the README".
Example PRs: #763
example
closes #1. SeeGitHub docs - Linking a pull request to an issue.
CHANGELOG.mdwith details about your change in a section titled## Unreleased. If such a section does not exist, please create one. FollowCommon Changelog for your additions.
Example PRs: #763
README.mdwith details of changes to theearthaccess interface, if any. Consider new environment variables, function names,
decorators, etc.
Click the "Ready for review" button at the bottom of the "Conversation" tab in GitHub
once these requirements are fulfilled. Don't worry if you see any test failures in
GitHub at this point!
Pull Request (PR) merge checklist - click to expand
Please do your best to complete these requirements! If you need help with any of these
requirements, you can ping the
@nsidc/earthaccess-supportteam in a comment and wewill help you out!
Request containing "pre-commit.ci autofix" to automate this.
📚 Documentation preview 📚: https://earthaccess--1104.org.readthedocs.build/en/1104/