Difference between revisions of "OSD700"
| (33 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| + | |||
=Open Source Project= | =Open Source Project= | ||
==[http://cs.senecac.on.ca/index.php?outline=OSD700 Subject Description]== | ==[http://cs.senecac.on.ca/index.php?outline=OSD700 Subject Description]== | ||
| − | This course builds on the skills and knowledge developed in [[ | + | This course builds on the skills and knowledge developed in [[OSD600]] by having students continue their work in open source contribution. Students should have an open source project/community to which they want to contribute. Through first-hand experience, students will learn what is necessary to take move from "good first bug" style contribution toward becoming a community member able to work on all manner of bugs, features, and other tasks. |
==Course Outcomes== | ==Course Outcomes== | ||
| Line 10: | Line 11: | ||
* work on a real world software project | * work on a real world software project | ||
| − | |||
* solve implementation problems by working with existing open source technical documentation and existing code | * solve implementation problems by working with existing open source technical documentation and existing code | ||
* work in a self-directed manner to plan and complete a major open source programming project | * work in a self-directed manner to plan and complete a major open source programming project | ||
| Line 18: | Line 18: | ||
* create appropriate technical and introductory documentation for a software product | * create appropriate technical and introductory documentation for a software product | ||
* devise and implement a QA and testing strategy in order to insure the quality of the software being produced | * devise and implement a QA and testing strategy in order to insure the quality of the software being produced | ||
| − | * apply the concepts, techniques and principles acquired in previous programming and open source courses to the programming of | + | * apply the concepts, techniques and principles acquired in previous programming and open source courses to the programming of an open source project |
* work within a community open source context, which means leveraging globally distributed tools and communication practices in order to include feedback in the development process | * work within a community open source context, which means leveraging globally distributed tools and communication practices in order to include feedback in the development process | ||
* participate in regular group meetings to review progress on the project | * participate in regular group meetings to review progress on the project | ||
| Line 25: | Line 25: | ||
==Major Project== | ==Major Project== | ||
| − | This is a project course, and the student’s mark will come from work done on a real open source project. The goal of this project is to get students to move beyond "learning" and "hacking" on a piece of open source software, and to focus on creating something of excellent quality. Furthermore, students will be expected to create something of value within the community. As was the case in [[ | + | This is a project course, and the student’s mark will come from work done on a real open source project. The goal of this project is to get students to move beyond "learning" and "hacking" on a piece of open source software, and to focus on creating something of excellent quality. Furthermore, students will be expected to create something of value within the community. As was the case in [[OSD600]], given the nature of the project, students will be expected to work using an open and transparent methodology, one which enables and encourages collaboration with the open source community. |
===Details=== | ===Details=== | ||
| − | * Each student | + | * Each student will focus on a particular project or community. Students who don't have an existing project/community, or who have a project of questionable value and potential, must work with their professor to find a suitable alternative quickly. |
| − | |||
* Students are expected to be self-directed and highly motivated. It is the responsibility of the student to make sure that projects move forward, and that external dependencies are resolved quickly (e.g., problems getting info from someone on-line). | * Students are expected to be self-directed and highly motivated. It is the responsibility of the student to make sure that projects move forward, and that external dependencies are resolved quickly (e.g., problems getting info from someone on-line). | ||
| − | |||
* Students will blog at least once per week. On your blog you should discuss the current iteration of your work, your thinking for future releases, and any interesting anecdotes or information about interactions with other people in the community. | * Students will blog at least once per week. On your blog you should discuss the current iteration of your work, your thinking for future releases, and any interesting anecdotes or information about interactions with other people in the community. | ||
| − | * | + | * Students will be required to lead regular demo and teaching presentations, both within the class, and also via online tools (blog, wiki, recordings, etc) |
==Intellectual Property== | ==Intellectual Property== | ||
| Line 44: | Line 42: | ||
Detailed grading information will be discussed later in the term. | Detailed grading information will be discussed later in the term. | ||
| − | * | + | * 80% - '''6 bi-weekly releases''' must be completed. Each release should correspond to a bug being fixed, a pull request being made, etc. You will be marked every two weeks as follows: |
| + | ** Pull Requests marked on code quality, ambition, process (e.g., did you do it vs. did they land it), completeness, professionalism, time management | ||
| + | ** Class Presentation: demos, status updates, teaching what you've been learning, etc. to be done in class and online | ||
| + | * 10% - class discussion, participation on Slack, feedback, and contributions to other students' demos, presentations, or bugs. | ||
| + | * 10% - managing the Telescope project: leading weekly triage and status meetings, overseeing issues and pull requests, helping to set priorities, co-ordination between developers, community management | ||
| − | + | ==Resources== | |
| − | * | + | * [[Winter 2020 DPS911 and OSD700 Resources]] |
| + | * [http://zenit.senecac.on.ca/~chris.tyler/planet/ Open Source@Seneca Planet] - soon to be replaced by Telescope! | ||
| + | * [https://seneca-open-source.slack.com #osd700-dps911 channel on our Slack] | ||
| − | == | + | ==Archives== |
| − | * [[Winter | + | * [[OSD700 Winter 2019]] |
| − | * [[Winter | + | * [[OSD700 Winter 2018]] |
| − | * [[ | + | * [[OSD700 Winter 2015]] |
| − | * [ | + | * [[OSD700 Winter 2014]] |
| + | * [[OSD700 Winter 2013]] | ||
| + | * [[OSD700 Winter 2010]] | ||
| + | * [[OSD700 Winter 2008]] | ||
| + | * [[OSD700 Winter 2009]] | ||
Latest revision as of 14:26, 6 January 2020
Contents
Open Source Project
Subject Description
This course builds on the skills and knowledge developed in OSD600 by having students continue their work in open source contribution. Students should have an open source project/community to which they want to contribute. Through first-hand experience, students will learn what is necessary to take move from "good first bug" style contribution toward becoming a community member able to work on all manner of bugs, features, and other tasks.
Course Outcomes
Upon successful completion of this subject students should be able to:
- work on a real world software project
- solve implementation problems by working with existing open source technical documentation and existing code
- work in a self-directed manner to plan and complete a major open source programming project
- create and post project planning and implementation information using on-line communication tools, for example: blogs, wikis
- develop and release software on a regular schedule
- use feedback gathered from school and community members to improve software
- create appropriate technical and introductory documentation for a software product
- devise and implement a QA and testing strategy in order to insure the quality of the software being produced
- apply the concepts, techniques and principles acquired in previous programming and open source courses to the programming of an open source project
- work within a community open source context, which means leveraging globally distributed tools and communication practices in order to include feedback in the development process
- participate in regular group meetings to review progress on the project
- create and give project demos, showing how the software works and where it is going in future releases
Major Project
This is a project course, and the student’s mark will come from work done on a real open source project. The goal of this project is to get students to move beyond "learning" and "hacking" on a piece of open source software, and to focus on creating something of excellent quality. Furthermore, students will be expected to create something of value within the community. As was the case in OSD600, given the nature of the project, students will be expected to work using an open and transparent methodology, one which enables and encourages collaboration with the open source community.
Details
- Each student will focus on a particular project or community. Students who don't have an existing project/community, or who have a project of questionable value and potential, must work with their professor to find a suitable alternative quickly.
- Students are expected to be self-directed and highly motivated. It is the responsibility of the student to make sure that projects move forward, and that external dependencies are resolved quickly (e.g., problems getting info from someone on-line).
- Students will blog at least once per week. On your blog you should discuss the current iteration of your work, your thinking for future releases, and any interesting anecdotes or information about interactions with other people in the community.
- Students will be required to lead regular demo and teaching presentations, both within the class, and also via online tools (blog, wiki, recordings, etc)
Intellectual Property
Given that this course is focused on open source development, all student work must be licensed using an appropriate open source license--probably the one used by the project of which your work is a part.
Grading
Detailed grading information will be discussed later in the term.
- 80% - 6 bi-weekly releases must be completed. Each release should correspond to a bug being fixed, a pull request being made, etc. You will be marked every two weeks as follows:
- Pull Requests marked on code quality, ambition, process (e.g., did you do it vs. did they land it), completeness, professionalism, time management
- Class Presentation: demos, status updates, teaching what you've been learning, etc. to be done in class and online
- 10% - class discussion, participation on Slack, feedback, and contributions to other students' demos, presentations, or bugs.
- 10% - managing the Telescope project: leading weekly triage and status meetings, overseeing issues and pull requests, helping to set priorities, co-ordination between developers, community management
Resources
- Winter 2020 DPS911 and OSD700 Resources
- Open Source@Seneca Planet - soon to be replaced by Telescope!
- #osd700-dps911 channel on our Slack
