CSC630: The Open Source Movement // Assignments

Phillips Academy Andover  ▪  Winter 2018

Open Source Project

Metrics

• The rubric that I will use you assess your project will make the following considerations, in somewhat similar weight.

• Usefulness:

   Your library should consist code that other people want to utilize, improve upon, and learn from. Thus, it shouldn’t be the code that powers a web app or contain only a collection of creative text, because it is unlikely that such a repository will be of much use to anyone.

• Novelty:

   Does your project fill a hole in the software landscape? What are you trying to accomplish with this library, and how is it different from those repositories that accomplish similar tasks?

• Coherence/Organization:

   Does your repository contain all of the content typically associated with an open source project? Is it well-thought-out, with a coherent folder structure and understandable purpose and direction?

• Documentation:

   Can a new user of your library get up-to-speed quickly on how to use it? Does a potential contributor know how to effectively make a contribution?

• Completeness:

   Does the project feel like it is in a complete and functional state, even if there is a great deal of desired work for the future?

• Future:

  Do you have a desired future direction for your project? This can, of course, include primarily maintenance and implementation of relevant features corresponding to related work (for example, if you are making a library in Python, updating the codebase upon new releases of Python itself).

• Collaboration:

   If you received pull requests, do you address them? Do you help others contribute to your work, and do you encourage it both vocally (including in class as well as potentially online) and through your documentation?

• Community:

  Your work on others projects is also an important factor, especially (but not limited to) during “Other’s Project Week”.

Keep in Mind

• You have a limited amount of time to work on it: approximately 30 hours, provided you work effectively in class and for the amount of time outlined in the Blue Book for coursework. Thus, you should choose a task that can reach a complete state within that time. That doesn’t necessarily mean the entire life’s goal of the project has to be completed, but it does need to reach a usable state.
• Your library may, with approval from me, be built upon another library. For example, you could add a new feature to the Linux kernel, in theory, or to Mozilla Firefox, or even to another classmate’s project (hence a group project is possible, in a way. However, the core collection of features in your project will still be subject to the above, especially in terms of Novelty and Usefulness, but in terms of everything else as well. Thus, your library can be an entirely novel feature to an established open-source library, or it can be a group project with minimal overlap between student’s classwork.

Submissions

• Apart from the actual repository itself, on Github (including all issues and pull requests), I will also ask you to submit a short report describing each of the bullets in Metrics above. Tell me why you think you’ve accomplished what was asked of you in each category. Feel free to link to examples.

Daily Commits

• Each day that you work on the project, you should commit your work. I should be able to go back to a particular day’s work and see what you did that day. In order to facilitate this, your commit message at the end of each class period and/or evening work toward the project should contain the following header:
Daily Commit 01/21/2018
/* The actual commit message, including potentially things from
    previous commits during the day, to summarize the day. */