Difference between pages "Git: GitHub Issues and Pull Requests" and "Reflect on Learning from Failure (Framework)"

From TeachingOpenSource
(Difference between pages)
 
 
Line 1: Line 1:
__NOTOC__
{| border="1"
{| border="1"
|-  
|-  
|'''Title''' || Working with GitHub Issues, Forks, and Pull Requests
|'''Title''' || Framework Reflection on Learning from Failure
|-
|-
|'''Overview''' || In this activity, students will try to close Issues in a GitHub repo and then merge their changes.
|'''Overview''' || We want students to understand how much they are learning from their failures during the course instead of getting frustrated over it
|-  
|-  
|'''Prerequisite Knowledge''' || Students are expected to have GitHub accounts and have a basic understanding of GitHub commits and pull requests.
|'''Prerequisite Knowledge''' || This framework can potentially be integrated for any of the courses using FOSS continuously.
|-
|-
|'''Learning Objectives''' || What should the student be able to do after completing this activity?
|'''Learning Objectives''' || Reflect on their progress in a project or course.
|}
|}


=== Background: ===
The goal of this activity is to give students experience working with GitHub Issues on a small-scale project, since presumably they will need to do this on their FOSS projects.


They will learn how to claim an Issue in GitHub, fork a repository, push their own changes, issue a Pull Request, and use communication mechanisms such as IRC to collaborate with the rest of the community and make sure their PR is merged.
== Background ==


It is assumed that students have completed these Learning Activities (or similar):
=== Rationale ===
* [[Intro_IRC_Activity]]
* [[Git:_Introduction_to_Github]]


This activity is meant to be done in a classroom setting, so that everything is happening synchronously in real time. The instructor's role is to act as the repo committer: ensure that contributors are not duplicating effort; check PRs for correctness, adherence to coding conventions, etc.; answer questions about the Issues; merge PRs; mark Issues as closed.
Our framework is motivated by the following:
* Students will get critiqued in the world they'll enter into. They need to learn how to deal with that in a constructive way.
* Students often presume others are doing better than them.
* Students associate being “productively lost” with failure.
* Underrepresented groups in CS can be challenged by a lack of confidence (including, but not limited to issues of stereotype threat).


Note that in the activity below, it is assumed that students are working individually and are not allowed to communicate except by IRC (so you will need to set up a channel) and the GitHub Issues comments. You may remove either or both of those restrictions as needed, though it does remove some of the "real-world" aspect of the activity.
=== Readings===
* Barker, Lecia J., Charlie McDowell, and Kimberly Kalahar. "Exploring factors that influence computer science introductory course students to persist in the major." ACM SIGCSE Bulletin. Vol. 41. No. 1. ACM, 2009.
* Dryburgh, Heather. "Underrepresentation of girls and women in computer science: Classification of 1990s research." Journal of Educational Computing Research 23.2 (2000): 181-202.
* Margolis, Jane, and Allan Fisher. Unlocking the clubhouse: Women in computing. MIT press, 2003 | https://pdfs.semanticscholar.org/c814/d8d066e64095e03d3193786b2fdd15243cac.pdf
* Roger Von Oech - A Whack on the Side of the Head: How You Can Be More Creative - http://courses.washington.edu/art166sp/documents/Spring2012/readings/week_3/AWhackOnTheSideOfTheHead.pdf


=== Directions (for students): ===
== Directions & deliverables ==
'''Step 1. Create an account'''
=== Micro-reflections ===  
''Extremely short "Tweet-sized", scheduled, in-class reflections asking the student to step out of their current activity, think about their current mindset, then return to the activity.''  
* Regular interval during class, e.g. every 30 minutes in class
* There is a social aspect to sharing them as tangible artifacts that help students step out of the technical details to see the social skills for a moment. Color-coded notes/notecards could be used for various categories (technical, communication, big picture, etc.)
* Some ways to think about implementing micro-reflections:
** Commit messages where students state their current stage of thought/problem-solving process, snapshot of where they’re at. If collecting them in a different place is preferred, a shared doc is an option.
** Index cards / Post-its if computers aren’t in use (and public, can optionally be categorized), but would have to be written up / redistributed / photographed if they are supposed to be available to the students for macro reflections.


If you do not already have an account, create one at http://github.com
=== Mini-reflections ===
''(weekly; outside of class) - longer reflections (e.g., 2-3 paragraphs) with prompted topics.''
* Some ways to think about implementing mini-reflections:
** Blog
** Wiki
* Prompt a different category every week: soft skills, technical aspect, communication, organization


Also be sure that you have git on your local computer or have GitHub Desktop: https://desktop.github.com/
=== Final/macro/meta Reflections ===
''(1-3 at milestones/checkpoints; outside of class) - Summative reflection, asking the students to re-explore their process from a previous period/project.''
* Suggested milestones: start of the semester (survey), middle of semester (survey), end of semester (survey and essay)
*Some ways to think about implementing Final/macro/meta Reflections (more than one may be appropriate):
** Surveys: use existing FOSS surveys and maybe add a couple of questions
** Short essay with reflection at the end (using their micro reflections) and the prompt to reflect on how they learned from failure.


'''Step 2. Fork and clone repo'''
=== ''Progress visualization over an academic term...'' ===
* How can we (help students) visualize progress? Charting on the following fronts:
* Let students set a goal - may be unrealistic but they engage more if they can contribute creatively
* Level of frustration, just for giggles, hoping it goes down over the semester ;)
* Learning goals / objectives (for the course, as determined by instructor)
* Data collection via Moodle/BlackBoard/whatever your course is already using


Make a fork of the repo at (''github repo URL'') into your account, then clone it onto your local computer.


'''Step 3. Claim an issue to work on'''


Go to that repo's "Issues" tab and find one that you would like to work on (some are easier than others!).
= Notes for Instructors =


/*Is there a way in github to assign this to people?*/
The remaining sections of this document are intended for the instructor.  They are not part of the learning activity that would be given to students.


To claim the issue as your own, add a comment indicating that you are working on it. Make sure you aren’t working on the same issue as someone else!
=== Assessment ===
 
'''How will the activity be graded?''' The larger the reflection, the more weight it gets assigned.
'''IMPORTANT NOTE!''' If you would like to communicate with another student or the instructor regarding the issue, you ''must'' use the IRC channel and you may ''not'' speak until the instructor has said it's okay to do so!
* The micro reflections are not graded on content, just on process (which basically means whether students did them or not).
 
* The mini reflections can be graded using questions below.
'''Step 4. Make local changes as needed'''
* The macro reflection can be graded using same and further questions.
 
* The data tracking is graded on process - did they submit their numbers or not.
Make changes to the code for your issue in your local environment.
 
How will learning will be measured? Ideally, there should be a way to measure each of the objectives described above.  
This shouldn't take too long but as above, if you need to communicate with another student or the instructor, you ''must'' use the IRC channel.
 
'''Step 5. Commit/push your changes to your fork'''
 
After modifying the code, commit your changes locally and then push them to your fork in GitHub.
 
'''Step 6. Submit a Pull Request'''
 
Create a new Pull Request (PR) in the (''github repo url'') repo from your fork.
 
Then add a comment in the Issue that you claimed, indicating that you have submitted a PR. Include a link to the PR.
 
'''Step 7. Wait patiently'''


Patiently wait in GitHub to see if your PR is merged by one of the repo owners. You may also get a follow-up comment in your Issue, or a note in IRC.


Only when your PR is merged can you consider this step "done," so don't celebrate just yet!
How will feedback to the student be determined?


=== Deliverables: ===
What will the student hand in?
=== Assessment: ===
How will the activity be graded?
How will learning will be measured?


Include sample assessment questions/rubrics.
Include sample assessment questions/rubrics. Feel free to indicate that the activity itself is not graded, however it would be helpful to include any questions that might be used at a later date to interpret learning, for example on a quiz or exam.  


The form of the assessment is expected to vary by assignment. One possible format is the table:
{| border="1" class="wikitable"
{| border="1" class="wikitable"
! Criteria
! Criteria
Line 83: Line 89:
! Level 4 (exceptional)
! Level 4 (exceptional)
|-
|-
| '''Criterion 1...'''
| '''How well did they follow the prompt on what to write about? '''
|  
| X
|  
|  
|
|
Line 90: Line 96:


|-
|-
| '''Criterion 2...'''
| '''Did they describe their observations well?'''
|  
| X
| X
|  
|  
|  
|  
|-
| '''Did they draw conclusions from their observations?'''
| X
| X
| X
|  
|  
|-
| '''Did they conclude lessons learned?'''
| X
| X
| X
| X


|}
|}


=== Comments/Notes to Instructors: ===
=== Comments: ===
A sample repo with 15 open issues is available at https://github.com/ChrisMurphyOnline/github-issues-activity
What should the instructor know before using this activity?
 
This particular repo assumes that students are familiar with Java and JUnit.


Feel free to fork this repo for your own course, but unfortunately I am not aware of ways to clone the issues. I have previously done this by hand (takes about 15 minutes) but there do seem to be scripts to help with this, e.g. https://github.com/IQAndreas/github-issues-import
What are some likely difficulties that an instructor may encounter using this activity?
 
Here are some notes about the issues in that repo:
* issue #2: in addition to making this change, the student should add a JUnit test. The student should realize this on their own, of course, but if they do not, mention it to them (via the Issue or IRC) and do not merge the PR until a test is added.
* issue #3: the fact that this new method needs a test is referenced in issue #8, so there is something of a constraint here
* issue #5: the conditions that check whether n1 and n2 are 0 are unnecessary. They're not wrong, they're just not needed because of the rest of the method.
* issue #6: clearly the "expected" variable is incorrect. The student can change it, or one of the other variables, but the values must all be negative in this test.
* issue #7: this (intentionally) does not tell the student what the name of the method should be, but it should start with "test" and be related to testing overflow
* issue #8: as noted above, this depends on issue #3 to be implemented
* issue #11: the two testAllDigits methods in DumbStringTest should be changed as a result of this change, though this is not explicitly stated in the Issue. Do not merge the PR until the student has modified the test cases; static methods should be referenced statically, not via an instance object.
* issue #12: although not explicitly stated, the student should modify the javadoc ''and'' write a new test case for this method; do not merge the PR until both of these are done
* issue #13: as with #12, this change should also result in a change to the javadoc ("chars" instead of "letters") as well as the test case, which will not compile if not modified
* issue #14: this is more challenging than the others, as the student needs to make sure that letters are not double-counted


=== Additional Information: ===
=== Additional Information: ===
{| border="1"
{| border="1"
|-  
|-  
|'''ACM Knowledge Area/Knowledge Unit''' || What ACM Computing Curricula 2013 knowledge area and units does this activity cover? [[ACM_Body_of_Knowledge]]
|'''ACM Knowledge Area/Knowledge Unit''' || Depends on the activity this framework is used in [[ACM_Body_of_Knowledge]]
|-
|-
|'''ACM Topic''' || What specific topics are addressed? The Computing Curriucula 2013 provides a list of topics - https://www.acm.org/education/CS2013-final-report.pdf
|'''ACM Topic''' || Soft skills: Reflection (not in ACM but it's the topic)
|-
|-
|'''Level of Difficulty''' || Is this activity easy, medium or challenging?
|'''Level of Difficulty''' || Carrying out the writing tasks is easy, doing a good reflection is medium.
|-
|-
|'''Estimated Time to Completion''' ||  How long should it take for the student to complete the activity?
|'''Estimated Time to Completion''' ||  Micro: 30 seconds, Mini: 10-30 minutes, Macro: 2 hours
|-
|-
|'''Materials/Environment''' || What does the student need?  Internet access, IRC client, Git Hub account, LINUX machine, etc.?
|'''Materials/Environment''' || Internet access if carried out on blog.
|-
|-
|'''Author(s)''' || [http://foss2serve.org/index.php/User:Cmurphy Chris Murphy]
|'''Author(s)''' || Birgit Penzenstadler, Emily Lovell, Mario Nakazawa, Scott Heggen, Matt Jadud
|-
|-
|'''Source''' || Is there another activity on which this activity is based?  If so, please provide a link to the original resource.
|'''Source''' || n.a.
|-
|-
|'''License''' || Under which license is this material made available? (http://creativecommons.org/licenses/)
|'''License''' || This learning activity is available for use under the [http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License].  Attribution need not include a link back to this site.
|}
|}


=== Suggestions for Open Source Community: ===
=== Suggestions for Open Source Community: ===
Suggestions for an open source community member who is working in conjunction with the instructor.
This framework seems to be more about reflection in any course context where students can fail than specifically OSS. We are not sure what suggestions may arise from that for the open source community.
 
--------------------
This work is licensed under a
[http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International License]


[[File:CC_license.png]]


[[Category: Learning_Activity]]
[[Category:Framework]]

Revision as of 19:00, 19 November 2016


Title Framework Reflection on Learning from Failure
Overview We want students to understand how much they are learning from their failures during the course instead of getting frustrated over it
Prerequisite Knowledge This framework can potentially be integrated for any of the courses using FOSS continuously.
Learning Objectives Reflect on their progress in a project or course.


Background

Rationale

Our framework is motivated by the following:

  • Students will get critiqued in the world they'll enter into. They need to learn how to deal with that in a constructive way.
  • Students often presume others are doing better than them.
  • Students associate being “productively lost” with failure.
  • Underrepresented groups in CS can be challenged by a lack of confidence (including, but not limited to issues of stereotype threat).

Readings

Directions & deliverables

Micro-reflections

Extremely short "Tweet-sized", scheduled, in-class reflections asking the student to step out of their current activity, think about their current mindset, then return to the activity.

  • Regular interval during class, e.g. every 30 minutes in class
  • There is a social aspect to sharing them as tangible artifacts that help students step out of the technical details to see the social skills for a moment. Color-coded notes/notecards could be used for various categories (technical, communication, big picture, etc.)
  • Some ways to think about implementing micro-reflections:
    • Commit messages where students state their current stage of thought/problem-solving process, snapshot of where they’re at. If collecting them in a different place is preferred, a shared doc is an option.
    • Index cards / Post-its if computers aren’t in use (and public, can optionally be categorized), but would have to be written up / redistributed / photographed if they are supposed to be available to the students for macro reflections.

Mini-reflections

(weekly; outside of class) - longer reflections (e.g., 2-3 paragraphs) with prompted topics.

  • Some ways to think about implementing mini-reflections:
    • Blog
    • Wiki
  • Prompt a different category every week: soft skills, technical aspect, communication, organization

Final/macro/meta Reflections

(1-3 at milestones/checkpoints; outside of class) - Summative reflection, asking the students to re-explore their process from a previous period/project.

  • Suggested milestones: start of the semester (survey), middle of semester (survey), end of semester (survey and essay)
  • Some ways to think about implementing Final/macro/meta Reflections (more than one may be appropriate):
    • Surveys: use existing FOSS surveys and maybe add a couple of questions
    • Short essay with reflection at the end (using their micro reflections) and the prompt to reflect on how they learned from failure.

Progress visualization over an academic term...

  • How can we (help students) visualize progress? Charting on the following fronts:
  • Let students set a goal - may be unrealistic but they engage more if they can contribute creatively
  • Level of frustration, just for giggles, hoping it goes down over the semester ;)
  • Learning goals / objectives (for the course, as determined by instructor)
  • Data collection via Moodle/BlackBoard/whatever your course is already using


Notes for Instructors

The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.

Assessment

How will the activity be graded? The larger the reflection, the more weight it gets assigned.

  • The micro reflections are not graded on content, just on process (which basically means whether students did them or not).
  • The mini reflections can be graded using questions below.
  • The macro reflection can be graded using same and further questions.
  • The data tracking is graded on process - did they submit their numbers or not.

How will learning will be measured? Ideally, there should be a way to measure each of the objectives described above.


How will feedback to the student be determined?


Include sample assessment questions/rubrics. Feel free to indicate that the activity itself is not graded, however it would be helpful to include any questions that might be used at a later date to interpret learning, for example on a quiz or exam.

The form of the assessment is expected to vary by assignment. One possible format is the table:

Criteria Level 1 (fail) Level 2 (pass) Level 3 (good) Level 4 (exceptional)
How well did they follow the prompt on what to write about? X
Did they describe their observations well? X X
Did they draw conclusions from their observations? X X X
Did they conclude lessons learned? X X X X

Comments:

What should the instructor know before using this activity?

What are some likely difficulties that an instructor may encounter using this activity?

Additional Information:

ACM Knowledge Area/Knowledge Unit Depends on the activity this framework is used in ACM_Body_of_Knowledge
ACM Topic Soft skills: Reflection (not in ACM but it's the topic)
Level of Difficulty Carrying out the writing tasks is easy, doing a good reflection is medium.
Estimated Time to Completion Micro: 30 seconds, Mini: 10-30 minutes, Macro: 2 hours
Materials/Environment Internet access if carried out on blog.
Author(s) Birgit Penzenstadler, Emily Lovell, Mario Nakazawa, Scott Heggen, Matt Jadud
Source n.a.
License This learning activity is available for use under the Creative Commons Attribution-ShareAlike 4.0 International License. Attribution need not include a link back to this site.

Suggestions for Open Source Community:

This framework seems to be more about reflection in any course context where students can fail than specifically OSS. We are not sure what suggestions may arise from that for the open source community.

Retrieved from "https://teachingopensource.org/index.php?title=Git:_GitHub_Issues_and_Pull_Requests&oldid=7147"
Powered by MediaWiki