Final Project Proposals
Due Date: Monday, May 5, @ 11:59PM
Your project team of four will be putting forward two separate proposals. We will evaluate both proposals in terms of feasibility and assign one as your team’s final project.
We do not require that you fully implement everything in your proposal in order to receive full credits for the group project, as sometimes certain features prove more difficult to implement/modify than originally thought as we dive deeper into the project.
Nonetheless, we highly encourage you to be more ambitious with your proposals. Remember that this is a month-long project for four engineers – Do not underestimate what can be achieved with that many engineering hours! We may reject project proposals that we deem lacking in complexity.
Motivating Your Project Idea
As you know, IDLE is a basic IDE primarily used by new programmers who are only learning to code. Therefore, it does not necessarily aim to have all the features that powerful IDEs include for experienced developers. Therefore, your project idea can be motivated by the educational value of IDLE. For example, you may look to add a feature to IDLE that aims to help novice programmers who are using it in their first programming class. Even if you do not consider an idea with an educational slant, you may motivate your proposal with impacts to developer productivity or well-being.
In short, please motivate your project proposal by relating it to some real world impact of the new feature, whether it is for students learning to program or developers being more productive.
A note about features that use LLMs (via API calls)
- It is okay to propose features that integrate LLMs with IDLE. However, one downside of these projects is that the projects depend on calls to external services (such as OpenAI’s API). It is okay to propose a feature that will make use of such services, but the overall feature should still require significant modification and extension of the idlelib codebase (rather than primarily consisting of calls to APIs).
Writing Your Project Proposals
Your proposals should have the following sections to receive full credits:
- Project title: A snappy title for your project.
- Team members: List all names, email addresses, and PIDs of your group members.
- Project summary: A brief description of what your project does.
- Project outline/Feasibility analysis: Provide a rough outline of your project timeline, as well as a basic analysis of what changes to which components will be involved, so that we have a good idea of the potential scope of your project.
- Checkpoint deliverables: There will be a checkpoint before the final due date (presentation) of your project. You should write down what you expect will be completed by each checkpoint.
Note that whatever feature you propose, you should endeavor to make it as full-fledged as possible. For example, the split screen feature would not be considered complete without the support of a series of convenient keyboard shortcuts and the ability to dynamically resize panels. Again, be ambitious with your proposals, and work hard to make it happen!
Example Project Ideas
Here are some example project ideas that the course staff have thought of. These are just examples to illustrate the approximate level of complexity that we expect from your project proposals.
I. Adding workspace support
In the current IDLE implementation, we can only open one Python file at a time, which makes editing multi-file code bases (even very small ones) rather inconvenient. We could try adding an option to “open a directory” like in VS Code, and have a file tree view for easy file navigation.
II. LLM features to explain code and error messages to students
Often times, students encounter error messages or code that they do not understand. A useful learning feature could allow students to see an explanation of an error message or highlighted code. This feature would likely require use of LLMs to generate explanations. You would want to consider how to display the explanations and how to embed the new feature within the IDLE code base.
III. Tracking values of variables
We could create a pop-up that can be invoked by the user that shows the values of different variables after execution of a piece of code. This could be extremely useful for a student that is trying to comprehend a piece of code.
IV. Miscellaneous Ideas
You may consider a wide range of project ideas. Feel free to propose projects related to the design and front-end of IDLE, the set of features available while programming, or anything else that you are able to motivate. Please don’t limit yourself to the few sample ideas listed here.
Submitting Your Proposals
We have created a new GitHub classroom assignment for the group project. Once you and your group members are ready, go ahead and accept the GitHub Classroom assignment.
Before your repository is generated, one of you needs to create a new group, after which the other members can locate and join that group. Feel free to choose a distinctive group name so that others don’t mistakenly join your group, and break the CS-people-can’t-name-things stereotype.
Click here for the GitHub Classroom assignment invitation.
To submit your two proposals, create two GitHub Issues in your group project repository, one for each proposal. The proposal contents should be written in the issue description. (Make it pretty with proper markdown usage!) You can also use the comment feature as a space to discuss your project proposals with your team members.
Grading
Make sure each of your two proposals contains, at a minimum, all the sections outlined earlier. Be as detailed and descriptive as you deem necessary to show us the estimated scope and complexity of your project ideas.
Your two proposals will be graded based on their quality. Therefore, you should spend some time to carefully investigate the existing code base once you have your initial ideas.
We have high expectations for your final projects, and we look forward to reading your proposals.
“Ugh, so much writing!” I hear you say. Welcome to the industry!