Skip to content

Latest commit

 

History

History
66 lines (57 loc) · 4.33 KB

CONTRIBUTING.md

File metadata and controls

66 lines (57 loc) · 4.33 KB
Raw

Contributing to Dragonfly

First, thank you for your interest in contributing to Dragonfly. 🎉

The following is a set of guidelines for contributing to Dragonfly. These are guidelines and in general it is recommended to stick to them when contributing, but you should use your best judgement. Feel free to propose changes to this document in our Discord.

Issues

Issues are very welcome, both in the form of bug reports and feature requests.

When opening a bug report, please try to provide as much information as you can to reproduce the issue. When opening a feature request, please be as clear as you can and provide concrete examples of how you think the proposed feature should work. The more precise you are, the easier it is for someone to pick up your request. Don't be afraid to propose any ideas you might have, they may help people looking to pick up your feature request!

As soon as a maintainer sees your issue and has enough information, your issue will be added to a milestone that indicates when we hope to have your issue resolved.

Pull Requests

In general, it is recommended to discuss any changes you would like to make in our Discord to before making changes, unless the change-set is otherwise small or limited to a specific part of the code base.

When reviewing pull requests, we aim to reach the following goals with the code proposed:

  • Maintain the quality of the source code.
  • Stick to the standard formatting of Go (go fmt).
  • Provide a well-documented, simple and clean codebase.

To make sure your pull request satisfies those points, we recommend you do the following before opening a pull request:

  • Run go fmt on any files you have changed to ensure the formatting is correct. Some IDEs have integration with this tool to run it automatically when committing. GoLand has a box that may be checked in the bottom-right corner when creating a commit.
  • Make sure to provide documentation for symbols where adequate. We generally follow the following conventions for documentation in pull requests:
    • Exported symbols (TypeName, FunctionName) should always have documentation over them, but if the function exists merely to satisfy an interface, the documentation may read // FunctionName ... or be completely absent if the method has no functional behaviour.
    • Unexported symbols (typeName, functionName) should have documentation, but doing so is not mandatory if the function is very simple and needs no clarification.
  • Make sure to use British English and proper punctuation throughout symbol names, variables and documentation.
  • Where possible, try to expose as few exported symbols (functions, types) as possible, unless strictly necessary. This makes it easier for us to change code in the future and ensures that users cannot use functions not suitable for the API.
  • In big functions it can become difficult to track the execution flow. Try to return as quickly possible in functions so that the main code flow is minimally indented and therefore easy to track and understand.
  • In places where there are three or more sequential variable declarations, these should be grouped into a single var ( ) block.
  • Try to be conservative with the usage of generics. While these are often useful, they can quickly pollute code if used in excess. Consider carefully if generics are needed, particularly for exported types and functions. Don't hesitate on using them if they are able to clean up the code significantly.
  • We strive to have only completely functional features in the codebase. While we recognise that it is not always possible to provide full functionality for a feature in a single pull request, you should attempt to do so to the extent that you can. Specific smaller features part of the pull request that cannot be implemented yet should be marked with a // TODO: ... comment so that we can implement these when the required functionality is present.
  • When you open a PR, we assume you have tested your code and made sure it is working as intended. As a general recommendation, you should enable the Minecraft Content Log in the Profile settings so that it becomes obvious when invalid data is sent to the client.

If you run into a problem or otherwise need help with your pull request, please feel free to reach out to us on Discord, so we can work towards a complete pull request together.