Create a `students` team

[afeld]

In teaching my JS class, I've found myself wanting to call all the student's attention to a particular comment, or ensuring everyone sees a particular announcement made through an issue. Team mentions are a good way to do this, so it would be nice to have a students team (and maybe an all team?) created within the class organization. Would be great to have this as its own action (e.g. create_students_team), but maybe called as part of create_teams.

---

Additionally, all the actions (aside from create_teams) could rely on this team to get the list of students.

• Pros
  • The teacher then doesn't need to keep the students file around
  • The teacher can populate the team in some way other than a students file (with the create_student_team action), but all the other actions work fine
• Cons
  • The actions then have two different ways of getting a student list
  • For group projects, the repositories should be created off the list of teams, so that would need to still be handled with a local file, or other way of specifying the team names

Thoughts?

[tarebyte]

create_teams sounds better to me, that way if you want to make a faculty team you can use the same method.

What about a class team along with an all team?

This is how I possibly envision it:

|-- all
     |-- Databases
     |    |--- Team 1
     |    |--- Team 2
     |-- AI
     |    |--- Team 1
     |    |--- Team 2
     |    |--- Team 3
     |-- Web Apps
          |--- Team 1
          |--- Team 2

There maybe times I need to alert a particular class about a specific issue that may not have any relation to what's going on in another class.

This could be too many levels of abstraction, I'm not sure how detailed you want to get.

[mikehelmick]

I would make this just another option on the existing create_teams script.

I hadn't added this originally because I didn't need it :) each team's repository was private to that team.

The faculty team already exists, using the owners team as that approximation. That has worked really well for me in team taught courses.

[afeld]

@tarebyte It's much simpler to manage when there's one organization per class.

https://education.github.com/guide#2-create-an-organization-for-your-class

@mikehelmick Using the Owners team instead of instructors sounds good to me.

[kelleydv]

@afeld I've been creating a students team by hand with relative ease. It only needs to happen once (per class). Since you all are actually using this in the field already, I will go along with whatever seems most useful to you.

[afeld]

Doing it by hand is a pain for classes with a large number of (more then a few dozen) students. Doesn't seem like having that team created would be a bad thing, even if many teachers never use it.

[brntbeer]

bump.

Currently just used teacher's pet in class, but attempting to add students to a repository as collaborators, however the repo was owned by an org.

In the cases of orgs, a students team being created would be :sparkles:

[kelleydv]

however the repo was owned by an org.

Were you not an owner of the org?

In the cases of orgs, a students team being created would be :sparkles:

OK. We should brainstorm a little about use cases here. I'm thinking that I will sometimes have student files that contain a subset of my class, and other student files that will contain a different subset. Therefore, I suggest that the create_teams action will always check the "students" team in the org, and add to it if necessary - i.e., if a student has ever been in a student file that has been used to create_teams, they will be in the students team for the org.

Thoughts?

[afeld]

I suggest that the create_teams action will always check the "students" team in the org, and add to it if necessary - i.e., if a student has ever been in a student file that has been used to create_teams

That sounds very reasonable to me. Probably worth having a more specific create_students_team action too.

[brntbeer]

Were you not an owner of the org?

definitely were, but because teacher's_pet tries to add contributors this doesnt work or maybe we were doing it wrong. You cant just add contributors to a repository, they need to be on a team first.

OK. We should brainstorm a little about use cases here. I'm thinking that I will sometimes have student files that contain a subset of my class, and other student files that will contain a different subset.

This sounds like a pretty complicated unique scenario to me! Not that that's bad, though! Just trying to think of a base case first. Why not pipe in the name of a team into the command line you're adding people to?

[brntbeer]

It's also possible I used this wrong =)

[kelleydv]

Check this out. The first thing you want to do with teachers_pet is create_teams. Once you have created teams, you run create_repos to create a private repo for each team in the students list. Then, push_files will add any content to those repos.

If you had a class of n students and ran create_teams with a students file that looked like this

AllStudents student1 student2 student3 ... studentn

you would actually end up with precisely what we're talking about in this thread - a team with all of your students added. That didn't actually dawn on me until today. Perhaps we should just document this better so that teachers know how to use create_teams this way.

I have not yet explored what happens with teachers_pet when you just add a team name to a line in the students file without students after it, assuming that team already exists in your org:

...
TeamBlue uname1 uname2
TeamName # safe to omit members when already in org?
...

[afeld]

I'm personally ok with creating a students team by default (maaaybe make the name configurable), because it doesn't really get in the way even if it isn't used. The open question (in my mind) is whether it's rolled into create_teams or whether it's a standalone action exclusively.

[brntbeer]

Thanks @kelleydv !

[kelleydv]

Made a pull request.

[kelleydv]

@afeld , I tried it out as a separate action at first. In this case, it doesn't really happen "in the background" because the user would have to explicitly run the action. I kind of agree that the name should be configurable.