Thank you for considering contributions to the ER tool! Community contributions are what make open source software work.

These guidelines provide an overview of how to submit a PR to our repository in such a way that we can effectively integrate it into our code base.

We accept any contributions that make ER easier to use, or help to support a wider set of tools. Since ER gets more effective the more profilers we support, these contributions are especially desired. If you want to use ER with some new benchmarking or power consumption profiler, consider writing a plugin for us and submitting it as a PR!

Did you find a bug during your time with ER? Letting us know could improve things for everyone! We are a small team with limited hardware to test ER on. Bug reports from our users can help us to make ER more platform agnostic, and allows us to leverage the power of the community.

Before submitting a report, check in the issues tab if a similar point has been raised before. Your issue might already be known.

• A description of the bug in your own words, describe what behavior you expected and what the result was.
• The configuration of ER you were using, any plugins, and relevant parts of your RunnerConfig.py file.
• If the output included an error, please include a copy from the terminal or log file.
• The python version, and versions of any other relevant software dependencies.
• The operating system and hardware used.

If you also had the time and resources to fix this bug, we greatly appreciate this. In this case a single PR can be submitted including both the bug you found and an overview of your proposed fix. When creating a fix for ER, consider how platform independent the proposal is. Our goal with ER is to support as many platforms and tools as possible, fixes should also adhere to this.

• An overview of the bug as previously described.
• A short description of your proposed fix.
• Any additional dependencies required.

Thanks for making an addition to ER! We have a few simple guidelines to streamline the processes. Most additions will be possible through the plugins system that we have, which defines an interface for modular components. Additions to the engine and core functionality are also possible, but pose a larger challenge as they must be platform agnostic where possible.

• Plugins should abstract a single tool, if you need more than one utility consider making two plugins.
• Plugins should attempt to use existing classes and constructs where possible, we provide abstract classes in the file DataSource.py.
• If you create a new plugin, it should include a example RunnerConfig.py to demonstrate how its used. Refer to the other examples, and include yours in the same directory.
• Examples should include a README describing the dependencies, and usage of the tool. Again refer to the other examples for references.
• Plugins are only required to support platforms the software tool or hardware they abstract supports.
• Changes to the engine, or other core functionality should maintain compatibility with existing features.
• Any changes to the core engine should be supported on Windows, Linux, and OSX.

If you are making any change or addition, tests can help to prove your submission meets our requirements. If you are adding complex functionality, we might additionally ask you to provide certain tests if we believe they are necessary to show reliability.

Tests should adhere to the following guidelines:

• All tests should be instantiated through python, which provides many convenient tools through the pytest and unittest libraries.
• Tests should be placed in the appropriate directory within the test folder.
• We prefer integration tests over unittests, as we feel they better emulate real usage and reach a larger portion of the code base.
• Focus on edge cases, and tests that show your changes are reliable and able to handle their intended ranges of values.
• Unittests, if used should, attempt to mock or emulate as little as possible to use as much of the code base as possible.