Open bnmnetp opened 5 years ago
presnick
commented
5 years ago This sounds like a nice feature. However, I'm concerned about how you specify the partner, by username. I'm not sure that we've resolved forever the issues we talked about a couple of years ago with SSO via LTI.
Also, do you want to have an approval process where the partner agrees to be paired, or it only works when both have gone through the process?
bnmnetp
commented
5 years ago At the end of the day the username is still how everything is stored in the database with respect to code and answers to all the other assessment widgets.
I see that it doesn't fit well with the LTI integration where the username is a a very long string of random digits, but this is not the place to solve that issue.
My original thinking was that there should be some kind of handshake approval process, but in the end keeping this light weight won the day. Many classes change up partners each day, and forcing both to log in just to set up who is partnering with who for the day seemed onerous and goes against the single driver pair programming practice.
This may not scale well to really large classes, but the vast majority of courses on academy are less than 25 students and so I think this works fine in those cases. Especially with the built in accountability of having the server make the pair explicit in the history.
bjones1
commented
5 years ago Random pair programming thoughts:
In general, I personally oppose this, since I see one person do the work while the other watches. However, I also know what many faculty support this.
It might be helpful to have a diff function that would show the difference between your code and your partner's code, so the two could them discuss which is correct.
It might be helpful to have a split screen, where your code goes on the left and your partner's code goes on the right, again to show the two approaches. Twin history sliders (one for each window) would allow looking at the past, perhaps.
Some kind of auto-notify feature which shows that your partner has updated code available to view would be neat.
bnmnetp
commented
5 years ago You have to be diligent about the pedagogy of pair programming. It is not one person codes and the other does the work. In pair programming one does the typing while the other tells them what to think. Both are engaged in catching typos and other minor mistakes. In addition you have to have them trade off every 10-20 minutes who is typing. Many people will set a timer and the students know to switch roles.
This feature is just a start as it alleviates the largest reported pain point for doing pair programming in Runestone -- Getting the shared code back to the partner. All the other stuff is great and could definitely be added over time.
Also I'll make it a global flag for a course so if you are not a pair programming person you can have it off for your entire course.
bjones1
commented
5 years ago Sounds good!
I have had numerous requests from professors who would like better support for pair programming in Runestone.
Here is one idea that I prototyped and demoed to a group of them and they liked:
The idea is simple, when you are pair programming you can check the pair box and then type in the username of your partner in the text box. When you save and run not only is the code saved to your own timeline but it is also saved to your partners timeline with a comment at the top that is inserted by the server. --- # This code was run by partner XXXX To see the shared code the partner just needs to refresh their history. Either by reloading the page, or perhaps by a refresh timeline button.
The server ensures that the two usernames are both registered for the same course.
The comment added by the server is meant to be a deterrent for students saving unwelcome code to the timelines of their fellow students, as well as to be an indication to the instructor that the work was done as a pair. Since it is added by the server, it becomes a part of the students history.
I can see that some rogue students could cause problems with this. But in discussions with instructors they feel the risk is manageable.
I would also add another flag to the activecode directive so that some activecodes would not enable the pair feature. We could also add a class wide flag so that instructors who did not want to use any pair programming could turn off the feature altogether.
Any thoughts? @presnick @bjones1 ??