doc: add adr

app/build.gradle.kts

@@ -103,8 +103,13 @@ android {
                 }
             }
         }
+
+        val sharedTestDir = file("src/sharedTest/kotlin")
         getByName("androidTest") {
-            java.srcDirs("src/androidTest/kotlin")
+            java.srcDirs("src/androidTest/kotlin", sharedTestDir)
+        }
+        getByName("test") {
+            java.srcDirs("src/test/kotlin", sharedTestDir)
         }
     }
 }

doc/adr/0000-template-lightway-adr.md

@@ -0,0 +1,24 @@
+# Decision record template by Michael Nygard
+
+This is the template in [Documenting architecture decisions - Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
+You can use [adr-tools](https://github.com/npryce/adr-tools) for managing the ADR files.
+
+In each ADR file, write these sections:
+
+# Title
+
+## Status
+
+What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
+
+## Context
+
+What is the issue that we're seeing that is motivating this decision or change?
+
+## Decision
+
+What is the change that we're proposing and/or doing?
+
+## Consequences
+
+What becomes easier or more difficult to do because of this change?

doc/adr/0001-record-architecture-decisions.md

@@ -0,0 +1,26 @@
+# 1. Record architecture decisions
+
+Date: 2024-08-05
+
+## Status
+
+Accepted
+
+## Context
+
+We agreed in the past to use ADR's, but we lost track of it as we were using confluence to keep
+them. This concern was raised in the last collective, and we need to decide how to proceed.
+
+## Decision
+
+We will use Architecture Decision Records in the code and as part of the review process.
+We will use the [Lightway ADR template](0000-template-lightway-adr.md) to keep the ADRs simple and
+easy to maintain.
+
+## Consequences
+
+- We need to add a new folder to the repository, `doc/adr`, to keep the architecture decision
+  records.
+- Whenever a new refactoring or library is introduced, a new ADR should be created.
+- You can always request in the Pull request review process to add a new ADR, if you think it's
+  necessary.

doc/adr/0002-calling-activities-refactor.md

@@ -0,0 +1,31 @@
+# 2. Calling activity refactor
+
+Date: 2024-08-01
+
+## Status
+
+Accepted
+
+## Context
+
+To support a second incoming call we need to refactor the code so we can handle the ongoing content
+context, without losing the current context.
+
+This is a retroactive decision record implemented
+on https://github.com/wireapp/wire-android/pull/3264
+
+## Decision
+
+Create 2 separate activities, one for the Incoming/Outgoing calls and another for the ongoing call.
+In this way, we can keep the context of the ongoing call and handle the incoming/outgoing calls.
+
+The design and interaction will look like this:
+
+<img src="https://github.com/user-attachments/assets/66f19cce-c2bc-4777-a0eb-b5cda035df8a"/>
+
+## Consequences
+
+- StartingActivity will handle Incoming and Outgoing calls content, these contents are disposable
+  and can be recreated when receiving a new call.
+- OngoingCallActivity will handle the ongoing call content, this content is not disposable and
+  should be kept during the call.

doc/adr/0003-introducing-junit5-parametrizable-tests.md

@@ -0,0 +1,21 @@
+# 3. Use parameterizable tests in JUnit5
+
+Date: 2024-08-05
+
+## Status
+
+Proposed
+
+## Context
+
+Sometimes we need to write multiple tests for the same scenario, changing only the input values.
+
+## Decision
+
+We will use parameterizable tests in JUnit5 to avoid writing multiple tests for the same scenario.
+
+## Consequences
+
+- Introduction of `@ParameterizedTest` annotation in the test class
+  and [library](https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests).
+- The test method will receive the parameters as arguments.