Skip to content

Latest commit

 

History

History
58 lines (44 loc) · 2.35 KB

CONTRIBUTING.md

File metadata and controls

58 lines (44 loc) · 2.35 KB
Raw

How to contribute

Any kind of contribution / feedback is appreciated! One of the greatest motivations to make an open source project is to see people use it and get involved (in any level).

How to:

  1. Suggest features / improvements
  2. Report bugs
  3. Contribute code

Suggest features / improvements

Got an improvement you think can make lwip better? Great!

Open an issue with a descriptive title. Describe in a clear language the feature you need. If possible, write a code sample of how you think this feature should work.

Report bugs

Open an issue with a descriptive title. Write instructions on how to reproduce the problem. Code samples which demonstrate the problem can be very useful. Also include error logs and information about your system (OS, node version, npm version, lwip version, etc.).

Contribute code

Code contributions are happily welcomed. In order to make the process managable and pleasant, please do not blindly open PRs without discussing it first.

A PR should address an already opened issue. If your PR fixes a bug, there should already be an issue reporting this bug. If your PR implements a new feature, there should be an issue requesting this feature.

  1. Disscuss your intention to work on an issue in the issue itself.
  2. Fork lwip.
  3. You may want to read development notes in DEVELOPMENT.md.
  4. Your code should be based on the latest version/x.x.x branch, or master if no version/x.x.x branch is available. Ask to be sure. Before releasing a new version, a version/x.x.x branch will be opened, into which all feature branches for this version will be merged. Eventually this version branch will be merged into master.
  5. Your commits should describe your changes. Try not to make too many unrelated changes in one commit. Split them. Write descriptive commit logs.
  6. Include tests for your changes / new feature.
  7. Make sure existing tests still pass.
  8. If your PR changes the public API, update the README accordingly.
  9. There are no written code conventions (yet), but try to get a sense of the coding style and keep similar style (no tabs, please).
  10. Don't change git history (no force push).
  11. Spell check.

Copyrights

This project is published under the MIT lisence. All contributions are included under the same lisence.