We suggest that engineering should be viewed as an experimental process. It is not, of course, an experiment conducted solely in a laboratory under controlled conditions.
Rather, it is an experiment on a social scale involving human subjects. — Mike Martin and Roland Schinzinger
Submitting Work
All projects are expected to be completed by push
ing your code to the course Gitlab server by the end of the day given as the due date (i.e., 11:59:59pm).
- You will not "submit" projects as in other CompSci classes, instead you will be graded only on what is pushed on the
main
branch of your project's repository
- You are responsible for ensuring that all files are correctly pushed to the repository on time so we recommend you push code to your repository very regularly (at least daily) to avoid excuses such as "my computer crashed"
- All files must include your name
Projects
- Update APT System
- LLM Learning Assistant
- Update Online "Book"
- Final Project
Personal Essays
- Future of Duke
- Micro-credentials and Mastery
- EdTech Statement
Files to Submit
You should submit only
- code files
- data files (json, xml, or csv)
- text files (md or txt)
- image files (gif, jpg, or png)
- sound files (mp3, au, or wav)
Make sure to give credit where credit is due: all asset files (images, sounds, etc.) must
README
Each project must be in a separate folder that includes a README file (either plain text or Markdown) that includes:
- your name and Net ID
- date you started, date you finished, and an estimate of the number of hours worked on the project
- list of the students with whom you discussed the assignment
In accordance with the Collaboration Policy, you are expected to keep track of anyone with whom you have had a significant conversation about your work
- any books, papers, or online resources that you consulted
- any assets (code, images, or sounds) used including links to the original work
- how to run the program
- any data or resource files required by the project (including format of non-standard files)
- any information about using the program (e.g., required resource files, key inputs, interesting example data files, or Easter eggs)
- any known bugs, crashes, or problems with the project's functionality
- any noteworthy features (so we do not miss them in the grading)
- any decisions, assumptions, or responses to user feedback that impact the project's value
You will lose points on your assignment if it does not include a proper README file. Here is a template to get you started.
We would appreciate it if you also included your impressions of the assignment to help improve it in the future.