Difference between revisions of "Open Source Comes to Campus/Curriculum/Git/Instructors"

From OpenHatch wiki
Jump to navigation Jump to search
imported>Shauna
imported>Shauna
Line 1: Line 1:
== Audience of this page ==
+
= Leading 'Practicing Git' =
  
A volunteer staff member
+
Your goal, over the course of this 40-60 minute activity, is to help students experience what it is like to make changes to a project through Github. 
  
== Your goal, over the next 60-90 minutes ==
+
== The background ==
  
* Provide students with a plausible, albeit simulated, open source project experience where they express some creativity and learn, by using, new technical skills (git+github) and  communication skills (issue trackers, IRC).
+
We've created a Github organization for you to use, and given you administrative access to it.  Within that organization is a repository.  The repository is named $organization-name.github.io, because this is the name it needs to have for Github to automatically generate a [http://pages.github.com/ Github page].  You can see an unaltered example of a new organization with a new repository [https://github.com/princeton-9 here].
  
== Things you need to know ==
+
Within the repository, we have created a set of bitesize issues for students to work on.  (See [https://github.com/princeton-9/princeton-9.github.io/issues here] for example.)  You will ask students to pick an issue to work on and claim it by leaving a comment.  Students can work by themselves or in groups.  If they decide to work together, try to have them leave all of their github usernames somewhere on the Github issue that they solved as a group. That's for our record-keeping about how the event went.
  
* We have created a Github organization for you to use, with your students forking and submitting pull requests to a static HTML website.
+
Sometimes a student will submit a pull request that needs fixing. For example:
  
* We have created bitesize issues in that static HTML project, filed in Github issues.
+
* They might make unrelated changes in the file.
 +
* They might fail to fix the issue correctly.
 +
* They might submit two commits that need to be in separate pull requests, since we haven't taught them about branches yet.
  
* Students are '''expected''' to:
+
When this happens, explain the situation out loud to the whole group and invite all of your students to watch as you address the issue. Typically the issue is something that everyone will benefit from learning about.
** within Github, assign the ticket to themselves before working on it.
 
** work using our "bug report" printed worksheet, so that the process of working with bugs in a project is very clear in their mind.
 
  
* Your goal is to help them succeed!
+
== The activity itself ==
  
* Students can chat in person with whoever they want, but you should encourage them to also keep IRC open during the experience. Feel free to mentor them in person, with your voice, and to encourage students to work together.
+
You can see the steps of the activity itself in the [https://openhatch.org/wiki/Open_Source_Comes_to_Campus/Practicing_Git/Students student guide].  (Note: there will be printed copies given to students during the activity.)  We encourage you as a mentor to go through the steps ahead of time and make sure you are comfortable with all of them.
  
* If students work together, try to have them leave all of their github usernames somewhere on the Github issue that they solved as a group. That's for our record-keeping about how the event went.
+
The last section of the student guide is the 'advanced' section.  The typical Practicing Git group will not get to this section, which is totally okay.  We encourage you to be prepared for it, however, as individual students may have questions about it. If you're not comfortable with the steps in the advanced section, we encourage you to ask for help from OpenHatch organizers ahead of time, or from other mentors at the event.
  
* Sometimes a student will submit a pull request that needs fixing. For example:
+
== Some notes ==
** They might make unrelated changes in the file.
 
** They might fail to fix the issue correctly.
 
** They might submit two commits that need to be in separate pull requests, since we haven't taught them about branches yet.
 
* When this happens, you should usually '''ask all students to watch you as you provide feedback (in person) to the person who submitted'''. Rationale:
 
** Usually there is something to learn about git, or about being careful, that all the students will benefit from.
 
** If you spend more than a few minutes working one on one with a student, the other students won't have anything to do, and then you'll have a long review queue and struggle to get on top of it.
 
 
 
* The laptop setup guide can be found at: http://bit.ly/laptop-setup
 
  
 
* Asheesh recommends you encourage Windows and Mac users to stay away from "Github for Windows" and "Github for Mac" because the steps you need to follow with those are different than what we have documented. Others have disagreed on this, but that's what Asheesh thinks. (The laptop setup guide also steers clear of those, so if students are following directions, they will do things the Asheesh way.)
 
* Asheesh recommends you encourage Windows and Mac users to stay away from "Github for Windows" and "Github for Mac" because the steps you need to follow with those are different than what we have documented. Others have disagreed on this, but that's what Asheesh thinks. (The laptop setup guide also steers clear of those, so if students are following directions, they will do things the Asheesh way.)
 
* You and students are encouraged to use [[Open Source Comes to Campus/Practicing Git/Students]] as a guide.
 
  
 
* Your main repository is configured, via [http://pages.github.com/ Github Pages], to load on the web at a HTTP URL the same as the repository name. So, once you merge students' pull requests, they should be visible on the web at that address.
 
* Your main repository is configured, via [http://pages.github.com/ Github Pages], to load on the web at a HTTP URL the same as the repository name. So, once you merge students' pull requests, they should be visible on the web at that address.
Line 41: Line 31:
 
** There may also be issues with caching.  To get around this problem, add "/?" to the end of the url.
 
** There may also be issues with caching.  To get around this problem, add "/?" to the end of the url.
  
* If you finish early, or if you have questions, tell Asheesh and Shauna on the #openhatch IRC channel.
+
* Although you will be working with students in person, and should engage with them in person, we encourage you to use the IRC channel where possible. If you need to give students a link, leave it in the channel instead of writing it out on a white board, for instance.  You can also encourage students to show off the their new page by linking to it in IRC.
 
 
* If students finish early, congratulate them, and tell them to work on the "Finding an open source project that suits a partner's interests" activity.
 

Revision as of 19:36, 23 January 2014

Leading 'Practicing Git'

Your goal, over the course of this 40-60 minute activity, is to help students experience what it is like to make changes to a project through Github.

The background

We've created a Github organization for you to use, and given you administrative access to it. Within that organization is a repository. The repository is named $organization-name.github.io, because this is the name it needs to have for Github to automatically generate a Github page. You can see an unaltered example of a new organization with a new repository here.

Within the repository, we have created a set of bitesize issues for students to work on. (See here for example.) You will ask students to pick an issue to work on and claim it by leaving a comment. Students can work by themselves or in groups. If they decide to work together, try to have them leave all of their github usernames somewhere on the Github issue that they solved as a group. That's for our record-keeping about how the event went.

Sometimes a student will submit a pull request that needs fixing. For example:

  • They might make unrelated changes in the file.
  • They might fail to fix the issue correctly.
  • They might submit two commits that need to be in separate pull requests, since we haven't taught them about branches yet.

When this happens, explain the situation out loud to the whole group and invite all of your students to watch as you address the issue. Typically the issue is something that everyone will benefit from learning about.

The activity itself

You can see the steps of the activity itself in the student guide. (Note: there will be printed copies given to students during the activity.) We encourage you as a mentor to go through the steps ahead of time and make sure you are comfortable with all of them.

The last section of the student guide is the 'advanced' section. The typical Practicing Git group will not get to this section, which is totally okay. We encourage you to be prepared for it, however, as individual students may have questions about it. If you're not comfortable with the steps in the advanced section, we encourage you to ask for help from OpenHatch organizers ahead of time, or from other mentors at the event.

Some notes

  • Asheesh recommends you encourage Windows and Mac users to stay away from "Github for Windows" and "Github for Mac" because the steps you need to follow with those are different than what we have documented. Others have disagreed on this, but that's what Asheesh thinks. (The laptop setup guide also steers clear of those, so if students are following directions, they will do things the Asheesh way.)
  • Your main repository is configured, via Github Pages, to load on the web at a HTTP URL the same as the repository name. So, once you merge students' pull requests, they should be visible on the web at that address.
    • Note that it may take up to 2 minutes for the site to update with new changes. So don't expect it all to happen immediately.
    • There may also be issues with caching. To get around this problem, add "/?" to the end of the url.
  • Although you will be working with students in person, and should engage with them in person, we encourage you to use the IRC channel where possible. If you need to give students a link, leave it in the channel instead of writing it out on a white board, for instance. You can also encourage students to show off the their new page by linking to it in IRC.