Skip to content

Latest commit

 

History

History
72 lines (57 loc) · 3.65 KB

CONTRIBUTING.md

File metadata and controls

72 lines (57 loc) · 3.65 KB
Raw

Contributing to PowerSystemDatamodel

Welcome dear fellow of sophisticated power system modelling! 👋 And thank you for considering your contribution to this project! With this document we would like to give you some orientation on how you can contribute.

Table of contents

Testing and reporting bugs

We really appreciate your usage of this project. Whenever you find a bug, it would be nice to check, if this isn't a feature to us. 😉 You may find extensive information about the intended behaviour when you Read the Docs. If you still think it's a bug, please raise an issue for us. Considering the following aspects in your inquiry, assists us in helping you:

  • Is there already an issue addressing your problem?
  • Try to locate the error as precise as possible.
  • What has to be done to reproduce the error?
  • Provide stack trace, logs etc. and further helpful information
  • What would do you expect to happen?
  • Mark the issue with the label bug.

Suggest extensions

We use issues as well to keep track of enhancement suggestions. Considering the following aspects, assists us in understanding your needs properly:

  • Is there already an issue addressing your request?
  • What would do you desire for?
  • If possible provide an example or sketch.
  • Show a use case, that should be as versatile as possible.
  • Mark the issue with the label enhancement.

Contributing code

If you intend to produce some lines of code, pick an issue and get some hands on!

Branching and handing in pull requests

We try to follow a branch naming strategy of the form <initials>/#<issueId>-<description>. If for example Prof. Dr. rer. hort. Klaus-Dieter Brokkoli would like to add some work on node models reported in issue 4711, he would open a branch kb/#4711-extendingNodeModels. Please hand in a draft pull request as early as possible to allow other to keep track on your changes. Before opening it for review, please finalise your pull request.

General (software) design guidelines

In order to maintain a consistent project, we thought of some general design guidlines, we kindly ask you to take care of:

  • We ❤️ immutability. Therefore, please don't provide setters and use proper instantiation instead.
  • double a = b * pow(x, j)? ✋ Please be expressive in what you code!
  • Document your code with javadoc.

Testing

Ensure the proper function of your code by test driven development (TDD). We have good experiences using Spock as a testing framework for Groovy.

Finalising your pull request

Some automated checks assist us in delivering a pretty fair quality of software. Before marking the pull request as 'ready to review', take these precautionary actions:

  • Are all tests passing? Run gradle test
  • Is your code properly formatted? Run gradle spotlessApply

gradle finalizePR summarizes all of these steps .

For any doubts

... please contact us

We are happy to help! 😃