You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 5, 2021. It is now read-only.
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+22-5Lines changed: 22 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -79,19 +79,36 @@ If you're interested in participating in the development of SORMAS, you can use
79
79
> #61 - added model to define classification, apply automatic case classification whenever a field value changes
80
80
6. Each pull request should be related to a single issue (if possible).
81
81
82
-
### SORMAS Sprint Board
82
+
### SORMAS Product Backlog
83
83
84
-
The SORMAS sprint board is segmented into the following categories:
84
+
The board **Product Backlog** is used to plan, refine and prioritize the tickets for the upcoming sprints.
85
+
The sorting from top to bottom in every column reflects the priority for the product. The Product Owner is responsible to put tickets into the Backlog and keep the ticket information updated.
85
86
86
-
***Backlog:** Issues that have been selected to be done in the current sprint, but for which work has not yet started.
87
+
The Product Backlog contains the following columns:
88
+
***Backlog:** Issues that have been identified by the Product Owner to be done in the next sprints. There can be a column for each Scrum Team if it fits the need.
89
+
***Sprint n:** Contain tickets picked by the Product Owner to be done in the named sprint. Text notes or separate columns are used to separate issues between Scrum Teams. It gives a forecast what might come in the upcoming sprint and it is the starting point for the Sprint Planning. Every ticket the Development Team do not pick into their Sprint Backlog needs to be moved back to the Backlog column or one sprint further.
90
+
***Done:** Tickets that are closed (usually resolved within the running sprint) are moved here **automatically**. The sorting does not represent the priority here any more.
91
+
92
+
93
+
### SORMAS Sprint Backlog
94
+
95
+
The board **Sprint Backlog** exists for each Scrum Team and is segmented into the following categories:
96
+
97
+
***Backlog:** Issues that have been selected by the Development Team to be done in the current sprint, but for which work has not yet started. The sorting top to bottom on this column reflects the priority given by the Product Owner at the time of the Sprint Planning.
87
98
***In Progress:** Issues that have been assigned to a contributor and for which work has started.
88
99
***Waiting:** Issues for which work has started and that have been put on hold, e.g. because action or feedback by an external contributor is required.
89
100
***Review:** Issues that have been resolved, but not been reviewed by another contributor yet. The ticket status is usually **Open**, but **Closed** is also allowed if no code change or merge is needed.
101
+
***Testing:** Issues that have been reviewed and merged to **development** branch to be tested and verified on a central TEST instance. The ticket status is supposed to be **Closed**.
90
102
***Done:** Issues that have been resolved, reviewed and satisfy the Definition of Done. The ticket status is supposed to be **Closed**.
91
103
92
-
The general workflow is that whenever a contributor starts working on an issue, they **assign** themselves to it and manually **move the issue** from **Backlog** to **In Progress**.
104
+
The general workflow is that whenever a contributor starts working on an issue, they **assign** themselves to it and manually **move the issue** from **Backlog** to **In Progress**.
105
+
Transitions to **Waiting** and **Review** also need to be done manually. When the developer is done with all work (no code changes or merges needed, milestone is set), the ticket is supposed to be closed to go automatically to **Testing**.
106
+
Approved tickets are supposed to be moved manually from **Testing** to **Done*.
107
+
108
+
The GitHub project has been configured to **automatically** move issues that are closed to **Testing** and issues that are reopened back to **In Progress**.
109
+
110
+
The Development Team is responsible to keep the tickets up to date on this board and to assign the appropriate milestone in which the work is going to be released.
93
111
94
-
The GitHub project has been configured to **automatically** move issues that are closed to **Done** and issues that are reopened back to **In Progress**.
Copy file name to clipboardExpand all lines: SERVER_CUSTOMIZATION.md
+23-11Lines changed: 23 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -58,16 +58,28 @@ SORMAS supports a wide range of diseases, and not all of those might be relevant
58
58
59
59
Right now, changing these variables unfortunately is not possible from within the user interface, but requires **direct database access**. If you have this access, you can edit the entries in the *diseaseconfiguration* table according to your needs.
60
60
61
-
**IMPORTANT:** Whenever you edit an entry in this table, you also need to manually set the *changedate* to the current date and time. This is required in order for the mobile app to synchronize the changes and use the edited disease configuration.
61
+
**VERY IMPORTANT:** Whenever you edit an entry in this table, you also need to manually set the *changedate* to the current date and time. This is required in order for the mobile app to synchronize the changes and use the edited disease configuration.
62
62
63
63
## Feature Configuration
64
-
Some of the features in SORMAS can be enabled or disabled for the system.
65
-
Examples for this are aggregated reporting, event surveillance, national case sharing and more.
66
-
67
-
Right now, changing these variables unfortunately is not possible from within the user interface, but requires **direct database access**. If you have this access, you can edit the entries in the *featureconfiguration* table.
68
-
69
-
* There will be an entry in the database table for each feature that is available in SORMAS
70
-
* Set the "enabled" value of the feature to true or false to enable or disable it
71
-
* The region, district, disease and enddate columns are currently only appicable for the line listing feature. The line listing feature is the only feature that can currently be configured using the UI.
72
-
73
-
**IMPORTANT:** Whenever you edit an entry in this table, you also need to manually set the *changedate* to the current date and time. This is required in order for the mobile app to synchronize the changes and use the edited disease configuration.
64
+
Some of the features in SORMAS can be enabled or disabled to further customize the system. Right now, changing these variables unfortunately is not possible from within the user interface, but requires **direct database access**. If you have this access, you can edit the entries in the *featureconfiguration* table. There is one entry for every configurable feature in this table, and you can set the value of the *enabled* column to *true* to enable it and *false* to disable it. The *region*, *district*, *disease* and *enddate* columns are currently only applicable for the line listing feature and define the scope in which line listing is used. Line listing is configurable from within the UI and does not need to be manually edited in the database.
65
+
66
+
**VERY IMPORTANT:** Whenever you edit an entry in this table, you also need to manually set the *changedate* to the current date and time. This is required in order for the mobile app to synchronize the changes and use the edited feature configuration.
67
+
68
+
The following features are currently configurable:
69
+
70
+
***Case Surveillance***(CASE_SURVEILANCE)*: The core module of SORMAS which allows the creation and management of suspect or confirmed disease cases.
71
+
***Contact Tracing***(CONTACT_TRACING)*: Management and follow-up of contacts of disease cases.
72
+
***Sample Management***(SAMPLES_LAB)*: Management of samples for cases, contacts or event participants and the documentation of pathogen tests performed on these samples.
73
+
***Event Surveillance***(EVENT_SURVEILLANCE)*: Creating and managing events and event participants to identify potential outbreaks or disease hotspots.
74
+
***Aggregate Reporting***(AGGREGATE_REPORTING)*: Allows collecting case numbers for a number of additional diseases for which case-based surveillance is not used. Commonly referred to as mSers in African countries.
75
+
***Weekly Reporting***(WEEKLY_REPORTING)*: Allows mobile users to confirm the number of cases they have collected on a weekly basis and web users to see an overview of whether or not mobile users have submitted their reports and how many cases they have reported.
76
+
***Clinical Management***(CLINICAL_MANAGEMENT)*: Enables the clinical management module of cases that allow collecting prescriptions and treatments as well as doctor's visits in a clinical context.
77
+
***National Case Sharing***(NATIONAL_CASE_SHARING)*: Allows users with the respective rights to make cases available to the whole country, i.e. other users will see these cases even if they don't belong to their jurisdiction.
78
+
***Task Generation (Case Surveillance)***(TASK_GENERATION_CASE_SURVEILLANCE)*: Enables or disables the automatic generation of tasks associated with case surveillance, especially the *Case Investigation* tasks that are usually generated when creating a new case.
79
+
***Task Generation (Contact Tracing)***(TASK_GENERATION_CONTACT_TRACING)*: Enables or disables the automatic generation of tasks associated with contact tracing, especially the *Contact Investigation* tasks that are usually generated when creating a new contact and the *Contact Follow-Up* tasks that are created once a day for every contact that is under follow-up.
80
+
***Task Generation (Event Surveillance)***(TASK_GENERATION_EVENT_SURVEILLANCE)*: Enables or disables the automatic generation of tasks associated with event surveillance.
81
+
***Task Generation (General)***(TASK_GENERATION_GENERAL)*: Enables or disables the automatic generation of tasks that aren't directly associated with one of the three other task types described above, e.g. the *Weekly Report Generation* task that asks mobile users to submit their weekly reports.
82
+
***Campaigns***(CAMPAIGNS)*: The campaigns module allows collecting flexible data which can be customized using the JSON format. Currently this is heavily geared towards vaccination campaigns in Afghanistan, but will be usable in a more generic way in the future for other countries as well.
83
+
***Area Infrastructure***(INFRASTRUCTURE_TYPE_AREA)*: Enables an additional infrastructure level above region that is called area by default. Currently only used in the campaigns module.
84
+
***Case Follow-Up***(CASE_FOLLOWUP)*: Enables the contact follow-up module for cases as well to allow a more detailed daily documentation of symptoms.
85
+
***Line Listing***(LINE_LISTING)*: Whether or not using line listing for case entry is enabled in the specified jurisdiction for the specified disease. Configurable from the UI, no database interaction needed.
0 commit comments