# Repsoitory structure Service repositories consist at least of a package.json, a README.md and the CHANGELOG.md. Assuming is the desired service name, the folder structure would be similar to the following example: ```bash rsi.service./ ├── doc/ │ └── ... ├── test/ │ ├── custom.spec.ts │ └── ... ├── src/ │ └── ... ├──package.json ├── README.md └── CHANGELOG.md ``` ## doc/ The [Doc](./doc) contains service usage specifications - e.g. userstories. The folder MUST only hold `*.md`, `*.pdf` for text and `*.png`, `*.jpg`, `*.bmp`, `*.svg` and `*.puml` files in any subfolder. ## test/ This folder is optional and might contain custom tests the service. Only test which can to be autogenerated from `src/schema.json` go here. ## src/ The `src/` folder contains the the `schema.json` file, which defines the service itself. # Contribution In order to streamline contribution to RSI servcie definitions, some guidelines are described below. ## Git Commit Guidelines These rules are adopted from [the AngularJS commit conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/). ### Commit Message Format Each commit message starts with a **type**, a **scope**, and a **subject**. Below that, the commit message has a **body**. - **type**: what type of change this commit contains. - **scope**: what item of code this commit is changing. - **subject**: a short description of the changes. - **body** (optional): a more in-depth description of the changes ``` (): ``` Examples: ``` feat(ruler): add inches as well as centimeters ``` ``` fix(protractor): fix 90 degrees counting as 91 degrees ``` ``` refactor(pencil): use graphite instead of lead Closes #640. Graphite is a much more available resource than lead, so we use it to lower the price. ``` ``` fix(pen): use blue ink instead of red ink BREAKING CHANGE: Pen now uses blue ink instead of red. To migrate, change your code from the following: `pen.draw('blue')` To: `pen.draw('red')` ``` Any line of the commit message should not be longer 100 characters. This allows the message to be easier to read on github as well as in various git tools. ### Type Is recommended to be one of the below items. Only **feat** and **fix** show up in the changelog, in addition to breaking changes (see breaking changes section at bottom). * **feat**: A new feature * **fix**: A bug fix * **docs**: Documentation only changes * **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) * **refactor**: A code change that neither fixes a bug or adds a feature * **test**: Adding missing tests * **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation ### Scope The scope could be anything specifying place of the commit change. Usually, the affected resource is named here. ### Subject The subject contains succinct description of the change: * use the imperative, present tense: "change" not "changed" nor "changes" * don't capitalize first letter * no dot (.) at the end ### Breaking Changes Put any breaking changes with migration instructions in the commit body. If there is a breaking change, put **BREAKING CHANGE:** in your commit body, and it will show up in the changelog.