<commit_before># How to Contribute

We'd love to get patches from you!

## Building dependencies

We are not currently publishing snapshots for TwitterServer's dependencies, which
means that it may be necessary to publish the `develop` branches of these
libraries locally in order to work on TwitterServer's `develop` branch. To do so
you can use our build tool, [dodo](https://github.com/twitter/dodo).

``` bash
curl -s https://raw.githubusercontent.com/twitter/dodo/develop/bin/build | bash -s -- --no-test twitter-server
```

## Building TwitterServer

TwitterServer is built using [sbt][sbt]. When building please use the included
[`./sbt`](https://github.com/twitter/twitter-server/blob/develop/sbt) script which
provides a thin wrapper over [sbt][sbt] and correctly sets memory and other
settings.

If you have any questions or run into any problems, please create
an issue here, chat with us in [gitter](https://gitter.im/twitter/finagle), or email
the Finaglers [mailing list](https://groups.google.com/forum/#!forum/finaglers).

## Workflow

The workflow that we support:

1.  Fork finagle
1.  Check out the `develop` branch
1.  Make a feature branch (use `git checkout -b "cool-new-feature"`)
1.  Make your cool new feature or bugfix on your branch
1.  Write a test for your change
1.  From your branch, make a pull request against `twitter/twitter-server/develop`
1.  Work with repo maintainers to get your change reviewed
1.  Wait for your change to be pulled into `twitter/twitter-server/develop`
1.  Merge `twitter/twitter-server/develop` into your origin `develop`
1.  Delete your feature branch

## Checklist

There are a number of things we like to see in pull requests. Depending
on the scope of your change, there may not be many to take care of, but
please scan this list and see which apply. It's okay if something is missed;
the maintainers will help out during code review.

1. Include [tests](CONTRIBUTING.md#testing).
1. Update the [changelog][changes] for new features, API breakages, runtime behavior changes,
   deprecations, and bug fixes.
1. All public APIs should have [Scaladoc][8].
1. When adding a constructor to an existing class or arguments to an existing
   method, in order to preserve backwards compatibility for Java users, avoid
   Scala's default arguments. Instead use explicit forwarding methods.
1. The second argument of an `@deprecated` annotation should be the current
   date, in `YYYY-MM-DD` form.<commit_msg>scrooge|finagle|twitter-server|finatra: Let's talk about snapshots<commit_after># How to Contribute

We'd love to get patches from you!

## Nightly Snapshots

Snapshots are published nightly for the current version in development and are
available in the [Sonatype](https://oss.sonatype.org/) open source snapshot
repository: [https://oss.sonatype.org/content/repositories/snapshots/](https://oss.sonatype.org/content/repositories/snapshots/). 

## Building dependencies

If you want to manually build and publish the `develop` branches of TwitterServer's 
dependencies locally, you can use our build tool, [dodo](https://github.com/twitter/dodo).

``` bash
curl -s https://raw.githubusercontent.com/twitter/dodo/develop/bin/build | bash -s -- --no-test twitter-server
```

This will clone, build, and publish locally the current `-SNAPSHOT` version 
from the `develop` branch of TwitterServer's other Twitter open source dependencies.

It is your choice to use the published nightly snapshot versions or to build 
the snapshots locally from their respective `develop` branches via the
[dodo](https://github.com/twitter/dodo) build tool.

## Building TwitterServer

TwitterServer is built using [sbt][sbt]. When building please use the included
[`./sbt`](https://github.com/twitter/twitter-server/blob/develop/sbt) script which
provides a thin wrapper over [sbt][sbt] and correctly sets memory and other
settings.

If you have any questions or run into any problems, please create
an issue here, chat with us in [gitter](https://gitter.im/twitter/finagle), or email
the Finaglers [mailing list](https://groups.google.com/forum/#!forum/finaglers).

## Workflow

The workflow that we support:

1.  Fork twitter-server
1.  Check out the `develop` branch
1.  Make a feature branch (use `git checkout -b "cool-new-feature"`)
1.  Make your cool new feature or bugfix on your branch
1.  Write a test for your change
1.  From your branch, make a pull request against `twitter/twitter-server/develop`
1.  Work with repo maintainers to get your change reviewed
1.  Wait for your change to be pulled into `twitter/twitter-server/develop`
1.  Merge `twitter/twitter-server/develop` into your origin `develop`
1.  Delete your feature branch

## Checklist

There are a number of things we like to see in pull requests. Depending
on the scope of your change, there may not be many to take care of, but
please scan this list and see which apply. It's okay if something is missed;
the maintainers will help out during code review.

1. Include [tests](CONTRIBUTING.md#testing).
1. Update the [changelog][changes] for new features, API breakages, runtime behavior changes,
   deprecations, and bug fixes.
1. All public APIs should have [Scaladoc][8].
1. When adding a constructor to an existing class or arguments to an existing
   method, in order to preserve backwards compatibility for Java users, avoid
   Scala's default arguments. Instead use explicit forwarding methods.
1. The second argument of an `@deprecated` annotation should be the current
   date, in `YYYY-MM-DD` form.
{'fraction_non_alphanumeric': 0.08414766558089033, 'fraction_numerical': 0.00579080709373869, 'mean_word_length': 4.408023483365949, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 14, 'lorem ipsum': 0, 'www.': 0, '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': '5581688', 'n_tokens_mistral': 1568, 'n_tokens_neox': 1506, 'n_words': 718}