├── CODE_OF_CONDUCT.md ├── CONTRIBUTION.md ├── LICENSE ├── README.md ├── issue_template.md └── pull_request_template.md /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | ## Purpose 2 | 3 | A primary goal of all the conferences and user groups that refer to this Code of Conduct is to be inclusive to the largest number of contributors, with the most varied and diverse backgrounds possible. As such, we are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, ability, ethnicity, socioeconomic status and religion (or lack thereof). 4 | 5 | This Code of Conduct outlines our expectations for all those who participate in our community, as well as the consequences for unacceptable behavior. 6 | 7 | We invite all those who participate in our events to help us create safe and positive experiences for everyone. 8 | 9 | ## Open [Source/Culture/Tech] Citizenship 10 | 11 | A supplemental goal of this Code of Conduct is to increase open [source/culture/tech] citizenship by encouraging participants to recognize and strengthen the relationships between our actions and their effects on our community. 12 | 13 | Communities mirror the societies in which they exist and positive action is essential to counteract the many forms of inequality and abuses of power that exist in society. 14 | 15 | If you see someone who is making an extra effort to ensure our community is welcoming, friendly, and encourages all participants to contribute to the fullest extent, we want to know. 16 | 17 | ## Expected Behavior 18 | 19 | - Participate in an authentic and active way. In doing so, you contribute to the health and longevity of this community. 20 | - Exercise consideration and respect in your speech and actions. 21 | - Attempt collaboration before conflict. 22 | - Refrain from demeaning, discriminatory, or harassing behavior and speech. 23 | - Be mindful of your surroundings and of your fellow participants. Alert community leaders if you notice a dangerous situation, someone in distress, or violations of this Code of Conduct, even if they seem inconsequential. 24 | 25 | ## Unacceptable Behavior 26 | 27 | Unacceptable behaviors include: intimidating, harassing, abusive, discriminatory, derogatory or demeaning speech or actions by any participant in our community online, at all related events and in one-on-one communications carried out in the context of community business. Community event venues may be shared with members of the public; please be respectful to all patrons of these locations. 28 | 29 | Harassment includes: harmful or prejudicial verbal or written comments related to gender, sexual orientation, race, religion, disability; inappropriate use of nudity and/or sexual images (including presentation slides); inappropriate depictions of violence (including presentation slides); deliberate intimidation, stalking or following; harassing photography or recording; sustained disruption of talks or other events; inappropriate physical contact, and unwelcome sexual attention. 30 | 31 | ## Consequences of Unacceptable Behavior 32 | 33 | Unacceptable behavior from any community member, including sponsors and those with decision-making authority, will not be tolerated. Anyone asked to stop unacceptable behavior is expected to comply immediately. 34 | 35 | If a community member engages in unacceptable behavior, the community organizers may take any action they deem appropriate, up to and including a temporary ban or permanent expulsion from the community without warning (and without refund in the case of a paid event). 36 | 37 | ## If You Witness or Are Subject to Unacceptable Behavior 38 | 39 | If you are subject to or witness unacceptable behavior, or have any other concerns, please notify a community organizer as soon as possible. You can find a list of organizers to contact for each of the supporters of this code of conduct at the bottom of this page. Additionally, community organizers are available to help community members engage with local law enforcement or to otherwise help those experiencing unacceptable behavior feel safe. In the context of in-person events, organizers will also provide escorts as desired by the person experiencing distress. 40 | 41 | ## Addressing Grievances 42 | 43 | If you feel you have been falsely or unfairly accused of violating this Code of Conduct, you should notify one of the event organizers with a concise description of your grievance. Your grievance will be handled in accordance with our existing governing policies. 44 | 45 | ## Scope 46 | 47 | We expect all community participants (contributors, paid or otherwise; sponsors; and other guests) to abide by this Code of Conduct in all community venues—online and in-person—as well as in all one-on-one communications pertaining to community business. 48 | 49 | ## License and attribution 50 | 51 | [Berlin Code of Conduct](https://berlincodeofconduct.org/) is distributed under a [Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)](https://creativecommons.org/licenses/by-sa/4.0/) license. It is based on the [pdx.rb Code of Conduct](https://pdxruby.org/CONDUCT). 52 | -------------------------------------------------------------------------------- /CONTRIBUTION.md: -------------------------------------------------------------------------------- 1 | # Contribution Guidelines 2 | 3 | ## Inhaltsverzeichnis 4 | 5 | - [Workflow](#workflow) 6 | - [Bounties](#bounty) 7 | - [Work on Bounty](#work-on-bounty) 8 | - [Project structure](#project-structure) 9 | 10 | ### Workflow 11 | 12 | The project follows [Git-flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) workflow for the codebase maintenance and release lifecycle. 13 | 14 | 1. Fork and clone the repository 15 | 16 | ```sh 17 | git clone git@github.com:YOUR-USERNAME/OPENSOURCE_REPONAME.git 18 | ``` 19 | 20 | 1. Create a branch in the fork 21 | 22 | The branch should be based on the `develop` branch in the master repository. Prepend the correct [type](#type) to your branch. 23 | 24 | ```sh 25 | git checkout -b TYPE/my-feature-or-bugfix master 26 | ``` 27 | 28 | 1. Commit changes on your branch 29 | 30 | Commit changes to your branch, following the commit message format. 31 | 32 | ```sh 33 | git commit -m "properly formatted SET statements." 34 | ``` 35 | 36 | 1. Push the changes to your fork 37 | 38 | ```sh 39 | git push -u myfork TYPE/my-feature-or-bugfix 40 | ``` 41 | 42 | 1. Create a Pull Request 43 | 44 | In the Github UI of your fork, create always a Pull Request to the backend or frontend `develop` branch of the master repository. Pull requests to the `master` branch will be closed. 45 | 46 | If the branch has merge conflicts or has been outdated, please do a rebase against the backend or frontend `develop` branch. 47 | 48 | 1. Review a Pull Request 49 | 50 | The application development team will review the pull request by going through the single commits. If the pull request is acceptable, they merge the pull request in the codebase. 51 | 52 | ### Commit message guidelines 53 | 54 | Commit messages should follow the [commit message convention](https://conventionalcommits.org/). 55 | 56 | #### Type 57 | 58 | Should be one of the following: 59 | 60 | - **feat:** A new feature 61 | - **fix:** A bug fix 62 | - **chore:** Changes to build and dev processes/tools 63 | - **docs:** Changes to documentation 64 | - **style:** Changes to code style formatting (white space, commas etc) 65 | 66 | #### Scope 67 | 68 | The `` of the commit is optional and can be omitted. When used though, it should describe the place or part of the project, e.g. `docs(examples)`, `feat(data)` etc. 69 | 70 | ## Bounty 71 | 72 | Bounty is a reward for completing a properly defined Action or Project. For simplicity, we will may call such Actions or Projects themselves a Bounties from now on. 73 | 74 | Properly defined bounty must specify the following attributes 75 | 76 | ### Title 77 | 78 | Succinct name for the bounty. 79 | 80 | ### Scope 81 | 82 | A list of specific things which should be done to deliver the bounty. These could be seen as requirements to verify/review the bounty against. 83 | 84 | ### Deliverables 85 | 86 | Artifacts produced as the result of this bounty. Something that could be verified/reviewed. Some examples: updated code, deployment made, blog post published, public event conducted etc 87 | 88 | ### Bounty owner/gardener 89 | 90 | The person responsible for the bounty. 91 | 92 | ### Priority 93 | 94 | Priority defines the importance of a bounty in relation to the other bounties. Additionally it helps to the users to determine which bounties should be completed first. 95 | 96 | - Blocker: This task will block progress 97 | - High: Serious task that could block progress 98 | - Medium: Has the potential to affect progress 99 | - Low: Minor problem 100 | 101 | ### Size 102 | 103 | Size of the bounty. 104 | 105 | We use t-shirt sizes: 106 | 107 | - size-XXS: 2h 108 | - size-XS: 3h 109 | - size-S: 5h 110 | - size-M: 8h 111 | 112 | ## How to create a new bounty 113 | 114 | 1. Create a Github issue with properly defined bounty description (see above) in an appropriate repository. 115 | 2. If the bounty spans across multiple repositories, consider splitting it in a smaller per-repo bounties if possible 116 | 3. Add the bounty to the [bounties board]() 117 | 118 | ## Work on Bounty 119 | 120 | ### Gardener 121 | 122 | Gardener is the one who creates the bounty and is responsible for it's completion. 123 | 124 | Gardener is expected to: 125 | 126 | - find a Worker for the Bounty. 127 | - help the Worker to understand the scope of the Bounty. 128 | - find a Reviewer for the Bounty. 129 | 130 | ### Worker 131 | 132 | Worker is the one who actually implements the Bounty. 133 | 134 | Worker is expected to: 135 | 136 | - create WIP Pull Request within 4 days from the start of the bounty (if applicable) 137 | - actively work on the Bounty according to it's Scope, don't linger (see "Challenging bounties" section below) 138 | - stay accountable by publishing WIP updates at least every 2 working days: 139 | - for coding bounties, the Worker is expected to push commits in WIP Pull Request. 140 | - for writeups, the Worker is expected to share a draft Hackmd document he is working at. 141 | - request a review once the work is done. 142 | 143 | ### Reviewer 144 | 145 | Reviewer is the person who reviews the Bounty's deliverables. 146 | 147 | Reviewer is expected to: 148 | 149 | - do review in timely manner 150 | - ensure all the deliverables are provided 151 | - ensure all the Scope items are addressed 152 | - for coding bounties: 153 | - make sure the code is compiling/building correctly 154 | - review the code for logical correctness, inefficiencies and style (TBD) 155 | - ensure unit tests are passing 156 | - ensure code coverage is not reduced 157 | - ensure integration tests are passing for the PR branch 158 | - for public writeups 159 | - do fact check 160 | - check readability 161 | - correct grammar and punctuation 162 | - check social network preview e.g. twitter card (if applicable) 163 | - forward all the issues found publicly to the Worker (e.g. as comments on Github) 164 | - approve the PR once the review is complete successfuly (if applicable) 165 | 166 | ## Challenging bounties 167 | 168 | Gardener/Worker/Reviewer roles may be taken over by other people in a certain situations (see below). Each takeover must be stated in written form in corresponding Github issue including new assignee and the reason for takeover. 169 | 170 | ### Challenging worker and reviewer 171 | 172 | If worker or reviewer are not publishing any updates for the bounty for 2 working days, then anyone can challenge him and take over the worker role. Updates for worker role can be in any form, most notably: commits to WIP Pull Request, updates on product artifact (hackmd, presentation, diagram etc), review comments or updates in form of github comments. 173 | 174 | ## Project structure 175 | 176 | We identify 4 separate applications that will have their release lifecycle independently of each other. These applications are: 177 | 178 | - Frontend: User facing application. It might be a web application or a mobile native application. 179 | - Backend: Server side application storing and managing user data and main business logic. 180 | - Project website: Webpage with project foundation and design details. 181 | - gh-pages: contains the compiled website that is going to be used by GitHub pages. 182 | 183 | These applications will leverage Continuous Integration and Continuous Deployment capabilities available from GitHub Actions. Each application will have its tech stack and therefore its build, test, and release processes. We recognize then the need for enabling the applications to be extended and enhanced without conflicting with the independent development lifecycles and versioning of the other components. To achieve this we then created 4 orphan main branches. 184 | 185 | - **frontend/master**, for frontend development 186 | - **backend/master**, for backend development 187 | - **website/master**, for project website development 188 | - **gh-pages**, for the project website 189 | 190 | These branches will behave as a regular master branch, protected from direct changes on the branch, and only updated when a pull request is approved by a reviewer. Additionally, we can configure separate CI/CD pipelines based on the branch name simplifying maintenance. 191 | The master branches will contain the latest production versions of each one of the applications and therefore the team should aim to keep the codebase of this branch stable and clean. 192 | From theses branches we created the development branches for frontend and backend applications: 193 | 194 | - **frontend/develop** 195 | - **backend/develop** 196 | 197 | These branches will serve as an integration branch of multiple feature branches and will contain the development version of the applications, meaning probably unstable and available for quality assurance. Every feature branch should be eventually merged to develop and when a stable version is reached develop will be merged to master, triggering the release of a new application version. 198 | All of the features branches should maintain the application name as its prefix. For example: 199 | 200 | - backend/feat/login: this branch is for the development of the login feature for the backend application. 201 | - frontend/fix/style: this branch is for a fix on the style for the frontend application. 202 | - website/chore/readme-update: this branch is for a chore on the readme file for the website application. 203 | 204 | The goal is to apply the git-flow workflow to our development lifecycle and to simplify the maintenance of each application that belongs to this project. 205 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Webseite 2 | 3 | Zur Dokumentation unseres Softwareprojekts haben wir eine Webseite erstellt, welche eine Überblick zu unseren Aktivitäten gibt - https://fub-hcc.github.io/20-SWP-CodingOpenness/ 4 | 5 | Eine fortlaufende Dokumentation des Stands unserer Arbeit erfolgt im [Wiki](https://github.com/FUB-HCC/20-SWP-CodingOpenness/wiki). 6 | 7 | Weitere Informationen zum Softwareprojekt befindet sich der [FU Webseite](https://www.mi.fu-berlin.de/en/inf/groups/hcc/teaching/summer-term-2020/swp-coding-openness.html). 8 | 9 | # Hintergrund 10 | 11 | Das Ziel unseres Open-Source Softwareprojekt im Sommersemester 2020 ist es, uns an der Entwicklung der Corona-App zu beteiligen. Wie das genau erfolgen kann, hängt von der weiteren Entwicklung ab, aber es geht vor allem darum, die Perspektive der Nutzer_innen dieser App geeignet zu berücksichtigen. 12 | 13 | "Die" Kontaktverfolgung-App wird mit dem Ziel entwickelt, mögliche Corona-Infektionsketten, datenschutzfreundlich zu erkennen. (Daneben gibt es die Datenspende-App, Nutzung in Verbindung mit den Fitnesstracker, und der Vorschlag einer Quarantäne-App zur Entlastung der Gesundheitsämter). Die Corona-App kann nur ein Baustein von einer Vielzahl Maßnahmen sein, mit dem wir versuchen, die SARS-CoV-2-Epidemie einzudämmen. Leider gibt es nicht "die Corona-App", sondern eine Vielzahl unterschiedlicher, teilweise konfligierende Ansätze, daher ist es zunächst unsere Aufgabe, diese Ansätze zu identifzieren, zu vergleichen und zu bewerten. Letztlich besteht die Hoffnung, dass wir im Sommersemester die Möglichkeit erhalten, die eine oder andere App zu installieren und zu erweitern. 14 | 15 | # Motivation 16 | 17 | Ein zentraler Aspekt bei der Gestaltung einer Tracing-App ist die Vermittlung der eingesetzten Datenschutzmaßnahmen. Auch wenn es sich hier um ein klassisches Problem aus dem Bereich Usable Privacy and Security handelt, so steht doch kein Lösungsansatz per sé zur Verfügung. Gerade die Interpretierbarkeit von technischen Ansätzen ist noch immer eine Herausforderung für nicht-technische Personen. Interpretierbarkeit ein sehr subjektiver Begriff und daher schwer zu formalisieren. Sicherheitskonzepte werden aber häufig über formale Ansätze bewertet, die nur schwer vermittelt werden können. 18 | 19 | In dem Softwareprojekt wollen wir uns vor allem auf Erklärungsmechanismen fokussieren. Das primäre Ziel besteht darin, dass Bürger|innen vom App-Betreiber|innen genügend Informationen erhalten, um die Ursachen eines Ereignisses oder einer Entscheidung zu verstehen. Diese Dimensionen betonen die Subjektivität von Erklärungen und unterstreichen die Notwendigkeit, die Erklärung an das Publikum, die Bürger|innen, anzupassen. Innerhalb des Vorhabens, sollen unterschiedliche Ansätze zur Erstellung solcher Erklärungen anhand von Low- und High-Fidelity-Prototypen konzipiert und implementiert sowie im Rahmen von Nutzerstudien (Remote Evaluation) evaluiert werden. 20 | -------------------------------------------------------------------------------- /issue_template.md: -------------------------------------------------------------------------------- 1 | 6 | # Bounty 7 | 8 | ## Scope 9 | 10 | - 11 | 12 | ## Deliverables 13 | 14 | - 15 | 16 | ## Gain for the project 17 | 18 | - 19 | 20 | ## Roles 21 | 22 | bounty worker: @username 23 | bounty reviewer: @username 24 | 25 | ## Issue creation checklist 26 | 27 | - [x] I have attached one of the team labels `Fragebogen`, `Technik`, `Projektwebseite`, `Vergleich`, `Organisation` to this bounty 28 | - [x] I have attached one of the priority labels `Blocker`, `High`, `Medium`, `Low` to this bounty 29 | - [x] I have attached one of the `size-` labels to this bounty 30 | - [x] I have added this bounty to bounty board here https://github.com/FUB-HCC/20-SWP-CodingOpenness/projects/1 31 | 32 | 62 | -------------------------------------------------------------------------------- /pull_request_template.md: -------------------------------------------------------------------------------- 1 | Please remember the / Bitte beachte die [Contribution Guidelines](https://github.com/FUB-HCC/20-SWP-CodingOpenness/blob/master/CONTRIBUTION.md) :heart: 2 | 3 | ## What does this PR do? 4 | 5 | - 6 | 7 | 8 | 9 | ## Recommendations for testing 10 | 11 | 12 | 13 | ## Links to relevant issues or information 14 | 15 | Closes 16 | 17 | 18 | --------------------------------------------------------------------------------