Working Group Guidelines

Guidelines for Managing Working Groups

Introduction

MPI Forum Working Groups are set up as their own GitHub organizations. This makes things simpler to manage so that working groups can self organize without going through a single administrator. It also allows them to have their own working copy of the MPI Standard source to be able to work on new ideas internally before exposing them to the entire MPI Forum.

Setup

Most working groups already have an organization set up for them. The list of current working groups can be found on the main wiki page. If your working group does not have an organization yet, you are welcome to set one up yourself. Recommended steps for doing this are:

• Create a new GitHub Organization.
  • Use the open-source (free) version.
• Create a fork of the mpi-forum/mpi-standard repository into the working group organization.
  • This does not count as a private repository for the organization so it won't cost anything.
• Create a new public repository called <wg>-issues to organize the working group's internal issues and wiki.

Access Management

How you decide to give access to your working group's organization is up to you. The simplest model is to just add each person who would like to participate in the working group to the list of members. You can do this under the "People" tab on the Organization's main page. See the screenshot below for the correct tab.

Then click the "Invite member" button:

Then enter their GitHub username/email/etc. to find the right person. If they don't have an account already, they will have to create one first. There should be two teams in each working group, one for owners and one for members. The WG Members team should include everyone who will have write access to the working group's repositories. The Owners team will only include the people who will administer the team (such as adding other users). You should add members to the appropriate teams.

Workflow

Just as working groups are welcome to self-organize, how each working group decides on its workflow is also free to be changed. A suggested model is to be similar to the main MPI Forum organization:

• The source of the MPI Standard should be in a fork of mpi-forum/mpi-standard. This repository must be kept private to comply with the MPI Forum rules.
• Another public repository can keep track of the business of the working group (internal issues/wiki/etc.)

While a working group is working on issues that are not ready for the full MPI Forum, it should create branches on it's own fork of the source (mpiwg-<wg>/mpi-standard). If multiple branches are being used simultaneously, it might be helpful to have a branch which can be used to integrate all of the other branches to internally check to see that the branches are consistent. We don't suggest using the branches inherited from the main mpi-forum repository (mpi-y.x) as these branches should remain mirrors of their respective branches in the mpi-forum repository to make it easy to track the work of the full forum.

A working group might use pull requests against an internal branch to keep track of large tasks. For instance, while working on User Level Failure Mitigation, the fault tolerance working group maintained a branch called ulfm/master which contained the current version of the ULFM proposal. Additions to that proposal were kept in separate branches and integrated into ulfm/master via pull requests. Another example is from the tools working group. A separate branch exists to integrate all tickets which lets someone checkout a single branch containing all of the work being done by the working group. Individuals clone the working group's mpi-standard repository to create new branches for each issue. Pull requests link these branches back to the working group's integration branch. When a pull request is accepted, the branch is merged into the integration branch and a new pull request is filed from the branch to the main MPI Forum repository.

When the text is ready, someone from the working group should create an issue on the main MPI Forum issues repository mpi-forum/mpi-issues and create a pull request from the working group's fork of mpi-standard back to the main repository mpi-forum/mpi-standard. From this point, the Issue Workflow should be followed.

Remember that any issues that are internal to the working group are not considered the "official issue" and therefore don't count as publicizing for readings/votes/etc. Only the issues in the main mpi-forum/mpi-issues repository fulfill the requirements.