2014-03-04 16:39:34 +04:00
# Contributing
2016-07-26 12:32:22 +03:00
Contributions are most welcome! All `tldr` pages are stored in Markdown right here on GitHub.
Just open an issue or send a pull request and we'll incorporate it as soon as possible.
2016-09-24 20:03:50 +03:00
To get started, sign the [Contributor License Agreement ](https://cla-assistant.io/tldr-pages/tldr ).
2014-03-04 16:39:34 +04:00
2016-07-24 10:05:21 +03:00
*Note*: when submitting a new command, don't forget to check if there's already a pull request in progress for it.
2015-04-12 22:54:27 +03:00
2014-03-04 16:39:34 +04:00
## Guidelines
2016-07-24 10:05:21 +03:00
The basic format of a `tldr` page is a set of concrete usage examples.
2016-01-07 22:53:19 +03:00
Here are a few guidelines to get started:
2014-03-04 16:39:34 +04:00
2015-12-25 13:20:32 +03:00
1. Focus on the 5 or 6 most common usages. It's OK if the page doesn't cover everything; that's what `man` is for.
2. When in doubt, keep new command-line users in mind. Err on the side of clarity rather than terseness.
2016-07-26 12:32:22 +03:00
3. Try to incorporate the spelled-out version of single-letter options in the example's description.
The goal is to allow people to *understand* the syntax of the commands, not just *memorize* it.
2015-12-25 13:20:32 +03:00
4. Introduce options gradually, starting with the simplest commands and using more complex examples progressively.
5. Use short but descriptive values for the tokens, ex. `{{source_file}}` or `{{wallet.txt}}` .
2016-07-26 12:32:22 +03:00
6. Focus on details specific to the command, and avoid explaining general UNIX concepts that could apply to any command
(ex: relative/absolute paths, glob patterns/wildcards, special character escaping...).
2014-03-04 16:39:34 +04:00
2016-01-07 22:53:19 +03:00
The best way to be consistent is to have a look at a few existing pages :).
2014-03-04 16:39:34 +04:00
## Markdown format
2015-08-25 06:07:19 +03:00
The format of each page should match the following:
2014-03-04 16:39:34 +04:00
```
# command-name
2016-01-07 22:53:19 +03:00
> Short, snappy description.
2016-01-08 05:01:59 +03:00
> Preferably one line; two are acceptable if necessary.
2014-03-04 16:39:34 +04:00
2016-01-07 22:53:19 +03:00
- Example description:
2014-03-04 16:39:34 +04:00
2015-08-25 03:16:26 +03:00
`command -opt1 -opt2 -arg1 {{arg_value}}`
2014-03-04 16:39:34 +04:00
2016-01-07 22:53:19 +03:00
- Example description:
2014-03-04 16:39:34 +04:00
2015-08-25 03:16:26 +03:00
`command -opt1 -opt2`
2014-03-04 16:39:34 +04:00
```
2016-01-22 02:35:37 +03:00
We actually have a linter/formatter that enforces our format.
2016-07-24 10:05:21 +03:00
It is run automatically on every pull request,
but you may install it to test your contributions locally before submitting them:
2016-01-22 02:35:37 +03:00
```
2016-07-24 10:05:21 +03:00
npm install tldr-lint
tldrl -f {{page.md}}
2016-01-22 02:35:37 +03:00
```
2016-07-24 10:05:21 +03:00
For other ways to use `tldrl` , such as linting an entire directory, check out (what else!)
[`tldr tldrl` ](https://github.com/tldr-pages/tldr/blob/master/pages/common/tldrl.md )
### Token syntax
2016-08-12 10:45:35 +03:00
User-provided values should use the `{{token}}` syntax
in order to allow clients to highlight them.
Use [`snake_case` ](https://en.wikipedia.org/wiki/Snake_case )
for multi-word tokens.
2015-08-25 03:16:26 +03:00
2016-08-12 10:45:35 +03:00
Keep the following guidelines in mind when choosing token names:
- If the example is clearer with an actual value rather than a generic placeholder, use the actual value. For example, use `iostat {{2}}` rather than `iostat {{interval_in_secs}}` .
- For any reference to paths to files or folders, use `{{path/to/<placeholder>}}` . For example, `ln -s {{path/to/file}} {{path/to/symlink}}` . In case of a possible reference both to a file or a folder, use `{{path/to/file_or_folder}}`
- If a command expects the file to have a particular extension, use it. For example, `unrar x {{compressed.rar}}` . In case needs a generic extension, use `{{.ext}}` , but **only** if it helps to clarify the command. For example, here:
```
Open all the files of a given extension in the current directory with the associated application:
open {{*.ext}}
```
... using `{{.ext}}` helps to clarify the command. But in a command like `wc -l {{file}}` , using `{{file}}` is sufficiently clear.
- Lastly, follow the `{{path/to/<placeholder>}}` convention when there is a path-related command. Not when the file location is implicit. But of course, use proper judgement, keeping simplicity and user friendliness as the top priority.
2016-01-07 22:53:19 +03:00
2016-07-26 12:32:22 +03:00
In short, make it as intuitive as possible
for the user to figure out how to use the command
and fill it in with values.
2015-12-29 03:36:49 +03:00
## Submitting a pull request
2016-07-24 10:05:21 +03:00
For submitting changes, you can use whatever workflow you're more comfortable with.
2016-07-26 12:32:22 +03:00
### Using Github's web interface
The easiest way to submit a change is to just edit the page directly on the Github interface.
2016-07-24 10:05:21 +03:00
Check out the step-by-step instructions (with screenshots) on
[Github Help ](https://help.github.com/articles/editing-files-in-another-user-s-repository/ ).
2015-12-29 03:36:49 +03:00
2016-07-26 12:32:22 +03:00
### Using the command line
2015-12-29 03:36:49 +03:00
2016-07-26 12:32:22 +03:00
Alternatively, you can do most of the process using the command line:
2015-12-29 03:36:49 +03:00
2016-07-26 12:32:22 +03:00
- fork the repository on the github web interface
2015-12-29 03:36:49 +03:00
2016-07-26 12:32:22 +03:00
- clone your fork locally:
`git clone https://github.com/{{your_username}}/tldr.git && cd tldr`
2015-12-29 03:36:49 +03:00
2016-07-26 12:32:22 +03:00
- create a feature branch, e.g. named after the command you plan to edit:
`git checkout -b {{branch_name}}`
2015-12-29 03:36:49 +03:00
2016-07-24 10:05:21 +03:00
- make your changes (edit existing files or create a new one)
2016-01-19 16:28:43 +03:00
2016-07-26 12:32:22 +03:00
- commit the changes:
`git commit --all -m "{{commit_message}}"`
2016-08-12 10:45:35 +03:00
2016-07-26 12:32:22 +03:00
- push to your fork:
`git push`
2016-08-12 10:45:35 +03:00
2016-07-24 10:05:21 +03:00
- go to the github page for your fork and click the green pull request button.
2015-12-29 03:36:49 +03:00
2016-07-24 10:05:21 +03:00
Please send only related changes in the same pull request.
Typically a pull request will include changes in a single file.
2016-01-25 01:37:37 +03:00
2016-07-24 10:05:21 +03:00
### Commit message
2015-12-29 03:36:49 +03:00
2016-07-24 10:05:21 +03:00
For the commit message, use the following format:
2016-01-03 13:01:16 +03:00
2016-07-24 10:05:21 +03:00
< command > : type of change
2015-12-29 03:36:49 +03:00
2016-07-24 10:05:21 +03:00
Examples:
- `ls: add page`
- `cat: fix typo`
- `git-push: add --force example`
- `uname: fix -a example`
2015-12-29 03:36:49 +03:00
## Licensing
2016-07-24 10:05:21 +03:00
`tldr` is licensed under the [MIT license ](https://github.com/tldr-pages/tldr/blob/master/LICENSE.md ).
2014-03-04 16:39:34 +04:00
2016-07-24 10:05:21 +03:00
**IMPORTANT**: By submitting a patch, you agree to license your work
under the same license as that used by the project.
2014-03-04 16:39:34 +04:00
2016-07-26 12:32:22 +03:00
You're free to modify or redistribute the content.
That being said, but why not contribute over here? :)
Say if you wanted to have `tldr` pages in `groff` format,
why not have a client that uses [pandoc ](http://johnmacfarlane.net/pandoc/ )
and periodically updates straight from this repo?