# Summer of Code: About Bevy!

As part of [Google Summer of Code](https://summerofcode.withgoogle.com/), the Bevy project / Foundation has been asked to provide some information.

We've replicated the questions (and their answers) here, for ease of collaboration, and to share our answers directly with the community and prospective students.

Editor's note: the forms that this information must be entired into do not use Markdown style linebreaks. As a result, we're using one line per paragraph in this document. I'm truly sorry.

## Organization Description

Bevy is an open source game engine, with a particular bent towards consistent user-friendly tools, modularity and innovation. This modularity means it's been used for everything from web-hosted jam games to high performance CAD software to fully produced indie games to scientific simulations.

Bevy is written in Rust, uses a unique ECS-centric (Entity-Component-System) architecture, and integrates with a modern cross-platform rendering framework, [`wgpu`](https://github.com/gfx-rs/wgpu). We aim to provide the tools that users expect to quickly develop games, offer the flexibility to customize the engine to fix unusual problems they encounter, and present them with shiny new toys to expand what they thought possible.

Our culture is unusually egalitarian and open, even among open source projects. We foster a sense of shared ownership, through distributed triage and planning, community code review, and a thriving, explicitly-valued ecosystem of projects, tools and learning material.

## Why does your oganization want to participate in Google Summer of Code?*

Bevy, culturally, cares a lot about mentorship and personal growth. Over the years, we've watched many contributors grow from beginners to experts, and are proud of both the personal and professional growth we've been able to support.

Blessed with nothing more than a computer, a desire to learn and a surfeit of free time, our unique community-review process has let hundreds of contributors organically mentor these juniors, teaching them about best practices in software engineering (tests! version control! docs!) as they grow a reputation of their own and learn to design and execute on increasingly ambitious designs.

One of our maintainers comes from exactly this background: starting with only basic scientific computing skills, struggling with illness and blossoming into a trusted, professional open source maintainer of one of the largest Rust open source communities. Open source doesn't care about your status, nationality or past: skill, compassion and hard work are enough to thrive.

We want to do more, but not all students thrive in a structureless setting, and even the free time to contribute to open source is a luxury. Google Summer of Code would give us the funding and framework needed to allow students to focus on learning these skills and making these connections, regardless of their personal circumstances.

## What would your organization consider to be a successful GSoC program?*

Bevy's success in the GSoC program will be primarily measured by the growth in its mentees, with progress on their chosen projects as a secondary goal. We expect students to come into the program with a good foundation of technical skills, although we expect a substantial ramp-up as they learn Bevy's codebase itself. As a result, we expect most of the growth to be in terms of the students' ability to design, communicate about and polish work to a professional standard.

Much of the work that we do at Bevy is fundamentally exploratory, experimental or open-ended in nature: user preferences, performance characteristics, and technical limitations are common. This is especially true for the proposed Summer of Code projects: while they are not all unusually challenging, we've biased our choices towards greenfield work, forming a working group around each student, to ensure that students spend less time waiting for feedback or dealing with merge conflicts, and have something of their own to show off at the end of their time with us.

While we hope that every project will result in a merged feature and a celebratory release note, we've done enough of this to know that no plan survives contact with reality. When setbacks inevitably strike, mentors and collaborators will be there to support them and teach them how to roll with the punches: analyze the failures without blaming individuals, tidy up loose ends, record your findings and formulate a new plan of attack.

Success comes when we can help our students grow: giving them the skills, confidence and love of open source that inspires them to keep contributing to open source (Bevy or otherwise) for years to come.

## How will you keep mentors engaged with their GSoC contributors?*

When selecting mentors, we are ensuring that each mentee has two mentors, screened by our maintainers to ensure that they are skilled, professional and engaged enough to be able to realistically dedicate the required time to mentorship.

We have made it clear to our mentors that we expect them to:

* Work with their mentee to develop a plan and rough timeline to ensure that the projects are well-scoped and planned out.
* Promptly review code and designs submitted by their mentees
* Appropriately commit time throughout the duration of GSoC to assisting and guiding their mentee(s)
* Raise any problems with maintainers and fellow mentors before they spiral out of control.

Each mentor is limited to two mentees, and each mentee will have two mentors, ensuring that they can give students the attention they need to thrive.

With that said, the overwhelming majority of our mentors are going to be volunteers. We do have a number of current contributors that work professionally with Bevy, and it may be in everyone's interest to discuss with their employers the prospect of dedicating some percentage of their work hours to mentorship. This can help ensure that mentors have the time and capacity to properly mentor their mentee(s) and incentivize them to make sure their mentee(s) are on track.

While each student will have two mentors for redundancy, in the event a mentor encounters unexpected problems, they will have access to a private channel with fellow mentors, Bevy maintainers and full-time Bevy Foundation employees. There, we will offer them advice, support and as a last resort, work to find replacements from our large and active community.

Most importantly though, mentors are not expected to guide and teach their mentees alone. Bevy's project management is centered around a limited number of temporary working groups, each targeting a specific set of new features, code cleanup, or refactors that we'd like to see implemented.

GSoC contributors are expected to form new working groups with their mentors, keeping them engaged with both their mentors and interested contributors as a whole.

## How will you keep GSoC contributors on schedule to complete their projects?*

At the start of their time with Bevy, potential GSoC contributors will be expected to work with their prospective mentors to complete a Proposal. For Bevy, this is a rough plan for their work, complete with background and motivation, broken down into discrete milestones with approximate timelines.

While we expect students to put in the honest work needed to get things done, deadlines ("target completion dates", in the lingo of GSoC) and estimates are inexact things at the best of times. Students (and their mentors) are expected to manage the scope of their project dynamically as it progresses: cutting back to the essentials as target completion dates draw near, or adding on nice-to-have features to fill extra time.

This plan will be iterated on as work progreses, tracked on via a project board, and coordinated in a working group. An incremental, collaborative process reduces the risk that students become overwhelmed, and lets us know quickly if things are going off the rails.

In addition to ongoing communication and review, mentors will be expected to check in weekly with their mentees to ensure that they're happy, motivated and functioning well.

## How will you get your GSoC contributors involved in your community during GSoC?*

Bevy is a thriving community, with over 20 thousand Discord members and hundreds of active contributors. It is a place to work and collaborate, but also a place to help each other, dream about ambitious projects, show off cool art you've made and socialize.

This also makes it a fairly unusual working environment, in ways that we have a duty to both disclose and screen for. Bevy is a casual and egalitarian environment that emphasizes organic collaboration, transparency, and a high standard of work. While this can be an incredible way to learn, students need to be prepared for frequent constructive critique (from the community as a whole, not just their mentor) and an unusually public internship. Asking questions and talking about your progress in front of a hundred strangers is not for the faint of heart, no matter how patient and kind they may be!

New contributors (including GSoC contributors) are encouraged to be curious, active members of our community. Helping users with their questions, messing around with the engine itself and reviewing code unrelated to their core project is a fantastic way to learn, make friends, and form a connection with the Bevy project as a whole.

During their [Community Bonding Period](https://google.github.io/gsocguides/mentor/community-bonding-period), we would like to gradually ease our GSoC contributors into the Bevy community as both users and contributors.

During week 1, they'll be focused on getting their development environment setup and their feet wet with Bevy, selecting a project and working directly with their mentors to produce a tiny, runnable game.

In week 2, students and mentors will go over the basics of contributing to Bevy: creating a simple PR to fix a problem or improve documentation, and reviewing a couple of existing open PRs together.

Finally, in week 3, we would like to hold a low-pressure game jam: forming small teams of students with community volunteers (and optionally their mentors) as they create small, creative web games to match a provided theme. Jams are a fun team activity and a great learning opportunity, but can take up a lot of time if you're striving for perfection. Participation is fully optional for both students and mentors: mandatory fun is anything but!