<commit_before># Contributing to mountebank

Congratulations! You're here because you want to join the millions of open source developers
contributing to mountebank. The good news is contributing is an easy process. In fact, you can
make a difference without writing a single line of code. I am grateful for all of the following contributions:

* Submitting an issue, either through github or the [support page](http://www.mbtest.org/support)
* Commenting on existing issues
* Answering questions in the [support forum](https://groups.google.com/forum/#!forum/mountebank-discuss)
* Letting me know that you're using mountebank and how you're using it. It's surprisingly hard to find
that out with open source projects, and provides healthy motivation. Feel free to email at
<EMAIL>
* Writing about mountebank (bonus points if you link to the [home page](http://www.mbtest.org/))
* Creating a how-to video about mountebank
* Speaking about mountebank in conferences or meetups
* Telling your friends about mountebank
* Starring and forking the repo. Open source is a popularity contest, and the number of stars and forks matter.
* Convincing your company to let me announce that they're using mountebank, including letting me put their logo
on a web page (I will never announce a company's usage of mountebank without their express permission or a
pre-existing public writeup).
* Writing a client library that hides the REST API under a language-specific API
* Writing a build plugin for (maven, gradle, MSBuild, rake, gulp, etc)

Still want to write some code?  Great! You may want to keep the
[source documentation](https://mountebank.firebaseapp.com/)
handy, and you may want to review [the issues](https://github.com/bbyars/mountebank/issues).

I have two high level goals for community contributions. First, I'd like contributing to be as fun
as possible. Secondly, I'd like contributions to follow the design vision of mountebank.
Unfortunately, those two goals can conflict, especially when you're just getting started and
don't understand the design vision or coding standards. I hope this document helps, and feel free
to make a pull request to improve it! If you have any questions, I am more than happy to help
at <EMAIL>, and I am open to any all suggestions on how to make code contributions
as rewarding an experience as possible.

## Designing mountebank

The code in mountebank is now a few years old, and maintaining consistency of design vision
is key to keeping the code maintainable. The following describe key concepts:

### API changes

I consider the REST API the public API from a semantic versioning standpoint, and I aspire never
to have to release a v2 of mountebank. In my opinion, *the API is more important than the code
behind it*; we can fix the code, but we can't change the API once it's been documented. Therefore,
expect more scrutiny for API changes, and don't be offended if I recommend some changes. I often
agonize over the names in the API, and use tests to help me play with ideas.

Before API changes can be released, the documentation and
[contract page](http://www.mbtest.org/docs/api/contracts) need to be updated. The contract page
is, I hope, friendly for users, but a bit unfriendly for maintainers. I'd love help fixing that.

### Protocol Agnosticism

Most of mountebank is protocol-agnostic, and I consider central to its design. In general, every file
outside of the protocol folders (http, tcp, etc) should _not_ reference any of the request or response fields
(like http bodies). Instead, they should accept generic object structures and deal with them appropriately.
This includes all of the core logic in mountebank, including predicates, behaviors, and response resolution.
To help myself maintain that mentality, I often write unit tests that use a different request or response
structure than any of the existing protocols. This approach makes it easier to add protocols in the future
and ensures that the logic will work for existing protocols.

I aim in a [future version](https://github.com/bbyars/mountebank/issues/174) to completely separate
the protocol implementations as separate plugins, making protocol extension as easy as pie.

### Aim for the broadest reach

Many development decisions implicitly frame a tradeoff between the developers of mountebank and the users.  Whenever I
recognize such a tradeoff, I always favor the users.  Here are a few examples, maybe you can think of more, or inform
me of ways to overcome these tradeoffs in a mutually agreeable manner:

* The build and CI infrastructure is quite complex and slow, but I'd prefer that over releasing flaky software
* I aim for fairly comprehensive error handling with useful error messages to help users out
* Windows support can be painful at times, but it is a core platform for mountebank

## Coding mountebank
<commit_msg>Fixed out of date info<commit_after># Contributing to mountebank

Congratulations! You're here because you want to join the millions of open source developers
contributing to mountebank. The good news is contributing is an easy process. In fact, you can
make a difference without writing a single line of code. I am grateful for all of the following contributions:

* Submitting an issue, either through github or the [support page](http://www.mbtest.org/support)
* Commenting on existing issues
* Answering questions in the [support forum](https://groups.google.com/forum/#!forum/mountebank-discuss)
* Letting me know that you're using mountebank and how you're using it. It's surprisingly hard to find
that out with open source projects, and provides healthy motivation. Feel free to email at
<EMAIL>
* Writing about mountebank (bonus points if you link to the [home page](http://www.mbtest.org/))
* Creating a how-to video about mountebank
* Speaking about mountebank in conferences or meetups
* Telling your friends about mountebank
* Starring and forking the repo. Open source is a popularity contest, and the number of stars and forks matter.
* Convincing your company to let me announce that they're using mountebank, including letting me put their logo
on a web page (I will never announce a company's usage of mountebank without their express permission or a
pre-existing public writeup).
* Writing a client library that hides the REST API under a language-specific API
* Writing a build plugin for (maven, gradle, MSBuild, rake, gulp, etc)

Still want to write some code?  Great! You may want to keep the
[source documentation](https://mountebank.firebaseapp.com/)
handy, and you may want to review [the issues](https://github.com/bbyars/mountebank/issues).

I have two high level goals for community contributions. First, I'd like contributing to be as fun
as possible. Secondly, I'd like contributions to follow the design vision of mountebank.
Unfortunately, those two goals can conflict, especially when you're just getting started and
don't understand the design vision or coding standards. I hope this document helps, and feel free
to make a pull request to improve it! If you have any questions, I am more than happy to help
at <EMAIL>, and I am open to any all suggestions on how to make code contributions
as rewarding an experience as possible.

## Designing mountebank

The code in mountebank is now a few years old, and maintaining consistency of design vision
is key to keeping the code maintainable. The following describe key concepts:

### API changes

I consider the REST API the public API from a semantic versioning standpoint, and I aspire never
to have to release a breaking change of mountebank. In my opinion, *the API is more important than the code
behind it*; we can fix the code, but we can't change the API once it's been documented. Therefore,
expect more scrutiny for API changes, and don't be offended if I recommend some changes. I often
agonize over the names in the API, and use tests to help me play with ideas.

Before API changes can be released, the documentation and
[contract page](http://www.mbtest.org/docs/api/contracts) need to be updated. The contract page
is, I hope, friendly for users, but a bit unfriendly for maintainers. I'd love help fixing that.

### Protocol Agnosticism

Most of mountebank is protocol-agnostic, and I consider central to its design. In general, every file
outside of the protocol folders (http, tcp, etc) should _not_ reference any of the request or response fields
(like http bodies). Instead, they should accept generic object structures and deal with them appropriately.
This includes all of the core logic in mountebank, including predicates, behaviors, and response resolution.
To help myself maintain that mentality, I often write unit tests that use a different request or response
structure than any of the existing protocols. This approach makes it easier to add protocols in the future
and ensures that the logic will work for existing protocols.

### Aim for the broadest reach

Many development decisions implicitly frame a tradeoff between the developers of mountebank and the users.  Whenever I
recognize such a tradeoff, I always favor the users.  Here are a few examples, maybe you can think of more, or inform
me of ways to overcome these tradeoffs in a mutually agreeable manner:

* The build and CI infrastructure is quite complex and slow, but I'd prefer that over releasing flaky software
* I aim for fairly comprehensive error handling with useful error messages to help users out
* Windows support can be painful at times, but it is a core platform for mountebank

## Coding mountebank

{'fraction_non_alphanumeric': 0.04668690463728672, 'fraction_numerical': 0.0004187166335182665, 'mean_word_length': 4.6767676767676765, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 7, 'lorem ipsum': 0, 'www.': 6, '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': '6461009', 'n_tokens_mistral': 2418, 'n_tokens_neox': 2322, 'n_words': 1457}