Skip to content

Latest commit

 

History

History
119 lines (69 loc) · 5.09 KB

CONTRIBUTING.md

File metadata and controls

119 lines (69 loc) · 5.09 KB

Contributing to mikroSDK repository


Welcome, and thank you for showing interest in contributing to MikroElektronika's mikroSDK!

There are many ways in which you can contribute, beyond writing code. The goal of this document is to provide a high-level overview of how you can get involved.

Asking Questions

Have a question? Rather than opening an issue, please consider one of the following steps:

  1. Check our Forum for more information.
  2. Contact our technical support at MikroElektronika and adding the tag mikroSDK in the message.

Our capable engineers will be eager to assist you.

Providing Feedback

Your comments and feedback are welcome, and the development team can be reached by contacting our technical support.

Technical support can be contacted using already mentioned chat or by submitting a conversation ticket.

Reporting Issues

Have you identified a reproducible problem in mikroSDK? Perhaps you have a feature request? We want to hear about it! Here's how you can make reporting your issue as effective as possible.

Look For an Existing Issue

Before you create a new issue, please do a search in open issues to see if the issue or feature request has already been filed.

If you find your issue already exists, make relevant comments.

  • 👍 - upvote
  • 👎 - downvote

If you cannot find an existing issue that describes your bug or feature, create a new issue using the guidelines below.

Writing Good Bug Reports and Feature Requests

File a single issue per problem and feature request. Do not enumerate multiple bugs or feature requests in the same issue.

Do not add your issue as a comment to an existing issue unless it's for the identical input. Many issues look similar, but have different causes.

The more information you provide, the more likely someone will be successful at reproducing the issue and finding a fix.

Please include the following with each issue:

  • Version of NECTO Studio

  • Version of SDK

  • Your operating system

  • Zipped project files

  • Reproducible steps (1... 2... 3...) that cause the issue

  • What you expected to see, versus what you actually saw

  • Images, animations, or a link to a video showing the issue occurring

  • A code snippet that demonstrates the issue or a link to a code repository the developers can easily pull down to recreate the issue locally

    • Note: Because the developers need to copy and paste the code snippet, including a code snippet as a media file (i.e. .gif) is not sufficient.
  • Errors from the mikroDap.log file

    • File located in:
      • Windows: %localappdata%/Mikroe/NectoStudio/log/
      • Linux: ~/.Mikroe/NectoStudio/log/
      • MacOS: ~/Library/Application Support/Mikroe/NectoStudio/log/

Final Checklist

Please remember to do the following:

  • Search the issue repository to ensure your report is a new issue

  • Recreate the issue after reinstalling NECTO Studio

  • Simplify your code around the issue to better isolate the problem

Don't feel bad if the developers can't reproduce the issue right away. They will simply ask for more information!

Follow Your Issue

Once submitted, developers will leave comments in the issue tagging the reporter. Be sure to understand what will happen next, so you know what to expect, and how to continue to assist throughout the process.

Contributing fixes

If you are interested in writing code to fix issues, follow these steps:

  1. Fork and clone the repository
  2. Create a new branch: git checkout -b my-branch-name
    • Branch name ( my-branch-name ) should be username/issue_name
  3. Make your change, test locally and make sure the tests still pass before continuing
  4. Push to your fork and submit a pull request
  5. Pat your self on the back and wait for your pull request to be reviewed and merged

Here are a few things you can do that will increase the likelihood of your pull request being accepted:

  1. Follow the defined coding rules ( click HERE )
  2. Keep your changes as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests
  3. Write a good commit message
  4. Work in Progress pull requests are also welcome to get feedback early on, or if there is something blocking you

Thank You

Your contributions to open source, large or small, make great projects like this possible. Thank you for taking the time to contribute.


Resources