@@ -10,16 +10,75 @@ and test before submitting code.
1010Checking that your PR passes the required testing and linting procedures will speed up
1111the acceptance of your PR.
1212
13- **If you find errors in the codebase: **
13+ Issues and bug reporting
14+ ------------------------
1415
15- 1. Submit an issue at the `pvops issues page <https://github.com/sandialabs/pvops/issues >`_
16+ To report issues or bugs please create a new issue on
17+ the `pvops issues page <https://github.com/sandialabs/pvops/issues >`_.
18+ Before submitting your bug report, please perform a cursory search
19+ to see if the problem has been already reported. If it has been reported,
20+ and the issue is still open, add a comment to the existing issue instead of opening a new issue.
1621
17- **If you would like to contribute: **
22+ Guidelines for effective bug reporting
23+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1824
19- 2. Create a pull request (PR) or help with other PRs which are in the library
20- by referencing `pvops PR page <https://github.com/sandialabs/pvops/pulls >`_.
21- Pull requests should contain code that follows the PEP8 python code style.
25+ - Use a clear descriptive title for the issue.
2226
23- **If you are confused: **
27+ - Describe the steps to reproduce the problem,
28+ the behavior you observed after following the steps, and the expected behavior.
2429
25- 3. Feel free to reach out to the package maintainer, found in ``setup.py ``.
30+ - If possible, provide a simple example of the bug using pvOps example data.
31+
32+ - When relevant, provide information on your computing environment
33+ (operating system, python version, pvOps version or commit).
34+
35+ - For runtime errors, provide a function call stack.
36+
37+ Contributing code
38+ -----------------
39+
40+ Software developers, within the core development team and external collaborators,
41+ are expected to follow standard practices to document and test new code.
42+ Software developers interested in contributing to the project are encouraged
43+ to create a Fork of the project and submit a Pull Request (PR) using GitHub.
44+ Pull requests will be reviewed by the core development team.
45+ Create a PR or help with other PRs which are in the library
46+ by referencing `pvops PR page <https://github.com/sandialabs/pvops/pulls >`_.
47+
48+ Guidelines for preparing and submitting pull-requests
49+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
50+
51+ - Use a clear descriptive title for your pull-requests
52+
53+ - Describe if your submission is a bugfix, documentation update, or a feature
54+ enhancement. Provide a concise description of your proposed changes.
55+
56+ - Provide references to open issues, if applicable, to provide the necessary
57+ context to understand your pull request
58+
59+ - Make sure that your pull-request merges cleanly with the `master ` branch of
60+ pvOps. When working on a feature, always create your feature branch off of
61+ the latest `master ` commit
62+
63+ - Ensure that appropriate documentation and tests accompany any added features.
64+
65+
66+ Once a pull-request is submitted you will iterate with NuMAD maintainers
67+ until your changes are in an acceptable state and can be merged in. You can push
68+ addditional commits to the branch used to create the pull-request to reflect the
69+ feedback from maintainers and users of the code.
70+
71+ Questions and feature requests
72+ --------------------------------
73+
74+ For any questions regarding pvOps or requests for additional features,
75+ users may open an issue on the `pvops issues page <https://github.com/sandialabs/pvops/issues >`_
76+ or contact the package maintainer found in ``setup.py ``.
77+
78+ Guidelines for effective bug reporting
79+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
80+
81+ - Use a clear, descriptive title for the question or feature request.
82+
83+ - If submitting a feature request, please provide context, examples, and
84+ references when relevant.
0 commit comments