<commit_before># Contributing

Thanks for contributing to the Encore programming language.

## Opening issues

If you find a bug, please feel free to open an issue.

If you taking the time to mention a problem, even a seemingly minor one, it is
greatly appreciated, and a totally valid contribution to this project. Thank
you!

## Guidelines (taken from [here](http://www.booleanknot.com/blog/2013/09/07/pull-requests.html))

### Stay on target
A pull request should be focused on a single bug fix or feature.

Resist the temptation **to clean up whitespace**, or **fix formatting errors**, or **add
useful rules to .gitignore**. Don't change the version number, either; is not your job
to determine release cycles. If you must do any of those things, send the author
a separate pull request.

**Diffs that are polluted with whitespace and formatting fixes are harder to
understand**, and pull requests that implement multiple features are harder to
test and approve.

**Stay focused**. Make things easy for the project maintainer, and they'll get your pull
request merged much more quickly.<commit_msg>Add some text about Git usage<commit_after># Contributing

Thanks for contributing to the Encore programming language.

## Opening issues

If you find a bug, please feel free to open an issue.

If you taking the time to mention a problem, even a seemingly minor one, it is
greatly appreciated, and a totally valid contribution to this project. Thank
you!

## Git

Please do **not** push to the `master` branch. Rather than that, clone the
encore repository in your own github account, push there and send a pull
request. This allows for code to be reviewed before it gets into `master`. Also,
when implementing a large feature, please do use a feature branch.

## Guidelines (taken from [here](http://www.booleanknot.com/blog/2013/09/07/pull-requests.html))

### Stay on target
A pull request should be focused on a single bug fix or feature.

Resist the temptation **to clean up whitespace**, or **fix formatting errors**, or **add
useful rules to .gitignore**. Don't change the version number, either; is not your job
to determine release cycles. If you must do any of those things, send the author
a separate pull request.

**Diffs that are polluted with whitespace and formatting fixes are harder to
understand**, and pull requests that implement multiple features are harder to
test and approve.

**Stay focused**. Make things easy for the project maintainer, and they'll get your pull
request merged much more quickly.
{'fraction_non_alphanumeric': 0.06569054214483577, 'fraction_numerical': 0.006331618519984171, 'mean_word_length': 4.531728665207877, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '863910', 'n_tokens_mistral': 658, 'n_tokens_neox': 620, 'n_words': 382}