Proposal (Fall 2019)
The project proposal is effectively an agreement between you, your teammates (if you’re in a team), and your mentor regarding what you will do for the rest of the semester. You’ll submit a draft of your proposal, but there may be a bit of back-and-forth between you and your mentor to reach a proposal on which you can agree. This shouldn’t delay you from getting started with the work you propose for the first week or two.
Although there will still be weekly discussions and conversations about general EdTech topics on Piazza, the vast majority (>90%) of the time you spend in the class for the final ten weeks will be spent on the project. As such, projects should likely be scoped to demand ~100 hours of work from each individual (note that estimated numbers of hours to spend on each task in the Full Calendar). A single individual should propose a 100-hour project, while a team of five should propose a 500-hour project.
As part of your project, you’ll also deliver a number of related deliverables. You’ll submit:
- Five weekly status reports, detailing your progress the past week, the challenges you’ve encountered, and any revised expectations for the final project.
- Two intermediate milestones, such as video presentations or prototypes to solicit feedback from your classmates and mentor.
- A final paper and presentation, reporting on your project.
- The final project itself (such as the data and research methods for the research track, or the tool itself for the development track, or the course material for the content track).
You should make sure to include these deliverables in your proposal as well.
You do not need to wait until the proposal is accepted to begin work on your project. Some projects will actually need work to begin sooner. The proposal acceptance will check the scope of the overall deliverable, but it likely will not affect the fundamental design of the project, and so these foundational steps can be taken earlier.
Every proposal will be different. There is no one template outline that will apply to all proposals. However, there are sections that will be covered by every proposal, as well as sections that will be covered by any proposal in a particular track. This sample outline is meant as a starting point: if you have good reason, you can add other sections or remove some of these.
Your proposal should be approximately 6 pages long in JDF, excluding the task list described below. This is neither a minimum nor a maximum, but rather a heuristic to simply describe the level of depth we would like to see. Team proposals are expected to be a bit longer. Submit your proposal as a PDF.
Every proposal should start with a title and a list of team members.
Briefly introduce your topic. Your goal in the introduction is to set up a narrative for why your project is actually valuable.
- If you’re on the Development track, this would frame the problem, specifically referencing why it’s a problem and why existing solutions aren’t sufficient, in order to leave room for you to contribute something meaningful.
- If you’re on the Research track, this would frame the phenomenon or question, especially in terms of what data or results exist to show the phenomenon exists (or may exist).
- If you’re on the Content track, this would frame the content, why it is valuable to learn, and who may benefit from it.
Cover what others in the same area have done. This sets up the foundation for your work and tells the reader how what you will do is different from what is already out there, as well as how they should interpret the results of what they do in a broader context.
- If you’re on the Development track, this may mean other tools targeting the same area, although you’ll absolutely want to cover tools developed in both industry and academia. Academic tools tend to have more robust results published about their successes and failures.
- If you’re on the Research track, this would be the other findings that set up the value of your investigation, showing that your question is prompted by others’ work.
- If you’re on the Content track, this would cover either alternative material on the same content to show what will make yours different, or other content that you want to emulate if there is little to no content out there on your content area so far.
This is the crux of the proposal. What are you going to do? Your description of your proposed work should be detailed enough that you could hand this proposal to someone else and they may be able to implement it themselves. We would expect every proposal to have subsections to the proposed work, but what those subsections are will differ based on your project.
- If you’re on the Development track, this would describe the tool, including what it will look like, how the user will access it, what languages or libraries it will be build in, etc. You might also have a section on evaluating the tool.
- If you’re on the Research track, this would be the methodology of the study you would be doing, including your hypotheses, how you’ll gather your data (Surveys? Interviews? Observation? Log analysis?), and how you’ll analyze it (Quantitatively? Qualitatively?).
- If you’re on the Content track, this be what content you plan to produce, how it will be organized, what tools will be used to build and share it, and what pedagogical theories you will use in development (e.g. active learning, blended learning, etc.).
If you are working on a team, you should note throughout the proposed work who will be responsible for what general parts. You will go into more detail on this in the task list. You may also want to include fall-back plans for portions of the work that may be unpredictable: for example, what will you do if you cannot recruit enough participants for a study, or if you are unable to integrate a certain pair of tools?
As part of the project, you will produce two intermediate milestones, as well as the final project. Describe what these deliverables will be. Take a look at the course calendar to see when the intermediate deliverables are expected.
Second, describe what you expect to be in your final project deliverable. This could be code, data, artifacts, courseware, videos, etc.
At the conclusion of the proposal PDF, your proposal must have a task list. To create your task list:
- Download or make a copy of the task list template. Delete the sample tasks.
- Fill out the task list. You may add or remove rows as necessary. If you have multiple team members, you’ll definitely need to add rows.
- Make sure to set aside some time for preparing each milestone, the final paper, and the final presentation.
- Copy your task list into your proposal document.
We recommend using the task list to monitor your progress throughout the semester. Each week, you should re-outline the rest of the semester to ensure you and your mentor remain in sync about your progress and expected final project.
Complete your assignment using JDF, then save your submission as a PDF. Assignments should be submitted to the corresponding assignment submission page in Canvas. You should submit a single PDF for this assignment. This PDF will be ported over to Peer Feedback for peer review by your classmates. If your assignment involves things (like videos, working software prototypes, etc.) that cannot be provided in PDF, you should provide them separately (through OneDrive, Google Drive, Dropbox, etc.) and submit a PDF that links to or otherwise describes how to access that material.
If you are working on your project on a team, only one person needs to submit each assignment. Make sure to coordinate who is submitting each, however.
Late work is not accepted without advanced agreement except in cases of medical or family emergencies. In the case of such an emergency, please contact the Dean of Students.
As with all assignments in this class, this assignment will be graded on an 11-point scale (0 to 10), in accordance with the grading policy outlined in the syllabus. Note, however, that your proposal serves an additional purpose: it acts as an agreement between you and your mentor. The proposal is a set of work your mentor agrees would satisfy the requirements of the final project (assuming, of course, that the work is also done adequately well). As such, you should ensure that your mentor accepts your proposal as satisfactory. This may be stated by them explicitly in your mentor thread, or it can also be inferred from a proposal grade of 9 or 10.
As usual, if your deliverable receives below a 9, you may revise and resubmit it once within one week of receiving a grade.. Resubmissions may receive up to a 9. Note again, though, that this should not be used as an excuse to delay your work on your actual project. You should begin work on the project as proposed, and refine the plan in parallel if your proposal is not accepted initially.
If your proposal is not still not accepted after revision, or if you choose not to revise your proposal after learning that it was not accepted, you may still progress in the class; you do so, however, without the agreement that the work proposed will satisfy the final project’s requirements. We will still grade your final project the same way we would have otherwise; an accepted proposal simply provides the reassurance that the work you proposed will meet those requirements.
After submission, your assignment will be ported to Peer Feedback for review by your classmates. Grading is not the primary function of this peer review process; the primary function is simply to give you the opportunity to read and comment on your classmates’ ideas. All grades will come from the mentors alone.
You will typically be assigned four classmates to review. You receive 1.5 participation points for completing a peer review by the end of the day Thursday following the deadline; 1.0 for completing a peer review by the end of the day Sunday; and 0.5 for completing it after Sunday but before the end of the semester. For more details, see the participation policy.