Theaninova/openstapps
1
0
Fork 0
mirror of https://gitlab.com/openstapps/openstapps.git synced 2026-01-19 08:02:55 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs: fix markdown errors and update

Browse Source
This commit is contained in:
Rainer Killinger
2020-10-30 17:45:49 +01:00
parent 5f34bc900c
commit ccb1b56a0f
8 changed files with 29 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
project-docs/workflow/COMMITS.md
View File

@@ -50,7 +50,7 @@ The result of those commit guidelines is a concise and clear history of the deve
Another advantage is the automatic [generation](https://www.npmjs.com/package/conventional-changelog-cli) of a changelog that gives an overview of the changes.
```
```shell
conventional-changelog -p angular -i CHANGELOG.md -s -r 0
```

11
project-docs/workflow/DOCUMENTATION.md
View File

@@ -1,6 +1,6 @@
# Documentation
Every projects need a `README.md` as a standardized entry of information about the scope of a [project](PROJECT.md) and how to install and execute it.
Every projects need a `README.md` as a standardized entry of information about the scope of a [project](PROJECT.md) and how to install and execute it.
## Inline (code) documentation
@@ -10,7 +10,7 @@ Code is annotated with [TypeDoc](https://typedoc.org/), which then can be used t
Please follow these guidelines to reduce redundance:
* The purpose of inline documentation is to explain what the line of code actually does without explaining syntax or external references. Example:
* The purpose of inline documentation is to explain what the line of code actually does without explaining syntax or external references. Example:
```typescript
// extend the template by the properties of the base template
@@ -36,10 +36,12 @@ async get<T>(key: string): Promise<T> {
return entry;
}
```
### Inline Comments `//`
* Start inline comments with a lowercase letter and a space after the `//`
* Place the comment above the line that it is referencing
```typescript
// lorem ipsum
const lorem;
@@ -55,10 +57,11 @@ const lorem;
* Document all parameters in functions using `@param`
* `@param` must not contain a type annotation, just `@param name description`
* Do not include `@return`, as it is redundant information
```typescript
/**
* Short summary of the function, without a period
*
*
* This is a very long description, that could never possibly fit on one line, nor could it
* be read in a short amount of time. Because we can use multiple sentences here, we can actually
* use a period.
@@ -70,7 +73,7 @@ function fun(foo: number): Foo {
## `CONTRIBUTING.md`
Every project can have a `CONTRIBUTING.md` which explains how to contribute to the project either just by issues or code contributions.
Every project can have a `CONTRIBUTING.md` which explains how to contribute to the project either just by issues or code contributions.
## Issue templates

8
project-docs/workflow/LICENSING.md
View File

@@ -10,7 +10,7 @@ Copy the license from [projectmanagement](../../LICENSE) or the [official standa
According to the GPLv3 guidelines for [adding the license to a new program](http://www.gnu.org/licenses/gpl-3.0-standalone.html#howto) a license note should be added at the beginning of each source file.
```
```typescript
/*
* Copyright (C) <year> StApps
* This program is free software: you can redistribute it and/or modify it
@@ -30,14 +30,16 @@ According to the GPLv3 guidelines for [adding the license to a new program](http
### New Files
The `<year>` should be inserted with the current year. E.g.:
```
```typescript
* Copyright (C) 2019 StApps
```
### Updating Files
If the file is updated in a new year after its creation, the `<year>` should be appended as a comma seperated list with spaces in between. E.g.:
```
```typescript
* Copyright (C) 2018, 2019, 2021 StApps
```

2
project-docs/workflow/MERGING.md
View File

@@ -1,6 +1,6 @@
# Merging & merge requests
Once development of an [issue](ISSUES.md) on a [branch](BRANCHING.md) is completed the merge request becomes relevant. It also can be used during development for continuous reviews and iterative improvements.
Once development of an [issue](ISSUES.md) on a [branch](BRANCHING.md) is completed the merge request becomes relevant. It also can be used during development for continuous reviews and iterative improvements.
A merge request can also gather the work of multiple issues.

4
project-docs/workflow/PUBLISHING.md
View File

@@ -4,7 +4,7 @@
All projects that use the [OpenStApps configuration](https://gitlab.com/openstapps/configuration) and implement the automatic publishing via GitLab CI can simply be published to the NPM registry by using the appropriate job. It uses the `NPM_AUTH_TOKEN` that is a [protected variable](https://gitlab.com/groups/openstapps/-/settings/ci_cd) of the OpenStApps group. To trigger this job, a new tag has to be created (on the master branch):
### Use current [master branch](BRANCHING.md):
### Use current [master branch](BRANCHING.md)
```shell
git checkout master
@@ -16,7 +16,7 @@ git pull
```shell
npm version (major|minor|patch)
```
After these steps there should 2 new commits:
* A version commit