Module 2 Exercise 4: Workflow and assignments with Classroom


(Amy Dickens) #101

Thanks for sharing your classroom screenshot - do you also have answers to the questions asked in this exercise? :sparkles:


(Amy Dickens) #102

Thanks for posting your screenshot - do you also have some feedback on workflow to share with us? :sparkles:


(Amy Dickens) #103

Thanks for sharing your screenshot - do you also have answers to the questions asked in this exercise? :sparkles:


(Amy Dickens) #104

Great stuff about commits here and how you’ll expect them to have a logical link to each part of the exercise… :raised_hands: :sparkles:


(Amy Dickens) #105

I would recommend that you advise students to make meaningful commits - as opposed to just “commit often” - this way you can avoid students making commits every other minute and having a git log that is difficult to navigate :sparkles:


(Amy Dickens) #106

Hey :wave: Thanks for submitting the screenshot - do you have answers to the questions in this exercise? It would be great to hear about your expectations for your student workflow :sparkles:


(Amy Dickens) #107

Remember that “as often as possible” does not always ensure students make logical and structured commits/push.

Committing frequently with no logical structure can lead to a chaotic git log with lots of commits that point to many changes and it could be difficult in the long term (should your students need to refer back to a previous commit). :slight_smile:


(Amy Dickens) #108

This is super interesting to know… maybe encourage your students to use a password manager to help them with having passwords available and for better security too :see_no_evil: :sparkles:

Great submission - thanks for sharing! :tada:


(Ali Bayram) #109

Will you keep all course materials in a repository? Or just assignments?
I will keep just assignments.
When will you expect students to commit?
When they feel that they made a significant change.
What sort of commit messages should they use?
Commit massage is like the title of their change which should be short, descriptive and distinct.
When do you want your students to push their code to GitHub?
When they want me and/or group members to see progress.


(Sara Marín-López) #110
  1. One repository per student per assignment
  2. Frequently, when they finish a type of change (they must be atomic logical chunks :slight_smile: )
  3. Informative messages
  4. At least once per day

(Dr. Ayaz H. Khan) #111

I have applied in my real classroom.


(Yann Thierry-Mieg) #112
  1. yes all course materials go to repositories, but some are private ofc.
  2. they commit during the lab sessions (in particular before ending session) and during the week if they work extra on it
  3. I don’t care, so long as it attempts to describe the change
  4. They can push any time they’ve made a commit. The master branch should have some CI linked into it, so pushing to master will trigger tests.

(Nathan Eloe) #113

This is kind of my testing ground (I was playing around with continuous integration and distributing “starter” IDE projects)

  1. For now only assignments. However I am hoping to move slides and other materials to github and use it as an LMS (with my course site only having relevant links to the github pages)

  2. I already kind of answered this a few exercises ago, but I am specifying “milestones” the students have to have at least one commit for. For example, my last lab I gave my Data structures students had the following milestones:

  • Add required headers to .java files in the src/ directory
  • Complete LengthMismatchException (will pass one test)
  • Complete non-default constructor in VectorM
  • Complete size, get, and set in VectorM
  • Complete dot in VectorM (will pass 3 tests)
  • Complete add in VectorM (will pass 3 tests)

They must have at least one commit per mielstone

  1. Their commit messages must clearly indicate which milestone they are completing with that commit. I do link them to https://chris.beams.io/posts/git-commit/, but I do not require they follow that; I only want them to clearly state what they’ve accomplished (and which milestone they have completed with the commit).

  2. I tell my students to push every time they stop working; if they are done, if they are waiting for help from a TA or myself, or just have to do other things, they should push. I can get an idea of how often they push because I’ve hooked my assignments up to travis-ci for grading, so the pass/fail badges that are added will show me which commits they pushed on.

I do tell them that if they want email help that they should push so I (or the TAs) can easily see what they currently have and leave comments on the commits).


(Hernando Enrique Moreno Moreno) #114

Exercise 4 module 2


(Amy Dickens) #115

Re chromebooks and IDEs you can try the following:

  • Glitch - I’ve used this before and it works great for live collaboration.
  • Codepen - I’ve used this too and it works nicely as an online in browser environment
  • For GitHub integration try CodeEnvy - I haven’t tried it but have seen other folks recommend it because it has this feature - however this is a paid subscription beyond 3 people so might not be a great solution for the classroom (though I’d personally reach out and explain your situation - you never know they might have flexibility for educational use)

In all senses do what works best for your students but these are some options you can try. :sparkles:


(Amy Dickens) #116

Great work here :tada:

Around commits - do you mean when an entire feature is coded or when a code file is updated to contain something new?

Sometimes having smaller incremental commits can be really helpful if something breaks and saves reconstructing everything built in the process of the feature :sparkles:


(Amy Dickens) #117

When you say

Description about their goals

for the commit messages what do you mean by this?

Ideally commits should describe the work completed in a concise format :sparkles:


(Amy Dickens) #118

Thanks for your submission :raised_hands:

I’m interested to know more about what you mean students should commit “when they have committed” - so how frequently is that?

Also asking students to push “on or before due date” could lead to some last minute panics - maybe showing students how to push earlier and recommending they treat their remotes like an external drive, somewhere to safeguard their work - that way they will be encouraged to push more regularly and have a back up of their work. :sparkles:


(Amy Dickens) #119

Great stuff here :tada:


(Jaime Rabasco Ronda) #120

Yes! commit messages describe one or more completed jobs, that is, one or more goals or objectives managed or achieved