Community Standards

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,128 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders 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, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+ecdar@cs.aau.dk.
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.

.github/CONTRIBUTING.md

@@ -0,0 +1,96 @@
+# Contributing
+When contributing to this repository, make your own fork and create pull requests to this repo from there.
+
+## Issues
+If you find a bug or a missing feature, feel free to create an issue. The system is continuously under development and suggestions are always welcome.
+
+### Bugs
+To increase the chances of the issue being resolved, please include the following (or use the `Bug Report` issue template):
+- Concise title that states the issue
+- An in-depth description of the issue
+  - What happened
+  - What was expected to happen
+  - Suggestion on possible cause [Not required]
+- Images (if relevant)
+
+### Feature
+To increase the chances of the issue being resolved, please include the following (or use the `Feature Request` issue template):
+- Concise title that describes the feature
+- An in-depth description of the feature
+  - What is the feature
+  - Use case
+  - How should it work for the user
+  - Suggestions for implementation [Not required]
+- Reasoning behind the request
+  - Added value
+  - Improved user experience
+
+> :information_source: To help organising the issue, please attach relevant tags (eg. `bug`, `feature`, etc.).
+
+## Pull Requests
+Pull requests are continuously being reviewed and merged. In order to ease this process, please open a pull request as draft, as long as it is under development, to notify anyone else that a given feature/issue is being worked on.
+
+Additionally, please add `Closes #{ISSUE_ID}` if the pull request is linked to a specific issue. If a PR addresses multiple pull requests, please add `Closes #{ISSUE_ID}` for each one.
+
+A CI workflow is executed against all pull requests and must succeed before the pull request can be merged, so please make sure that you check the workflow status and potential error messages.
+
+## Tests
+All non-UI tests are executed as part of the CI workflow and hence must succeed before merging. The tests are written with JUnit and relevant tests should be added when new code is added. If you are new to JUnit, you can check out syntax and structure [here](https://junit.org/junit5/docs/current/user-guide/).
+
+The test suite can be executed locally by running:
+```shell
+./gradlew test
+```
+
+> :information_source: Currently, the codebase has high coupling, which has made testing difficult and the test suite very small.
+
+### UI Tests
+For features that are highly coupled with the interface, a second test suite has been added under `src/test/java/ecdar/ui`. These tests are excluded from the `test` task are can be executed by running:
+```shell
+./gradlew uiTest
+```
+These tests are more intensive to run and utilizes a robot for interacting with a running process of the GUI. The tests are implemented using [TestFX](https://github.com/TestFX/TestFX). As these tests are more intensive, they are not run as part of the standard CI workflow.
+
+You should prefer writing non-UI tests, as they are less demanding and are part of the CI workflow.
+
+## Code Organisation
+The code within the project is structure based on the Model-View-ViewModel (**MVVM**) architectural pattern. However, the terms _Abstraction_, _Presentation_, and _Controller_ are used instead of _Model_, _View_, and _View-Model_ respectively.
+This means that each element in the system consists of:
+- An _Abstraction_ (located in `abstractions` package).
+- A _Controller_ (located in `controllers` package).
+- A _Presentation_ (located in `presentations` package).
+    - Most of the presentations are related to an `FXML` markup file that specifies the look of the presentation. These files are located in `src/main/resources/ecdar/presentations`.
+
+In addition to these, a `utility` package is used for additional business logic to improve separation of concern and enhance the testability of the system.
+
+### Abstractions
+The abstractions are used to represent logical elements, such as `components`, `locations`, and `edges`. These classes should mostly be pure data objects. They are used to save and load data to and from existing project files.
+
+### Controllers
+The controllers contain the business logic of the system. They function as the link between the UI and the abstractions.
+This is implemented such that an action performed to an element in the UI triggers a method inside the controller, which then alters the state of the related abstraction.
+
+They implement the `Initializable` interface and are initialized through their associated presentation when an instance of that is instantiated. Hierarchically, a presentation therefore contains a controller.
+
+Each controller controls an instance of its related abstraction. If an action to one element should affect another element, this effect is enforced through the controller.
+
+### Presentations
+As mentioned above, most of the presentations are split into a Java class and an FXML markup file. The Java class can be seen as a shell to initialize the FXML element from inside the business logic. It initializes the related controller and ensures that any needed elements are set within it. This allows the controllers to be initialized without any UI elements, which is very useful for testing, while ensuring that they are correctly connected while the UI is running.
+
+The FXML files are markup specifying how the elements should look in the UI and have a reference to the related controller. Each element that should be addressable or changeable from the controller has an `fx:id` that is directly referenced as a member inside the controller. The direct connection to a controller allows events, such as `onPressed`, to trigger the correct methods in the controller and also helps IDEs identified any potentially missing methods or members.
+
+> :question: **Why use both a controller and a presentation Java file?**\
+> The advantage of during this is that the `controller` can contain all the business logic and bindings to the FXML elements, while the `presentation` can be used to instantiate and reference the UI elements inside the Java code. The `controller` should contain the logic and is bound within the FXML file, so the `presentation` Java file should be seen as a shell.
+
+### Utility
+To increase the testability and separation of concern further, the `utility` package is introduced. This package includes useful functionality that is either used in multiple unrelated classes or outside the responsibility of the given class.
+
+An example of one of the classes located in this package is the `UndoRedoStack` used to keep track of actions performed by the user.
+
+### Miscellaneous
+Besides the packages mentioned above, some larger functionalities are located in their own packages. Here is a small description of each:
+- `backend`: Responsible for the communication with the engines and model checking.
+- `code_analysis`: Responsible for analysing the elements of the current project and construct messages if errors or warnings are encountered.
+- `issues`: Classes for representing `Errors`, `Issues`, and `Warnings`.
+- `model_canvas.arrow_heads`: Arrowheads used in the UI to visualize the direction of edges.
+- `mutation [Deprecrated]`: Functionality for supporting mutation testing of components. **This feature is currently not implemented in the engines and is therefore currently not supported**.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,44 @@
+---
+name: Bug
+about: File a bug report
+title: '[BUG] <title>'
+labels: bug
+assignees: ''
+---
+
+<!--
+Note: Please search to see if an issue already exists for the bug you encountered.
+-->
+
+### Description
+<!--
+Should include:
+1. What happened
+2. What was expected to happen
+3. Suggestion on possible cause [Not required]
+-->
+#### Where was the error encountered
+- [ ] Using a distribution from the main ECDAR repository
+
+
+- [ ] Using a local JDK 
+  - **Used JDK** (ex. Zulu 11.62.17 JDK FX 11.0.18):
+  - **Operating System**:
+    - [ ] Linux
+    - [ ] MacOS Arm
+    - [ ] MacOS Intel
+    - [ ] Windows
+
+### Steps To Reproduce
+<!--
+Example: steps to reproduce the behavior:
+1. In this environment...
+2. With this config...
+3. Run '...'
+4. See error...
+-->
+
+### Images
+<!--
+Links? References? Anything that will give us more context about the issue that you are encountering!
+-->

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,25 @@
+---
+name: Feature
+about: Suggest a new feature
+title: '[Feature] <title>'
+labels: enhancement
+assignees: ''
+---
+
+<!--
+Note: Please search to see if an issue already exists for the feature you request.
+-->
+
+### Description
+<!--
+Should include:
+1. What is the feature
+2. Use case
+2. How should it work for the user
+3. Suggestions for implementation [Not required]
+-->
+
+### Reason For Request
+<!--
+Explanation for the request and how it will improve the system/user experience
+-->

.github/pull_request_template.md

@@ -0,0 +1,4 @@
+Closes #{ISSUE_ID}
+
+### Changes/Additions:
+-