Application {#intro}

This page describes the application process for nonprofits who have a project idea and are interested in having it become an SLP project. If you want to learn more about the SLP, see the various links to the right under the "slp pages" header.

Applications are currently closed. Applications open in the late spring (May or early June time frame), and are typically due by early to mid July.

 

Questions Posed {#questions}

Most of the questions are short-answer, and deal with contact information and other information about the nonprofit. We ask the operating budget so that we can get an idea for the size of the nonprofit.

There are a number of yes/no questions, to ensure that those applying understand the requirements for such a project. These requirements are described in more detail in the SLP: Nonprofits: Requirements section.

The mission statement is likely on the nonprofit's website, and can just be cut-and-pasted from there. The project description is described below.

Once you have completed the fields, hit submit! There is no way to resubmit an application that you have already submitted, but you can submit a second (or third) one; we'll only consider the last one submitted.

 

Project description {#description}

The project description is the heart of the application, and should describe the project as you envision it. This will likely take the most amount of time to complete. Please understand that we are not looking for a perfectly written project description! What we are looking for is to get an idea of what type of project you had in mind, and whether it would be a good fit for an SLP project.

You must have an idea for a project. It need not be fully fleshed out at this point, but it should be an idea for a software system that will help your nonprofit. You are supplying the vision and the concept; we'll handle the technical details. Thus, you have to the high-level view of what the software is to be.

The project will be undertaken by a group of 4th year computer science majors. They will all be technically savvy, but it may well be the case that none of them know your nonprofit or anything about the domain of your nonprofit. Thus, they will not be able to judge what you are looking for. To this extent, there will need to be specific requirements for the system (i.e., functions it must perform, etc.). These need not necessarily be in this application, but if not, then it must be clear that these requirements exist.

Certain types of project work better for SLP projects, and certain types of projects do not work well. Projects that duplicate existing technologies are not appropriate for SLP projects. One example of a project that would not work well is sharing documents: this is easier with one of the many free cloud-storage applications, such as Dropbox. Likewise, email lists are easily done through a number of online services that provide exactly that. Projects that do work well are ones that do not have an existing online solution, often because of the complexities of the individual nonprofit's situation. To get an idea of the types of projects that work well, you can see descriptions of all the old projects on the pages for the projects from the 2012-2013, 2013-2014, 2014-2015, and 2015-2016 academic years.

While everybody wants a pretty website, that is not really in the domain of computer science students. While some may be quite good at creating visually appealing websites, that is more formally in the domain of digital artists rather than computer science students. Likewise, adding written content to the website is more appropriate to be added by the nonprofit rather than the computer science students.

Complexity is a critical factor. A project cannot be too simple, and it cannot be too complex. Too little complexity means the project is not properly utilizing the students who are working on it. Too much complexity causes a project to be unable to be completed within the existing time frame (the academic year). Systems that require too many components (a web portal, an iPhone app, and an Android app) and also requires them to be polished is likely too complex. This is a delicate balance, and there is no perfect demarcation for what is too much complexity and what is too little. What you can do is list features that you must have for the system to be of use to you, and then list (in a prioritized order) additional features that you would like to have -- this allows for the complexity to be scaled appropriately.

We ask you to keep the project description down to about 200 words -- there are a couple of reasons for this. One is that we are going to have to read through a LOT of applications, and having many applications of great length will just slow down the process (not to mention rid us of our free time). Also, this application is meant as a first understanding of what the project could be -- it's not meant to be the final set of requirements of the project.

 

What happens next? {#after}

Once the application is submitted, we will take a look at it. We do not expect to be in contact with any nonprofits until well into August. If a project were to move forward, then there would need to be a meeting sometime in August or early September to narrow down the scope of the project, and list out the requirements in more detail.

Either way, we will be in touch with you. We want the SLP to succeed, and we are going to try to service as many nonprofits as we can.