Help newcomers to adopt Git quickly

[vladimir-v-diaz]

Is the Git+GitHub guide sufficient for newcomers in helping them get started with our recommended software development platform? Should we have a repository to serve as a sort of Git playground, or should newcomers get started right away with contributions and learning how to use Git+GitHub that way?

[Copying the following from this comment, which was posted by @aaaaalbert]

How can we help our newcomers to adopt Git quickly (to use it productively for their own work) and in a way that interfaces nicely with our workflows?

Should we send newcomers to @octocat's Spoon-Knife repo to actually try out the theoretic skills acquired through this guide?

Or shall we have a playground repo of our own where people can experiment? "First task on first day on the team: Add your favorite sports/treat/metro line to secure-systems-lab/playground" sorts of thing?

[lukpueh]

I think having lab newcomers go through the Spoon-Knife tutorial is a great idea.

In general I wonder if it wouldn't make more sense to limit our guides to workflows that are specific to the securesystemslab, plus linking to existing guides.

IMHO, there are already many excellent official (and non-official) git [1] and GitHub [2], [3] guides for every expert level and level of detail out there.

I know we (mostly @vladimir-v-diaz and @aaaaalbert, but I as well) just spent some time on updating our existing git and GitHub guide, but maybe it would be worth to rethink our strategy and rather provide a meta-guide that helps newcomers read through the plethora of git and GitHub guides instead of adding another one to it?

[aaaaalbert]

@lukpueh, I do feel similar re: our Git/GitHub guide, but let's keep that discussion on PR #9 if you don't mind.

For the "helping newcomers" issue at hand, the Spoon-Knife tutorial repo is great for trying out the various buttons on the GitHub web interface, creating own forks/branches/commits/issues/PRs, and so on.

What it lacks though is interaction with other developers or repo maintainers, and this is why I was thinking of a sandbox repo of our own. @octocat doesn't comment on your PRs or asks you to provide better commit messages. There are no merge conflicts, no rebasing required, etc.

However, having an ssl sandbox repo that introduces newcomers to this obviously means additional work for us! Even if the contents are just slightly amusing gibberish, we have to execute the procedures in earnest.

[vladimir-v-diaz]

If someone wants to work on a sandbox repo of own, I guess that's fine. However, why not have newcomers get started contributing real code and pull requests ASAP rather than play in a sandbox?

Since pull request summaries, commits, issues, etc. can be edited, I don't see any harm in having a newcomer gain experience via mergeable pull requests/contributions.

[vladimir-v-diaz]

This issue was briefly discussed in one of our recent in-person meetings. @JustinCappos recommended that we have newcomers submit a "projects that interest me" pull request, which falls in line with @aaaaalbert last listed suggestion:

"First task on first day on the team: Add your favorite sports/treat/metro line to secure-systems-lab/playground" sorts of thing?