can't separate from group

[MoSBanapple]

after you join with a group for a lab you can't unjoin it

[bboe]

Yes, I can see that being a problem. The intent for this feature is group formation occurs just prior to submission, or even after. Can you provide a little more details on how this group formed and then subsequently disbanded? Were any submissions made as the group?

[pconrad]

Students started as a pair, but due to circumstances needed to finish up and submit separately. (I forget whether it was travel or illness or whatnot). its lab02 for cs56-w18 Student: did you make any lab02 submissions as a pair yet? If there is a way I can do some "hack" at the python shell as a one time work around, let me know (e.g. delete some database object). I'm suggesting that if we make "unpairing" or "u grouping" a feature that it be a feature only for course admins (instructors and TAs). Adding this is probably also a nice easy "starter feature" for my Agile SAAS class to try to add to the product. Side note, we now have github.com/ucsb-cs/submit_ops_docker partially functional (submit pyramid app and postgres work. RabbitMQ and workers still WIP). Bryce, any advice on what we would need to do in the database to "reverse" a pair / group formation while leaving database in a consistent state would be helpful. My guess is that one of the complications is what to do with any submissions that had already been made by the pair/group, i.e. whom to give credit for those. I can forsee at least three possible approaches (0) prohibit undoing a pair/group if it has any existing submissions. (i.e. duck the issue for now. A reasonable way to get started, even if we do something more complicated later). Might cover 80% or more of use cases (1) if there is a group consisting of u1.. un, n>=2 allows instructor to remove one user at a time from group. When only one user would remain, existing group submissions get associated with that user. (2) Rather than removing individuals from a group one at a time, only allow dissolving the entire group. All group submissions either (a) revert to individual submissions of user that submitted (if we have that info in database?) or (b)are deleted as if they had never happened or (c) get associated with some arbitrary group member.

…

On Feb 4, 2018 11:48, "Bryce Boe" ***@***.***> wrote: Yes, I can see that being a problem. The intent for this feature is group formation occurs just prior to submission, or even after. Can you provide a little more details on how this group formed and then subsequently disbanded? Were any submissions made as the group? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABETKSq8Mn5UTX-nzZALmF0YyWOxhKXIks5tRgmMgaJpZM4R4htF> .

[pconrad]

Also: regardless of intent of feature, in practice, instructors have told students to register as a pair immediately, or not, as a way of signalling intent to work together or work separately. Late binding of pairs is not ideal, educationally. It facilitates abuse where someone that did not contribute to the assignment gloms on to someone else's work (with their permission) at the last minute. Enforcing early binding makes it easier for course staff to supervise whether pair programming is legit pairing, vs. just person A does the work and person B gets a free ride.

…

On Feb 4, 2018 11:48, "Bryce Boe" ***@***.***> wrote: Yes, I can see that being a problem. The intent for this feature is group formation occurs just prior to submission, or even after. Can you provide a little more details on how this group formed and then subsequently disbanded? Were any submissions made as the group? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABETKSq8Mn5UTX-nzZALmF0YyWOxhKXIks5tRgmMgaJpZM4R4htF> .