This page provides information about the Georgia Tech OMSCS CS6460 class on Educational Technology relevant only to the Fall 2015 semester. Note that this page is subject to change at any time.
The inaugural semester of the OMS CS6460 class will begin on August 17th. Below, find the course's calendar, grading criteria, and other information. For more complete information about the course's requirements and learning objectives, please see the general CS6460 page here.
To help with navigation, here are some of the links you'll be using frequently in this course:
Below is the calendar for the Fall 2015 OMS CS6460 class. Note that all due dates are Saturday at 11:59PMAnywhere on Earth time. We recommend changing your time zone in T-Square to show the due date in your local time. We know that OMS students generally do much of their work on weekends, and thus Sunday due dates are often preferred. We have chosen Saturday hoping to leverage that, actually: we hope that by having Sunday for peer review, you'll be able to receive feedback from both mentors and classmates more quickly after assignment submission.
|Week #||Week Of||Week's Goals||Deliverable||Due Date|
|1||8/16/2015||Acquiring Knowledge||Introductions, Start-of-Course Survey, Personal Statement||8/22/2015|
|2||8/23/2015||Acquiring Knowledge||Assignment 1, Peer Feedback||8/29/2015|
|3||8/30/2015||Acquiring Knowledge||Assignment 2, Peer Feedback||9/05/2015|
|4||9/06/2015||Acquiring Knowledge||Mini-Proposal, Peer Feedback||9/12/2015|
|5||9/13/2015||Demonstrating Mastery||Personal Question, Peer Feedback, Quarter-Course Survey||9/19/2015|
|6||9/20/2015||Proposing Projects||Proposal First Draft, Peer Feedback||9/26/2015|
|7||9/27/2015||Proposing Projects||Proposal Final Draft, Peer Feedback||10/03/2015|
|8||10/04/2015||Executing Projects||Weekly Status Check||10/10/2015|
|9||10/11/2015||Executing Projects||Weekly Status Check, Mid-Course Survey||10/17/2015|
|10||10/18/2015||Executing Projects||Progress Report, Weekly Status Check||10/24/2015|
|11||10/25/2015||Executing Projects||Weekly Status Check, Peer Feedback||10/31/2015|
|12||11/01/2015||Executing Projects||Weekly Status Check||11/07/2015|
|13||11/08/2015||Executing Projects||Trailer (Presentation), Weekly Status Check||11/14/2015|
|14||11/15/2015||Executing Projects||Weekly Status Check, Peer Feedback||11/21/2015|
|15||11/22/2015||Executing Projects||Weekly Status Check||11/28/2015|
|16||11/29/2015||Executing Projects||Project, Presentation, Paper||12/05/2015|
|17||12/06/2015||Delivering Projects||End-of-Course Survey, CIOS Survey, Peer Feedback||12/12/2015|
In most OMSCS courses, you have a set of videos you're expected to watch each week that create a natural pacing and routine to the class; these are similar to the lectures you would attend if you took the class in person. This course, however, has no such prescribed videos to watch each week. So, how are you supposed to know what to do each week?
Below is a roadmap for each week of the course. This roadmap should generally replace the typical lecture schedule you would have. Follow these steps to keep on pace with the course. Note that in general to these weekly milestones, you should be checking in on Piazza every day and with your mentor every few days. Make sure to ask either your classmates on Piazza or your mentor for help finding information, refining ideas, and making your way through this roadmap.
Below are the various assessments in this course, as well as the relative importance attached to each. Note that we expect all students in this course to enter with enthusiasm and an earnest desire to contribute to both the course and the field, not simply a desire to get a grade and move on. Additionally, we expect that the projects in the course will be extremely different, and it will not be possible to create any single rubric that can apply to every student's work.
As such, grading typically will be very general. We assess most assignments on a simple three-category scale: Does Not Meet Expectations (0 points), Meets Expectations (1 point), and Exceeds Expectations (2 points). Students that meet expectations on all assignments will receive As. Students that receive a lower mark on an early assignment will have the opportunity to revise and resubmit. Status checks later in the semester aim to ensure final projects will meet expectations as well. Students ultimately receiving one or more grades of '0' may receive a B or lower in the course (depending on the assignments).
Because the grading is very general, the percentages below do not correspond to a traditional mathematical representation of a final grade. Instead, they correspond to the relative importance of each assignment. For those desiring a more mathematical formula, a reasonable heuristic to assume would be that a final average of 1 or above will correspond to an A.
The first four weeks of the semester, you will complete four short (~500 word) written assignments: a Personal Statement, two Reflective Assignments, and a Mini-Proposal. These should reflect the progress you are making towards understanding a particular community and preparing to contribute to it, culminating in a high-level proposal of what you would like to work on in the remainder of the class.
Once you have explored and identified a general project area you would like to emphasize, your mentor will pose to you a targeted question about the chosen community. Your answer to this targeted question should reflect your understanding of the community, your ability to reason about the community, and your understanding of the broader issues facing the community.
After completing the first portion of the class, you will propose your project, either individually or in a group. You should lay out a broad description of the motivating principles and objectives of the project, a clear statement of what work will be done, a week-by-week plan for completing that work (including separating individuals' responsibilities in the case of group projects), and a description of the ultimate contribution that will be delivered. Your mentor will then work with you to scope your proposal, address any potential issues, ensure the feasibility of the project plan, and ultimately approve your proposal.
Each week, you will submit a short status check. If you are in a group, each member of the group will submit their own status check. The purpose of the status check is to ensure progress is being made on a weekly basis in accordance with the plan outlined in the proposal, to identify early on if group members are not fulfilling their roles, and to recover if unexpected obstacles arise.
One-third of the way into the project, you or your group will complete a slightly more extensive project progress report. The goal of this report is to demonstrate that real, identifiable, observable progress has been made. On this progress report, you will describe the work that has been done, as well as provide any artifacts that have been completed (code, designs, surveys, protocols, etc.). The purpose of this report is to ensure that the weekly status checks are not merely lip-service to progress, but represent actual work.
Two-thirds of the way into the project, you or your group will complete a short "trailer". This could be a video, a working demo, an interactive web page, or something else. The goal is to present and "tease" your project to the rest of the class, as a way of seeing and sharing progress. The goal here is also to solicit feedback from your classmates on your project progress, in order to potentially adjust or make any changes once there is enough of a project to solicit useful feedback. This could also be the foundation on which you build the final project presentation.
At the end of the semester, you or your group will deliver three things: the project itself, a presentation of the project, and a paper in the format most pertinent to your project. The nature of the deliverable will differ based on your project. If you do research, the deliverable will be the data and the analysis. If you create a tool, the deliverable will be the working tool itself. The presentation is meant to present the project to your classmates and, if you agree, to future students in the class. The paper is meant to present the project to potential conferences, journals, or investors, if you choose to use it that way.
Because this course is driven by the community of students, participation is required and assessed explicitly. Participation can come in many forms: interacting and posting on Piazza; contributing new articles and information to the class library; completing class surveys; completing Peer Feedback tasks; participating in conversations via other tools; and more. Generally, participation is simply anything you do to make the class better for everyone else. Note that when we evaluate participation, we never evaluate based solely on volume. We will never look directly at the number of times you post to Piazza, for example. Instead, for each student, we'll look to identify ways that they clearly improved the class. If we can identify ways the class was better because you were here, you will have fulfilled your participation score. We will also let you know during the semester if you are in danger of not fulfilling your participation obligation.
The following policies are binding for this course.
We have an incredible team of mentors helping out with this course. However, all our mentors are busy professionals with jobs, families, and OMS classes of their own. Each mentor will be assigned a group of roughly 15 students, and each mentor will be devoting a maximum of 10 hours per week to helping with this course. As such, each student should expect to effectively receive around 30 minutes of dedicated mentor time each week for the duration of the semester. This time includes time spent reading assignments and writing feedback. Additional time outside that 30 minutes may be spent giving feedback on Piazza or interacting in other ways, depending on the mentors' availability.
Because of this, we ask that you be respectful and efficient with mentors' time. Remember that live conversations generally take up more real-time commitment than asynchronous communications that can be squeezed in during short breaks or strange times. Work or family obligations may sometimes prevent mentors from responding within a couple days. We encourage you to ask your mentor for expectations on how quickly you might hear from them or when they are most available, but we ask that you be respectful and understanding about their limited availability. Finally, this is the first time this class is run: the mentors, the students, and the instructors are all learning about how this type of class will work. So, please be patient and understand that oftentimes, the mentors may be faced with responsibilities or expectations that they did not anticipate when they signed up.
Most importantly, note that with a few clearly-defined exceptions (providing the personal question, approving the project proposal), nothing you do in this class is dependent on the mentors. If absence of feedback or communication with your mentor becomes an issue, that should not be considered an excuse not to complete any assigned work. It may be taken under consideration with regard to the quality of your work, but waiting on feedback is not an excuse to fail to move forward.
Finally, there may be times when we need to shift mentors around. For example, if you get together with a few other students for a group project, we'll rearrange those partnerships so that one mentor can work with everyone on that project. Or, if a person's interests change and end up aligning very closely with a different mentor, we may move people around then as well. Finally, if drops or anything result in the load being very imbalanced between mentors, we may make switches then.
We don't anticipate issues here, but we believe it's better to set these expectations in advance than to have to write policies governing these things later.
You are responsible for knowing the following information:
Because T-Square announcements are emailed to you as well, you need only to check your Georgia Tech email once every 24 hours to remain up-to-date on new information during the semester. Georgia Tech generally recommends students to check their Georgia Tech email once every 24 hours. So, if an announcement or message is time sensitive, you will not be responsible for the contents of the announcement until 24 hours after it has been sent.
We generally prefer to handle communication via Piazza to help with collaboration amongst the teaching team, but we understand Piazza is not ideal for having information "pushed" to you. We may contact you via a private Piazza post instead of an email, but if we do so, we will choose to send email notifications immediately, bypassing your individual settings, in order to ensure you're alerted. As such, this type of communication will also fall under #4 above.
Note that in three semesters as a Georgia Tech instructor, I've encountered exactly one instance of a time-sensitive email; so, the 24-hour rule likely won't ever be relevant. As with other things, however, we believe it's better to be clear at the beginning rather than write policies later.
Note that this means you won't be responsible for knowing information communicated in several other methods we'll be using. You aren't responsible for knowing anything posted to Piazza that isn't linked from an official announcement. You aren't responsible for anything said in HipChat, Slack, or other third-party sites we may sometimes use to communicate with students. You don't need to worry about missing critical information so long as you keep up with your email and understand the documents on this wiki.
The student-driven and open-ended nature of this class means that deadlines are not quite as important here as they would be in other classes. However, deadlines and weekly routines help our mentors spend the majority of their time interacting with students and a minority handling administrative and organizational tasks. Therefore, we require that all work be delivered on time.
We have made the descriptions of all assignments available on the first day of class so that if there are expected interruptions (business trips, family vacations, etc.), you can complete the work ahead of time. In proposing your project, you are welcome to include external constraints in the planning process and build in time where you know you won't be able to work on your project.
Of course, emergencies (illness, family emergencies) will happen. In those instances, please contact the Dean of Students office here. The Dean of Students is equipped to verify emergencies and pass confirmation on to all your classes. For consistency, we ask all students to do this in the event of an emergency.
The primary objective of this class is to produce a contribution to the field of educational technology. As such, it is acceptable to leverage existing code, libraries, resources, and information to use as pieces for your projects, reflections, and presentations. After all, part of joining a research community is building on what the community has already produced.
However, it is critical that your contribution be evaluated on what you have contributed. As such, anything that is borrowed from existing resources must be cited. In all written work, such as reflections and final reports, sources should be cited in APA style. Please consult the Purdue OWL for information on when and how to cite sources in research. When in doubt, don't hesitate to ask!
Similarly, any resources used in the production of software tools should be cited as well. If you copy code to use within your project, cite the source of
the code in a comment alongside the copied code. Include a link to the original source of the code and clearly note where the copied code begins and ends
(for example, with
/* BEGIN CODE FROM (source link) */ before and
/* END CODE FROM (source link) */ after the copied code). Any
external libraries, images, or any other materials not created by you should be referenced either within the code (where possible) or in a README file
included with the deliverable.
As mentioned previously, this course is as much an experiment in educational technology as it is a class on educational technology. First, both because this class is experimental and because it is being offered for the first time, there are bound to be things that go wrong. We ask your patience and support as we figure things out, and we in return, we promise that we, too, will be fair and understanding, especially with anything that might impact your grade or performance in the class. Second, we want to consistently get feedback on how we can improve and expand the course for future iterations. You can take advantage of the feedback box on Piazza (especially if you want to gather input from others in the class), give us feedback on the surveys, or contact us directly via private Piazza messages.