YTEP-1776: Team Infrastructure


Created: August 24, 2014 Author: Britton Smith

This document describes the structure, policies, procedures, and processes of the yt development team.


In Progress

Detailed Description

Team Structure

The yt development team consists of developers and members. Anyone contributing at least one changeset to the codebase is a developer and shall be listed in the Contributors section here. A member is someone who has made continued and significant contribution to the project (changes to the codebase, discussion on mailing lists, feedback on pull requests, etc.) for some period of time. After such a period, potential new members are nominated for membership by an existing member and confirmed by positive votes from three additional members. Once a developer becomes a member, they remain a member for life. A member maintains the option to give up their membership and have their name removed from the list. Membership may be revoked for anyone who is deemed to be directly harmful to the project or the community upon a nomination by another member and five supporting member votes. Upon the initial creation of yt membership status, all developers having contributed at least 50 changesets shall be granted membership. The Project Members page gives a description of the requirements for membership and provides a list of all members and the year in which membership was granted.

Current yt members:

  • Kenza Arraki (2014)
  • Brian Crosby (2016)
  • Bili Dong (2016)
  • Hilary Egan (2014)
  • Nathan Goldbaum (2014)
  • Cameron Hummels (2014)
  • Suoqing Ji (2014)
  • Allyson Julian (2016)
  • Ben Keller (2014)
  • Kacper Kowalik (2014)
  • Sam Leitner (2014)
  • Chris Malone (2014)
  • Andrew Myers (2014)
  • Jill Naiman (2014)
  • Jeff Oishi (2014)
  • Brian O’Shea (2014)
  • Douglas Rudd (2014)
  • Anthony Scopatz (2014)
  • Sam Skillman (2014)
  • Stephen Skory (2014)
  • Britton Smith (2014)
  • Casey Stark (2014)
  • Matthew Turk (2014)
  • John Wise (2014)
  • Michael Zingale (2014)
  • John Zuhone (2014)

Members have write access to all official yt repositories and can, therefore, accept pull requests. Members are eligible to serve on the yt project steering committee. The steering committe shall meet quarterly or more often as needed to discuss project-related business. Members may join the steering committee by attending one of the team meetings and self-nominating. One person on the steering committee shall act as the coordinator, in charge of making sure the team meetings happen. All developers are welcome to participate in team meetings.

Current steering committee members:

  • Hilary Egan
  • Nathan Goldbaum
  • Cameron Hummels
  • Kacper Kowalik
  • Sam Skillman
  • Britton Smith (c)
  • Matthew Turk
  • John Zuhone

c - meeting coordinator

Similar to subcomponent representatives, each frontend shall have at least one designated liason to act as a knowledge-base for issues relating to implementation and testing of that frontend in the yt codebase. The current list of frontends and liasons is given below.

Frontend Liaisons
ART Kenza Arraki
ARTIO Douglas Rudd
Athena John ZuHone
Boxlib Chris Malone, Michael Zingale
Enzo Britton Smith, Nathan Goldbaum
FLASH John ZuHone
Gadget Nathan Goldbaum
Gadget_FOF Britton Smith
GDF Kacper Kowalik
HaloCatalog Britton Smith
OWLSSubfind Britton Smith
Rockstar Britton Smith
SDF Sam Skillman

Team Meetings

Public meetings, optimally including all members of the steering committee and frontend maintainers, should happen at least once a quarter. These meetings are to encourage frank and open discussion about the future of the project. Meetings will happen over video chat to encourage remote participation, and times should be chosen to accomodate international atendees. The meetings invite will be public, and any interested developer or user is welcome to attend.

PR Review Meetings

Once weekly, or as required, video chats should be help to ensure timely review of pending pull requests. All PRs that are not marked incomplete or work in progress will be reviewed, and any outstanding tasks will be discussed and mentioned publicly as a comment on the pull request. Any developer or user is welcome to attend the meeting. Developers who have open pull requests they would like to see reviewed are particularly encouraged to attend to aid discussion about the pull request.

Development Practices and Releases


The main yt repository is located at

Until a compelling need for a new named branch arises, the yt repository will maintain three active branches: yt, stable, and yt-2.x. The yt branch contains all accepted changes and new features that have yet to be included in a release. The tip of the stable branch will be the latest release. The yt-2.x branch will maintain the latest state of the 2.x version of yt.


In addition to the named branches listed above, we further split development on the yt branch into two topological branches. These two lines of development should at all times have bookmarks named development and experimental pointed at the branch heads. The development bookmark is the “main” line of yt development, used for branching minor releases and as a place to land bug fixes. The experimental bookmark is for long-term work. An example of such a long-term development effort is the (at the time of writing) ongoing work to refactor and update the volume rendering interface and add unstructured mesh support. For now there should only be two topological branches on the yt named branch. If a compelling reason arises to add a new topological branch, the project members must agree to create it and add a new bookmark to track the work.

If no ongoing work is happening on a long-term feature, the experimental and development bookmark might be temporarily deleted until a compelling need to create another branch head comes up. In these cases the yt branch will only have one head.

Standards for Changes to the Code

Development shall occur in forks off of the main repository with changes being pulled in via pull requests into the yt branch. Modifications to the code typically fall into one of three categories, each of which have different requirements for acceptance into the code base. Pull requests should be tagged in the title with [NEW], [BREAKSAPI], [BUGFIX], or [WIP] (for “work in progress”).

  • New Features
    • Pull request should be issued with “[NEW]” in the title.
    • New unit tests (possibly new answer tests)
    • Docstrings for public API
    • Addition of new feature to the narrative documentation
    • Addition of cookbook recipe
    • Issue created on issue tracker, to ensure this is added to the changelog
  • Extension or Breakage of API in Existing Features
    • Pull request should be issued with “[BREAKSAPI]” in the title.
    • Update existing narrative docs and docstrings
    • Update existing cookbook recipes
    • Modify or create new unit tests
    • Issue created on issue tracker, to ensure this is added to the changelog
  • Bug fixes
    • Pull request should be issued with “[BUGFIX]” in the title.
    • Unit test is encouraged, to ensure breakage does not happen again in the future.
    • Issue created on issue tracker, to ensure this is added to the changelog

No specific standard shall exist for accepting pull requests of minor bug fixes. New features, API breakages, and more substantial bug fixes require approval of three yt members or people designated as qualified reviewers by the issuer. When a [WIP] pull request is ready to be reviewed for acceptance, the tag should be changed to one of the other options above.

For the development of large features or infrastructure changes involving the work of more than one developer, a bookmark named experimental will be created on a head of the yt branch to enable collaboration in the main yt repository. Pull requests to the experimental bookmark will be accepted according to criteria laid out by the issuer. Documentation will not be considered a requisite for pull requests to be accepted into the bookmark (although still encouraged), but a merge of the bookmark into the primary yt branch head shall not occur until all criteria laid out above have been met.


Minor releases will follow the schedule given in YTEP-0008: Release Schedule. Major or unscheduled releases will occur after criteria proposed and accepted in a prior team meeting are met. Before the release, members will be identified as playing an integral role in the content of the release, and the release will happen only after all of those members give their approval. Each release will have a designated release manager as described in YTEP-0008: Release Schedule. The release manager should also be present at the team meeting.

Backwards Compatibility

Sic semper inordinatio.


The alternative is to continue with no official guidelines and somehow manage.