Website Project-Activity

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
(Created page with "__NOTOC__ {{Category:Learning Activity}} == Using This Format == The format below contains sections which describe the items that should be included when creating a [[:Categ...")
 
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
−
{{Category:Learning Activity}}
 
  
−
== Using This Format ==
+
<span style="color:red">'''THIS PAGE IS CURRENTLY UNDER CONSTRUCTION '''</span>
−
 
+
−
The format below contains sections which describe the items that should be included when creating a [[:Category:Learning Activity]]. To use this format:
+
−
# Create a new page with a short, descriptive name that ends with "(Activity)". For example: '''Edit a Wiki Page (Activity)'''
+
−
# Copy the source for this format into your new page.
+
−
# Follow instructions to fill in the sections below.
+
−
#* '''Overview''' uses [[Template:Learning Activity Overview]].
+
−
#* '''Additional Information''' uses [[Template:Learning Activity Info]].
+
−
# Categorize the page using tags at the bottom of the page.
+
−
#* Include <nowiki>[[Category:Learning Activity]]</nowiki>
+
−
#* Add at least one subcategory from the list in [[:Category:Learning Activity|Learning Activities]], e.g. <nowiki>[[Category:Coding and Style]]</nowiki>
+
−
#* Remove <nowiki>[[Category:Format]]</nowiki>, since this page is a format, but your new page is not.
+
−
# Use the '''Discussion''' tab (upper left of the page) to leave feedback to the author(s) of the activity, such as usage or suggestions for enhancements.
+
−
 
+
−
 
+
−
== FORMAT ==
+
−
 
+
−
=== Overview ===
+
  
 
{{Learning Activity Overview
 
{{Learning Activity Overview
 
|title=
 
|title=
−
''Title of the activity (same as page name).''
+
Website Project Activity
 
|overview=  
 
|overview=  
−
''High level description of what the student will do.''
+
The students collaborate on a course website project hosted in a git repository.
 
|prerequisites=
 
|prerequisites=
−
''What topics and tools does the student need to know prior to beginning this activity?''
+
basics of version control, basics of web-development
 
|objectives=
 
|objectives=
−
''What should the student be able to do after completing this activity?''
+
Learn the basic tools required to make contributions to actual open source project: issue reporting, verification of issues, discussion of issues, claiming and fixing issues, making pull requests, resolving potential merge conflicts.
 
|process skills=
 
|process skills=
−
''What process skills will the student practice while completing this activity?''
+
communication, teamwork
 
}}
 
}}
  
−
=== Background ===
+
== Background ==
  
−
* Is there background reading material?
+
The idea of this activity is to allow the students to collaborate on a "real" project in a safe environment of their own class rather than jump directly into outside open source project.
−
* What is the rationale for this activity?
+
* Course website has to be hosted in a public repository. GitHub provides such hosting.
 +
* Students have to be familiar with basics of version control (bare minimum, they learn more are the project goes on).
 +
* Instructor has to introduce a sufficient number of problems to the website so that the students can report issues, but the website should be functional and contain the essential course information during the process.
 +
* (Optional) It may be a good idea to add a banner to the website mentioning that it is under active development by the students.
  
−
=== Directions ===
+
== Directions ==
  
−
* What should the student do?
+
=== Part 1: Finding and Verifying Issues ===
  
−
=== Deliverables ===
+
* As you are exploring the course website, take a note of any problems, inconsistencies, broken links, miss-formatting, etc.
 +
* Once you discover a problem, go the course website repository and look through the existing issues.
 +
* If the issue that you found has not been reported yet, report it. Provide a detailed description of the problem (when it occurs, why you think it is a problem), state which browser and operating system (name and version) you are using.
 +
* If the issue has been reported, you can comment on it. If nobody verified it before, you can add a comment stating that you have also encountered the issue. If other people already verified it, but you have additional details to add, you can do that as well. If you You can also suggest a solution if you think that you know how to solve it.
 +
* If you find reported issues that are not really issues, you can contribute that to the discussion.
  
−
* What will the student hand in?
+
'''Goal''': By the due date, you should
 +
* report ONE issue (please, do not report more than one since there are many people in the class trying to complete this task)
 +
* comment on at least two issues reported by others
  
−
= Notes for Instructors =
+
You SHOULD NOT be attempting to solve any of the issues just yet!
−
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 ===
+
You SHOULD pay close attention to the issues that you reported and commented on. Other people may ask follow-up questions and suggest modifications to the issue. Eventually, someone may provide a fix to an issue and you should be able to verify quickly that their fix actually works and that it fixes the issue. You should respond to all such comments and requests in a timely manner (i.e., a couple of days, not weeks).
  
−
* How will the activity be graded?
+
Always remember that you are working/collaborating with other people. BE COURTEOUS!!!
−
* 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?
+
=== Part 2: Claiming Issues ===
 +
 
 +
At this point, there should be a lot of open issues for the project. Add a comment to one of the issues that you would like to fix. The comment should basically state "I would like to claim this issue."
 +
 
 +
Restrictions: you will not be assigned to fix an issue that you reported yourself. For that reason, there is no point in claiming an issue that you reported.
 +
 
 +
It may be a good idea to claim issues that have not been claimed before since we will use "first come first serve" rule in assigning the issues.
 +
 
 +
'''Goal''': By the due date, you should
 +
 
 +
* claim a single issue to fix
 +
 
 +
=== Part 3: Fixing Problems and Verifying Fixed Problems ===
 +
 
 +
==== Part 3A ====
 +
 
 +
You were assigned an issue to work on. (If that is not the case, let the instructor know about it as soon as possible.)
 +
 
 +
Attempt to fix the issue and submit a pull request. You should make a fork of the exiting code and make and test all the changes that you are proposing in that fork repository. If you enable github pages for that repository, then you can verify that the issue that was reported is actually fixed and that your fix did not break any other parts of the website. Make sure that you carefully read the report of the issue and all/any follow-up discussion. Your fix should implement exactly what was agreed on.
 +
 
 +
Issue a pull request. In the pull request you should ask the original poster of the issue and (optionally) the people who commented on the issue to verify that the fix is acceptable to them. Provide a link to your fork that stores a functional website with your changes. <br> If there are merge conflicts when you issue a pull request, you HAVE to resolve them before the pull request can be accepted.
 +
 
 +
Make sure that you pay close attention to the pull request until it is rejected or merged. The maintainers and/or original posters may ask you to make changes and you should respond to such comments and requests in a timely manner.
 +
 
 +
==== Part 3B ====
 +
 
 +
As people submit pull requests in order to fix the issues, the original posters (and anybody else) should be verifying that the fix is really relevant to the original issue and that it fixes it according to the discussion for the issue. The author of the pull request should provide the location of a fork for the website so that people can easily verify it.
 +
 
 +
As changes are incorporated into the website, there may be new issues coming up. If you spot a new problem or previously unreported problem, feel free to report it as a new issue or comment on the previously reported issue.
 +
 
 +
If an issue is closed and you discover that the problem still exists, you should suggest that it is reopened.
 +
 
 +
If an accepted fix introduces a new problem, report it as a new issue but mention all other issues and pull request that might be related to this new problem.
 +
 
 +
Always remember that you are working/collaborating with other people. BE COURTEOUS!!!
 +
 
 +
'''Goal''': By the due date, you should
 +
* issue a pull request with a fix for the issue that you claimed
 +
* verify the fix in the pull request for the issue that you reported
 +
* verify the fix in the pull request for the issue that you commented on
 +
 
 +
== Deliverables ==
 +
 
 +
== Notes for Instructors ==
 +
 
 +
 
 +
=== Part 1: Finding and Verifying Issues ===
 +
 
 +
* This can be started very early in the course. Students need be able to report an issue using the bug tracker and be able to comment on issues reported by other students.
 +
* There has to be a sufficient number of problems with the site for all students to be able to participate. Although students tend to find issues that might not have been placed there intentionally by the instructor.
 +
* Estimated time: 5-7 days.
 +
 
 +
=== Part 2: Claiming Issues ===
 +
 
 +
* You cannot officially assign an issue to a GitHub user who does not have write access for the repository. This means that assigning issues has to be done either manually or by a bot. (I created a label "ASSIGNED" and manually assigned issues to the students. Each time an issue was assigned to a student, the label was added to the issue. This is time consuming process that could be helped by a TA or by a bot.)
 +
* Estimated time: 2-3 days.
 +
 
 +
=== Part 3: Fixing Problems and Verifying Fixed Problems ===
 +
 
 +
* Set very strict deadlines for submitting pull requests and for verifying them. This project (at least the first round of it) should not take more than a couple of weeks.
 +
* Estimated time: 5-7 days.
 +
 
 +
== Assessment ==
  
−
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:
 
The form of the assessment is expected to vary by assignment. One possible format is the table:
Line 81: Line 132:
 
|}
 
|}
  
−
=== Comments ===
+
== Comments ==
  
−
* What should the instructor know before using this activity?
 
−
* What are some likely difficulties that an instructor may encounter using this activity?
 
  
−
=== Suggestions for Open Source Community ===
 
  
−
Suggestions for an open source community member who is working in conjunction with the instructor.
+
== Suggestions for Open Source Community ==
  
−
=== Additional Information ===
+
 
 +
== Additional Information ==
  
 
{{Learning Activity Info
 
{{Learning Activity Info
 
|acm unit=
 
|acm unit=
−
''What [[ACM Body of Knowledge]] Area and Unit(s) are covered?''
+
''What ACM BoK Area and Unit(s) are covered?''
 
|acm topic=
 
|acm topic=
 
''What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/education/CS2013-final-report.pdf''
 
''What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/education/CS2013-final-report.pdf''
 
|difficulty=
 
|difficulty=
−
''Is this activity easy, medium, or hard?''
+
easy to medium (depending on the student background)
 
|time=
 
|time=
−
''How long should a typical student take to complete the activity?''
+
2-3 hours distributed over two weeks.
 
|environment=
 
|environment=
−
''What does the student need? (e.g. Internet access, IRC client, Git Hub account, LINUX machine, etc.)''
+
GitHub account, Internet access
 
|author=
 
|author=
−
''Who wrote this activity?''
+
Joanna Klukowska
 
|source=
 
|source=
−
''Is there another activity on which this activity is based?  If so, please provide a link to the original resource.''
 
 
|license=
 
|license=
−
''Under which license is this material made available? We request that you pick a [http://creativecommons.org/licenses/ Creative Commons license].''
+
{{License CC BY SA}}
−
''We suggest using a template like'': <nowiki>{{License CC BY}}</nowiki> or <nowiki>{{License CC BY SA}}</nowiki>
+
 
}}
 
}}
−
 
−
--------------------
 
−
<!-- this license is for the FORMAT - remove it for a new activity -->
 
−
For this blank '''format''': {{License CC BY SA}}
 
  
 
[[Category:Learning Activity]]
 
[[Category:Learning Activity]]
−
<!-- add appropriate subcategory(s) for a new activity -->
 
−
[[Category:LEARNING_ACTIVITY_SUBCATEGORY]]
 
−
 
−
<!-- this category is for the FORMAT - remove it for a new activity -->
 
−
[[Category:Formats]]
 

Latest revision as of 12:12, 15 October 2018


THIS PAGE IS CURRENTLY UNDER CONSTRUCTION

Title

Website Project Activity

Overview

The students collaborate on a course website project hosted in a git repository.

Prerequisites

basics of version control, basics of web-development

Learning
Objectives 		After successfully completing this activity, the learner should be able to:

Learn the basic tools required to make contributions to actual open source project: issue reporting, verification of issues, discussion of issues, claiming and fixing issues, making pull requests, resolving potential merge conflicts.

Process Skills
Practiced

communication, teamwork


Background

The idea of this activity is to allow the students to collaborate on a "real" project in a safe environment of their own class rather than jump directly into outside open source project.

  • Course website has to be hosted in a public repository. GitHub provides such hosting.
  • Students have to be familiar with basics of version control (bare minimum, they learn more are the project goes on).
  • Instructor has to introduce a sufficient number of problems to the website so that the students can report issues, but the website should be functional and contain the essential course information during the process.
  • (Optional) It may be a good idea to add a banner to the website mentioning that it is under active development by the students.

Directions

Part 1: Finding and Verifying Issues

  • As you are exploring the course website, take a note of any problems, inconsistencies, broken links, miss-formatting, etc.
  • Once you discover a problem, go the course website repository and look through the existing issues.
  • If the issue that you found has not been reported yet, report it. Provide a detailed description of the problem (when it occurs, why you think it is a problem), state which browser and operating system (name and version) you are using.
  • If the issue has been reported, you can comment on it. If nobody verified it before, you can add a comment stating that you have also encountered the issue. If other people already verified it, but you have additional details to add, you can do that as well. If you You can also suggest a solution if you think that you know how to solve it.
  • If you find reported issues that are not really issues, you can contribute that to the discussion.

Goal: By the due date, you should

  • report ONE issue (please, do not report more than one since there are many people in the class trying to complete this task)
  • comment on at least two issues reported by others

You SHOULD NOT be attempting to solve any of the issues just yet!

You SHOULD pay close attention to the issues that you reported and commented on. Other people may ask follow-up questions and suggest modifications to the issue. Eventually, someone may provide a fix to an issue and you should be able to verify quickly that their fix actually works and that it fixes the issue. You should respond to all such comments and requests in a timely manner (i.e., a couple of days, not weeks).

Always remember that you are working/collaborating with other people. BE COURTEOUS!!!

Part 2: Claiming Issues

At this point, there should be a lot of open issues for the project. Add a comment to one of the issues that you would like to fix. The comment should basically state "I would like to claim this issue."

Restrictions: you will not be assigned to fix an issue that you reported yourself. For that reason, there is no point in claiming an issue that you reported.

It may be a good idea to claim issues that have not been claimed before since we will use "first come first serve" rule in assigning the issues.

Goal: By the due date, you should

  • claim a single issue to fix

Part 3: Fixing Problems and Verifying Fixed Problems

Part 3A

You were assigned an issue to work on. (If that is not the case, let the instructor know about it as soon as possible.)

Attempt to fix the issue and submit a pull request. You should make a fork of the exiting code and make and test all the changes that you are proposing in that fork repository. If you enable github pages for that repository, then you can verify that the issue that was reported is actually fixed and that your fix did not break any other parts of the website. Make sure that you carefully read the report of the issue and all/any follow-up discussion. Your fix should implement exactly what was agreed on.

Issue a pull request. In the pull request you should ask the original poster of the issue and (optionally) the people who commented on the issue to verify that the fix is acceptable to them. Provide a link to your fork that stores a functional website with your changes.
If there are merge conflicts when you issue a pull request, you HAVE to resolve them before the pull request can be accepted.

Make sure that you pay close attention to the pull request until it is rejected or merged. The maintainers and/or original posters may ask you to make changes and you should respond to such comments and requests in a timely manner.

Part 3B

As people submit pull requests in order to fix the issues, the original posters (and anybody else) should be verifying that the fix is really relevant to the original issue and that it fixes it according to the discussion for the issue. The author of the pull request should provide the location of a fork for the website so that people can easily verify it.

As changes are incorporated into the website, there may be new issues coming up. If you spot a new problem or previously unreported problem, feel free to report it as a new issue or comment on the previously reported issue.

If an issue is closed and you discover that the problem still exists, you should suggest that it is reopened.

If an accepted fix introduces a new problem, report it as a new issue but mention all other issues and pull request that might be related to this new problem.

Always remember that you are working/collaborating with other people. BE COURTEOUS!!!

Goal: By the due date, you should

  • issue a pull request with a fix for the issue that you claimed
  • verify the fix in the pull request for the issue that you reported
  • verify the fix in the pull request for the issue that you commented on

Deliverables

Notes for Instructors

Part 1: Finding and Verifying Issues

  • This can be started very early in the course. Students need be able to report an issue using the bug tracker and be able to comment on issues reported by other students.
  • There has to be a sufficient number of problems with the site for all students to be able to participate. Although students tend to find issues that might not have been placed there intentionally by the instructor.
  • Estimated time: 5-7 days.

Part 2: Claiming Issues

  • You cannot officially assign an issue to a GitHub user who does not have write access for the repository. This means that assigning issues has to be done either manually or by a bot. (I created a label "ASSIGNED" and manually assigned issues to the students. Each time an issue was assigned to a student, the label was added to the issue. This is time consuming process that could be helped by a TA or by a bot.)
  • Estimated time: 2-3 days.

Part 3: Fixing Problems and Verifying Fixed Problems

  • Set very strict deadlines for submitting pull requests and for verifying them. This project (at least the first round of it) should not take more than a couple of weeks.
  • Estimated time: 5-7 days.

Assessment

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)
Criterion 1...
Criterion 2...

Comments

Suggestions for Open Source Community

Additional Information

ACM BoK
Area & Unit(s)

What ACM BoK Area and Unit(s) are covered?

ACM BoK
Topic(s)

What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/education/CS2013-final-report.pdf

Difficulty

easy to medium (depending on the student background)

Estimated Time
to Complete

2-3 hours distributed over two weeks.

Environment /
Materials

GitHub account, Internet access

Author(s)

Joanna Klukowska

Source
License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

CC license.png

Retrieved from "http://foss2serve.org/index.php?title=Website_Project-Activity&oldid=12759"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox