Module 2 Exercise 4: Workflow and assignments with Classroom


(Amy Dickens) #121

Thanks for your submission :sparkles:

Question about the commits -

Once they complete each goal

How much work goes into each goal?

Perhaps encouraging small, meaningful commits here might work better - if the goals are quite large there could be quite a lot of edits between commits and that could lead to issues if there is a need to go back to a previous commit. Just something to think about :thought_balloon: :smile:


(Amy Dickens) #122

Great work here :raised_hands:

Just a note on pushing - it might be better to suggest to your students that they push when they want to save their progress to the remote (and not just when they want others to check up on their work). :blush:

This helps to ensure they have a copy of the code in the cloud which protects their work in case of any loss of work locally. :floppy_disk:


(Amy Dickens) #123

Great - thanks for the screenshot!

Did you have answers to the questions in the exercise about your student workflow?

It would be great to understand how that works in real life for you :sparkles:


(Amy Dickens) #124

Thanks for the submission.

A quick note about commit messages:

I don’t care, so long as it attempts to describe the change

It’s good practice to teach that commit messages are a concise description of the changes made.

In big teams it is even more crucial for the messages to be clean, concise and descriptive. :blush:


(Amy Dickens) #125

Great submission here :tada:


(Amy Dickens) #126

Hey :wave: Thanks for sharing your screenshot.

Did you also have answers to the questions about your student workflow?

It would be great to hear about this :sparkles:


(Yann Thierry-Mieg) #127

Just to answer on “short descriptive concise”,
for me it is really most important that it actually describes the code change in that file, I don’t go by the logical block of changes across files view that much, I prefer a micro commit per file, let branches and pushes decide what is a set of increments that make a compilable version. You can reconcile things for a PR with a single commit ofc, that is separate issue from “personal” use you have on you dev branch.
I’d argue short is not necessarily better, argued paragraph of why the change and how it happens is often precious doc, the first line should be concise, not the commit message (esp if it’s a hard change). The traces stay in the repo, you can go back to them. It is not antinomous from documenting and keeping source code doc up to date, but documenting change is the VCS is as good a place as any else.
Teaching, I give the ideal goal, and discuss these different chapels of logical commit/fine grain etc… but then in practice I only really make “nasty” remarks to students that have commit messages that say “updated” or such noise.
So what I want them to remember is really what I put as answer to the question : “anything as long as it really tries to describe the actual change”.
True discipline comes from repos with actual rules to commit message format, e.g. Gnu or Eclipse projects, with lots of rules to sign your commit and make it be accepted.
But teaching students to first use git ? I want them not to be afraid to commit and revert and branch all ways to heaven. So not too many rules at first regarding commit messages, that is not the point.


(Yann Thierry-Mieg) #128

but yes I agree with the canonical answer in true collaborative setting, for labs with work shared between self and other student, rules are can be relaxed a bit.


(Michael Clausen) #129
  1. Will you keep all course materials in a repository? Or just assignments?

We have one (private) repository that contains all course material and we use GitHub Pages (Jekyll) to deliver the course material to the students.

  1. When will you expect students to commit?

Whenever they feel they have to. For each mandatory step in the assignment we ask the students to create tags.

  1. What sort of commit messages should they use?

They are basically free, but the significance of those messages is taken into consideration for the final assignment mark.

  1. When do you want your students to push their code to GitHub?

Whenever they want, as a basic rule we expect the code to build that is pushed. In some exercises we use Travis to check if their code builds and passes some unit tests.


(Ivonetafe) #130

Incremental commits are a good practice, but I would encourage students to only commit changes when they have tested that their program changes work correctly.


(Dr. Ayaz H. Khan) #131

My Answers:

  1. I created the assignment for course project. So, only project related documents are in the repository.
  2. Students are working in teams, they are expected to commit their work on regular basis.
  3. Student should clearly highly highlight their contributions in each commit.
  4. Code should be updated on github whenever there is a change.

(Ali Bayram) #132

Thank you :blush:


(Christian Nievas) #133
  1. No, only assignments or codes that the students need. The others documents like pdf, ppt are published in Google Drive.
  2. Well, they have to do an groupal anual practice exercise about programming a determined system, so I expect that will be in the second or third week after publishing it.
  3. Messages that represents what they do in that commit.
  4. They dont have restrictions about that. The best practice is only if the code is working but for being a group they also commits the code to be solved by another.


(JagCode) #134
  1. Ideally I would like to keep all course materials and assignments in the repository. The whole point of this is to try to one stop shop my teaching and learning. Right now I feel like we’re working on 4 different LMS’s with 5 different CMS’s and 15 CRM’s for students data. Too much, too extra.
  2. I expect students to commit as often as possible and every time they make a single change until they memorize the commands and learn how to fix their own probs and begin learning the nuances of commit messages and best practices meanwhile trying my best to model.
  3. I think this is also a learning practice and I’ll give them a basic idea but if students should check themselves as they make an break stuff.
  4. Check question #2 response except pushes should be done more at the end of the day. I feel like less pushes = less merge conflicts.


(Pol Benedito Momplet) #135


(Baptiste Pesquet) #136

I’ve been teaching with Classroom since it came out of beta 3 years ago. Rather than creating an artificial assignment, I’ve taken a screenshot of my most recent (group) assignment.


(Gustavo Freitas) #137

Will you keep all course materials in a repository? Or just assignment
I keep all course materials at the repository.

When will you expect students to commit?
Whenever an change is included for group assignments.

What sort of commit messages should they use?
A description of the changes included in that commit.

When do you want students to push their code to GitHub?
When change is successful.

First task click here.


(Lluisgarciapons) #138

1. Will you keep all course materials in a repository? Or just assignments?
One repository per assigment, then when the students join the assignment will have a private repo for themselves.

2. When will you expect students to commit?
Depending of the length of the assigment. But every commit should have a descriptive name and should be commited at the end of each assigment task.

3. What sort of commit messages should they use?
A descriptive one, refering the task the sstudent is doing.

4. When do you want your students to push their code to GitHub?
At least once per day (if there are new commits), so the teacher can see the work he has done.


(Chris Jones) #139

I already keep all of my course materials in Github although I don’t distribute them to my students that we since we have an LMS already. However, I think the classroom tools are going to give me a much better ability to evaluate the contributions of individual students in the group projects that I like to put them on. It’s always a challenge to figure out how much one person contributed over another and commits are some of the most objective ways of doing that at least as far as code volume and overall activity.

For those projects I expect the students to be contributing over the course of the project, which is run in 2-week sprints for the duration of the term. For the occasional individual assignment my expectations are that they’ll probably wait until close to the last minute and then do one or two large commits rather than incremental commits over the duration of the assignment. This is similar to how I think their pushes to Github will go.

Commit messages are intended to be descriptive. I’d actually like to introduce the use of Github issue tracking as well so that they can tie their commits to the issues that they are intended to address, just like we do on professional projects.


(Glenn) #140