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

← Older edit

Open Source Comes to Campus/Curriculum/Git/Instructors (view source)

Revision as of 23:03, 17 April 2015

545 bytes added , 9 years ago

no edit summary

Anonymous user

imported>Paulproteus

Revision as of 00:02, 29 December 2013 (view source) imported>Shauna No edit summary ← Older edit		Latest revision as of 23:03, 17 April 2015 (view source) imported>Paulproteus No edit summary
(4 intermediate revisions by 2 users not shown)
Line 1: = Leading 'Practicing Git' = ~~== Audience of this page ==~~ 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. ~~A volunteer staff member~~ == The background == ~~== Your goal, over the next 60-90 minutes ==~~ 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]. * 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). 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. ~~== Things you need to know ==~~ * Sometimes a student will submit a pull request that needs fixing. For example:▼ * We have created a Github organization for you to use, with your students forking and submitting pull requests to a static HTML website. ** They might make unrelated changes in the file.▼ * We have created bitesize issues in that static HTML project, filed in Github issues. 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. * Students are '''expected''' to: 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. == The activity itself == * Your goal is to help them succeed! 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. * 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. 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. * 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. == Some notes == ▲* 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, 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. * Asheesh recommends you encourage Windows and Mac users to stay away from "~~Github~~GitHub for Windows" and "~~Github~~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.)▼ * The laptop setup guide can be found at: http://bit.ly/laptop-setup * Your main repository is configured, via [http://pages.github.com/ ~~Github~~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.▼ ▲* 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. 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. * If you finish early, or if you have questions, tell Asheesh and Shauna on the #openhatch IRC channel. == Further reading == Some students will finish early. For those people, I recommend: * [http://gitimmersion.com/ Git Immersion] * 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. * How to [http://think-like-a-git.net/ Think Like Git]