# Project-evidence checklist

Choose one piece of work you can explain completely. Label a tutorial, simulation, classroom exercise, independent project or professional engagement accurately.

## Define the work

Project and setting:

Intended user or audience:

Question or task:

Input and permission to use it:

What I personally produced:

What came from a collaborator, library or example:

## Explain one decision

Decision I made:

Alternative I considered:

Evidence for the choice:

How I checked the result:

An edge case or failed approach:

Feedback I received:

What I changed:

What the output does not establish:

## Make the handoff usable

| Check | Done or next action |
| --- | --- |
| A new reader can understand the purpose | |
| Instructions reproduce a small example | |
| Expected outputs and tests are visible | |
| Missing or rejected records are not silently hidden | |
| Completed features are separate from the roadmap | |
| Sources and contributors are credited | |
| No credentials, client data or private records are exposed | |
| Public sharing is permitted | |

## Turn the work into a truthful application example

Describe the task, your own action and the supported result. Do not turn a proposed change into a deployed result, a list of prospects into completed partnerships, or a program application into employment.

Draft example in your own words:

One follow-up question I should be able to answer:

One claim I removed because I could not support it:

Preparation examples are not confidential employer assessments. Follow the actual program's rules during applications and interviews.

Related guides:
https://internshipdeadlines.com/guides/google-summer-of-code-application-guide
https://internshipdeadlines.com/guides/mlh-fellowship-application-guide