commit 0a3a035cc794a63af63c86c0c68decfdb2d808f2 Author: Mark Claypool <claypool@cs.wpi.edu> Date: Mon Aug 8 13:58:58 2022 -0400 Updates diff --git a/writing-full.md b/writing-full.md index fc48692..8c69cf5 100644 --- a/writing-full.md +++ b/writing-full.md @@ -1,14 +1,17 @@ -# Project General Writing Guidelines - -v3.2 - -**Audience**: The target audience for your report is a future project -group of students. Thus, they are WPI students, well trained in many -of the same skills your peer have, Internet and tech savvy, but not -familiar with your project specifics and probably not familiar with -your project tools. Think of this another way - what would you needed -someone to tell *you* before you started your project in order to -understand what you ended up doing. +--- +pagetitle: General Writing +version: 3.4 +--- + +# General Writing + +**Audience**: Know your audience. The target audience for your report +is a future project group of students. Thus, they are WPI students, +well trained in many of the same skills your peer have, Internet and +tech savvy, but not familiar with your project specifics and probably +not familiar with your project tools. Think of this another way - what +would you needed someone to tell *you* before you started your project +in order to understand what you ended up doing. **Abstract**: Abstracts the whole paper in one paragraph. (See one pager) commit d4128661ee0785908dc7548a8b4ee9b53509e7fe Author: Mark Claypool <claypool@cs.wpi.edu> Date: Tue Feb 25 06:22:58 2020 -0500 Updates diff --git a/writing-full.md b/writing-full.md index 4ddd31a..fc48692 100644 --- a/writing-full.md +++ b/writing-full.md @@ -1,10 +1,10 @@ # Project General Writing Guidelines -v3.1 +v3.2 -**Audience**: The target audience for your MQP is a future MQP group. -Thus, they are WPI Computer-Science seniors, well trained in many -computer skills and familiar with many Internet technologies, but not +**Audience**: The target audience for your report is a future project +group of students. Thus, they are WPI students, well trained in many +of the same skills your peer have, Internet and tech savvy, but not familiar with your project specifics and probably not familiar with your project tools. Think of this another way - what would you needed someone to tell *you* before you started your project in order to commit 385f82b8934327afa719a97fb9e7900893906afc Author: Mark Claypool <claypool@cs.wpi.edu> Date: Wed Sep 25 14:28:05 2019 -0400 Updates diff --git a/writing-full.md b/writing-full.md index 11fd29a..4ddd31a 100644 --- a/writing-full.md +++ b/writing-full.md @@ -1,6 +1,6 @@ -# MQP Project General Writing Guidelines +# Project General Writing Guidelines -v3.0 +v3.1 **Audience**: The target audience for your MQP is a future MQP group. Thus, they are WPI Computer-Science seniors, well trained in many commit c5850b62b1f29e6f4a0d1405bf38d77edc4ed15d Author: Mark Claypool <claypool@cs.wpi.edu> Date: Wed May 1 06:40:12 2019 -0400 Updates diff --git a/writing-full.md b/writing-full.md index 3ec75bb..11fd29a 100644 --- a/writing-full.md +++ b/writing-full.md @@ -1,4 +1,6 @@ -# MQP General Writing Guidelines (v2.2) +# MQP Project General Writing Guidelines + +v3.0 **Audience**: The target audience for your MQP is a future MQP group. Thus, they are WPI Computer-Science seniors, well trained in many @@ -8,36 +10,22 @@ your project tools. Think of this another way - what would you needed someone to tell *you* before you started your project in order to understand what you ended up doing. -**Abstract**: Astracts the whole report, meaning it provides a broad -statement, narrows to the problem, mentions the problem, describes the -approach, describes the solution and summarizes. Roughly, 1-2 -sentences for each. While the e-Projects system will limit the number -of characters to 800 (so it will fit on a transcript), the abstract -for the report document can and should be longer. +**Abstract**: Abstracts the whole paper in one paragraph. +(See one pager) *Tip*: Typically, this will be written last. -**Introduction**: Provide context and motivate your work. Give clear -description of the problem and background necessary to fully -understand the problem. Consider using high level examples or -scenarios to make the problem crystal clear. Part of of the -introduction should be titled "The Goal of this MQP:". Present a -bulleted list of specific MQP goals/research questions. +**Introduction**: Introduces the problem, but also excerpts the +approach and results. (See one-pager) *Tip*: Typically, this chapter will be written last. **Background**: Technologies relevant to your MQP that you want to provide details on so a reader will understand your -approach/methodology. - -**Related Work**: What have other people done to tackle this -problem. Describe entire systems that try to solve the problem or -specific algorithms proposed to solve the main parts of the -problem. Is your approach similar/different to them? How? +approach/methodology. (See one-pager) -*Important*: The reader should be told *how* each section/subsection -in Background and Related work is related to the project. This can -be brief, but needs to be explicitly called out. +**Related Work**: What have other people learned/done to tackle this +problem. (See one pager) *Tip*: Background and Related Work may sometimes be combined into one chapter, depending upon the project and focus. @@ -81,15 +69,10 @@ from the graph. **Discussion**: What did you learn from your results, implications and take-aways of your main results. Also discuss limitations, bugs, etc. -*Note*: This section is not always included. - -**Conclusion and Future Work**: Revisit the main motivation and problem -statement and conclude if the problem was "solved". Should also -summarize your main achievements/contributions Future work should -briefly (1 pgraph per idea) what could be done next (e.g., a -follow-on MQP). +*Note*: This section is not always included in a report. -**References**: Include full bibliographic information. For -Web pages, include as much information as possible: author, -title, date accessed... +**Conclusion and Future Work**: Revisit the main motivation and +problem statement and conclude if the problem was "solved". (See +one-pagers.) +**References**: Include full bibliographic information. (See one pager) commit b79bb200fda9bfb225e95d36cb5a1dfc6bfc9f46 Author: Mark Claypool <claypool@cs.wpi.edu> Date: Sat Feb 24 09:05:55 2018 -0500 Updated, and started Back/RW diff --git a/writing-full.md b/writing-full.md index eb3e745..3ec75bb 100644 --- a/writing-full.md +++ b/writing-full.md @@ -1,4 +1,4 @@ -# MQP General Writing Guidelines (v2.1) +# MQP General Writing Guidelines (v2.2) **Audience**: The target audience for your MQP is a future MQP group. Thus, they are WPI Computer-Science seniors, well trained in many @@ -37,7 +37,7 @@ problem. Is your approach similar/different to them? How? *Important*: The reader should be told *how* each section/subsection in Background and Related work is related to the project. This can -be brief, but needs to be explicit called out. +be brief, but needs to be explicitly called out. *Tip*: Background and Related Work may sometimes be combined into one chapter, depending upon the project and focus. commit f3a04665538c8b2e78a4ee246d7f16bbc86f741f Author: Mark Claypool <claypool@cs.wpi.edu> Date: Fri Feb 16 12:45:02 2018 -0500 Updated writing diff --git a/writing-full.md b/writing-full.md new file mode 100644 index 0000000..eb3e745 --- /dev/null +++ b/writing-full.md @@ -0,0 +1,95 @@ +# MQP General Writing Guidelines (v2.1) + +**Audience**: The target audience for your MQP is a future MQP group. +Thus, they are WPI Computer-Science seniors, well trained in many +computer skills and familiar with many Internet technologies, but not +familiar with your project specifics and probably not familiar with +your project tools. Think of this another way - what would you needed +someone to tell *you* before you started your project in order to +understand what you ended up doing. + +**Abstract**: Astracts the whole report, meaning it provides a broad +statement, narrows to the problem, mentions the problem, describes the +approach, describes the solution and summarizes. Roughly, 1-2 +sentences for each. While the e-Projects system will limit the number +of characters to 800 (so it will fit on a transcript), the abstract +for the report document can and should be longer. + +*Tip*: Typically, this will be written last. + +**Introduction**: Provide context and motivate your work. Give clear +description of the problem and background necessary to fully +understand the problem. Consider using high level examples or +scenarios to make the problem crystal clear. Part of of the +introduction should be titled "The Goal of this MQP:". Present a +bulleted list of specific MQP goals/research questions. + +*Tip*: Typically, this chapter will be written last. + +**Background**: Technologies relevant to your MQP that you want to +provide details on so a reader will understand your +approach/methodology. + +**Related Work**: What have other people done to tackle this +problem. Describe entire systems that try to solve the problem or +specific algorithms proposed to solve the main parts of the +problem. Is your approach similar/different to them? How? + +*Important*: The reader should be told *how* each section/subsection +in Background and Related work is related to the project. This can +be brief, but needs to be explicit called out. + +*Tip*: Background and Related Work may sometimes be combined into +one chapter, depending upon the project and focus. + +*Tip*: These chapters are often written first. + +**Methodology (and Architecture)**: An outline of your solution and +system diagram if you are building a system. Describe the process +used to address the problem. State assumptions if any of your +solution, talk about how you will evaluate your solution (e.g +simulation, etc). If your work is experimental, present your +hypothesis which your experiments will prove or disprove. + +*Tip*: Figures of architecture and process are often illustrative +and make it easier to write the document. + +**Implementation**: This section is necessary only if you designed a +system architecture above. You should talk about what languages, +technology, you used and how you brought it together to solve the +problem. This section should contain details that would allow a +reader to implement a similar system if they wanted to. + +**Experiments/Evaluation**: Describe means used to evaluate the +solution, often through experiments for a scientific contribution. +Experimental design, including setup (hardware and software), +independent variables (those that you will vary), dependent variables +(those you will measure). Include experimental conditions and tools +used. Should also include design rationale (why specific aspects were +chosen), for any system assumptions in setup. + +**Results**: Present sample screen shots, performance tables of +results and graphs produced while evaluating your +system. e.g. performance numbers. If you have specific design or +simulation assumptions state them before presenting your results. For +all graphs presented, provide a descriptive caption, a figure number +and refer to the figure number in the text. Graphs need to be +described, telling the ready what the axes and trendlines/data points +are. Especially important is the message the reader should take away +from the graph. + +**Discussion**: What did you learn from your results, implications and +take-aways of your main results. Also discuss limitations, bugs, etc. + +*Note*: This section is not always included. + +**Conclusion and Future Work**: Revisit the main motivation and problem +statement and conclude if the problem was "solved". Should also +summarize your main achievements/contributions Future work should +briefly (1 pgraph per idea) what could be done next (e.g., a +follow-on MQP). + +**References**: Include full bibliographic information. For +Web pages, include as much information as possible: author, +title, date accessed... +