-
Notifications
You must be signed in to change notification settings - Fork 2
/
decision-record.txt
98 lines (73 loc) · 4.41 KB
/
decision-record.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
Title: A short description of the decision to be made, this is similar to an
email subject
Date: The Date the decision was made
Participants: List the people involved in the decision. This can make it easier
to get more information later
Context: Provide as much context around the problem as possible.
This should include any factors at play including; technological, political,
social and anything else. This should be fact based and in full sentences.
Decisions: Describe the decision made and the reasons why in full sentences.
Consequences: Describe the resulting context after applying the decision. All
consequences should be listed here, positive, negative, and neutral. They
affect the team and project in the future.
Review Triggers: Provide any factors that would cause a re-evaluation of the
decision. Examples of this might be newer versions of software, assumptions
or situations changing
References:
https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records
--------------------------------------------------------------------------------
Title:
Date:
Participants:
Context:
Decisions:
Consequences:
Review Triggers:
--------------------------------------------------------------------------------
Title: Feature toggle strategy
Date: 24-Jan-2023
Participants: Vanessa Teague, Luke McCarthy, Komal Kaur, George Ostrobrod, Wenping Du, Alicia Duong, Shuai Wang
Context:
Currently the Right to Ask app has no way of toggling features on or off. Before the release of the MVP we would
like to hide the share a question, as it hasn't been fully implemented yet. The team feels a feature toggling strategy
would help with situations like this going forward.
Decisions:
The team decided to use hard coded feature toggles to start with and iterate on the strategy as we gained a better
understanding of the requirements and pain points. George and Wenping raised concerns around using an online service to
dynamically control the values of feature toggles. This was because both Apple and Google require us to provide a way
for them to change the values of a toggle to ensure malicious code isn't hidden by a toggle.
Note
* Toggles should have unit tests for both the on and off position to ensure the expected behaviour is correct when a
toggle is on or off
* Toggles need to have different values for dev and non dev. This is to ensure a feature isn't accidently released
before intended
Consequences:
* Toggle doesn't need to support different operating systems or app version
* Don't need to worry about old versions still installed on users phones/devices
* Don't need to provide Apple and Google a way to change toggle values
* Will need to know at build time which version is being built to load the correct values for the toggles
* Feature can't be turned off in production if a bug is found
* A/B Testing and other advance toggle strategies aren't possible
Review Triggers:
* Team wants the ability to toggle features dynamically in production
* Team wants the ability to A/B Testing or other advance toggle strategies
--------------------------------------------------------------------------------
Title: Automated testing strategy before MVP release
Date: 17-Jan-2023
Participants:
Vanessa Teague, George Ostrobrod, Wenping Du, Luke McCarthy, Alicia Duong, Shuai Wang, Komal Kaur
Context:
Currently the Right to Ask app only has unit tests. The only other testing done is manual testing.
Decisions:
The team will continue with unit testing and manually testing the app until the MVP release is done. A testing plan
will be created in confluence, to enable consistent manual testing be done before a release. This documentation will be
used to create the automated user acceptance tests in the future. The team made this decision because setting up
automated user acceptance tests can take a considerable amount of time and the team is trying to release the first MVP
at the beginning of February.
Consequences:
Team will develop features more slowly and may miss some bugs because we don't have any automated user acceptance
testing in place.
Review Triggers:
Once the MVP has been launch the team should look at doing some automated user acceptance testing.
--------------------------------------------------------------------------------