New Trilinos Developers

Developer Expectations

When a new person is to begin contributing to Trilinos, they are typically expected to become familiar with and adhere to the policies listed on this wiki, and complete the Trilinos New Developer Process Checklist. The possible exception to this is if someone wishes to submit occasional pull requests against the project and not be deeply involved in the project. Even in this case, it is helpful to be aware of the policies and tools that have been adopted. For example, a pull request that has been tested using the checkin test script or pull request testing will have a better chance of being accepted into the code base than one that is untested, or was tested in other ways.

Trilinos is developed entirely in the open on GitHub, and developers at Sandia and elsewhere must keep this in mind while working on Trilinos. Any questions about this should be directed to the Trilinos leadership team.

Push Access to the Trilinos Repository

Thanks to GitHub, anyone can view Trilinos source code, as well as fork the repository and issue pull requests against the primary Trilinos repository (pull requests should be issued against the 'develop' branch, or some other branch negotiated with a Trilinos developer, but never the 'master' branch). Push access is not required to be a Trilinos contributor or developer. According to current policy, whether or when a new Trilinos developer is granted push access is determined by the new developer's mentor. That person will decide if the new developer requires push access, and if so, when they have completed sufficient training to be given push access. When appropriate, the mentor can request push access by sending an email to the Trilinos Framework mail list. Eventually all contributions to Trilinos will be via pull request. This will provide build and test feedback via pull-request testing on multiple platforms as well as easy access to review as needed.