Open Source Software Development, NYU, Klukowska

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
(→Overview)
(→Course Deliverables and Assessment Methods)
 
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
  
−
'''THIS PAGE IS CURRENTLY UNDER CONSTRUCTION '''
 
  
−
= Overview =
+
== Overview ==
  
 
{{Course Overview
 
{{Course Overview
Line 13: Line 12:
 
[https://cs.nyu.edu/~joannakl/ Joanna Klukowska]  
 
[https://cs.nyu.edu/~joannakl/ Joanna Klukowska]  
 
|offerings=
 
|offerings=
−
Spring 2018, [https://joannakl.github.io/cs480_s18/ course website], 38 students
+
First offered Spring 2018, [https://joannakl.github.io/cs480_s18/ course website] with 38 students. Revised and improved for [https://joannakl.github.io/ossd_s19/ Spring 2019] and [https://joannakl.github.io/ossd_s20/ Spring 2020] semesters.
 
|overview=
 
|overview=
 
This course prepares students to become active participants in open source projects. It begins with an overview of the philosophy and brief history of open source development, followed by an in-depth look at different types of open source projects and the study of various tools involved in open source development. In particular, it covers the collaborative nature of open source projects, community structure, version control systems, licensing, intellectual property, types of contributions (programming and non-programming) and the tool-chains that enable such contributions. The students are expected to contribute to existing open source projects.
 
This course prepares students to become active participants in open source projects. It begins with an overview of the philosophy and brief history of open source development, followed by an in-depth look at different types of open source projects and the study of various tools involved in open source development. In particular, it covers the collaborative nature of open source projects, community structure, version control systems, licensing, intellectual property, types of contributions (programming and non-programming) and the tool-chains that enable such contributions. The students are expected to contribute to existing open source projects.
 +
|courselength=
 +
14-week semester + 1 week for final exams
 
|students=
 
|students=
−
This course is upper-level undergraduate elective. <br>The first time this class was offered, there were 38 students.   
+
This course is an upper-level undergraduate elective. <br>The number of students in the course  in its first two offerings was 38 students.   
−
|prerequisites= Familiarity with a programming language for the chosen FOSS project. Basic familiarity with command line tools and a version control system. <br>Formally: Computer Systems Organization course (required prerequisite for all electives).  
+
|prerequisites= Familiarity with a programming language for the chosen FOSS project. Basic familiarity with command-line tools and a version control system. <br>Formally: Computer Systems Organization course (required prerequisite for all electives).  
 
|infrastructure=
 
|infrastructure=
 
The class meets twice a week for 75 minutes each time. In general, one of the class meetings will consist of discussions of the reading assignments and/or guest speakers, and the other class meeting that week will be for learning activities, project status updates, and presentations, or time to work on the project.
 
The class meets twice a week for 75 minutes each time. In general, one of the class meetings will consist of discussions of the reading assignments and/or guest speakers, and the other class meeting that week will be for learning activities, project status updates, and presentations, or time to work on the project.
  
−
Use of specific software and technologies depends on the chosen FOSS projects.  
+
The use of specific software and technologies depends on the chosen FOSS projects.  
  
−
The instructor should have a GitHub organization to which all students are added at the start of the semester. The students should have rights to create repositories within this organization.  
+
The instructor should have a GitHub organization (or equivalent) to which all students are added at the start of the semester. The students should have the right to create repositories within this organization.  
  
−
Students should be able to bring their computers to the class meetings.  
+
Students should be able to bring their computers to class meetings.  
 
}}
 
}}
  
−
= Learning Objectives =
+
== Learning Objectives ==
  
−
* ''objectives & prerequisites should be active, student-centered, specific, and measurable''
+
Students gain experience in:
−
** ''the student will be able to...''
+
# understanding the origins and implications of open source development;
−
* ''for the entire course, and/or for FOSS-specific parts of the course''
+
# interacting with a community of developers and users;
−
* ''might include content & process skills''
+
# managing code using a version control system;
−
* ''might consider all levels of Bloom's taxonomy''
+
# reading/modifying/testing within a substantial existing code base;
 +
# recognizing the ethical, legal and social implications of computing.
  
−
= Assessment Methods =
+
== Course Deliverables and Assessment Methods ==
  
−
* ''what will students do in this course, and how will it be evaluated''
+
Students are graded based on
−
** ''Exams, assignments, projects, etc.''
+
* participation (10%),  
−
* ''should be tied to learning objectives''
+
* homework (10%),  
 +
* contributions to open source projects (40%),  
 +
* several mini-exams (40%).
  
 +
The types of graded activities are
  
 +
* '''Weekly blog posts'''. Students are required to make weekly blog posts containing answers to posed questions and reflections about readings and invited speakers. Counts towards homework.
 +
 +
* '''Participation in class discussions'''. Students are expected to actively participate in class discussions about assigned readings, course activities, invited speakers' lectures, etc. Counts towards participation.
 +
 +
* '''Small individual contributions'''. Students are expected to make a total of 20 small individual contributions. These include (but are not limited to) course website contributions, Wikipedia (and other Wiki projects) contributions, OpenMaps contributions, etc. The contributions to code projects can be in the form of comments on existing issues, reporting new issues, documentation edits, code fixes to reported issues. Counts towards contributions to open source projects.
 +
 +
* '''Team project contributions'''. Students spend the last 6 weeks of the semester working on a team projects. Their individual contributions to the team effort count towards their own grade. Counts towards contributions to open source projects.
 +
 +
* '''Mini-exams'''. Students are given several 20 minute long mini-exams during the semester. Counts towards the mini-exams.
 +
 +
== Course Outline and Materials ==
 +
 +
Course outlines:
 +
 +
* [https://joannakl.github.io/cs480_s18/daily.html The day by day outline for the Spring 2018 instance of this course ] (first offering)
 +
* [https://joannakl.github.io/ossd_s19/daily.html The day by day outline for the Spring 2019 instance of this course ] (second offering)
 +
* [https://joannakl.github.io/ossd_s20/daily.html The day by day outline for the Spring 2020 instance of this course ] (in progress)
 +
 +
Course materials (slides, activities, and sample assessments) are available at [https://github.com/joannakl/ossd_materials OSSD materials repository]. This repository evolves as we make modifications to the course.
 +
 +
== Experiences and Assessment ==
 +
 +
No formal pre- or post-surveys were performed in this course.
 +
 +
This section is based on personal reports by students made during workshop days and final presentations, and on students' success in making contributions.
 +
 +
 +
''' Student Expectations and Experiences'''
 
----
 
----
  
−
* '''Weekly blog posts'''
+
'''Creating an open source project vs. working on an existing project''' <br>
−
* '''Participation in class discussions'''
+
One of the major objectives of this course is to give students the experience of working on a large third party software base and interact with the community that maintains the project.
−
* '''Small individual contributions'''
+
Some students come into this course hoping that they can create their own open source project and are disappointed when they learn this is not the case.    The reasons they cite for wanting to work on their own project are: 1) being in charge of all the code, 2) creating a large project that can be included in their portfolio, 3) not wanting to deal with existing communities. Most realize the benefits of working on an existing project after the initial discussion, but not all.
−
* '''Team project contributions'''
+
−
* '''Quizzes'''
+
−
* '''Midterm and final exams'''
+
  
−
= Course Outline =
+
'''Selecting large ''cool'' and ''fast-moving'' project to work on''' <br>
 +
When students select projects to work on, they often start with the large popular projects that are widely used. There are two reasons for this: 1) students are familiar with those projects, 2) students view those projects as prestigious and contributions made to such projects seem more significant. Large active projects have their benefits for first contributors, but they also have some major drawbacks. Such projects usually have very active communities and it is relatively easy for the students to get responses. On the other hand, the very active community also implies that many issues (especially the easier ones) get resolved quickly leaving students with not much choice of the issues to work on. In the past, several student groups realized that picking such a project was a mistake and they would have had a much easier time working on a project if they picked one that is smaller and not as fast-paced.
  
−
* ''major topics, events, milestones''
+
'''Large vs. small contributions''' <br>
−
* ''learning activities that can be adopted or adapted''
+
Most students have high expectations of what they will be able to accomplish when they start the class. They expect to be able to make significant code contributions (i.e., implementing a new feature or adding something that involves on the order of hundreds of lines of code). They do not see much value in smaller code contributions, in contributions to documentation or in bug gardening (commenting on the existing issue). Students tend to get frustrated with the ''small'' contributions and need regular reassurance and reminders about the importance of such contributions. Some open source communities are very good at stating appreciation for all contributions when they are merged, but that is not always the case.
−
* ''new learning activities that should or could be developed''
+
−
* ''include links to foss2serve Learning Activities where appropriate''
+
−
* ''reading assignments and supporting materials''
+
−
* ''or link to course website''
+
  
−
[https://joannakl.github.io/cs480_s18/daily.html The day by day outline for the Spring 2018 instance of this course.]
+
'''Interacting with the community''' <br>
 +
Interacting with communities of other developers who are not just other students is one of the largest challenges for students in the class. Many groups attempt to actually solve the problems before they reach out to the project communities rather than trying to get feedback and advice from the more experienced developers or people more familiar with the project in advance. This is somewhat to be expected, but instructors need to constantly remind students about the importance and necessity of reaching out to the community before spending any significant amount of time on solving issues. Ultimately, most student groups report on successful communication and positive experience with the project community. Many of them mention that, in retrospect, they wish they had reached out to the community sooner.  
  
−
= Notes to Instructor =
+
'''Changing projects''' <br>
 +
At the start of the semester, students perform a project evaluation exercises for several different projects. The goal of these exercises is to develop skills that allow students to recognize projects that 1) are suitable for contributions made by first-time developers, 2) have an active community, 3) have enough of issues appropriate to the students' level, etc. Unfortunately, an evaluation is a fairly passive activity and even students sometimes try to get involved in projects that turn out to be inappropriate for one reason or another.  Some groups decide to change the project after they have invested some time into it. This may be a good idea or a bad idea and the instructors should be involved in making such a decision. In some cases, students might be simply overwhelmed by the initial steps and hope to change to something that may seem more beginner-friendly (although, there is never a guarantee that this will be the case). In other cases, the response (or lack of it) from the community or difficulty with installing a development environment might be clear indicators that students will not be able to succeed and they should not be spending more time on such a project.
  
−
This course has been offered once so far. It will be revised before the next offering in spring 2019. The revisions will be based primarily on student feedback and instructor experience. (See the Moving Forward section for some directions of revisions.)
 
  
−
Feel free to contact me with any questions regarding the materials and the structure of this course.
+
'''Students' Success/Failure '''
 +
------------------------
  
−
= Moving Forward =
+
Students work in groups of 2-5 for the last several weeks of the semester with the goal of contributing to a single existing open source project.
 +
In the past two semesters, almost all groups were able to make accepted contributions to those projects.
  
−
The course will be revised before its next offering in spring 2019.
+
In the first offering of this course, there were eight student groups working on eight different projects. Seven of those groups were able to make contributions to open source projects. One group chose to work on a plugin for an application that was not completed by the time the semester ended. One of the groups that made contributions did not have those contributions merged into the actual project by the time the semester concluded. One group changed the project after the initial attempt of reaching out to the community of their first-choice project; another group changed their project after a couple of weeks of unsuccessful attempts at working with the code base.
−
Some of the changes suggested by students and/or instructor:
+
  
−
* start working on projects earlier in the semester (not necessarily "real" projects, but maybe another type of the website project)
+
In the second offering of this course, there were eleven student groups working on ten different projects (two groups worked on the same project but independent of one another). All groups were able to make contributions to the projects. Several groups worked on writing documentation and translations for the projects that they were involved with. Students from one group were asked to join the maintainers for the project on which they were working. Two groups considered changing the project after some initial unsuccessful attempts, but eventually stayed with their initial project and were able to contribute to it.
−
* create a list of "easy for beginners" projects
+
 
−
* reorganize order in which topics are covered
+
== Notes to Instructor ==
−
* go deeper into how version control works
+
 
 +
This course has been offered twice so far. It is continually revised as we learn new things about best practices for teaching open source software development.
 +
The major challenge is in finding the balance in how much we need to teach the students before they can start attempting to contribute to the existing open source projects. The current belief of the instructor is that students can learn a lot about communities and structures of projects that they are interested in right from the start of the semester. They can also make meaningful contributions that bust their morale and provide the introduction to open source contributions without spending many weeks learning the ''basics''. This technical material can be introduced in parallel to students' immersion into an actual project.
 +
 
 +
Feel free to contact me with any questions regarding the materials and the structure of this course.
  
−
= License =
+
== License ==
 
{{License CC BY SA}}.
 
{{License CC BY SA}}.
  

Latest revision as of 01:45, 27 December 2019


Overview

Course Open Source Software Development (OSSD)
Institution Courant Institute of Mathematical Sciences, New York University
Instructor(s) Joanna Klukowska
Term First offered Spring 2018, course website with 38 students. Revised and improved for Spring 2019 and Spring 2020 semesters.
Course Overview This course prepares students to become active participants in open source projects. It begins with an overview of the philosophy and brief history of open source development, followed by an in-depth look at different types of open source projects and the study of various tools involved in open source development. In particular, it covers the collaborative nature of open source projects, community structure, version control systems, licensing, intellectual property, types of contributions (programming and non-programming) and the tool-chains that enable such contributions. The students are expected to contribute to existing open source projects.
Course Length 14-week semester + 1 week for final exams
Student Characteristics This course is an upper-level undergraduate elective.
The number of students in the course in its first two offerings was 38 students.
Prerequisites Familiarity with a programming language for the chosen FOSS project. Basic familiarity with command-line tools and a version control system.
Formally: Computer Systems Organization course (required prerequisite for all electives).
Infrastructure The class meets twice a week for 75 minutes each time. In general, one of the class meetings will consist of discussions of the reading assignments and/or guest speakers, and the other class meeting that week will be for learning activities, project status updates, and presentations, or time to work on the project.

The use of specific software and technologies depends on the chosen FOSS projects.

The instructor should have a GitHub organization (or equivalent) to which all students are added at the start of the semester. The students should have the right to create repositories within this organization.

Students should be able to bring their computers to class meetings.


Learning Objectives

Students gain experience in:

  1. understanding the origins and implications of open source development;
  2. interacting with a community of developers and users;
  3. managing code using a version control system;
  4. reading/modifying/testing within a substantial existing code base;
  5. recognizing the ethical, legal and social implications of computing.

Course Deliverables and Assessment Methods

Students are graded based on

  • participation (10%),
  • homework (10%),
  • contributions to open source projects (40%),
  • several mini-exams (40%).

The types of graded activities are

  • Weekly blog posts. Students are required to make weekly blog posts containing answers to posed questions and reflections about readings and invited speakers. Counts towards homework.
  • Participation in class discussions. Students are expected to actively participate in class discussions about assigned readings, course activities, invited speakers' lectures, etc. Counts towards participation.
  • Small individual contributions. Students are expected to make a total of 20 small individual contributions. These include (but are not limited to) course website contributions, Wikipedia (and other Wiki projects) contributions, OpenMaps contributions, etc. The contributions to code projects can be in the form of comments on existing issues, reporting new issues, documentation edits, code fixes to reported issues. Counts towards contributions to open source projects.
  • Team project contributions. Students spend the last 6 weeks of the semester working on a team projects. Their individual contributions to the team effort count towards their own grade. Counts towards contributions to open source projects.
  • Mini-exams. Students are given several 20 minute long mini-exams during the semester. Counts towards the mini-exams.

Course Outline and Materials

Course outlines:

Course materials (slides, activities, and sample assessments) are available at OSSD materials repository. This repository evolves as we make modifications to the course.

Experiences and Assessment

No formal pre- or post-surveys were performed in this course.

This section is based on personal reports by students made during workshop days and final presentations, and on students' success in making contributions.


Student Expectations and Experiences

Creating an open source project vs. working on an existing project
One of the major objectives of this course is to give students the experience of working on a large third party software base and interact with the community that maintains the project. Some students come into this course hoping that they can create their own open source project and are disappointed when they learn this is not the case. The reasons they cite for wanting to work on their own project are: 1) being in charge of all the code, 2) creating a large project that can be included in their portfolio, 3) not wanting to deal with existing communities. Most realize the benefits of working on an existing project after the initial discussion, but not all.

Selecting large cool and fast-moving project to work on
When students select projects to work on, they often start with the large popular projects that are widely used. There are two reasons for this: 1) students are familiar with those projects, 2) students view those projects as prestigious and contributions made to such projects seem more significant. Large active projects have their benefits for first contributors, but they also have some major drawbacks. Such projects usually have very active communities and it is relatively easy for the students to get responses. On the other hand, the very active community also implies that many issues (especially the easier ones) get resolved quickly leaving students with not much choice of the issues to work on. In the past, several student groups realized that picking such a project was a mistake and they would have had a much easier time working on a project if they picked one that is smaller and not as fast-paced.

Large vs. small contributions
Most students have high expectations of what they will be able to accomplish when they start the class. They expect to be able to make significant code contributions (i.e., implementing a new feature or adding something that involves on the order of hundreds of lines of code). They do not see much value in smaller code contributions, in contributions to documentation or in bug gardening (commenting on the existing issue). Students tend to get frustrated with the small contributions and need regular reassurance and reminders about the importance of such contributions. Some open source communities are very good at stating appreciation for all contributions when they are merged, but that is not always the case.

Interacting with the community
Interacting with communities of other developers who are not just other students is one of the largest challenges for students in the class. Many groups attempt to actually solve the problems before they reach out to the project communities rather than trying to get feedback and advice from the more experienced developers or people more familiar with the project in advance. This is somewhat to be expected, but instructors need to constantly remind students about the importance and necessity of reaching out to the community before spending any significant amount of time on solving issues. Ultimately, most student groups report on successful communication and positive experience with the project community. Many of them mention that, in retrospect, they wish they had reached out to the community sooner.

Changing projects
At the start of the semester, students perform a project evaluation exercises for several different projects. The goal of these exercises is to develop skills that allow students to recognize projects that 1) are suitable for contributions made by first-time developers, 2) have an active community, 3) have enough of issues appropriate to the students' level, etc. Unfortunately, an evaluation is a fairly passive activity and even students sometimes try to get involved in projects that turn out to be inappropriate for one reason or another. Some groups decide to change the project after they have invested some time into it. This may be a good idea or a bad idea and the instructors should be involved in making such a decision. In some cases, students might be simply overwhelmed by the initial steps and hope to change to something that may seem more beginner-friendly (although, there is never a guarantee that this will be the case). In other cases, the response (or lack of it) from the community or difficulty with installing a development environment might be clear indicators that students will not be able to succeed and they should not be spending more time on such a project.


Students' Success/Failure

Students work in groups of 2-5 for the last several weeks of the semester with the goal of contributing to a single existing open source project. In the past two semesters, almost all groups were able to make accepted contributions to those projects.

In the first offering of this course, there were eight student groups working on eight different projects. Seven of those groups were able to make contributions to open source projects. One group chose to work on a plugin for an application that was not completed by the time the semester ended. One of the groups that made contributions did not have those contributions merged into the actual project by the time the semester concluded. One group changed the project after the initial attempt of reaching out to the community of their first-choice project; another group changed their project after a couple of weeks of unsuccessful attempts at working with the code base.

In the second offering of this course, there were eleven student groups working on ten different projects (two groups worked on the same project but independent of one another). All groups were able to make contributions to the projects. Several groups worked on writing documentation and translations for the projects that they were involved with. Students from one group were asked to join the maintainers for the project on which they were working. Two groups considered changing the project after some initial unsuccessful attempts, but eventually stayed with their initial project and were able to contribute to it.

Notes to Instructor

This course has been offered twice so far. It is continually revised as we learn new things about best practices for teaching open source software development. The major challenge is in finding the balance in how much we need to teach the students before they can start attempting to contribute to the existing open source projects. The current belief of the instructor is that students can learn a lot about communities and structures of projects that they are interested in right from the start of the semester. They can also make meaningful contributions that bust their morale and provide the introduction to open source contributions without spending many weeks learning the basics. This technical material can be introduced in parallel to students' immersion into an actual project.

Feel free to contact me with any questions regarding the materials and the structure of this course.

License

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

CC license.png .

Materials linked to by this page may be governed by other licenses.

Retrieved from "http://foss2serve.org/index.php?title=Open_Source_Software_Development,_NYU,_Klukowska&oldid=13712"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox