Difference between revisions of "DPS909"

From CDOT Wiki
Jump to: navigation, search
(Grading)
(Resources)
 
(38 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
=Topics in Open Source Development=
 
=Topics in Open Source Development=
  
==[http://cs.senecac.on.ca/index.php?outline=DPS909 Subject Description]==
+
==[http://www.senecacollege.ca/cgi-bin/subject?s1=DPS909 Subject Description]==
  
This course introduces students to the technological, social, and pragmatic aspects of developing open source software through direct involvement in the Mozilla project.  Students will learn to use the tools, techniques, and strategies of open source developers. This is a project-based programming course.  The Mozilla project has been chosen as an example  open source project because of its maturity, breadth and depth of technology, and strong community.
+
This course introduces students to the technological, social, and pragmatic aspects of developing open source software through direct involvement in large open source projects.  Students will learn to use the tools, techniques, and strategies of open source developers. This is a project-based programming course.
  
 
==Course Outcomes==
 
==Course Outcomes==
Line 11: Line 11:
 
* Describe the history and philosophy of an open source project
 
* Describe the history and philosophy of an open source project
 
* Choose between the various open source licenses understanding the implications for users, developers, and the software community in general
 
* Choose between the various open source licenses understanding the implications for users, developers, and the software community in general
* Use the communication modes particular to the open source world through participation in such things as mailing lists, IRC, wikis, etc.
+
* Use the communication modes particular to the open source world through participation in such things as GitHub, Slack, wikis, etc.
 
* Use the tools of open source development, for example: distributed revision control; documentation tools; automated build and test systems; debuggers; source code utilities; tracking systems; on-line resources, etc.
 
* Use the tools of open source development, for example: distributed revision control; documentation tools; automated build and test systems; debuggers; source code utilities; tracking systems; on-line resources, etc.
 
* Work with a pre-existing large source code base
 
* Work with a pre-existing large source code base
* Write software that integrates and interacts with existing open source systems (e.g., Firefox). For example: add-ons; bug fixes; new features; etc.
+
* Write software that integrates and interacts with existing open source systems. For example: add-ons; bug fixes; new features; etc.
* Work collaboratively with fellow students and members of the Mozilla community.
+
* Work collaboratively with fellow students and members of the open source community.
  
 
==Major Project==
 
==Major Project==
  
This is a project course, and the majority of each student’s mark will come from work done on a real development project. The primary goal of this project is to get students involved in the Mozilla development community and codebase. Through this experience students will learn about the processes, tools, and practices involved in developing software as part of a large open source community.
+
This is a project course, and the majority of each student’s mark will come from work done on a real development project. The primary goal of this project is to get students involved in the open source development community and its codebases. Through this experience students will learn about the processes, tools, and practices involved in developing software as part of a large open source community.  Students will also have the opportunity to contribute their own code to real-world software projects, thereby gaining important experience.
  
 
===Philosophy===
 
===Philosophy===
Line 25: Line 25:
 
Many of the practices inherent in open source development will seem to go against the structures often set in place for similar course work. For example, students are typically forbidden to collaborate with peers, to copy from the web, etc. However, these rules must be re-evaluated in the context of proper and pragmatic open source development practices.  
 
Many of the practices inherent in open source development will seem to go against the structures often set in place for similar course work. For example, students are typically forbidden to collaborate with peers, to copy from the web, etc. However, these rules must be re-evaluated in the context of proper and pragmatic open source development practices.  
  
First, consider the typical rules around cheating and plagiarism. In this assignment, students are encouraged to work within the set of best practices natural to open source development. Open source developers do not write from scratch what already exists and is freely available for use. Students should be thinking in terms of code reuse. It is acceptable for students to use code from other open source projects, so long as the license is amenable to the use.  
+
First, consider the typical rules around cheating and plagiarism. In this course, students are encouraged to work within the set of best practices natural to open source development. Open source developers do not write from scratch what already exists and is freely available for use. Students should be thinking in terms of code reuse. It is acceptable for students to use code from other open source projects, so long as the license is amenable to the use.  
  
 
Second, consider the typical restrictions on peer-collaboration. In this project students are encouraged to work together, to help one another, to look at each other's code, etc. Open source collaboration is about leveraging the collective knowledge of a community to help solve the problems of the individual.  
 
Second, consider the typical restrictions on peer-collaboration. In this project students are encouraged to work together, to help one another, to look at each other's code, etc. Open source collaboration is about leveraging the collective knowledge of a community to help solve the problems of the individual.  
  
Third, consider the sharp dividing line between student projects in most programming courses. For the most part, students are evaluated on their ability to do a particular project or to solve a particular problem on their own. The outcome is measured against peer outcomes. However, in this course students are not in competition with their peers; rather, they are all working on one large project (i.e., Mozilla) with many sub-projects within it. As a result, there is no clean line to divide one student’s work from another, or even student work from that of the open source community. This means that collaboration between students and even other members of the open source community is acceptable practice.  
+
Third, consider the sharp dividing line between student projects in most programming courses. For the most part, students are evaluated on their ability to do a particular project or to solve a particular problem on their own. The outcome is measured against peer outcomes. However, in this course students are not in competition with their peers; rather, they are all working on one large project (e.g., Mozilla) with many sub-projects within it. As a result, there is no clean line to divide one student’s work from another, or even student work from that of the open source community. This means that collaboration between students and even other members of the open source community is acceptable practice.  
  
 
To summarize, students should:  
 
To summarize, students should:  
Line 36: Line 36:
 
* Give others encouragement and credit when they offer help  
 
* Give others encouragement and credit when they offer help  
 
* Use existing open source code whenever possible  
 
* Use existing open source code whenever possible  
* Be open to helping others and to being helped  
+
* Be open to helping others and to being helped
 
 
===Details===
 
 
 
* Each student must actively and independently participate in the course open source project(s).  This means using IRC, mailing lists, wikis, filing bugs, following bugs, writing patches, doing reviews, etc.  Projects have been created in consultation with the Mozilla community, and students are not allowed to work on other projects (i.e., suggesting your own project will not be allowed).
 
* Students are expected to work both on their own, and as part of an active community, both with members of the class and the wider open source community.
 
* Update your blog at least once or more per week. Remember that the more you write, the easier it will be to get help from other people: it is easier for people to understand your question with supporting documentation on the web.
 
  
 
==Intellectual Property==
 
==Intellectual Property==
Line 48: Line 42:
 
Given that this course is focused on open source development, and given that students work on real open source codebases, all student work will become open source. The particular license used will be determined based on the particular project and open source project.
 
Given that this course is focused on open source development, and given that students work on real open source codebases, all student work will become open source. The particular license used will be determined based on the particular project and open source project.
  
Each student will be required to agree in writing regarding the open sourcing of their project work before it can be used or considered for grading.  Details will follow soon in class.
+
==Grading==
  
==Grading==
+
Detailed grading information will be discussed later in the term.  Below is a breakdown of how students will be graded, and [http://blog.humphd.org/vocamus-680/?p=680 this blog post] gives more details about the rationale:
  
Detailed grading information will be discussed later in the term. Below is a breakdown of how students will be graded, and [http://vocamus.net/dave/?p=680 this blog post] gives more details about the rationale:
+
* '''60%''' - Project Deliverables (e.g., code, Pull Requests, documentation), marked in terms of quality, quantity, process, etc.
 +
** '''10%''' - [[OSD & DPS909 Fall 2020 - Release 0.1|Release 0.1]] due Fri, Sept 25
 +
** '''20%''' - [[OSD & DPS909 Fall 2020 - Release 0.2|Release 0.2]] due Sat, Oct 31
 +
** '''15%''' - [[OSD & DPS909 Fall 2020 - Release 0.3|Release 0.3]] due Fri, Nov 20
 +
** '''15%''' - [[OSD & DPS909 Fall 2020 - Release 0.4|Release 0.4]] due Fri, Dec 11
 +
* '''40%''' - Labs: There will be approximately 10 labs, each worth 4%.
  
* '''75%''' - Project Deliverables (e.g., code, documents), marked in terms of quality, quantity, etc.  Your project will be marked at four milestone releases, the number and values being:
+
Students must satisfactorily complete all project deliverables and labs to pass the course.
** '''15%''' - 0.1 Release (Due Sept 26)
 
** '''20%''' - 0.2 Release (Due Oct 17)
 
** '''20%''' - 0.3 Release (Due Nov 14)
 
** '''20%''' - 0.4 Release (Due Dec 5)
 
* '''15%''' - Blog.  You will be marked on your blog's quality, depth of explanation, frequency of update, etc.  You are expected to blog weekly throughout the course.
 
* '''5%''' - FSOSS 2014 Report. You will be marked on a report that will be based on research and analysis you will do at [http://fsoss.ca FSOSS 2014].
 
* '''5%''' - [[2014 Open Source Project Case Study]]. You will be marked on a class presentation about an open source project you study, its community, code, and culture.
 
  
 
==Resources==
 
==Resources==
  
* [[DPS909 and OSD600 Fall 2014 Notes|Class Notes, links, and other info]]
+
* [[DPS909 & OSD600 Fall 2020]] - Weekly Course Notes and Links
* [[Fall 2014 Open Source Students]]
+
* [https://seneca-open-source.slack.com Seneca Open Source Slack] - Our main communication platform is Slack. You can sign-up with your @myseneca.ca email address.
* [http://github.com Github]
+
* [https://telescope.cdot.systems/ Telescope Open Source Blog] - All student open source blogs are aggregated here in our custom blogging software
* [[Git Cheatsheet and Gotchas]]
 
* [http://zenit.senecac.on.ca/~chris.tyler/planet/ Open Source@Seneca Planet]
 
* [http://planet.mozilla.org Planet Mozilla]
 
* [http://wiki.mozilla.org Mozilla Wiki]
 
* [https://developer.mozilla.org/en-US/ Mozilla Developer Network]
 
  
 
== Archives ==
 
== Archives ==
Line 84: Line 71:
 
* [[DPS909 Fall 2012|Fall 2012]]
 
* [[DPS909 Fall 2012|Fall 2012]]
 
* [[DPS909 Fall 2013|Fall 2013]]
 
* [[DPS909 Fall 2013|Fall 2013]]
 +
* [[DPS909 Fall 2015|Fall 2015]]
 +
* [[DPS909 Winter 2017|Winter 2017]]
 +
* [[DPS909 Fall 2017|Fall 2017]]
 +
* [[DPS909 Winter 2018|Winter 2018]]
 +
* [[DPS909 Fall 2018|Fall 2018]]
 +
* [[DPS909 Winter 2019|Winter 2019]]
 +
* [[DPS909 Fall 2019|Fall 2019]]
  
 
[[Category:DPS909]]
 
[[Category:DPS909]]

Latest revision as of 13:46, 9 September 2020

Topics in Open Source Development

Subject Description

This course introduces students to the technological, social, and pragmatic aspects of developing open source software through direct involvement in large open source projects. Students will learn to use the tools, techniques, and strategies of open source developers. This is a project-based programming course.

Course Outcomes

Upon successful completion of this course students should be able to:

  • Discuss the issues and currents in open source and open source development
  • Describe the history and philosophy of an open source project
  • Choose between the various open source licenses understanding the implications for users, developers, and the software community in general
  • Use the communication modes particular to the open source world through participation in such things as GitHub, Slack, wikis, etc.
  • Use the tools of open source development, for example: distributed revision control; documentation tools; automated build and test systems; debuggers; source code utilities; tracking systems; on-line resources, etc.
  • Work with a pre-existing large source code base
  • Write software that integrates and interacts with existing open source systems. For example: add-ons; bug fixes; new features; etc.
  • Work collaboratively with fellow students and members of the open source community.

Major Project

This is a project course, and the majority of each student’s mark will come from work done on a real development project. The primary goal of this project is to get students involved in the open source development community and its codebases. Through this experience students will learn about the processes, tools, and practices involved in developing software as part of a large open source community. Students will also have the opportunity to contribute their own code to real-world software projects, thereby gaining important experience.

Philosophy

Many of the practices inherent in open source development will seem to go against the structures often set in place for similar course work. For example, students are typically forbidden to collaborate with peers, to copy from the web, etc. However, these rules must be re-evaluated in the context of proper and pragmatic open source development practices.

First, consider the typical rules around cheating and plagiarism. In this course, students are encouraged to work within the set of best practices natural to open source development. Open source developers do not write from scratch what already exists and is freely available for use. Students should be thinking in terms of code reuse. It is acceptable for students to use code from other open source projects, so long as the license is amenable to the use.

Second, consider the typical restrictions on peer-collaboration. In this project students are encouraged to work together, to help one another, to look at each other's code, etc. Open source collaboration is about leveraging the collective knowledge of a community to help solve the problems of the individual.

Third, consider the sharp dividing line between student projects in most programming courses. For the most part, students are evaluated on their ability to do a particular project or to solve a particular problem on their own. The outcome is measured against peer outcomes. However, in this course students are not in competition with their peers; rather, they are all working on one large project (e.g., Mozilla) with many sub-projects within it. As a result, there is no clean line to divide one student’s work from another, or even student work from that of the open source community. This means that collaboration between students and even other members of the open source community is acceptable practice.

To summarize, students should:

  • Help each other, contribute to one another’s projects
  • Work with and within the open source community
  • Give others encouragement and credit when they offer help
  • Use existing open source code whenever possible
  • Be open to helping others and to being helped

Intellectual Property

Given that this course is focused on open source development, and given that students work on real open source codebases, all student work will become open source. The particular license used will be determined based on the particular project and open source project.

Grading

Detailed grading information will be discussed later in the term. Below is a breakdown of how students will be graded, and this blog post gives more details about the rationale:

  • 60% - Project Deliverables (e.g., code, Pull Requests, documentation), marked in terms of quality, quantity, process, etc.
  • 40% - Labs: There will be approximately 10 labs, each worth 4%.

Students must satisfactorily complete all project deliverables and labs to pass the course.

Resources

Archives