Note: I am calling this “revamp” and not “removal” because something like groups will exist in the real world regardless of what fire implements. That is, students will work together, and this will be reflected in the model somehow (either implicitly or explicitly).

Motivation

Groups are today implemented as follows:

• Groups contain members. (1:N)
• Groups have a group number. (1:1)
• Students belong to at most one group. (1:0..1).
• Joining a group is done by means of a join code. The join-code is only known by members of the group.
• Submissions are associated to groups (N:1)
• The list of members of a group are mutable.

This causes some problems.

• https://bitbucket.org/cse-fire/fire/issues/51/student-cannot-resubmit-after-changing-the
• https://bitbucket.org/cse-fire/fire/issues/113/add-group-number-to-exported-student
• https://bitbucket.org/cse-fire/fire/issues/71/group-join-codes-may-jeopardize
• https://bitbucket.org/cse-fire/fire/issues/56/retroactively-add-a-submitter-to-a
• https://bitbucket.org/cse-fire/fire/issues/25/more-clear-procedure-for-people
• https://bitbucket.org/cse-fire/fire/issues/108/leading-0-in-group-number

Activities and solutions

People selection

Many solutions require the ability for students to select one or more other participants from the course.

Individual case: If the course does not have group submissions, then all features for people selection are hidden.

Solution 1. We all trust each other.

Expose the whole list of participants via a searchable field (similar to how people find users on Bitbucket).

Students can search by (pick at least 1):

• [ ] Typing a few characters from the name
• [X] Typing the e-mail address the other guy used.
• [X] Typing the date of birth/personal number from the other guy.

To make the search easier, we can give prominence to the people that the student knows, that is, has a submission (or submission draft) in common with them.

Solution 2. We all trust each other with shortcuts.

×××××××××××××

(redundant)

Solution 3. Small circle of trusted people.

Implement a contact roster per user (or per user-course). People can become friends by mutual consent (e.g. finding each other by Solution 1.) and thus they will appear in each other’s contact roster.

Only people in one’s contact roster can be selected for other activities (e.g. collaborating on a submission).

Solution 4. A concept of trustees

If we do solution 3., the issue comes up of how to select the people to trust.

A few issues arise:

• Trust/friendship is not transitive. So, for example, if A adds B, C, D, E as friends, and nothing else happens, A can submit on behalf of {A,B,C,D,E}, but B cannot submit on behalf the same group.

Make a non-transitive trustee relation

People can trust other people in the system.

If A trusts B, then B can:

• Submit labs with A in the list of authors.
• Add people to the list of people that B trusts. (more on this later).

B is a trustee of A. A is a “truster” of B, for lack of a better word.

Note that trustees cannot read the contents of submissions authored by the truster in general. Each person can only view contents and feedback to submissions they authored. Of course, users are free to share whatever information they want out-of-band.

People have a list of trustees, where they can add and remove people. The trust relation is reflexive, but has no other particular properties: it is neither symmetric nor transitive (more on this later).

People can also send trust requests to other people. This is done simultaneously when adding trustees.

One can revoke trust unilaterally. This will come with a warning, as this may prevent the two people from submitting together later on. Also, if a person leaves a group, each person

Trust is contagious

The amount of harm that a trustee can do is limited (same as writing the wrong name on a piece of paper). On the other hand, a lack of trust can be pretty inconvenient, specially if it prevents the other people in the group from meeting a deadline.

An specially annoying case is when a new person is added to the group after group creation: then all members of the group might need to confirm the new person before this new person can submit on behalf of the group.

So, we want to encourage people to trust as many other people as possible.

Even with this contagious notion of trust, we achieve the following goals: - Avoid 'picking the wrong Eric' when submitting a lab. - People being misled into thinking they are working together with other people.

To make trust contagious, we will make trust requests multiparty. That is, if A requests trust from B,C,D,E., then this will be a single request with the names of all the other people. If B accepts the request, then B will trust A, but also C, D, and E.

If later on, a new person F wants to work with A,B,C,D,E, then any of them (e.g. A) must make a trust request from the others + F (i.e. {B,C,D,E,F}). When F accepts, F will trust all of B,C,D,E, and all of B,C,D,E will trust F. Note that no interaction is required from B,C,D,E when adding F, as they already trust A to make them trust other people on their behalf.

Trust may be explicit or implicit

There are two ways of handling trust:

• The list of trustees is explicit. Users can add/remove people from this list.

• The list of trustees is implicit. It is populated automatically with i) people that the persons have ever collaborated with, and ii) people that the persons have ever authorized to add them as authors to a submission. It is not possible to remove a person from the list of trustees.

  This means that we could call trustees “collaborators” instead. Collaborators are people with whom one has ever or will at some point collaborate. Making collaborator status revocable or not is a separate design decision. Fabian suggested that it might be better if this internal list of collaborators is not exposed at all.

Generating trust

Any time that a user A wants to work together with others (B₁,…,Bₙ), a “trust request” will be sent to the others (B₁,…,Bₙ).

For each B₁, two things can happen:

• B₁ trusts A already. Then, without intervention from B₁, B₁ will also trust B₂,…,Bₙ. Also, if any of B₂,…,Bₙ trusts B₁, they will now automatically trust A, and B₂ through Bₙ.

• B₁ does not trust A. Then B₁ will get an e-mail, asking him to accept the request. They can do so directly from the e-mail, or they can log on Fire, where they will be greeted with a prominent banner. Once the request is accepted, they will also trust B₂,…,Bₙ. Then again, if any of them trusts

Limiting trust

This is strictly optional.

If we want to limit trust, a black-list facility might be more useful than having users manage a list of trustees manually. A user A can block another user B, so that A will never trust B. This means that B cannot use A as an author in a submission. B and A can still author things together, but there needs to be a third party that both A and B trust, and that they have not blocked.

Submitting together

Solution 1. Submission-centered approach

The idea is that everything in the system is handled as submissions. There is only one point of interaction for the student: the submission form.

In the submission form,

A student is encouraged to, some time before the deadline (preferably as soon as they know who they are working with), create an empty submission draft.

Submission model

Submissions have the following data:

• 1:1 . A submission number
• 1:1..N . A list of authors date and time).
• 1:0..1 . A comment
• 0 or more files.
• 1:N . A submission parent(s)
• N:1 . A grade

Deadline extensions

Per student

The idea is: this student can submit after the deadline.

A submission draft can be submitted iff: - Option 1: All the authors have enough of a deadline extension. - Option 2: One of the authors has enough a deadline extension.

Per group

It might be desirable to move the deadline extensions to groups instead, as in “this set of people can submit after the deadline”.

Per submission

One could also attach deadline extensions to specific submissions instead of groups. Evgeny said this was messy before, so it might be a bad road to go down to.

This adds two new fields to the submission:

• 1:0..1 . A first submission deadline extension (given by a specific date and time).
• 1:0..1 . A final submission deadline extension (given by a specific

Group size exemptions

Per student

The idea is "Students have the priviledge of working in smaller groups"

(Student·Lab)s have the following data:

• 1:0..1 . A minimum group size override.
• 1:0..1 . A maximum group size override.

Per group

• (Student^N^ · Lab) have the following data

  “This group has the right size”

Submission draft creation

At submission creation:

• The submission number is assigned sequentially.
• The list of authors has 1 element, the creator
• The submission has no parents.
• The submission has no extensions or exemptions.
• The submission has an empty comment "".
• The submission has no files.

Once an empty submission draft is created, it can be changed:

• By the student:

  • Adding or removing authors.
    • Consent for this is assumed to have been negotiated out-of-band.
  • Adding or removing files.
  • Changing the comment
  • Changing the parent(s) (e.g. what submission this responds to).
    • To add a parent, one must be one of the authors of that parent.
    • The intersection between the authors of a submission and the authors of the parent must be non-empty.

Note: For convenience, we allow the student to specify the members at submission creation.

• By the grader

  • Adding deadline extensions
  • For convenience, the grader can refer to the authors of a submission as a set to give them all a group size exemption for a particular lab. The grader can also give an exemption for all labs. But the exemption is assigned to each student-lab pair individually, not to the submission.

When creating a submission draft, Fire will prompt the user to get authorization from all the other authors that do not trust the user.

Submitting

A submission draft can be "submitted" if the following conditions hold:

• The number of authors is larger than the largest minimum number of authors for any student in the group (if they do not have an override, they get the global default).

• The current date is earlier than the submission deadline.

  • If the submission has no parents.
    • Then the deadline is the first deadline extension, or the global first submission deadline.

  • If the submission has parents.

    • Then the deadline is the final deadline extension for this submission. If there is none, then the final deadline is the latest of the final deadline submissions for the parents. If there are no parents, then take the global final deadline.

• Also, we can enforce that submission parents can be (pick one or more):

  • [ ] Accepted submissions
  • [X] Rejected submissions
  • [ ] Withdrawn submissions

• The submitter is an author in the submission draft.

• All the authors trust the person who is doing the submission.

Any potential violation of these criteria is displayed prominently in the submission draft page. For example:

• It is too late to submit. “Details: The deadline was 2 hours ago.”
• The group size is too small. (If it is only the fault of one member, then show “Details: Alice cannot submit as part of a group smaller than 3 people.”)
• Your previous submission (#455) has already been accepted.

• Author A has not authorized the submitter to submit on their behalf.

  “A has not given you permission to submit on their behalf.”

  A link "Fix this" should be provided, that sends a trust request to A (again?).

Resubmitting

To resubmit, one creates a new submission with the resubmitted submission as the parent, and the same authors. There can be a “resubmit” button on every submission that does this automatically.

• Evgeny said that we only want people to resubmit the last submission, so that the history is linear. This can be enforced.

Note that different groups could have a resubmission with the same parent, as long as each of them have a member who is an author of that submission.

However, a user can only create a submission with a parent if they are authors of that submission. A submission must share one author with its parent submission. Users cannot see the parent submission unless they are authors of it. Of course, they can share the submission with each other out of band if they want.

Victor said that having the resubmit button be linked to a specific submission helps keep things tidy, specially if the constitution of groups changes. Although, in most cases the parent submission will just be the most recent submission for that lab.

Withdrawing

A submission can be withdrawn by any of the authors. Withdrawn submissions are not deleted, they are only greyed out.

Avoiding multiple submissions

• A person is only allowed to be author in one submitted, non-graded submission and one draft submission.
• Submitting a draft withdraws the previous non-graded submission (after confirmation).
• Resubmitting a non-graded submission creates a draft copy.

Adding/removing authors

Once a submission is sent, the authors cannot be changed by the student (except by withdrawing or resubmitting).

The grader has the faculty to add extra authors to a submission, as long as they are authorized.

Creating groups

Some courses may want to have the old notion of groups, where people declare in advance (e.g. in the beginning of the course) which group they belong to.

This can be handled without further additions by having a first, mock “lab”. By submitting this first lab, the students declare the group of people they belong to. One can effectively set a deadline for group creation by setting a deadline for the first lab.

Having this first 'mock' lab in a course would also help students familiarize themselves with the submission system, and make sure that they are authorized by their peers to submit in their behalf. Also, if they want to work in smaller or bigger groups than allowed, they will be thus encouraged to ask for approval a good amount of time before the first real lab deadline.

In this model, it would be good to add a feature to auto-accept submissions (so that graders do not have to manually accept all the group-creation assignments).

Note that even if the students change group later they should not need to resubmit this first group creation assignment.

Solution 2. Group-oblivious approach

××××××××××××××××××××××××

(redundant)

Solution 3. ???

Previous meeting notes

Some random ideas we came up with:

• declare intent to work together prior to submission
• privacy of list of students
• immutable notion of group
• refer to groups conveniently
• avoid tree view
• having no groups in the model
• prevent person from having two submissions with different sets of people in the same lab
• a group has a parent group, and inherit access to the previous submissions