-
Notifications
You must be signed in to change notification settings - Fork 30
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
Add a GitHub chapter? #320
Comments
Oh, and I would also want to say a few words of caution: to make sure people realize that GitHub is a commercial provider who while historically great may at any point change policies and, for instance, start deleting old issues. Since many of us use GitHub as some kind of historical archive, we should be aware that it may not be and perhaps keep on the lookout for alternatives that are guaranteed sustainable (and equally convenient). This is btw also another reason to keep good commit history etiquette: if your git commits contain all the relevant information on changes as well, then nothing relevant will ever get lost. You don't need to store whole discussions leading up to changes, but just document the end result + the why and then everything is safe inside the git repo itself, which exists independently of GitHub. |
Also e.g. "use Zenodo integration". |
There is a Turing Way chapter on this! https://book.the-turing-way.org/collaboration/github-novice.html We should link to it as starting point and add specifics for what we expect. |
Add to #321 |
Following discussion in #286 and the removal of the e-Infra chapter in #312, I was thinking it may make sense to add a short chapter with best practices on using GitHub. This is definitely not unique to NLeSC, but it is specific to NLeSC (it is our default option), so a few intermediate-level tips that everybody should know (and I'm pretty sure not everybody knows it when they join NLeSC) may be useful. We can also add some general Git things.
Three things I would suggest we mention:
There are of course many more things that could be mentioned, but some are perhaps too obvious ("use issues", "use PRs", etc) and others are too technical ("use git rebase -i so you can do git bisect" for instance is perhaps too much detail? maybe not). So while keeping things to the minimum of things you would recommend your (new) colleagues to do, what more could be in here? Are the things I mention above necessary or not?
Open to comments!
The text was updated successfully, but these errors were encountered: