PR Creation & Approval Guidelines for Tpetra, Ifpack2, and MueLu Developers

A minimal PR description should include the following:

Issue: #XXX
Tests: YYYY
Stakeholder Feedback: ZZZ

If you're a code reviewer, be sure to either add that information or get the PR author to do so.

Issue

Make sure there's a Trilinos Issue associated with your PR. Ideally, this will explain what the PR is supposed to do. Link to the issue in the PR description on the "issue" line.

Tests

What did you do to convince yourself the code is correct? If you added a new test, note that. If you fixed a test that is somehow erroneous, note that too. If the change is a "back end" sort of change that the testing system shouldn't notice then "all tests pass" is probably fine. New capabilities should almost always have an accompanying test. (Experimental code may be an exception.) "Untested code is by definition broken" -- Anonymous.

Stakeholder Feedback

If this PR is in response to a stakeholder request, note that. Something like "Discussed with George Washington via email" would be fine. For requests that aren't stakeholder-driven, e.g., you're fixing the nightly tests because an OS upgrade broke them, "n/a" is fine.