"Fossies" - the Fresh Open Source Software Archive

Member "kotlin-1.3.72/docs/contributing.md" (14 Apr 2020, 3721 Bytes) of package /linux/misc/kotlin-1.3.72.tar.gz:


As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field. See also the last Fossies "Diffs" side-by-side code changes report for "contributing.md": 1.3.50_vs_1.3.60.

Contributing

We love contributions! There is a lot to do on Kotlin and on the standard library so why not chat with us about what you're interested in doing? Please join the #kontributors channel in our Slack chat and let us know about your plans.

If you want to find some issues to start off with, try this query which should find all open Kotlin issues that are marked as "up-for-grabs".

Currently only committers can assign issues to themselves so just add a comment if you're starting work on it.

A nice gentle way to contribute would be to review the standard library docs and find classes or functions which are not documented very well and submit a patch.

In particular, it'd be great if all functions included a nice example of how to use it such as for the hashMapOf() function. This is implemented using the @sample macro to include code from a test function. The benefits of this approach are twofold; First, the API's documentation is improved via beneficial examples that help new users and second, the code coverage is increased.

Some of the code in the standard library is created by generating code from templates. See the README in the stdlib section for how to run the code generator. The existing templates can be used as examples for creating new ones.

Also the JavaScript back-end could really use your help. See the JavaScript contribution section for more details.

If you want to contribute a new language feature, it is important to discuss it through a KEEP first and get an approval from the language designers. This way you'll make sure your work will be in line with the overall language evolution plan and no other design decisions or considerations will block its acceptance.

Submitting patches

The best way to submit a patch is to fork the project on GitHub and then send us a pull request to the master branch via GitHub.

If you create your own fork, it might help to enable rebase by default when you pull by executing

git config --global pull.rebase true

This will avoid your local repo having too many merge commits which will help keep your pull request simple and easy to apply.

Intention/QuickFix/Inspection

Please read the Intention/QuickFix/Inspection Quick Notes if you are going to implement an inspection or intention or add a quick fix.

Checklist

Before submitting the pull request, make sure that you can say "YES" to each point in this short checklist: