do we want students to fork the hw repos?

[tansaku]

we say that's standard practive in the c9 setup instructions, but I'm not sure it serves much purpose:

https://github.com/saasbook/courseware/wiki/Setting-up-Cloud9

It's an extra step they have to remember, and can thus get wrong, and ideally we don't want people pushing their solutions to their forked repos, and it makes it more difficult for students to receive any quick fixes we might have to push out.

I mean personally I think trying to keep the solutions is a losing battle, but forking seems like something we should recommend as a first step if people are getting set up to maintain their own copy of a repo, or to submit a fix ... I guess we do get some of that ... but feels like suggesting forking as a first step is front loading complexity ...

/me is conflicted ...

[armandofox]

the problem is people clone the hw repos, then try to submit PRs against the original repo with their solutions.

if people want to version their own solutions, they need to fork. (and the READMEs in the HW repos should probably all begin with "NOTE: Don't submit PRs against this repo -- fork it to your account first" or something like that.

[tansaku]

the problem is people clone the hw repos, then try to submit PRs against the original repo with their solutions

Is that more or less of a problem than people pushing the solutions to their public repos that are forks of ours?

Also I would have thought that pull requests are more likely to come after a student has forked a repo than after a pure clone. In fact students can't create pull-requests from pure clones because they can't push any code to our original repo. I would have thought that having the students fork the repos at the beginning of the homework actually increases the chances of pull requests ...

if people want to version their own solutions, they need to fork.

Do they? they can version them in their own local git repos, no need to fork. Forking helps them have a place on Github they can back up their local versions to, but that also ensures that it's linked to our repo, and so their solutions become discoverable. If students want to create their own backups on GitHub they don't have to fork - they could just create their own new repos. So again I think this points to avoiding forking.

The forking functionality appears to me to be set up to make it easier to make pull requests, and diverge a different version of a project; which we want the students to be able to do to work with OS projects, but is not what the course wants at the moment?

Now GitHub offers unlimited private repos we could be encouraging students to make their forked? new? repos private, but there's no guarantee any students will use that functionality. There's also nothing in the homeworks that helps scaffold students into using remote Github repos to backup their versioned code, or indeed take regular git snapshots ...

Maybe we want to move to a model where we assume that the solution to any assignment is in principle available (allowing us to stop worrying about keeping them secret), but what we assess students on is their process, i.e. do they TDD, do they pair effectively, do they back up to git regularly etc. ...

[freeranger]

re: Private repos - this only applies to paid plans. Free plans still don't get private repos.
Bitbucket gives you private git based repos for free if you want them, but not github.

It is easy for students to fork or clone the HW repo and push to their copy not realising that they have now made their solution public (many will be new to github) so you may indeed want to assume the solutions are out there, whether deliberate or otherwise.