Changes

This course introduces students to the technological, social, and pragmatic aspects of developing open source software through direct involvement in the Mozilla projectlarge open source projects. 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.

* Use the communication modes particular to the open source world through participation in such things as GithubGitHub, mailing listsSlack, wikis, etc.

* Work collaboratively with fellow students and members of the Mozilla 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 Mozilla open source development community and codebaseits 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.

First, consider the typical rules around cheating and plagiarism. In this assignmentcourse, 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.

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 (ie.eg., 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.

* Be open to helping others and to being helped

* '''7560%''' - Project Deliverables (e.g., code, documentsPull Requests, documentation), marked in terms of quality, quantity, process, etc. Your project will be marked at four milestone releases, the number and values being:** '''1510%''' - [[OSD & DPS909 Fall 2020 - Release 0.1 |Release (Due 0.1]] due Fri Feb 3), Sept 25** '''20%''' - [[OSD & DPS909 Fall 2020 - Release 0.2 |Release (Due Fri Feb 24)0.2]] due Sat, Oct 31** '''2015%''' - [[OSD & DPS909 Fall 2020 - Release 0.3 |Release (Due 0.3]] due Fri Mar 24), Nov 20** '''2015%''' - [[OSD & DPS909 Fall 2020 - Release 0.4 |Release (Due Thurs April 13)0.4]] due Fri, Dec 11* '''2040%''' - Blog. You Labs: There will be marked on your blog's qualityapproximately 10 labs, depth of explanation, frequency of update, etceach worth 4%. You are expected to blog weekly throughout the course,  Students must satisfactorily complete all project deliverables and many labs will require you to write a blog post in order to submit them.* '''5%''' - At pass the end of the term, you will be marked on a class presentation in which you demo and discuss the work of your releasescourse.

* [[DPS909 & OSD600 Winter 2017Fall 2020]]- Weekly Course Notes and Links* [httphttps://zenitseneca-open-source.senecacslack.oncom Seneca Open Source Slack] - Our main communication platform is Slack. You can sign-up with your @myseneca.caemail address.* [https://~christelescope.cdot.tyler/planetsystems/ Telescope Open Source@Seneca PlanetBlog]- All student open source blogs are aggregated here in our custom blogging software