Developer Onboarding

How someone joins the Pengin Open Source development team — from interview to first issue.

There are two paths in:

  • Interns — join through the Tobu Pengin internship program, with a structured syllabus and handouts. See Program Training.
  • Volunteers — upgraded interns, or experienced applicants joining the community proper. Volunteers are expected to arrive with the setup and training below already done.

Members of the general public don't need any of this to contribute — anyone can open a pull request on GitHub. See Contributing.

1. Interview

Every applicant interviews before joining. Interns interview for a place in the program; experienced applicants interview to join as volunteers.

2. Credential review

Your background, experience, and any credentials you list are reviewed. For interns this sets the starting point in the syllabus; for experienced applicants it decides whether you join directly as a volunteer.

3. Agreement

  • Interns sign the internship offer letter and accompanying contracts, and follow the filing instructions that come with them.
  • Volunteers sign the Contributor License Agreement (CLA).

Nothing past this step happens until the agreement is signed and filed.

4. Accounts

Create:

  • An account on penginopensource.org
  • An account on the Pengin Open Source GitLab

And provide your GitHub username. It's required — you're added to both the GitLab and GitHub teams, and GitHub membership is how your identity links across the two.

Then request access to, and accept invites for:

  • The team Discord servers
  • The team calendar
  • The GitLab project and its repositories

5. Credentialed access

Most work needs nothing beyond the accounts above. Two kinds of access need more:

  • AWS access keys
  • SSH access to Pengin Open Source servers

Both require valid government-issued identification and a signed use policy.

  • US residents and citizens: a valid government-issued photo ID
  • Everyone else: a valid passport

On rare occasions, for international applicants, a slightly expired passport alongside a current government identification card is accepted.

Credentialed access is granted as a need arises, not by default. Onboarding for server and CI/CD administration is provided once access is approved.

Intern setup checklist

If you get stuck on any step, ask for help in Discord and move on to the next step while you wait. Nobody expects you to solve setup problems alone.

Tools

If you're granted AWS access later:

Never commit AWS credentials, and never put them in .env files you share.

Python

Work through at least one of these if you don't already know Python:

The program's own handouts cover the Python this codebase leans on hardest — classes, MRO, dunder methods, and decorators. See Program Training.

Git

  • [ ] Git tutorial — if you haven't used Git, or don't feel confident with it

First steps in the project

  • [ ] Clone Pengin-Pi-3 from GitLab
  • [ ] Get it running locally — see Install. The SQLite fallback means you need no database server to start.
  • [ ] Create a branch named yourname-test, make a small change, and push it
  • [ ] Explore the running application. Create a page in the slug editor, start a wiki, and read through main/ alongside Architecture.

Once you reach this point, you're ready to take on issues.

Git workflow

Official work happens on GitLab. The full process is in Contribution Workflow; this is the version to learn first.

Never push to main, a protected branch, or an issue branch you don't own.

Issues get their own branch, named <issue-number>-<issue-title>. You branch off the issue branch into your own, named <issue-number>-<issue-title>-<your-name>.

For issue 165, the calendar:

git fetch origin
git checkout 165-calendar
git checkout -b 165-calendar-yourname

Work and commit in your branch, then push it:

git push -u origin 165-calendar-yourname

When you're done, open a merge request on GitLab from 165-calendar-yourname into 165-calendar. GitLab calls pull requests merge requests; they're the same thing.

Your merge request is reviewed, and you'll get feedback to address before it can be merged. Push fixes to your branch — the merge request updates automatically. Once nothing is outstanding, it's merged.

This sub-branch workflow is how interns train. In practice, someone who owns an issue branch usually works on it directly, and only creates sub-branches when trying out features or separate components.

Optional

Volunteers

Volunteers are expected to already have:

  • The tools above installed and configured
  • The project cloned and running
  • Working knowledge of Python, Django, and Git
  • Access to GitLab, GitHub, Discord, and the calendar

If you're an experienced applicant rather than an upgraded intern and any of that is missing, the checklist above is the fastest way to close the gap. Read Contribution Workflow and the Style Guide before your first merge request.

Contents

Pages Here

No sub-pages yet.

Page Info

Wiki: Docs

Created on Sep 21, 2026 by Tobu Pengin, L.L.C.

Maintainers

Editor Last Activity
Tobu Pengin, L.L.C. creator Sep 21, 2026
Pengin Open Source