Osredocs | UCSC OSPO

General AI Use Policy for Contributions to OSRE Affiliated Projects

Sat, 28 Feb 2026 00:00:00 +0000

Note that individual projects and mentor teams may have their own policy with regards to AI tools that go beyond the expectations set below. When in conflict, project specific policies supersede these general OSRE guidelines.

While the administrators of the OSRE permit some use of AI/ML tools that help contributors improve efficiency and productivity, we do not condone the use of these tools as a replacement for necessary technical skill, personal judgment, or individual accountability.

All contributors are fully responsible for each line of code or other contributions they make to one of our projects. Therefore, for all aspects of your contributions you must – without the assistance of AI – be able to:

Fully explain (including in live discussions with mentors) the process you took to make the contribution;
Defend the value and correctness of the contribution/code you submitted; and
Make modifications to the contribution based on critiques/feedback from the community.

If you are unable to confidently meet these three expectations then you should not be submitting the related code/contribution.

While AI can enhance your workflow, it should not be used to compensate for gaps in knowledge or experience. Evaluate all AI output for correctness, security, performance, and alignment with the project architecture. If you submit bad or sloppy work, that reflects poorly on you and could disqualify you from being considered for any of our mentorship programs.

Our mentors are committed to helping students and contributors who want to improve their skills – be respectful of their time and talents. DO NOT WASTE THEIR TIME by submitting sloppy or unreviewed AI outputs as your contribution. You are more likely to make a good impression with a mentor if you submit thoughtful and well reviewed submissions that relate to the project ideas they have posted about. Be thoughtful about all the PRs or other contributions you submit – is it really helping the project? Is it really showing your capabilities?

When submitting a proposal (including via GSoC), your full PR/contribution history will be evaluated to ensure that you have the technical expertise to complete your project. Using AI (or any other tools/cheats) to compensate for lack of necessary technical knowledge will result in your disqualification or removal from the program.

These guidelines were in part inspired by AI usage policy from our affiliated project PeerSky

How to add a new project idea to OSRE

Wed, 07 Feb 2024 00:00:00 +0000

Instructions for adding/updating a project

A project serves as the context for one or more project ideas. Each project is represented as a web page with project information and ideas. Projects and their updates are subject to review of the OSRE administrators.

Preferred method (via git):
- Fork git repository
- Create content/project/osre26/ORGANIZATION/PROJECTNAME directory or copy it from previous year’s content/project/osre25/ORGANIZATION/PROJECTNAME
- In that directory create/update index.md and the project’s image (featured.png or featured.jpg)
- In index.md fill in the frontmatter (see example):
  - Add the project’s title in title:,
  - Date the project entry with date: and lastmod:, using the format YYYY-MM-DD, e.g. 2026-05-27. Note that projects dated in the future will not display.
  - Include a list of authors:, using either names in quotes or user names (see below for instructions on how to add user names)
  - IMPORTANT: set a list of tags that include "osre26". Feel free to add additional tags.
  - Below the frontmatter start with a description of the project and include links to the project’s webpage.
  - Add each project idea with level-3 header, i.e., ### ... and add a list of essential information that includes topics, skills, difficulty, size (175 vs 350 hours), and mentors.
  - Every mentor should at least have a mailto: link. Better yet: add the mentor using the instructions below and use the shortcut {{% mention "USERNAME" %}}. There should be at least two mentors per project idea.
- Make a pull request and email OSRE Admins (currently: Stephanie Lieggi).

If you are unable to upload via git please email OSRE Admins (currently: Stephanie Lieggi) for other options

Instructions for adding a mentor

Mentors are welcome to add information about themselves (see example):

Preferred methond (via git):
- Fork git repository (or combine with pull request of adding/updating a project above)
- Create /content/authors/USERNAME directory.
- In that directory copy an _index.md file from another user and update it (see example)
  - Many icons are available (see documentation)
  - IMPORTANT: Under user_groups: add - University of California Mentors.
  - The short bio and any other information goes below the frontmatter.
- Make a pull request and email OSRE Admins
Or email OSRE Admins
- Include name, title, affiliations, email, short bio, whether you are UC or Summer of Reproducibility mentor (or both), and, optionally, photo, web page and social media links.

FAQ for Mentors

Fri, 13 Jan 2023 00:00:00 +0000

What kind of projects are you accepting? Are there specific technologies or topics that you prefer?

The OSRE program supports projects in a wide range of open source communities and reproducibility efforts. We have no requirement for the type of technology or aspects of the project being worked on, so long as it is or ultimately will be part of an open source project or community.

For Summer of Reproducibility mentors: The SoR supports projects that focus on developing and using reproducible artifacts. Project ideas for the SoR program should steer students towards producing reproducibility artifacts for use by others and/or using artifacts to validate research results, evaluate/develop teaching tools for classrooms, and extend research insights. See the SoR program page to read more about these objectives. As with all OSRE projects, we do not require that SoR projects use any particular technology or platform. However, we encourage mentors to design projects that leverage public infrastructure and open source platforms (such as Chameleon Cloud and CloudLab) to exploit the availability of shared resources, which can lead to more robust reproducibility artifacts and usage. For example, Chameleon enhances experiment reproducibility by offering shared access to uniform hardware resources and enabling users to configure, deploy, and share experimental environments (with the Trovi service) through cloud-based tools. Additionally, Chameleon’s Jupyter Notebook integration supports the implementation, analysis, and visualization of experiments within a cohesive environment, significantly facilitating the packaging of experiments for repeatability and further research collaboration.

What is the process for becoming a mentor and submitting a project / project idea?

The program organizers invite potential mentors to post their project ideas directly onto the Project Ideas page so that interested student can review them. Project ideas do not have to be pre-screened by the OSRE/SoR organizers in order to be submitted. We will review your submission before uploading and let you know if we have any questions about your project idea or think the description could use any editing/additional information.

To add a project idea, please read the instructions for participating mentors. Mentors should use tags to associate with a particular year. More tags can be used to associate the project with a particular research area, e.g. AI, machine learning, chip design, storage systems, data science. We also ask all mentors to include their biosketch and headshot on the mentor page.

There is a mentor-only mailing list. Please write us an email if you want to be added to this list.

For new research groups wishing to join OSRE: just create one or more projects (see instructions).

What happens after a mentor submits a project idea and what criteria is used to determine which student projects get support for the summer?

Once we open the project ideas page up for review by potential students, interested students will begin reaching out to mentors with questions about the project and requests for review of their potential OSRE project. The proposal writing process is iterative and the mentor works closely with students as they formulate a proposal for their summer project based on the mentor’s project idea. The primary criteria for which student projects get picked for support is the extent to which the mentor and student appear to be a good fit. Mentors are ultimately responsible for choosing a student project that will be beneficial to their overall work. Other criteria we consider when evaluating projects include 1) whether a student projects will have a significant impact on the relevant open source or reproducibility project and 2) if all timelines and deliverables seem attainable. The importance of building and maintaining a diverse community is also an important goal of the OSRE, thus the inclusion of mentors and applicants from historically excluded groups will also be a consideration when selecting student projects.

Can students who currently work with a mentor be considered for support under the OSRE?

The OSRE program’s ability to support students work is based on participation in a number of programs in addition to Google Summer of Code. Each of those programs have different rules for those related to whehter current students can be supported with their funding. When OSRE projects are supported through the Google Summer of Code, student must be be new to the communities that they will work with over the summer. Students already working on those projects will therefore generally not be allowed to apply under the OSRE unless it fits to a program other than Google Summer of Code. If you have questions on this please contact the OSRE organizers.

How are selected students compensated for their summer work?

Selected students are provided a stipend for the summer. The amount of stipend they receive is based on the number of hours their project is expected to take. For example a full time project is considered to take approximately 350 hours over the course of the summer. A US-based undergraduate student will receive approximately $6000 over the course of the summer for a full time project. Note that the stipend rate for students is based on the location where they will be completing the work. OSRE uses the same rate as those for the Google Summer of Code contributors. Questions about stipends can be addressed to OSRE organizers.

Guidelines for Summer Students

Mon, 01 Jan 0001 00:00:00 +0000

AI USAGE POLICY

How to apply to the be a contributor in our summer programs

Take a look at the current year’s project ideas and refer to the timeline for exact dates.
Between late February and mid March, select projects of interest, contact mentor(s), and tell them your motivation and provide them with your relevant background/experience. You are strongly encouraged to apply to no more than two projects.
Join the slack channel for contributor applicants. You should contact the Organization Admins for access. Note that we will only review proposals of contributors who have also joined our slack channel by the deadline stated on the timeline. Use this time to also get to know the project to which you are applying and the members of the project community. You are highly encouraged to ask questions.
Be prepared to provide mentors with some examples of your technical knowledge as an initial step. For instance, mentors may ask you to carry out a technical test or show work you have done in the past to assess your knowledge. This is an important step for ensuring you are proposing something that is beneficial to you, the mentor and the community. We have opportunities for contributors with a wide range of skill levels, so do not worry about “passing” the test - just show what your skill levels are and areas you are interested to grow in.
Once you and the mentor have established your level of proficiency and how it fits within project ideas, you may receive feedback from the mentor on writing the proposal. Each mentor or mentor team will establish their own process for reviewing and commenting on the work of interested students. Note – DO NOT RELY ON AI TOOLS for your proposal writing or showing your competence. Mentors need to see your work in order to judge if you are a good fit and will be successful in your project. While you can utilize tools to refine you project if necessary YOU WILL BE EXPECTED TO BE ABLE TO EXPLAIN ANY AND ALL WORK THAT YOU PRESENT TO THE MENTORS and the application text must be your origianal work. We prohibit the use of AI tools for generating your project deliverables. Misuse of AI tools will be grounds from removal from the program.
Keep track of that year’s project deadlines. Proposal must be turned in on time and include:
- A detailed plan of work with an estimate of the time needed (typically 175 or 375 hours in total). See below for a suggested template.
- Well defined tasks and their objectives, list of deliverables
- Note: any committments that could impact the amount of time you can spend on the project.
- Submit via the GSoC portal
Mentors will provide a ranked list of proposals to Org Admins. Results are made public in early May.

IMPORTANT REQUIREMENT FOR ALL ACCEPTED PROPOSALS

Summer contributors will be required to provide short bi-weekly status updates. These will help the mentors and the Org Admins see that your project is on track. They are also meant to provide a basis for blog posts to be completed by the contributors and highlighted by the organization admins.

Mentors and Org Admins expect summer contributors to act professionally and respect the mentor’s time and efforts. As with any professional setting, it is the responsibility of the contributor/student to inform their mentor if they will be taking any vacations or if they have any other obligation that conflicts with the proposed workplan. Not informing the mentor of these conflicts can result in removal from the program.

Contributors will be expected to attend all-hands and other group meetings throughout the program. These meetings will be via zoom and held at various times of day to allow participation for a wide range of time zones.

Do not hesitate to contact Org Admins for further questions.

Suggested proposal template

In your proposal, be specific and make sure your mentor can see evidence that you will be able to succeed at your project.

Proposal title - Should give an indication of what your proposal is expecting to accomplish
Name of project mentor(s)
Contributor’s full name
Slack and github handles
Introduction
- Define the problem you are trying to solve
- Provide background about the current state of the problem
- Descrbe you solution
Project goals
- Project objectives: What do you expect to get from this project? How will the community benefit?
- Expected deliverables: What do you think the results will be from this proposal?
- Future work based on project (if applicable)
Implementation plan
- Project methodology: How will you work to meet your objectives? How will you interact with the mentor and other members of the relevant open source community?
- Describe the project’s technical elements
- Describe any challenges and proposed solutions
Project timeline
- Project plan and deliverables schedule.
- Total number of hours expected to need for project and number of weeks to complete.
- IMPORTANT – the timeline must specify any time conflicts that you anticipate during the program (ie conflicts due to travel, school, other activities.)
Biographical information
- Relevant experience and educational background
- Technical interests and strengths
- Contact information:
  - Required: your full name, email address, current affiliation (for instance, which school are you currently attending);
  - Required: Timezone you will reside in during program;
  - Optional: relevant blog or website URL; Linkedin profile; other social media links.