Summer Code Sprint2015

Goal

The OWASP Summer Code Sprint 2015 is a program that aims to provide incentives to students to contribute to OWASP projects. By participating in the OWASP Summer Code Sprint a student can get real life experience while contributing to an open source project. A student that successfully completes the program will receive in total $1500.

Program details

Projects that are eligible: All code/tools projects. Documentation projects are excluded.

Duration: 2 months of full-time engagement.

How it works

Any code/tool project can participate in the OWASP Summer Code Sprint. Each project will be guided by an OWASP mentor. Students are graded by their University, based on success criteria identified at the beginning of the project.

Projects are focused on developing security tools. It is required that the code any student produces for those projects will be released as Open Source.

Note on language: English is required for code comments and documentation, but not for interactions between students and advisers. Advisers who speak the same language as their students are encouraged to interact in that language.

How you can participate

As a student:

1. Review the list of OWASP Projects currently participating in the OWASP Summer Code Sprint 2015.

2. Get in touch with the OWASP Project mentor of your choice.

3. Agree deliverables with OWASP mentor.

4. Work away during Summer 2015.

5. Rise to Open Source Development Glory :-)

(Students apply now!)Google form application link

As an OWASP Project Leader:

1. Edit this page adding your project and some proposed tasks as per the examples

2. Promote the initiative to your academic contacts

Timeplan

Phase 1: Proposals

Project leaders who want to include their project to the program should submit some initial proposal ideas on this page. These ideas serve as guidance to the students; they are things that project leaders would like to get done, like new features, improvements, etc.

Subsequently students are invited to submit detailed proposals that can (but do not necessarily have to) be based on these ideas. Students are strongly encouraged to engage with project leaders and each project's community (e.g. through the project's mailing list) in order to discuss the details of their proposal. Proposals should provide details about the implementation, time plan, milestones, etc.

Phase 2: Scoring of proposals

After the submission of proposals, project leaders and contributors/mentors are required to review the submitted proposals and score them (on a 1 to 5 scale). Each proposal should receive at least 3 assessments/scores from different mentors. Each mentor, contributor or leader can score only proposals for their OWN project. All assessments should provide justification. Reviewers are strongly encouraged to provide constructive comments for students so that they can improve in the future.

Project leaders are responsible to attract a sufficient number of volunteer mentors to score proposals and subsequently supervise those that will get selected.

Phase 3: Slot allocation.

When proposal scoring has been completed, each project leader requests a specific number of slots. This number should be based on: The number of truly outstanding proposals according to submitted scores. The importance of the proposal to the project's roadmap. The number of available mentors for the project. At least 2 mentors are needed for each proposal that gets accepted. If the total number of requested slots is less than or equal to the available number of slots, then all projects get the requested slots. If not, the following rules apply: All projects that have requested a slot get at least 1 slot, provided they have a high quality proposal and sufficient number of mentors. Two mentors are required per slot allocated to the project. The program's administrators get in touch with project leaders, especially those that have requested a large number of slots to receive additional feedback on the requested slots and explore any available possibilities for reducing the requested number of slots. A project leader might choose to donate one or more requested slots back to the pool so that other projects can get more slots. The program administrators can choose to initiate a public discussion between projects in need of more slots and projects that have requested a lot of slots in order to determine the best possible outcome for everyone. If all else fails, slots are equally allocated to projects, i.e. all projects get 1 slot; projects that have requested 2 or more slots get an extra slot if available; projects that have requested 3 or more slots get an extra slot if available, etc. When there are no more slots available for all projects that have requested them a draw is used to allocate the remaining slots.

In any case, the program's administrators should perform a final review of the selected proposals to ensure that they are of high quality. If concerns arise they should request additional information from project leaders.

Phase 4: Coding.

This is the main phase of the program. Students implement their proposal according to the submitted timeplan and under the supervision of their mentors.

Evaluations

In the middle of the coding period, mentors should submit an evaluation of their students to ensure that they are on track and provide some feedback both to OWASP and the students.

If no/little progress has been made up to this point, the mentors could decide to fail the student in which case the student does not receive money. If successful, OWASP will pay half the amount ($750). The final evaluations are submitted at the end of the coding period and the second installment ($750) is paid to the student if all agreed deliverables are met. If the student has failed to demonstrate progress during the second period, then the second installment will not be paid and the student will get only half of the amount.

Ideas

OWASP OWTF

Brief explanation:

Background problem to solve:

Expected results

You should be able to...

Prerequisites

OWASP Mentors