Initial readme and contribution guide

# CODE OF CONDUCT

## Our Pledge

In the interest of fostering an _open and welcoming_ environment, we as

contributors and maintainers pledge to making participation in our project and

our community a harassment-free experience for everyone, regardless of age, body

size, disability, ethnicity, gender identity and expression, level of experience,

education, socio-economic status, nationality, personal appearance, race,

religion, or sexual identity and orientation.

## Our Standards

Examples of behavior that contributes to creating a positive environment

include:

* Using welcoming and inclusive language

* Being respectful of differing viewpoints and experiences

* Gracefully accepting constructive criticism

* Focusing on what is best for the community

* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or

  advances

* Trolling, insulting/derogatory comments, and personal or political attacks

* Public or private harassment

* Publishing others' private information, such as a physical or electronic

  address, without explicit permission

* Other conduct which could reasonably be considered inappropriate in a

  professional setting

## Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable

behavior and are expected to take appropriate and fair corrective action in

response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or

reject comments, commits, code, wiki edits, issues, and other contributions

that are not aligned to this Code of Conduct, or to ban temporarily or

permanently any contributor for other behaviors that they deem inappropriate,

threatening, offensive, or harmful.

## Scope

This Code of Conduct applies both within project spaces and in public spaces

when an individual is representing the project or its community. Examples of

representing a project or community include using an official project e-mail

address, posting via an official social media account, or acting as an appointed

representative at an online or offline event. Representation of a project may be

further defined and clarified by project maintainers.

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be

reported by contacting the project leader of the latest [TTCN-3 project of the

MTS body](https://portal.etsi.org/xtfs/#/). All complaints will be reviewed and

investigated and will result in a response that is deemed necessary and

appropriate to the circumstances. The project team is obligated to maintain

confidentiality with regard to the reporter of an incident. Further details of

specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good

faith may face temporary or permanent repercussions as determined by other

members of the project's leadership.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,

available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

[homepage]: https://www.contributor-covenant.org

[Code of Conduct for ETSI Members]: https://portal.etsi.org/Resources/ETSI-Directives

## Creating a Change Request

[Create a brief issue](https://labs.etsi.org/rep/ttcn3/standard/-/issues/new)

describing desired change request and choose a template that fits your request

best:

![issue templates](assets/issue-templates.png)

The **Editorial Changes** template is used for changes that do not affect

meaning of the standard. For example, fixing typos, grammar, or formatting.

Create a **Bug Report** if the standard does not specify TTCN-3 as intended. For

example, if two specifications contradict each other, or if an example does not

reflect defined behavior.

**Clarification Needed** is used when the standard is unclear or ambiguous. For

example, if a term is not defined, or if an enumeration is missing a value and

it is unclear if this is on purpose.

A **Feature proposal** is used to suggest new features, interfaces, documents

or changes to existing ones.  

You do not need to provide a full specification document, yet. It is practice

to discuss the proposal first and create the document when the proposal is

accepted and all details are clear.

## The Process

### Overview

GitLab is a powerful tool that can be used in many ways, it is easy to get lost

in finding the perfect process. Therefore we deliberately keep it to a bare

minimum initially, and improve it later based on our experience and needs.

![sidebar](assets/gitlab-sidebar.png)

Everything sits in a single repository. Our GitLab project has a few major

sections, reachable via sidebar. Our main focus is on **Issuess**. The other

sections **Repository**, **Merge Requests**, **CI/CD**, **Deployments** are

related to version control and open source development processes, which we do

not use at the moment.

### Working on Change Requests

* der process ist wie bei mantis, aber andere oberfläche und andere begriffe

* Der state funktioniert via label (tags)

* kanban board

* columns

* label based

* issues are added and moved through the columns/stages

An Issue moves through the following stages:

### 1. Create Issue

### 2. To-Do

### 3. Work In Progress

### 4. Ready for Review

### 5. Done

### 6. Closed

Issues that are reviewed and do not need further refinement are moved to the "Done" column

Before you close an issue, make

**By Design**

This issue was examined and we decicded it wasn't a problem after all.

**Duplicate**

This issue already exists.

**Fixed**

This issue was fixed.

**Won't Fix**

This issue examined and we decided to live with it.

## Guidelines for Writing

* Use British English in normative Text. For example, use "colour" instead of

  "color", "behaviour" instead of "behavior".

* For normative text use *shall* and *shall not*. Inside informative text never

  use *shall*, use *must* instead.

* Use singular instead of plural.

* Don't say the same thing normatively in more than on place; say it once and

  point to that place, as needed.

* Normative text must be clear without examples and notes.

* A section should contain either subsections or text, but never both.

* Keep examples small, simple, and narrowly focused without using unnecessary

  features.

* Avoid using quoted text, as in "natural type". If it is a term, except for

  its first use, it should be in regular font without the quotes and defined in

  the Terms-and-definitions clause. If it is not a term use the right term or

  other English text.

* Technical terms should be defined in the Terms-and-definitions clause.

* Avoid enumerations where a term exists. For example, don't say

Copyright 2022 ETSI

Redistribution and use in source and binary forms, with or without 

modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, 

   this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, 

   this list of conditions and the following disclaimer in the documentation 

   and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors 

   may be used to endorse or promote products derived from this software without 

   specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND 

ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 

WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 

IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, 

INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 

BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 

DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 

LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE 

OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED 

OF THE POSSIBILITY OF SUCH DAMAGE.

# TTCN-3 language standard

# TTCN-3 Standard

* the tool should serve us, not the other way round. Reduce overhead/automate

* minimal setup and only grow/complicate when needed

  * one repository for planning, issues, standard, conformance-tests

  * milestone+issues+labels instead of iterations+epics+...

  * the standard itself (first docx, later markdown?)

* document processes to make it easier for newcomers to participate/contribute

* seed for further improvement (markdown, formatting, automatic conformance tests)

## Workflow

* Beguendungen:

  * Board dient zum synchronisieren (und ersetzt die Mantis States). Signalisiert wann bereit zum Review, schliessen, ...

  * Milestones, sind nciht notwendig, aber hilfreich um zu sehen wie weit wir sind.

try to be close to previous mantis process without making gitlab complicated.

* issue (what templates should I create?)

* board (workflow)

This is the working space for [ETSI TC MTS TTF T040 and

previous](https://portal.etsi.org/xtfs/#/xTF/T040/).  

It does _not_ contain the actual TTCN-3 standard deliverables. If you are

looking for the TTCN-3 standard, please visit the [ETSI

website](https://www.ttcn-3.org/) or its [download

section](https://www.ttcn-3.org/index.php/downloads/standards)

## Change Request

You can request changes by creating an issue or merge request. Have a look at

the [contribution guidelines](CONTRIBUTING.md#creating-a-change-request) for

more information.