<h1>Some technical solutions</h1>
<p>I am not looking for technical solutions, but I have included a few here, in case they would be useful to others (and this is not the right site for asking for such solutions).</p>
<ul>
<li><p>Use Access Control Lists (ACLs). These are available on MS-Windows and Gnu/Linux, and can be used to set a list of users that have access to files.</p>
</li>
<li><p>Set up the computer or websites, so that two users can login at the same time. For Gnu/Linux you could probably configure PAM.</p>
<p>I imagine that this would be a lot of work to set up resources, e.g. a web-based resource that tracks which two students did each activity.</p>
</li>
</ul>
<p>The first solution, is the only one that could be used adhoc, without any set up. I have noticed that very few people use MS-Windows ACLs, probably because they are very complex. However there is a sub-set that is simple and useful. With the correct tools they could be made easy to use.</p>

CC BY-SA 3.0
2017-12-28T19:26:15.523Z
another option would be any sync tool - maybe your institution offers their own cloud, where you could manage who has access to which files. Or maybe even use git where you own the repositories
lucidbrot
CC BY-SA 3.0
2017-12-29T15:50:52.927Z
You could create a new Runestone Interactive Component, [examples](https://runestone.academy/runestone/static/overview/overview.html), [source](https://github.com/RunestoneInteractive/RunestoneComponents)
Guy Coder
CC BY-SA 3.0
2017-12-28T12:15:34.727Z
2017-12-28T12:15:34.727Z
2020-06-18T08:36:57.023Z
ctrl-alt-delor
<p>Any solution will be "technical" in nature since the problem involves technology anyway. However, for the "access" issue, you can create a solution which puts more work on you than on the technology. (Since tech is supposed to make human work easier, that's kind of an anti-tech concept, right?)</p>

<p>Required environment is a publicly (relative to the classroom computers) accessible file storage in which <strong>you</strong> (the instructor) can create password-protected directories. <em>[This can still be a closed environment relative to the wider network, including other parts of the LAN, and the Internet as a whole, so long as it is a location that the students can access during class.]</em> Out-of-class access could be an issue, either because it is desirable and making it happen is not easy on the school's system, or because it is undesirable, yet hard to prevent on the school's system. As mentioned in <a href="https://cseducators.stackexchange.com/a/4106/104">another answer</a>, the students can always print a copy, or email a copy to themselves, for out-of-class review and planning.</p>

<p>For the project, create a directory for each pair, or team of any size, with a unique (per directory) password. Provide that password to each of the team members. When one is absent, for any reason, the other (rest) can still access the directory. If you have the need to reassign team membership, you change the password(s) in the affected directories and give them to the reorganized teams.</p>

<p>This provides each team a space to work, and share, including a place to make related notes, trials, documents, etc. You, as the instructor, will have access to all the directories, and can check the work at any time. The solution works equally well for program coding, research paper writing, and even graphic design. The hard part for the instructor is creating, and maintaining, the collection of directories and passwords. Especially if there are overlapping project time-frames, requiring that there be multiple sets of directories available at one time (along with remembering who has access to which one) with each directory needing a unique, yet easily used, password.</p>

<p>This solution <em>does not</em> scale well at all, and is unworkable in a workplace environment, yet is simple enough to set up and use in the controlled environment of an educational arena. At the end of the term you can merely delete/clean the parent directory and you're ready to start the next term.</p>

<p>Of course, the underlying principle may be enhanced, or modified, using ACLs, Apache user names, SSH with PGP keys, and many other "technological" variations; but, non-technological was the target.</p>

CC BY-SA 3.0
2018-01-04T17:56:03.090Z
2018-01-04T17:56:03.090Z
Gypsy Spellweaver
<p>Speaking from an industry perspective, my team is scattered around the world.</p>

<p>Source code is managed on a server in our rack in the USA.  We use subversion because git and mercurial are a pain to work with. I can get to my team's checked in source code daily.</p>

<p>While some of my team live close enough to each other to have face to face time, most work at a distance. Partner work is handled through online conferencing software.</p>

<p>Everyone has their own accounts. Work is checked in to the version control system regularly (daily or more often if possible).  Since everyone has their own account, we can use the subversion "blame" function to identify who checked in the code.</p>

<p>A caution - operating the computer takes a certain amount of brain power, so the real work on the problem may be done by the partner who is not keyboarding. Detecting "freeloaders" based on counts or volume of checkins creates a false sense of security, and my be punitive to a team that has really worked out how pair programming works for them. </p>

<p>I remember my final assignment for PDP-11 assembly class, which I worked on with a partner. With my prior experience, I was able to quickly solve the assigned problem in a way that earned all of the bonus points. For the curious, we built an desktop calculator in assembly. Bonus points were handling algebraic order, parentheses, square root, remainders, hexadecimal conversion, and smallest program. We got all of that into 120 bytes.</p>

<p>My partner, who handled the keyboarding, looked at the finished program, had no idea of why it even worked and (wisely from a learning perspective) decided to try to solve the problem on his own without my help. </p>

<p>Had he not made that decision, one could argue either that I was the freeloader because I had not keyboarded anything, or that he was the freeloader because he depended wholly on my experience. The instructor would have no way to tell who (if either) was the freeloader without knowing both of us very well.</p>

<p>LOC and similar metrics from code and checkins are not useful for determining programmer productivity either in industry or in education.</p>

CC BY-SA 3.0
2018-01-15T19:24:35.710Z
Similar situation.  Was taking a hardware interfacing course. The µC we were using (68HC12) had to be programmed in assembly.  68HC12 assembly is similar to 6502 assembly; learned 6502 assembly over a decade prior.  My lab partner was a EE major; he knocked out the hardware parts and I knocked out the software parts (faster than other teams; excellent grades). If you looked only at software, you'd think he was a freeloader. Knowing we would be working separate on the final exam, we knocked out each assignment then switched roles and did it again to ensure each of us could do each role.
Meower68
CC BY-SA 3.0
2017-12-30T02:59:36.703Z
2017-12-30T02:59:36.703Z
pojo-guy
<p>The way our network is setup I have access to my students network shares. So, if a kid is absent I can get to their stuff and copy it for their partner. Not ideal, and definitely doesn't scale well if there are a bunch of students absent. Plus, I really don't like the privacy implications. But it works in a pinch.</p>

<p>I've also had groups share a flash drive, and then leave that flash drive in the classroom. Works okay if there's no plan on working outside of class.</p>

<p>Some groups will zip up and email themselves the work they've done at the end of class. Or, upload to DropBox, Google Drive, or something like that. </p>

<p>My personal preference would be some type of source control. I've been looking for a reason to introduce git into my 2nd year course. Maybe this would be a good excuse. </p>

CC BY-SA 3.0
2017-12-28T21:15:54.100Z
Do you have any idea how that network is setup, and if so could you describe it so that someone else reading this answer could replicate it?
thesecretmaster
CC BY-SA 3.0
2017-12-28T21:22:54.777Z
Not sure. It's something they've done specifically for the CompSci classes and only works in our labs.
Ryan Nutt
CC BY-SA 3.0
2017-12-28T20:06:08.027Z
2017-12-28T20:06:08.027Z
Ryan Nutt
<p>For point 2. I can think of a few solutions each with different amounts of work and tradeoffs.</p>

<ol>
<li><p>At work we'd use revision control for this. The repository is stored
in a common location where all people have access. Whenever you're
done working as a pair you'd push/commit your work. </p></li>
<li><p>Have everyone work on a shared network drive permissioned by
you. Each pair would get a folder just for them. Or its just a freeforall.</p></li>
<li><p>Have every workstation be 'public' as in there's only one user and
it's always logged in. The students will do their work, and as long
as the work station is available they can work on it.</p></li>
</ol>

CC BY-SA 3.0
2017-12-28T20:32:57.670Z
Welcome to CSEducators. Thanks for your comment and we hope to hear more from you in the future.
Buffy
CC BY-SA 3.0
2017-12-28T17:42:39.070Z
2017-12-28T18:29:49.820Z
2017-12-28T18:29:49.820Z
jmathew
<p>One technical option is repl.it,  it is a web IDE ( supporting all languages), and anyone with a link to a 'repl' can edit and run (or from browser).<br/> 
(i think they support github, not sure).</p>

<p>They also have multi-player option, that few folks can edit the same file simultaneously!<br/> 
( never used multi-player, nor github integration, but used the ide, it is good, yet without built-in SC).</p>

CC BY-SA 4.0
2019-09-27T18:17:22.090Z
2019-09-27T18:56:42.677Z
2019-09-27T18:56:42.677Z
jsonphy
<p>Actually, in true pair-programming no one works (or at least modifies any code) unless the partner is present. This is an important rule as I've seen really bad things happen when one member of a pair (or team) thinks he/she "gets it" and doesn't. I've had to spend half a day backing out "improvements" that were really misunderstandings by the perpetrator. People are not, however, forbidden to think about the project when alone - which would be foolish. To ease the offline thinking, pairs can be encouraged to simply email the existing code to both members so they have a basis for their deliberations. Printing it is even better, as it can be marked up on the bus, etc. </p>

<p>To solve the other issues, you could create meta-accounts for the pairs in which pair members know the credentials and change them when pairs are reassigned. Using personal accounts for group work is probably a mistake. </p>

<p>One way to manage exchange of ideas and peer-teaching in such a situation is to let pairs work for a while, swapping roles as appropriate, and then mixing up the pairs. The navigators at that moment move to a new station and the driver stays with the one they are "driving". The navigator continues to navigate, coming up to speed for a bit. </p>

<p>However, a caveat, and a suggestion for your overall process. I consider it poor practice to swap roles by the clock. They should switch at natural points. The classic one is that the driver drives until he/she gets stuck and the navigator, who has been really navigating and not just observing, knows how to proceed. Rather than make a suggestion about how to proceed, the navigator just takes the keyboard and continues. This may not be sufficiently often in the classroom as some students will (foolishly) try to dominate and others (equally foolishly) may try to ride along for "free". So...</p>

<p>Another way to encourage frequent switching is to combine pair programming with a strict pre-test rule: <em>No code without a failing test</em>. Switching then goes like this. One partner writes a failing test for the code and the other takes over long enough to (a) make that test pass and (b) write another failing test. Then they switch again and continue. This has been called "heartbeat" switching. It also encourages the navigator at the moment to stay engaged. </p>

<p><em>The navigator is NOT an observer</em>. Don't let students think that it is easier than driving. It has an important "strategic view" purpose that complements the "tactical view" of the current driver. With no need to think at the detail level, the navigator keeps the direction of travel in mind. Both participate equally, though differently. Make sure students understand that. The job of the navigator is definitely NOT to get coffee for the driver, nor even to do background research. Both should do those things together. </p>

<hr>

<p>For paired/group work that does not involve just programming you should seek to assure that the members of a group don't just "divide up the work" between them, but actually work cooperatively on it for all phases. Students think that division is a great idea until they reach the point of trying to integrate possibly inconsistent separate work. On Agile teams, pairs work together, but the team's pairs work on different things. The daily <em>Stand Up Meeting</em> is the way for all of the pairs to assure that they all work toward the common purpose. So, you might institute a practice of <em>daily face to face</em> meetings in each pair/team so that if they work separately they do so only on small and easily integrated things rather than big chunks that don't necessarily fit together. </p>

<hr>

<p>Additionally, in a course that uses pair and group work extensively it is a good idea to use <a href="https://cseducators.stackexchange.com/questions/3408/how-can-i-effectively-manage-peer-evaluation-among-my-students">peer evaluation</a>. In addition to the suggestions at the link you can use index cards creatively to capture the individual evaluations and create a matrix form in which to record them. I'm assuming that you change teams/pairs, so that students get to work with a variety of partners. It is really only necessary to record the exceptional evaluations (good and bad). The matrix lets you see not only who is consistently given good or bad evaluations, but also lets you see who <em>gives</em> consistently good or bad peer evals. </p>

CC BY-SA 3.0
2017-12-28T13:11:35.213Z
I am not considering just pair programming, but all activities, that use a computer. I would like pupils to do all work in pairs, and for me to be able to rearrange pairings (may be at the start of a lesson). I have never considered using a  clock to determine when to switch role, and agree it would be a bad thing to do. You have some good ideas about when to switch. While there is useful stuff in your answer, I don't think it addresses the question.
ctrl-alt-delor
CC BY-SA 3.0
2017-12-28T14:13:10.870Z
I added a bit at the end, but you might also modify the question a bit to emphasize what you've said above: all work, not just programming.
Buffy
CC BY-SA 3.0
2017-12-28T12:46:45.117Z
2017-12-29T10:36:01.813Z
2017-12-29T10:36:01.813Z
Buffy
<p>You mention this:</p>

<blockquote>
  <p>Access to previous work, when partner is not present. Because pupils have to log-in, and use a single account. There is a problem if the account holder is not present (ill), or if I want to re-pair students.</p>
</blockquote>

<p>... but how do they access it when their partner <em>is</em> present?  Do they have to be on the same machine?  That's fragile (computer dies, is stolen, in use by another pair, etc).</p>

<p>So you need something on a centralized server.  Something that can control access to accounts, where multiple people can share code, and (probably) you can use to hand out any "starting point" code for assignments.</p>

<p>It would also be nice if the system tracked things like changes to the code (enable the students to figure out what changes caused a problem), the ability to automate submission assignment and grading, and a few other things.  Plus it should look like something the students are going to be expected to use for any real-world programming.</p>

<hr />

<p>If you haven't realized it yet, I'm proposing that what you really need is a version control system, probably a packaged server version like what most of the big name providers give you:</p>

<ul>
<li>Allows you to hand out "stub" assignments (fork)</li>
<li>Students can restrict code view to assigned partner (private repositories)</li>
<li>Automatic submission of assignment (pull requests, or at least links to a specified branch/revision)</li>
<li>Can track how much work is done by each student.</li>
</ul>

<p>I wouldn't be surprised if there was already an "educator" version of something like Github or GitLab out there.  Get a distributed server package, set yourself and any TAs up as system admins.  That would allow you to be able to change teams, if necessary, as well (grant access to repository).</p>

<p>(As a note, I'd just go ahead and use a git-based system.  True, it's more complicated overall, but it's unlikely you'd need more than straight commit/push in this situation)</p>

CC BY-SA 3.0
2017-12-28T18:32:58.197Z
They have there own account on a file server. So they can work anywhere, but can not share.
ctrl-alt-delor
CC BY-SA 3.0
2017-12-28T19:30:49.377Z
@ctrl-alt-delor - An account per-pair, or an account per-user?  I'm really more recommending the latter, and using an actual VCS just enables some additional helpful features.
Clockwork-Muse
CC BY-SA 3.0
2017-12-28T20:31:35.583Z
Welcome to CSEducators. Hope to hear more from you in the future.
Buffy
CC BY-SA 4.0
2019-10-13T23:09:12.707Z
@ctrl-alt-delor: The straightforward answer (that minimizes reworking your infrastructure) is then for them to have a folder where they both have access. Whether you create one big folder where everyone has access and pairs are expected to stick to their folder, or whether you create actual folders with specific rights for each pair, is a matter of implementation and what your admins are willing to put up with.
Flater
CC BY-SA 3.0
2017-12-28T17:40:35.573Z
2017-12-28T17:40:35.573Z
Clockwork-Muse
<p>I like pupils to work in pairs, as they learn quicker this way, and need teacher help less often.</p>

<p>However, there are problems, when working together on a computer:</p>

<ul>
<li><p>Free loaders. For this, I give them two roles: Driver and Navigator. The Driver controls the computer, the Navigator does most of the thinking, and tells the Driver what to do. They then switch role often. I manage this by walking around.</p></li>
<li><p><strong>Access to previous work, when the partner is not present. Because pupils have to log in, and use a single account. There is a problem if the account holder is not present (ill), or if I want to re-pair students.</strong></p></li>
</ul>

<p>Has any one any experience with this <strong>2nd point</strong>, and do you have any solutions?</p>

<hr>

<p>I am mostly looking for non-technical solutions. I will add a technical solution.</p>

<p>Edit: I am not only asking about programming. There may be other work on the computer.</p>

CC BY-SA 3.0
2017-12-28T17:22:19.657Z
As a note, I don't know that the driver-navigator scheme will combat freeloading all that much. I've had friends was were freeloader and I hated doing this style of work with any of them. When I was navigating, they would control the computer without any understanding what I was asking them to do. When I was driving, they'd just tell me they didn't know what to do; we had to either not progress, or have me do both roles. This was the case for other similarly paired students as well.
Lord Farquaad
CC BY-SA 3.0
2017-12-28T18:25:39.537Z
Did you consider asking your students to develop [free software](https://en.wikipedia.org/wiki/Free_software) as their school project, and then to use some *existing* forge like e.g. [github](http://github.com/) ? I assume that your students are somehow learning to program.
Basile Starynkevitch
<collaboration>
Allowing students to work cooperatively on a computer, and retain access to their work
# Allowing students to work cooperatively on a computer, and retain access to their work

(Asked by: username_0 on 2017-12-28)

I like pupils to work in pairs, as they learn quicker this way, and need teacher help less often.

However, there are problems, when working together on a computer:

* Free loaders. For this, I give them two roles: Driver and Navigator. The Driver controls the computer, the Navigator does most of the thinking, and tells the Driver what to do. They then switch role often. I manage this by walking around.
* **Access to previous work, when the partner is not present. Because pupils have to log in, and use a single account. There is a problem if the account holder is not present (ill), or if I want to re-pair students.**

Has any one any experience with this **2nd point**, and do you have any solutions?

---

I am mostly looking for non-technical solutions. I will add a technical solution.

Edit: I am not only asking about programming. There may be other work on the computer.

**Tags:** collaboration

> **Comments:**
> **username_1**: As a note, I don't know that the driver-navigator scheme will combat freeloading all that much. I've had friends was were freeloader and I hated doing this style of work with any of them. When I was navigating, they would control the computer without any understanding what I was asking them to do. When I was driving, they'd just tell me they didn't know what to do; we had to either not progress, or have me do both roles. This was the case for other similarly paired students as well.  
> **username_2**: Did you consider asking your students to develop [free software](https://en.wikipedia.org/wiki/Free_software) as their school project, and then to use some *existing* forge like e.g. [github](http://github.com/) ? I assume that your students are somehow learning to program.  

---

## 8 answers

### Answer by username_11 on 2017-12-28. Score: 4

Actually, in true pair-programming no one works (or at least modifies any code) unless the partner is present. This is an important rule as I've seen really bad things happen when one member of a pair (or team) thinks he/she "gets it" and doesn't. I've had to spend half a day backing out "improvements" that were really misunderstandings by the perpetrator. People are not, however, forbidden to think about the project when alone - which would be foolish. To ease the offline thinking, pairs can be encouraged to simply email the existing code to both members so they have a basis for their deliberations. Printing it is even better, as it can be marked up on the bus, etc.

To solve the other issues, you could create meta-accounts for the pairs in which pair members know the credentials and change them when pairs are reassigned. Using personal accounts for group work is probably a mistake.

One way to manage exchange of ideas and peer-teaching in such a situation is to let pairs work for a while, swapping roles as appropriate, and then mixing up the pairs. The navigators at that moment move to a new station and the driver stays with the one they are "driving". The navigator continues to navigate, coming up to speed for a bit.

However, a caveat, and a suggestion for your overall process. I consider it poor practice to swap roles by the clock. They should switch at natural points. The classic one is that the driver drives until he/she gets stuck and the navigator, who has been really navigating and not just observing, knows how to proceed. Rather than make a suggestion about how to proceed, the navigator just takes the keyboard and continues. This may not be sufficiently often in the classroom as some students will (foolishly) try to dominate and others (equally foolishly) may try to ride along for "free". So...

Another way to encourage frequent switching is to combine pair programming with a strict pre-test rule: *No code without a failing test*. Switching then goes like this. One partner writes a failing test for the code and the other takes over long enough to (a) make that test pass and (b) write another failing test. Then they switch again and continue. This has been called "heartbeat" switching. It also encourages the navigator at the moment to stay engaged.

*The navigator is NOT an observer*. Don't let students think that it is easier than driving. It has an important "strategic view" purpose that complements the "tactical view" of the current driver. With no need to think at the detail level, the navigator keeps the direction of travel in mind. Both participate equally, though differently. Make sure students understand that. The job of the navigator is definitely NOT to get coffee for the driver, nor even to do background research. Both should do those things together.

---

For paired/group work that does not involve just programming you should seek to assure that the members of a group don't just "divide up the work" between them, but actually work cooperatively on it for all phases. Students think that division is a great idea until they reach the point of trying to integrate possibly inconsistent separate work. On Agile teams, pairs work together, but the team's pairs work on different things. The daily *Stand Up Meeting* is the way for all of the pairs to assure that they all work toward the common purpose. So, you might institute a practice of *daily face to face* meetings in each pair/team so that if they work separately they do so only on small and easily integrated things rather than big chunks that don't necessarily fit together.

---

Additionally, in a course that uses pair and group work extensively it is a good idea to use [peer evaluation](https://cseducators.stackexchange.com/questions/3408/how-can-i-effectively-manage-peer-evaluation-among-my-students). In addition to the suggestions at the link you can use index cards creatively to capture the individual evaluations and create a matrix form in which to record them. I'm assuming that you change teams/pairs, so that students get to work with a variety of partners. It is really only necessary to record the exceptional evaluations (good and bad). The matrix lets you see not only who is consistently given good or bad evaluations, but also lets you see who *gives* consistently good or bad peer evals.

> **Comments:**
> **username_0**: I am not considering just pair programming, but all activities, that use a computer. I would like pupils to do all work in pairs, and for me to be able to rearrange pairings (may be at the start of a lesson). I have never considered using a  clock to determine when to switch role, and agree it would be a bad thing to do. You have some good ideas about when to switch. While there is useful stuff in your answer, I don't think it addresses the question.  
> **username_11**: I added a bit at the end, but you might also modify the question a bit to emphasize what you've said above: all work, not just programming.  

---

### Answer by username_13 on 2017-12-28. Score: 4

You mention this:

> Access to previous work, when partner is not present. Because pupils have to log-in, and use a single account. There is a problem if the account holder is not present (ill), or if I want to re-pair students.

... but how do they access it when their partner *is* present? Do they have to be on the same machine? That's fragile (computer dies, is stolen, in use by another pair, etc).

So you need something on a centralized server. Something that can control access to accounts, where multiple people can share code, and (probably) you can use to hand out any "starting point" code for assignments.

It would also be nice if the system tracked things like changes to the code (enable the students to figure out what changes caused a problem), the ability to automate submission assignment and grading, and a few other things. Plus it should look like something the students are going to be expected to use for any real-world programming.

---

If you haven't realized it yet, I'm proposing that what you really need is a version control system, probably a packaged server version like what most of the big name providers give you:

* Allows you to hand out "stub" assignments (fork)
* Students can restrict code view to assigned partner (private repositories)
* Automatic submission of assignment (pull requests, or at least links to a specified branch/revision)
* Can track how much work is done by each student.

I wouldn't be surprised if there was already an "educator" version of something like Github or GitLab out there. Get a distributed server package, set yourself and any TAs up as system admins. That would allow you to be able to change teams, if necessary, as well (grant access to repository).

(As a note, I'd just go ahead and use a git-based system. True, it's more complicated overall, but it's unlikely you'd need more than straight commit/push in this situation)

> **Comments:**
> **username_0**: They have there own account on a file server. So they can work anywhere, but can not share.  
> **username_13**: @username_0 - An account per-pair, or an account per-user?  I'm really more recommending the latter, and using an actual VCS just enables some additional helpful features.  
> **username_11**: Welcome to CSEducators. Hope to hear more from you in the future.  
> **username_14**: @username_0: The straightforward answer (that minimizes reworking your infrastructure) is then for them to have a folder where they both have access. Whether you create one big folder where everyone has access and pairs are expected to stick to their folder, or whether you create actual folders with specific rights for each pair, is a matter of implementation and what your admins are willing to put up with.  

---

### Answer by username_0 on 2017-12-28. Score: 1

# Some technical solutions

I am not looking for technical solutions, but I have included a few here, in case they would be useful to others (and this is not the right site for asking for such solutions).

* Use Access Control Lists (ACLs). These are available on MS-Windows and Gnu/Linux, and can be used to set a list of users that have access to files.
* Set up the computer or websites, so that two users can login at the same time. For Gnu/Linux you could probably configure PAM.

  I imagine that this would be a lot of work to set up resources, e.g. a web-based resource that tracks which two students did each activity.

The first solution, is the only one that could be used adhoc, without any set up. I have noticed that very few people use MS-Windows ACLs, probably because they are very complex. However there is a sub-set that is simple and useful. With the correct tools they could be made easy to use.

> **Comments:**
> **username_3**: another option would be any sync tool - maybe your institution offers their own cloud, where you could manage who has access to which files. Or maybe even use git where you own the repositories  
> **username_4**: You could create a new Runestone Interactive Component, [examples](https://runestone.academy/runestone/static/overview/overview.html), [source](https://github.com/RunestoneInteractive/RunestoneComponents)  

---

### Answer by username_5 on 2018-01-04. Score: 1

Any solution will be "technical" in nature since the problem involves technology anyway. However, for the "access" issue, you can create a solution which puts more work on you than on the technology. (Since tech is supposed to make human work easier, that's kind of an anti-tech concept, right?)

Required environment is a publicly (relative to the classroom computers) accessible file storage in which **you** (the instructor) can create password-protected directories. *[This can still be a closed environment relative to the wider network, including other parts of the LAN, and the Internet as a whole, so long as it is a location that the students can access during class.]* Out-of-class access could be an issue, either because it is desirable and making it happen is not easy on the school's system, or because it is undesirable, yet hard to prevent on the school's system. As mentioned in [another answer](https://cseducators.stackexchange.com/a/4106/104), the students can always print a copy, or email a copy to themselves, for out-of-class review and planning.

For the project, create a directory for each pair, or team of any size, with a unique (per directory) password. Provide that password to each of the team members. When one is absent, for any reason, the other (rest) can still access the directory. If you have the need to reassign team membership, you change the password(s) in the affected directories and give them to the reorganized teams.

This provides each team a space to work, and share, including a place to make related notes, trials, documents, etc. You, as the instructor, will have access to all the directories, and can check the work at any time. The solution works equally well for program coding, research paper writing, and even graphic design. The hard part for the instructor is creating, and maintaining, the collection of directories and passwords. Especially if there are overlapping project time-frames, requiring that there be multiple sets of directories available at one time (along with remembering who has access to which one) with each directory needing a unique, yet easily used, password.

This solution *does not* scale well at all, and is unworkable in a workplace environment, yet is simple enough to set up and use in the controlled environment of an educational arena. At the end of the term you can merely delete/clean the parent directory and you're ready to start the next term.

Of course, the underlying principle may be enhanced, or modified, using ACLs, Apache user names, SSH with PGP keys, and many other "technological" variations; but, non-technological was the target.


---

### Answer by username_6 on 2017-12-30. Score: 0

Speaking from an industry perspective, my team is scattered around the world.

Source code is managed on a server in our rack in the USA. We use subversion because git and mercurial are a pain to work with. I can get to my team's checked in source code daily.

While some of my team live close enough to each other to have face to face time, most work at a distance. Partner work is handled through online conferencing software.

Everyone has their own accounts. Work is checked in to the version control system regularly (daily or more often if possible). Since everyone has their own account, we can use the subversion "blame" function to identify who checked in the code.

A caution - operating the computer takes a certain amount of brain power, so the real work on the problem may be done by the partner who is not keyboarding. Detecting "freeloaders" based on counts or volume of checkins creates a false sense of security, and my be punitive to a team that has really worked out how pair programming works for them.

I remember my final assignment for PDP-11 assembly class, which I worked on with a partner. With my prior experience, I was able to quickly solve the assigned problem in a way that earned all of the bonus points. For the curious, we built an desktop calculator in assembly. Bonus points were handling algebraic order, parentheses, square root, remainders, hexadecimal conversion, and smallest program. We got all of that into 120 bytes.

My partner, who handled the keyboarding, looked at the finished program, had no idea of why it even worked and (wisely from a learning perspective) decided to try to solve the problem on his own without my help.

Had he not made that decision, one could argue either that I was the freeloader because I had not keyboarded anything, or that he was the freeloader because he depended wholly on my experience. The instructor would have no way to tell who (if either) was the freeloader without knowing both of us very well.

LOC and similar metrics from code and checkins are not useful for determining programmer productivity either in industry or in education.

> **Comments:**
> **username_7**: Similar situation.  Was taking a hardware interfacing course. The µC we were using (68HC12) had to be programmed in assembly.  68HC12 assembly is similar to 6502 assembly; learned 6502 assembly over a decade prior.  My lab partner was a EE major; he knocked out the hardware parts and I knocked out the software parts (faster than other teams; excellent grades). If you looked only at software, you'd think he was a freeloader. Knowing we would be working separate on the final exam, we knocked out each assignment then switched roles and did it again to ensure each of us could do each role.  

---

### Answer by username_8 on 2017-12-28. Score: 0

The way our network is setup I have access to my students network shares. So, if a kid is absent I can get to their stuff and copy it for their partner. Not ideal, and definitely doesn't scale well if there are a bunch of students absent. Plus, I really don't like the privacy implications. But it works in a pinch.

I've also had groups share a flash drive, and then leave that flash drive in the classroom. Works okay if there's no plan on working outside of class.

Some groups will zip up and email themselves the work they've done at the end of class. Or, upload to DropBox, Google Drive, or something like that.

My personal preference would be some type of source control. I've been looking for a reason to introduce git into my 2nd year course. Maybe this would be a good excuse.

> **Comments:**
> **username_9**: Do you have any idea how that network is setup, and if so could you describe it so that someone else reading this answer could replicate it?  
> **username_8**: Not sure. It's something they've done specifically for the CompSci classes and only works in our labs.  

---

### Answer by username_10 on 2017-12-28. Score: 0

For point 2. I can think of a few solutions each with different amounts of work and tradeoffs.

1. At work we'd use revision control for this. The repository is stored
   in a common location where all people have access. Whenever you're
   done working as a pair you'd push/commit your work.
2. Have everyone work on a shared network drive permissioned by
   you. Each pair would get a folder just for them. Or its just a freeforall.
3. Have every workstation be 'public' as in there's only one user and
   it's always logged in. The students will do their work, and as long
   as the work station is available they can work on it.

> **Comments:**
> **username_11**: Welcome to CSEducators. Thanks for your comment and we hope to hear more from you in the future.  

---

### Answer by username_12 on 2019-09-27. Score: 0

One technical option is repl.it, it is a web IDE ( supporting all languages), and anyone with a link to a 'repl' can edit and run (or from browser).  
(i think they support github, not sure).

They also have multi-player option, that few folks can edit the same file simultaneously!  
( never used multi-player, nor github integration, but used the ide, it is good, yet without built-in SC).


---

