Contributing¶

Code of conduct
Question or problem
Issues and bugs
Feature requests
Submission guidelines
Coding rules
Commit message guidelines
Developing

Code of conduct¶

Please read and follow code of conduct.

Question or problem¶

Please read the support.

Found a bug¶

Submitting an issue
Submitting a pull request

Submission guidelines¶

Submitting an issue¶

Before submitting an issue to the Project, search the issue tracker to see if a similar problem already exists. The Project requires a minimal reproduction to confirm and fix bugs efficiently, which also helps the developers identify coding problems. If the Project doesn’t receive a minimal reproduction, they may close the issue without investigating or fixing it.

Submitting a pull request¶

Search GitHub for related open or closed PR on GitHub to avoid duplicating existing efforts.
Describe your issue accurately and discuss the design beforehand to increase the chances of your work being accepted by the Project.
Fork the attilasomogyi and repository name.
In your forked repository, make your changes in a new Git branch:
```
git checkout -b my-fix-branch main
```
Create your patch, including appropriate test cases.
Follow the Coding Rules
Run the full test suite, because described in the developer documentation, and ensure that all tests pass.
Commit your changes by using a descriptive commit message that follows the Project commit message conventions. Adherence to these conventions is necessary because release notes are automatically generated from these messages.
```
git commit --all
```
Note: the optional commit -a command line option is going to automatically “add” and “rm” edited files.
Push your branch to GitHub:
```
git push origin my-fix-branch
```
In GitHub, send a pull request to asterisk-configuration-files:main.

Reviewing a pull request¶

The Project team reserves the right not to accept pull requests from community members who haven’t been good citizens of the community. Such behavior includes not following the Project code of conduct and applies within or outside of Project managed channels.

Addressing review feedback¶

If the Project asks for changes on code reviews then:

Make the required updates to the code.
Re-run the test suites to ensure tests are still passing.
Create a fixup commit and push to your GitHub repository (this is going to update your Pull Request):
```
git commit --all --fixup HEAD
git push
```

That’s it. Thank you for your contribution.

Updating the commit message¶

A reviewer might often suggest changes to a commit message (for example, to add more context for a change or adhere to commit message guidelines of the Project). To update the commit message of the last commit on your branch:

Check out your branch:
```
git checkout my-fix-branch
```
Change the last commit and change the commit message:
```
git commit --amend
```
Push to your GitHub repository:
```
git push --force-with-lease
```

NOTE: If you need to update the commit message of an earlier commit, you can use git rebase in interactive mode. See the git docs for more details.

After the project have merged your pull request¶

Vou can delete your branch and pull the changes from the main upstream repository:

Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
```
git push origin --delete my-fix-branch
```
Check out the main branch:
```
git checkout main -f
```
Delete the local branch:
```
git branch -D my-fix-branch
```
Update your local main with the latest upstream version:
```
git pull --ff upstream main
```

Coding rules¶

To ensure consistency throughout the source code, keep these rules in mind as you are working:

One or more specs unit-tests must test all features or bug fixes.
Documenting all public API methods is a requirement.

Project follows¶

File and directory name conventions¶

File name regexp select: ^[a-z0-9]+(?:-[a-z0-9]+)*\.[a-z0-9]+$
Directory name regexp select: ^[a-z0-9]+(?:-[a-z0-9]+)*$
Keep it simple
Don’t capitalize letters
Use hyphens for spaces
Separate words with hyphens
Avoid special characters

Commit message format¶

This specification draws inspiration from theAngular JS commit message format, and supersedes it.

The Project enforces specific rules on how to format Git commit messages. This format leads to easier to read commit history.

Each commit message consists of a header, a body, and a footer.

<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and must conform to the Commit Message Header format.

The body is mandatory for all commits except for those of classification docs. When the body is present it must be at least 20 characters long and must conform to the Commit message body format.

The footer is optional. The Commit message footer format explains the purpose of the footer and outlines its required structure.

Commit message header¶

<type>(<scope>): <short summary>
  │       │             │
  │       │             └─⫸ Summary in present tense.
  |       |                  Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit Scope: directory name or file name without extension
  |                         (for example: changelog, code-of-conduct, readme)
  │
  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test

The <type> and <summary> fields are mandatory, the (<scope>) field is optional.

Type¶

Must be one of the following:

build: Changes that affect the build system or external dependencies example scopes: gulp, broccoli, npm
ci: Changes to Project CI configuration files and scripts examples: Circle Ci, Sauce Labs
docs: Documentation only changes
feat: A new feature
fix: A bug fix
perf: A code change that improves performance
refactor: A code change that neither fixes a bug nor adds a feature
test: Adding missing tests or correcting existing tests

Scope¶

The scope should be the name of the npm package affected (like perceived by the person reading the changelog generated from commit messages).

The following is the list of supported scopes:

filename without extension for example: changelog, code-of-conduct, readme
none or empty string: useful for test and refactor changes that are done across all packages (for example: test: add missing unit tests) and for docs changes that aren’t related to a specific package (for example: docs: fix typo in tutorial).

Summary¶

Use the summary field to give a succinct description of the change:

use the imperative, present tense: change not changed nor changes
don’t capitalize the first letter
no dot . at the end

Commit message body¶

Just like in the summary, use the imperative, present tense: fix not fixed nor fixes

Explain the motivation for the change in the commit message body. This commit message should explain why you are making the change. You can include a comparison of the earlier behavior with the new behavior to illustrate the impact of the change.

Commit message footer¶

The footer can contain information about breaking changes and deprecations. It is also the place to reference GitHub issues, Jira tickets, and other PRs that this commit closes, or it’s relate to. For example:

BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Fixes #<issue number>

DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
<BLANK LINE>
Closes #<pr number>

Breaking Change section should start with the phrase BREAKING CHANGE:. It follows by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.

Similarly, a Deprecation section should start with DEPRECATED:. It follows by a short description of what’s deprecated, a blank line, and a detailed description of the deprecation that also mentions the recommended update path.

Revert commits¶

If the commit reverts an earlier commit, it should begin with revert:, followed by the header of the reverted commit.

The content of the commit message body should contain:

information about the Secure Hash Algorithm of the commit reverts in the following format: This reverts commit <Secure Hash Algorithm>,
a clear description of the reason for reverting the commit message.

Developing¶

Prerequisites¶

Getting the sources¶

Fork and clone the repository:

Login to your GitHub account
Fork the attilasomogyi/asterisk-configuration-files repository
Clone your fork of the asterisk-configuration-files repository and define an upstream remote pointing back to the asterisk-configuration-files repository that you forked in the first place.

git clone --recurse-submodules \
git@github.com:<github username>/asterisk-configuration-files.git

cd asterisk-configuration-files

git remote add upstream \
git://github.com/attilasomogyi/asterisk-configuration-files.git

Installing¶

yarn setup

Testing¶

yarn test