GSoC Contributor Guidance
ALPS (Algorithms and Libraries for Physics Simulations) is an open-source software ecosystem for simulations of correlated quantum systems and related many-body models. GSoC contributors help us improve the software infrastructure around these algorithms (build systems, APIs, workflows, documentation, testing, and tooling) that make ALPS easier to use and maintain.
How to contact us (start here)
Initially, please email our Steering Committee GSoC point of contact, Prof. Adrian Feiguin (a.feiguin@northeastern.edu)
In your email, include:
- Which idea(s) you are interested in (copy/paste the idea title or describe it briefly).
- A short summary of your background and relevant skills.
- Your availability during the program period (and any known conflicts).
- Any early questions or a short draft plan (even bullets are fine).
What to include in your application
Please provide a brief CV. You do not need a physics or scientific background to participate. You will be trained and guided to get you familiarized with the ALPS package, its structure and functionality. You will not be required to understand the algorithms per se, but to help build a software infrastructure around them.
In your application please include answers to the following questions:
- What interests you most about our project?
- As mentors and project coordinators, how can we get the best out of you?
- Is there anything that you’ll be studying or working on whilst working alongside us?
Once you have selected a project assignment from the Ideas List page, please include a schedule with milestones and deliverables.
Recommended proposal structure (template)
To help mentors evaluate proposals consistently, we strongly recommend this structure:
Title + short abstract (5–10 lines) What you will build and what “success” looks like.
Motivation and impact Who benefits (users, maintainers, new contributors)? What pain point does it solve?
Technical approach What parts of ALPS you will touch, planned interfaces/APIs, data formats, and design choices.
Deliverables (must-have / optional / stretch) Be explicit about what will be merged by midterm and final.
Timeline (weekly milestones) A plan with measurable outputs and some buffer time.
Testing and validation plan What tests you’ll add (unit/integration), and how you’ll validate correctness or stability.
About you Relevant experience, links to GitHub/projects, and your availability/conflicts.
Communication plan How often you’ll post updates and where (e.g., GitHub contributions and weekly GitHub discussion posts).
What we look for (quick checklist)
- Clear scope and realistic milestones (not “rewrite everything”).
- Evidence you can execute (small PR, issue discussion, or prototype).
- Testing + documentation included as first-class deliverables.
- A plan that fits the GSoC timeline and can be merged incrementally.