Requirements

To be eligible for credit toward the assignments for this course, projects must meet the following requirements:

Must be released under an OSI-approved license
Must be at least moderately complex, comprising multiple source code files and at least several KLOC.
Must be in keeping with OSU's student conduct policies and standards.
Your contribution and interactions with the project must follow the license and community standards set by the owner/creator.

We have also provided a page of Curated Projects for you to browse. All of the projects listed there are appropriate for the reports in this class. Please not that you are not limited to these projects—they are provided for your convenience and enrichment.

Finally, we recommend the Up for Grabs website: "a list of projects which have curated tasks specifically for new contributors". Projects are searchable by language and other features. Note that we do not have control over this site and so if you wish to use one for an assignment in this class you will have to check to be sure that it has an OSI license and is in keeping with OSU's community standards, etc.

KLOC

Thousands [K] of Lines of Code; the total count of lines of source code in a product. This is an umbrella term for both physical (literal) lines of code (excluding comments, generally) and logical lines of code (executable statements). See Here's how many millions of lines of code it takes to run different software.

There are many ways to count KLOC, but here's a quick-and-dirty way to get a ballpark: https://codetabs.com/count-loc/count-loc-online.html (enter just the Github username and project e.g. tensorflow/tensorflow).

Note that we do not specify an exact minimum number of lines of code because this isn't something we prioritize, nor indeed is the exact number very meaningful. The purpose of this requirement is to steer students away from choosing projects that are not robust enough for analysis or appropriate for college credit, such as random homework assignments that have been put on Github but aren't meant to underpin an OSS project community.

Examples of projects I would NOT recommend would be things like 2048, which is about 1 KLOC, or Hello-World. Although I am a fan of both of these projects, I think you can set your sights a bit higher than this. (Imagine yourself sitting in an interview and saying you spent a term adding a "Hello world" program to Github.) If you find a project that is highly appealing but you are worried it may be too small, feel free to ask any instructor, TA, or your discussion group for feedback.

Strategies

Here are a few ideas for choosing a project for each of the assignments.

Choose a product you use, are already familiar with, and would like to contribute to.
Choose a project that would be useful for your career path or that would make a good talking point in an interview.
Choose a large, complex, or young project that would be challenging.
Choose a simple project so that you can focus more on the assignment techniques (e.g. if you haven't taken 362 yet and are new to testing, you may want to choose a fairly small project for Assignment 3 so that you can spend more time learning about testing rather than becoming familiar with the project).

You may use the same project for all 4 assignments, but are not required to do so. Some students have found staying with one project throughout the term to be a very rewarding experience because it enabled them to dive deep and immerse themselves in the code over the whole 10-week term, an opportunity not afforded often in this program. Others switched projects several times and reported that this made the course feel more valuable as they were able to explore and compare different projects and come to appreciate the uniqueness of each one and note the differences in maturity and community practices.

Note that the best strategy will probably vary based on the assignment, your experience as a programmer and software developer, your current workload this term, and the courses you have completed already for this degree.

How To Find A Contribution

It's tough to dive right into a codebase, especially for a large project and if you don't have guidance from an existing developer. It takes significant experience to get the hang of it. To find a place to contribute to, here are some suggestions of steps to take first:

Read the documentation: Documentation can guide you through how everything is put together at a higher level and what functionality it has. Documentation itself can also be something to contribute to, especially with smaller projects that don't have much in terms of documentation.
Build and use the software -- This allows you to have a hands-on experience with the software. You could potentially make a change to the build process, find a bug for your particular environment that needs documentation and testing, or find something that's broken or you think can be improved in the software itself.
Walk Through The Software With A Debugger -- After building it, debug it. You might find something that needs fixing.
Browse The Testing Suite -- Many projects do not have a testing suite, but many larger ones do. You can see what they're testing and what kind of results they expect.
Make Diagrams Of Dependencies And Flow
Trace a specific feature, finding out how they are implemented and what files are used

These tasks may seem daunting, but it is normal to feel that way. For a larger project such as Firefox or Node, you simply will not know all the ins and outs immediately, or even over weeks of use and reading. What you can do, however, is become familiar with a few features, files, or libraries. Over time and with practice, you'll get better and faster at reading unfamiliar code.

Above all, remember that anything that improves the project is a good contribution. Bug reports, bug fixes, testing, writing new features, and revisions to documentation and processes are all contributions that improve the project. You also will not be graded on acceptance, rejection, or non-response to your contribution by the project maintainers, although their response should be documented in your report.

Resources

How to Contribute to Open Source