Skip to content

Project 5A: Project and Task Selection

Deliverables

Project & Task Selection – 80 points – due Monday, April 17th, 11:59pm

Open Source Project Selection

You may select any active open source project in any language, as long as it's not already being selected on by another team. You can find a list of open source projects selected by other teams on the Public Project Selection Spreadsheet.

Here are some helpful resources for finding open source projects:

You may want to consider any open-source projects you have used before, or are interested in using in the future!

The open source project you pick should be active and have multiple contributors. Generally you want to pick projects that are quick at reviewing and accepting PRs from external contributors for a better chance of getting your bonus. Previous students have lamented choosing dead or maintenance projects without sufficient community support. Do not make this mistake.

If you have questions on if we would consider a project active, contact the course staff.

Once you have selected a project, add it to the Public Project Selection Spreadsheet.

Task Selection

For the rest of this assignment, we will refer to bug fixes and feature extensions as tasks.

You are free to chose any task(s) to complete for this assignment, as long as they:

  • Are taken from a bug report or feature request in a public database or message board. Do not invent a task. Address a documented project need.
  • Make changes to the project’s source code. Pure documentation or design tasks are not appropriate
  • Benefit from teamwork and are appropriate for your team size (i.e. do not select one small independent task per team member). You may choose one large task or several smaller, related tasks. The tasks should be scoped such that each team member spends one week of development effort

We expect students to actively communicate with the project owners the task you are trying to do via the owners' preferred methods of communication (GitHub comments, Discord server, etc) and follow the repository's issue assignment process(es). This will also ensure that they are more likely to accept your pull request(s) in the future.

If you have questions on these criteria, contact the course staff.

Task Planning

Once you have selected a project and task(s), break them down into subtasks, consider their priority and assign them to each team member. Identify a set of tasks as your core goal for this project, and another set of tasks as stretch goals.

You are expected to achieve your core goal for this project, and stretch goals as much as possible. We will work with you to adjust your goals during the check-in presentation to ensure that they are appropriate your team size and timeframe.

As per previous project, plan before you start coding. You should identify risks and requirements, and develop a collaboration plan and schedule.

Check-In Presentation (80 pts)

The recitation after Spring Carnival will be dedicated to an in-person group presentation about your project and task selection.

  • Presentations are 7 minutes long, with 3 minutes of feedback and Q&A
  • The order of presentations will be randomly determined
  • Participation from all team members during the presentation is required

Presentation Attendance

For full credit, you would have to be on time for the presentation session (within 5 minutes of recitation start time). If you are unable to attend in-person, you must

  • Send a Slack message to your TA with justifications at least 24 hours before the start of your recitation, else you will receive no credit for this part of the assignment, and
  • Pre-record your segment of the presentation, which your teammate will play during the presentation

Your group presentation will serve as a check-in to determine if the open source project and task(s) chosen were reasonable

Your 7-minute check-in presentation should include (the recommended slides amount is in parenthesis):

  1. Overview and Justification (~1 slide)
    An overview on the project you selected, summarizing the relevant characteristics you considered when making your selection. Beyond whatever additional information you collect in your research, include at least a name, a website link, and a brief description of the project (what it does, who uses it, etc).

  2. Successful Build (~1 slide)
    Evidence that you can build and run the software (e.g., a screenshot or text output from a successful build, a screenshot of the running program). Getting an open-source project to build/run can be a huge effort, and we want to mitigate this risk.

  3. Task(s) Description (~2-3 slides)

    • A brief textual description of your proposed change(s). In addition to your core task(s), you may choose to include a stretch task, depending on how difficult the changes end up being, you may not need to implement it. Note that if your actual changes deviate from the plan, we expect a short explanation with the final submission.
    • A justification as to why the task(s) benefit(s) from teamwork and are appropriate for your team size.

  4. Task Requests(s) (~1 slide)

    • Evidence that the task(s) is/are requested by the community (links suffices).
    • Evidence of communication with the project owners (e.g., a link to a discussion thread, a screenshot of a chat, etc).

  5. Subtasks & Assignments (~1 slide)
    A table to summarize for each subtask:

    • A description of each subtask
    • The priorities & justification of priorities of the subtasks (and if it's part of core goals or stretch goals)
    • An initial assignment of subtasks to team members.

  6. Schedule (~1 slide)
    A table to summarize the schedule for each team member, including:

    • The start and end date of each subtask
    • The number of hours each team member will spend on each subtask
    • The number of hours each team member will spend on the project in total

  7. Risk & Mitigation Strategies (~1 slide)
    A list of at least two relevant risks when it comes to working on the tasks in your selected open source project and corresponding mitigation strategies.

    • We expect you to identify risks that are specific to your project and team. For example, if you are working on a project that is written in a language that none of your team members have used before, you should identify this as a risk and discuss how you will mitigate it.
    • We will not accept risks that are generic to all open source projects (e.g., "the project may be abandoned"), or risks that are generic to all software development projects (e.g., "the project may have bugs").

Submit the presentation deck listed above as a single PDF file per team to Gradescope. You will be presenting this in the recitation after Spring Carnival.