Working Group Guidelines
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.
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>-issuesto organize the working group's internal issues and wiki.
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.
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). We don't suggest using the branches inherited from the main mpi-forum repository (mpi-y.x) internally 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.
Working groups are free to create their own workflows to use branches internally. Below are two examples from the fault tolerance working group and the tools working group
The Fault Tolerance working group acts as an single individual in the usual Git Flow model:
- It uses individual branches for each issue which are not integrated internally.
- Each branch has its own pull request back to the main
mpi-forum/mpi-standardrepository. - For larger issues, such as User Level Failure Mitigation, a new branch called
ulfm/masterwas created which contains the current version of the proposal. Because the proposal is too large for one person to manage on their own, other branches are created within the working group repository and pull requests link those branches back to theulfm/masterbranch. When ULFM is ready to go to the full MPI Forum, the entireulfm/masterbranch will get a pull request back to the main MPI Forum repository.
[See this wiki page](Working Group Example 1) for example Git commands to effect this model.
Another example is from the Tools working group, where individuals contribute to the working group before contributing to the main MPI Forum repository.
- 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-standardrepository 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.
[See this wiki page](Working Group Example 2) for example Git commands to effect this model.
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 How to file an MPI Forum issue ("ticket") workflow should be followed.
Remember that any issues that exist in the Working Group repositories are not considered "official," and therefore don't count as publicizing for readings/votes/etc. Only the issues created in the main mpi-forum/mpi-issues repository fulfill the requirements.