Skip to content
Permalink
Browse files

Reorganization and cleanup of README.md (#364)

* Initial split of README into legacy and contributing

* Update contributing steps
  • Loading branch information
alanbato authored and n8downs committed Jul 10, 2019
1 parent dbd85df commit 0bff51c31b216a4e2ccbf9fe61f5015ab82bd81c
Showing with 404 additions and 162 deletions.
  1. +44 −11 CONTRIBUTING.md
  2. +322 −0 LEGACY.md
  3. +38 −151 README.md
@@ -33,11 +33,28 @@ Contribution enquiries should take place before any significant pull request,
otherwise you risk spending a lot of time working on something that we might
have good reasons for rejecting.

## Pull requests
## Making Changes

Good pull requests - patches, improvements, new features - are a fantastic
help. They should remain focused in scope and avoid containing unrelated
commits.
If you'd like to test and/or contribute please follow these instructions.

[Fork this repo on GitHub](https://github.com/twitter/twemoji.git/fork)

### Setup

```bash
# clone your fork
git clone -b master https://github.com/$YOUR_USERNAME/twemoji.git/
cd twemoji
# install dependencies
yarn install
# Build and test your installation
yarn build
yarn test
```

### Making changes

Make sure to adhere to the coding conventions used throughout the codebase
(indentation, accurate comments, etc.) and any other requirements (such as test
@@ -48,21 +65,37 @@ project:

1. Create a new topic branch to contain your feature, change, or fix:

2. Commit your changes in logical chunks. Provide clear and explanatory commit
> If you'd like to test and/or propose some changes to the latest library version please change the `./scripts/generate` file at its end so that everything will be generated properly once launched.
1. Commit your changes in logical chunks. Provide clear and explanatory commit
messages. Use git's [interactive rebase](https://help.github.com/en/articles/about-git-rebase)
feature to tidy up your commits before making them public.

3. Locally merge (or rebase) the upstream development branch into your topic branch:
2. Run `yarn prepublish`. This will do several things:

1. Ask for the version number (See: [SemVer](https://semver.org/))
2. Build the project and put the built assets in `dist/`
3. Run the tests
4. Move the contents of the `dist/` directory to the `gh-pages` branch
5. Place the contents of the `dist/` directory in its correspoding versioned folder.
6. Commit the changes and push them to the `gh-pages` branch of your fork.

## Pull requests

Good pull requests - patches, improvements, new features - are a fantastic
help. They should remain focused in scope and avoid containing unrelated
commits.

4. Push your topic branch up to your fork:
1. Push your topic branch up to your fork: `git push origin my-feature-branch`

5. [Open a Pull Request](http://help.github.com/send-pull-requests/) with a
clear title and description.
2. [Open a Pull Request](http://help.github.com/send-pull-requests/) with a
clear title and description. One for your changes in `master` and another one for
your changes in `gh-pages`.

## License

By contributing your code:

You agree to license your contribution under the terms of the MIT (for code) and CC-BY (for graphics) licenses
https://github.com/twitter/twemoji/blob/gh-pages/LICENSE
https://github.com/twitter/twemoji/blob/gh-pages/LICENSE-GRAPHICS
<https://github.com/twitter/twemoji/blob/gh-pages/LICENSE>
<https://github.com/twitter/twemoji/blob/gh-pages/LICENSE-GRAPHICS>

0 comments on commit 0bff51c

Please sign in to comment.
You can’t perform that action at this time.