21 | Architectural Decision Records are a way to quickly write down Architectural Decisions.
22 | This tool is meant to make the editing and management of ADRs on GitHub easier.
23 |
5 |
6 |
7 |
55 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/material-during-study/interview-guide.md:
--------------------------------------------------------------------------------
1 | # Interview Guide
2 |
3 | The following sections contain the basic agenda for our semi-structured interviews.
4 | We will loosely follow these questions based on the participant's responses.
5 |
6 |
7 | ## Demographic and Professional Background
8 |
9 | * Role (e.g. (lead) developer, (lead) architect, data engineer, etc.)
10 | * General domain (e.g. web, frontend, backend, data science, something completely different)
11 | * Years of professional experience
12 | * Experience with ADRs (any document containing ADs)
13 | * For how long have you used ADRs?
14 | * What was the average size of the teams you used ADRs with?
15 | * What formats do you use for ADRs?
16 | * How standardized are the formats? Are there templates?
17 | * Do you have experience with [MADRs](https://github.com/adr/madr)?
18 | * Which tools do you use to manage ADRs? (e.g. adr-tools + GitHub, local text editor like VSC, IntelliJ, Confluence, PowerPoint, etc.)
19 |
20 |
21 |
22 | ## Functional Suitability
23 |
24 | * Which provided functionality needs to be improved?
25 | * Which additional functionality would you need to consider using the tool in your professional work?
26 |
27 | ## Usability
28 |
29 | * How understandable was the user interface for you?
30 | * How efficiently usable was the user interface for you?
31 | * Which modes would you use most often? Would you switch between modes?
32 |
33 |
34 | ## Final Verdict
35 |
36 | Please indicate your (dis)agreement to the following statements with these 5 labels:
37 | `strongly disagree`, `disagree`, `neutral`, `agree`, `strongly agree`
38 |
39 | * The functional suitability of the tool is fitting for its purpose.
40 | * The usability of the tool allows its convenient usage.
41 | * It is likely that I will use the tool in the future.
42 |
43 |
--------------------------------------------------------------------------------
/src/components/EditorRaw.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
11 |
12 |
13 |
14 |
15 |
70 |
71 |
81 |
--------------------------------------------------------------------------------
/jest.config.js:
--------------------------------------------------------------------------------
1 | // For a detailed explanation regarding each configuration property, visit:
2 | // https://jestjs.io/docs/en/configuration.html
3 | export default {
4 | // Automatically clear mock calls and instances between every test
5 | clearMocks: true,
6 | // Indicates whether the coverage information should be collected while executing the test
7 | collectCoverage: false,
8 | // An array of glob patterns indicating a set of files for which coverage information should be collected
9 | collectCoverageFrom: ["./src/**/*.js"],
10 | // The directory where Jest should output its coverage files
11 | coverageDirectory: "coverage",
12 | // An array of regexp pattern strings used to skip coverage collection
13 | coveragePathIgnorePatterns: ["/node_modules/", "/plugins/parser/", "/tests/"],
14 | // A list of reporter names that Jest uses when writing coverage reports
15 | coverageReporters: ["json", "text", "lcov", "clover"],
16 | // An array of directory names to be searched recursively up from the requiring module's location
17 | moduleDirectories: ["node_modules"],
18 | // An array of file extensions your modules use
19 | moduleFileExtensions: ["js", "json", "vue", "node"],
20 | // A map from regular expressions to module names that allow to stub out resources with a single module
21 | moduleNameMapper: {
22 | vue$: "vue/dist/vue.common.js",
23 | "^@/(.*)$": "/src/$1"
24 | },
25 | // The test environment that will be used for testing
26 | testEnvironment: "node",
27 | // The glob patterns Jest uses to detect test files
28 | testMatch: ["**/__tests__/**/*.js?(x)", "**/?(*.)+(spec|test).js?(x)"],
29 | // An array of regexp pattern strings that are matched against all test paths, matched tests are skipped
30 | testPathIgnorePatterns: ["/node_modules/"],
31 | // An array of regexp pattern strings that are matched against all source file paths, matched files will skip transformation
32 | transformIgnorePatterns: ["/node_modules/(?!three)"]
33 | };
34 |
--------------------------------------------------------------------------------
/docs/adr/0002-use-antlr-for-parsing-adrs.md:
--------------------------------------------------------------------------------
1 | # Use ANTLR for parsing ADRs
2 |
3 | * Status: accepted
4 |
5 | Technical Story: Proposed in the GitHub Issues [#17](https://github.com/koppor/adr-manager/issues/17), [#19](https://github.com/koppor/adr-manager/issues/19)
6 |
7 | ## Context and Problem Statement
8 |
9 | ADR Manager needs to parse existing ADRs. Each ADR is stored in a markdown file. Example: https://github.com/adr/madr/blob/master/docs/adr/0001-use-CC0-as-license.md.
10 |
11 | ## Considered Options
12 |
13 | * Use a generic Markdown Parser
14 | * Use ANTLR to create an ADR specific parser
15 | * Write a parser from scratch
16 |
17 | ## Decision Outcome
18 |
19 | Chosen option: "Use ANTLR to create an ADR specific parser", because comes out best (see below).
20 |
21 | ### Positive Consequences
22 |
23 | * Some existing ADRs are accepted now without changes.
24 | * Better control over output
25 |
26 | ### Negative Consequences
27 |
28 | * The new parser is worse at parsing "invalid" ADRs than the generic one.
29 | * ANTLR Parser seems to be quite slow.
30 |
31 | ## Pros and Cons of the Options
32 |
33 | ### Use a generic Markdown Parser
34 |
35 | Enhance generic Markdown parser and use the result of that parser. For that, available options are listed at https://github.com/f43i4n/md-schema/blob/master/docs/related-work.md.
36 |
37 | This option was used in the mock-up with the library [md-to-json](https://github.com/ajithr/md-2-json).
38 |
39 | * Good, because easiest solution.
40 | * Good, because md-to-json can parse the json back to a Markdown.
41 | * Bad, because md-to-json adds extra line breaks, which are hard to remove.
42 |
43 | ### Use ANTLR to create an ADR specific parser
44 |
45 | Use ANTLR4 to write a parser specifically for ADRs.
46 |
47 | * Good, because flexible parser and full control over output.
48 | * Good, because hopefully maintainable. ANTLR Grammar can be used to specify how ADRs must look.
49 | * Bad, because extra work.
50 |
51 | ### Write a parser from scratch
52 |
53 | * Bad, because extra work.
54 | * Bad, because writing stuff from scratch is a bad anti pattern.
55 |
--------------------------------------------------------------------------------
/tests/parser.test.js:
--------------------------------------------------------------------------------
1 | // Tested functionality
2 | import { md2adr, adr2md, naturalCase2snakeCase, snakeCase2naturalCase } from "../src/plugins/parser.js";
3 |
4 | // Needed for testing
5 | import { randomStrings, MD_ParsedMADR_Pairs, validMarkdownADRs } from "./constants.js";
6 |
7 | /**
8 | * Convergence of the parser:
9 | * The output of the parser must always be accepted by the parser.
10 | */
11 | for (let i = 0; i < randomStrings.length; i++) {
12 | test("Test parser convergence of random strings.", () => {
13 | let result1 = adr2md(md2adr(randomStrings[i]));
14 | let result2 = adr2md(md2adr(result1));
15 | expect(result2).toBe(result1);
16 | });
17 | }
18 |
19 | for (let i = 0; i < MD_ParsedMADR_Pairs.length; i++) {
20 | test("Test parser convergence of possibly incorrect ADRs.", () => {
21 | let result1 = adr2md(md2adr(MD_ParsedMADR_Pairs[i].md));
22 | let result2 = adr2md(md2adr(result1));
23 | expect(result2).toBe(result1);
24 | });
25 | }
26 |
27 | /**
28 | * Precision for valid ADRs:
29 | * The output of the parser should be equal to the input ADR. This only holds for valid MADRs.
30 | */
31 | for (let i = 0; i < validMarkdownADRs.length; i++) {
32 | test("Test exact reparsing", async () => {
33 | let result = adr2md(md2adr(validMarkdownADRs[i]));
34 | expect(result).toBe(validMarkdownADRs[i]);
35 | });
36 | }
37 |
38 | /**
39 | * Test of the function md2adr.
40 | * Compares some parsed ADRs to manually parsed ADRs.
41 | */
42 | MD_ParsedMADR_Pairs.forEach(function (pair) {
43 | test("Test md2adr", () => {
44 | let result = md2adr(pair.md);
45 | expect(result).toStrictEqual(pair.adr);
46 | });
47 | });
48 |
49 | /**
50 | * Tests of the utility functions snakeCase2naturalCase and naturalCase2snakeCase
51 | */
52 | test("Test snakeCase2naturalCase", () => {
53 | let result = snakeCase2naturalCase("0005-use-dashes-in-file-names.md");
54 | expect(result).toBe("0005 Use Dashes In File Names.md");
55 | });
56 |
57 | test("Test naturalCase2snakeCase", () => {
58 | let result = naturalCase2snakeCase("0005 Use dashes in File names.md");
59 | expect(result).toBe("0005-use-dashes-in-file-names.md");
60 | });
61 |
--------------------------------------------------------------------------------
/src/components/DialogDeleteAdr.vue:
--------------------------------------------------------------------------------
1 |
2 |
12 |
13 |
14 |
15 |
16 |
17 |
58 |
59 |
60 |
87 |
--------------------------------------------------------------------------------
/docs/architecture/FMC-Diagram.drawio:
--------------------------------------------------------------------------------
1 | 7V1dc+K6Gf41zLQXYfwNXG5Ctr3YzMlkd3raq47AAnRiLI5tAumvr2TLNpZkW2DL0AZ2ZhdkWbLf99H7Le3Iftoe/xaB3eYF+zAYWYZ/HNnzkWWZtueQf2jLZ9Yy8eysYR0hn3UqG36i/0DWaLDWPfJhXOmYYBwkaFdtXOIwhMuk0gaiCB+q3VY4qM66A2soNPxcgkBs/R35yYa1mq5RXvg7ROsNm3qSX1iA5fs6wvuQzTey7O/pJ7u8BflYrH+8AT4+nDTZzyP7KcI4yb5tj08woLTNyZbd973mavHcEQwTlRus+SEObBzNXx4eJqG32P57/vwwyUb5AMGe0eMJ43dEGGIZOCJ//cCEVOTfnwmOKCWzV0k+c/KlBIB0CnNkPx42KIE/d2BJrx4IYEjbJtkG7PIHjBJExvsWoHVI2hJMO6xQEDzhgExHR7RXLv1D2uMkwu/w5IqXfugdOExO2rMPaWcvQ2aBx1oqmQXtCaYh3sIk+iRd2A0zx81uYXA2c/YdTsDhsbbNCS4KQAMGyHUxdskU8oXx5QwemZbAJLoMu7GiD1J5HKk8CaksCakcXZSyHIFSzz4hg0/avs3f4psjmTVRJJmri2TOVCDZyPICMu2jjz7I1zX9+vsGhlQi7GCIwjV9jjAjKZXWG5CM6DNndy2i/Ka8hTzXyVCS0ZcgDDEdYwEzasYpx8jlP/dUOj7uYLQisj/4LJtG1lO3SZMNilO1st3hkLKPSmi8D/zsy6Hr6PRVfLRaQYKNJUxfLjnAlIzZRRyhNQpT4dphoowHIPTLcffJbk9fB6+KtpSmUbeZwCpJh6BjZSBAyVj57g4T/0pfYZ+9wDJFHlgu4Y6+43IDwnWprTrMskJHuuZQXGVNRl9Usu0NUGj8Aoux+mSc1CGWwI5+JaCH7WKntDN+2ycBCiFr90H0/hu5CyVUmBhjg+rMqkDrQWK5blViuVNRYlm2RGKZ2kSWK+pDgcQw9L9R45D8WgYgjtGyStTCGDNkhoaRfirkpL+gTyxHNgcMFvjwXDY8pg3kQm7jFOSndzUTnzw53kdLqGADJCBaw6ShoyXn5gm33Ab1EsEAJOij+rwyBrIZXjFKJWeu3mxOvfEYyN6T3XVqq/IDTbmBDG6gjA7CQITn4POk2452iNUf2JxVbGjyJRuxBGtB08vx68lULodfuuB3tcuX+UJgkXcvfBXVZW0brrCMPUOGDG3LWFzF1FbD0T8QPIw/9k32rdEuNftzKmIqY8P1I04SvM0lRtb2xuiUiYqELB0csp8BWMDgFceItS0JY4gCK32gH1yHLfL9VJAA5hwJd1S9JoKJZI4iAoPs/iCJVCV+AyobJcfAAPFULNPvKKBa+fm4I5yjFoJMA9NOeY/u0FLyYmH6kQHO9uyZ7Wvh1TEXu+1OxlTCSk/bUncFiuMo2eA1JkbWD0zpl1L2D5gknyxEBPYJrtK9Uf1WDZ/LlHGjtG5V0baihnZtOfM66t4JU12FocbHI2pUZl9azZoKPD5lWMnvU64t99FHwbQLIKFoxmnnvavK/F54f66VU5hhDBqOyUUKz+uvxyqyxdgNDTeIMZtGMaAPQzLPSqc0UTb4J426wBhz2uDBZITWi7kcM4Vl7TZjju9vNWFOuJu72am+DF6tYqhF6OVcOgHtL4yDBaDBCGaavMBw36stq2BayE0UbQaHY3PMlgXNZWHNqbYYgS0w5mkf0bekQUSycMuocANv+goKX0JTk8O0PZPQVBZ4sbXZ40YD2LOMxFXAPhisHUVUa8tveKKOjGFAs6KDKklpcI00EoFXXRYa9aOnqB7rrO1CPTrW1KsuNO8S/SiqJH798rKupxDWlJtmco7efKi++oPFPaM+zTkRoSyAuHsQ7JJVzxm/kqSmLY1368tqikn6OQIBXnfMZ/ZlVvgg3pyXcmhARGMAamjCzwTCf/Op1fAGdzRwh6O0UILjQWuAj6dicaEqb9MU0fa4pmU34wUgUnYcpQUwJeMIueYhDkum5RUs6RCZLLeoxEYEFSnxXUlodLaaUPbVhyyFiKQOXVzH/lwXu+OpffrhhLZENZtDquY8kVCppNluERW2T3mS8o6U6yNFkr8cGCliXJuYaDCBNe7IHSU6UGLOrLEzO/lMbkueOKIDe0fJHSXc409NAQjX9vxUI6iSFA1hVfT5TzrVeOLmv/9VTE1+zI+VX5/s10i3tzlhluBAyZ1zfUCbC1TYTnOwVehvtyQEZo3j60kITETr+ymCIJWAITy0Bu8uKBLIZdJVYk0KxbQy2aIv3CfSX6D2dTx0AY6uSKuiT8VV1BZvFrW1pFYhq2+Rlyj82sDs8v9FfcJMzr/r8UeGZYE/L1mxZxOb5OWp2R0vwGfcu7Au9HZlVw0/5dk3yWoctqY9f54WboPonVg24WsEP4qSs6/GObeddbYxnjkDcs+xVLj3mle0z9Fq1aHs+y84TDOCuwAQZeX/9etB4MLUrb6yP1ug7f+wTzNqd01Ua8DzsoZWJ8STM1yvDzLhNs7ZQxQNec3+r7zorMqzq8KnR3Tk/kIrOrKtBEPDYzrh/JumPGVf8HDFutN2eNyQPOkRHo5qhaJVExHTCw+Pr1lmG0D0lhxeUrJ6QxWGvSuOLAYxNO9dbrOPbTRHo/j+eahEryhR2LTzVVWPcnS0Trbk1SjG2HImfLnqRVvTzq+i4eSP6TZi0DR4gWU2CKzydv2FNY5C2O4EOCyRcwqxSk7H4kEnqfboR0FNFUHk1Ngvw2xxdM0q3x0+/qq6xdHljgJQrQ/rCydTMWSZ+9RdPNuRip/ackjCtIbEbS6ptv1LU6dR1rdsRlIV8xLvUUHyswVciv3OW2FUV2zOptYVO+2aFOvGPLEyh0Z5R5YHthS88nAOGRjtYtgOeBDvsmOJVuiYxnCqzJcH48/eHbpgu0/FrHgfC47TZY4kDDhopXlekXtfb5dsMJz2YsWLJhIvlvliYeXN/V7LQLo1n2ghgR0a/9FUTjuQ5qs59eBqim8mZlIewfL9mR43cy1a3YxVMLtbBTKqKFsFNXmJrvsuBLvaVZIuZ0esuP2KLSU0/MFfXkuMw20aXU+IYyY1lJiVFC7ibAuh8TGYrVSUKPLmUgBXSYOxJBylEWXSoA8RXZPluJqpNPuKplKrbMmh3C6tDC1CqE0GqZpKJg83vpJUs6mU17t+KXS1g0Y1VNVLIlasxuRKBW0+Fa8ZFKYhiSjeUaGMin4Mn3PtFUGUtEW43cb+mkwQpdNIC6OE1eUYb+rHZfp+uu+/uoOPnZ+ZHRF7Yf3PVwoYWVy2xJY4qoNaQaZxZtHQ1xBJpqHqjFl6nLECGFx94WCa6u6id4KFLh9dOJNIz9kIJr+pwmjReWZjfz06r+BGs9J7g3/uYUwf9hVGWxTHVM6fcfpyJdlRasyb0XOFwjpb1WUacgg9JzmCZ1g1l6+TuzyrrqAbN705U3qQgqWCKNpsafF8gxsTKTdpOvNYyN2y65nOs7tMqT/Po72c2qjZrNjVRuJTAIpHoIsnKxpG5UAMq3oehsnnx2pik/VCT91qJz/L/+8o617+p1L2838B
--------------------------------------------------------------------------------
/docs/evaluation/adr-parsing/README.md:
--------------------------------------------------------------------------------
1 |
2 | # Parser test
3 |
4 | ## Manual test
5 |
6 | The results of the manual check are included in [adr-parsing-manual-results.csv](./adr-parsing-manual-results.csv).
7 |
8 | ## Automatic test
9 |
10 | An automatic test checking whether an ADR can be parsed was implemented.
11 |
12 | ### Prerequisites
13 |
14 | 1. The repositories that are checked are defined in the list `REPO_NAMES` in `cypress/integration/EmpriricalAnalysis.js`. Your GitHub account must have access to those.
15 | 2. Add a file `cypress.env.json` in this folder with the auth ID of an active session. While running the ADR-Manager, you can find your `authId` in the local storage.
16 | The file content of `cypress.env.json` should look like
17 |
18 | ```[JavaScript]
19 | {
20 | "OAUTH_E2E_AUTH_ID": "abcdefg-123456"
21 | }
22 | ```
23 |
24 | where `abcdefg-123456` is your `authId`.
25 |
26 | ### Execute tests
27 |
28 | 1. Start the ADR-Manager locally: In the `adr-manager` directory execute:
29 |
30 | ```[bash]
31 | npm run serve
32 | ```
33 |
34 | 2. Run the tests: In this directory (i.e. the same as this `README`, `cypress.json` and `cypress.env.json`) execute one of the following commands
35 |
36 | ```[bash]
37 | # Open the Cypress GUI to execute tests interactively
38 | npx cypress open
39 |
40 | # Run all tests in the command line
41 | npx cypress run --spec "./cypress/integration/EmpiricalAnalysis.js"
42 | ```
43 |
44 | Possible reasons for failing tests:
45 |
46 | * The ADR-Manager is not run at `localhost:8080`. --> Start it.
47 | * The auth ID is not valid. --> Add or update `cypress.env.json`.
48 | * The repository was not found. Possible reasons I can think of:
49 | * You do not have access to a repository with a name defined in `REPO_NAMES`. --> Only include repositories you have access to.
50 | * The repository does not appear in the first tab of the "Add repositories" dialogue because e.g. are too many other repositories that were recently updated. (I didn't have problems with that but I think it will cause issues...)
51 | * A possible quick fix might be increase the maximum displayed repositories in the adr-manager's source code...
52 | * Alternatively one could modify the test to press the Next button. That would require to add a `data-cy` attribute to the Next button in the adr-manager source code
53 | and I would need to remember how to use if/else in the asynchronous setting of Cypress...
54 |
55 | The test now uses the search field. The pagination of repositories should not cause problems anymore.
56 | * The search function could be bugged.
57 | I'm having a feeling that, if someone has access to maaaany repositories, then searching will take veeeery long.
58 | This is because, while searching, all private repositories are fetched and compared to the search term before the public repositories are fetched.
59 |
60 | * The `docs/adr` folder doesn't exist, i.e., no ADR is found. --> Move ADRs into this folder.
61 |
62 | When in doubt, open the Cypress GUI and check which step fails.
63 |
64 | ### View results
65 |
66 | * `cypress/fixtures/CounterAdrsPerRepo.json`: Number of all ADRs per repository.
67 | * `cypress/fixtures/CounterDiffPerRepo.json`: Number of times the Convert tab was opened per repository.
68 | * `cypress/fixtures/Counter{Diff|Adrs}AllRepos.json`: Total numbers, i.e., sum of the above per-repository-counters.
69 | * `cypress/videos/EmpiricalAnalysis.js.mp4`: If the test was run with `npx cypress run --spec` a video is generated in `cypress/videos` where you can watch cypress clicking through the repositories. (Or possibly check what went wrong in case of failures.)
70 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/results/case-descriptions/case-description-06.md:
--------------------------------------------------------------------------------
1 | # Case Description 6
2 |
3 | ## Demographic and Professional Background
4 |
5 | * Role: lead architect
6 | * Domain: IoT, cloud platforms (includes frontend, backend, data science)
7 | * Years of work experience: 10 years
8 | * ADR experience: 5-6 years
9 | * Team size: 3-7 architects + 6 reviewers
10 | * Used template: custom template
11 | * Tools: Microsoft based -> Wiki in DevOps
12 |
13 | ## Think-Aloud Protocol
14 |
15 | _Abbreviations_: In the following, each statement is started with a letter describing the context of the statement.
16 | * O = Observation: An observation by the researchers that the participant did not explicitly mention.
17 | * P = Participant: A statement of the participant.
18 | * I = Interference: The researchers helped or pointed out something that the participant had trouble with.
19 |
20 | Needed time: 11 min
21 |
22 | * O: No problems while connecting to GitHub, adding a repository, and creating an ADR.
23 | * O: Participant tries to fill in Markdown into option fields in basic mode only at the beginning.
24 | * O: Participant tries to enter advantages and disadvantages into a considered options field in basic mode.
25 | * I: Organizers inform them about modes.
26 | * O: All fields are filled in without further instructions except for the deciders (here, it was not exactly clear to them what they have to enter)
27 | * O: Date and status are filled in at the end.
28 | * O: No problems while pushing to GitHub.
29 |
30 | ## Interview
31 |
32 | ### Functional Suitability
33 |
34 | **Which provided functionality needs to be improved?**
35 |
36 | * It was not intuitive that you don't have to write Markdown in basic mode.
37 |
38 | **Which additional functionality would you need to consider using the tool in your professional work?**
39 |
40 | * Images for architecture diagrams, e.g. pictures in the repository.
41 | * Status tracking
42 | * Who made the first proposal?
43 | * What changes were made?
44 | * When was the individual status changed?
45 | * Who accepted it?
46 |
47 | ### Usability
48 |
49 | **How understandable was the user interface for you?**
50 |
51 | * Basic and advanced mode were confusing at the start.
52 | * Considered option fields were confusing.
53 | * Differences between advanced and professional were not clear. Professional would be enough.
54 | * It was not directly clear what was meant by "Deciders".
55 |
56 | **How efficiently usable was the user interface for you?**
57 |
58 | * Efficient to use. The drag and drop in the considered options supports this.
59 | * It was intuitively usable.
60 |
61 | **Which mode would you use most often?**
62 |
63 | * The participant would directly take the mode that can do the most, since a meeting usually contains all the information that is being requested there.
64 |
65 | #### Would you switch between modes?
66 |
67 | * No.
68 |
69 | ### Final Verdict
70 |
71 | | Statement | strongly disagree | disagree | neutral | agree | strongly agree |
72 | | --------------------------------------------------------------------- | :---------------: | :------: | :-----: | :---: | :------------: |
73 | | 1. The functional suitability of the tool is fitting for its purpose. | | | | | x |
74 | | 2. The usability of the tool allows its convenient usage. | | | | x | |
75 | | 3. It is likely that I will use the tool in the future. | | | x | | |
76 |
77 | Additional comments:
78 |
79 | - Missing support for images for completeness
80 | - If it was integrated in Azure DevOps, then yes, else no.
81 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/results/case-descriptions/case-description-09.md:
--------------------------------------------------------------------------------
1 | # Case Description 9
2 |
3 | ## Demographic and Professional Background
4 |
5 | * Role: head of cloud innovation
6 | * Domain: IT service provider
7 | * Years of work experience: 5-10 years
8 | * ADR experience: 3-5 years
9 | * Team size: 5-15 people
10 | * Used template: Depends on project, Confluence or another Wiki format
11 | * Tools: Wikis
12 |
13 | ## Think-Aloud Protocol
14 |
15 | _Abbreviations_: In the following, each statement is started with a letter describing the context of the statement.
16 | * O = Observation: An observation by the researchers that the participant did not explicitly mention.
17 | * P = Participant: A statement of the participant.
18 | * I = Interference: The researchers helped or pointed out something that the participant had trouble with.
19 |
20 | Needed time: 9 min
21 |
22 | * O: No problems while connecting to GitHub, adding a repository, and creating a new ADR.
23 | * O: Participant copy-pastes options including pros and cons. They try to use Markdown syntax in the `Considered Options` field.
24 | * I: Organizers inform about modes.
25 | * O: Participant fills in the `Deciders`.
26 | * P: Participant is unsure what exactly the `Technical Story` is for. They guess that it refers to a issue-tracking system.
27 | * O: Participant fills in the `Positive Consequences`.
28 | * O: Participant fills in the `Negative Consequences`.
29 | * O: Participant fills in the `Decision Outcome`.
30 | * O: Participant is not sure if the information is saved.
31 | * O: Participant tries to switch branch but it is bugged. I: Organizers point out that it is bugged.
32 | * O: `Commit and Push` button is not easy to find.
33 |
34 | ## Interview
35 |
36 | ### Functional Suitability
37 |
38 | **Which provided functionality needs to be improved?**
39 |
40 | * Needed functionality is there.
41 |
42 | **Which additional functionality would you need to consider using the tool in your professional work?**
43 |
44 | * Voting Tool: In practice, the participant's team often votes on which option is chosen. Thus, the participant suggests to add a link to an online voting tool or integrate one.
45 |
46 | ### Usability
47 |
48 | **How understandable was the user interface for you?**
49 |
50 | * Understandable because participant knew the template. Otherwise, they may have needed more explanations of text fields.
51 | * `Commit and Push` button was hard to find.
52 | * It was not clear that, when pressing the `Accept` button in the `Convert` tab, information (that does not respect the format of MADR) is deleted.
53 |
54 | **How efficiently usable was the user interface for you?**
55 |
56 | * The tool is pretty efficiently usable.
57 | * Raw Markdown may be easier.
58 | * Having a structure is nice.
59 |
60 | **Which mode would you use most often?**
61 |
62 | * Professional mode.
63 |
64 | #### Would you switch between modes?
65 |
66 | * No.
67 |
68 | ### Final Verdict
69 |
70 | | Statement | strongly disagree | disagree | neutral | agree | strongly agree |
71 | | --------------------------------------------------------------------- | :---------------: | :------: | :-----: | :---: | :------------: |
72 | | 1. The functional suitability of the tool is fitting for its purpose. | | | | | x |
73 | | 2. The usability of the tool allows its convenient usage. | | | x | | |
74 | | 3. It is likely that I will use the tool in the future. | | | x | | |
75 |
76 | Additional comments:
77 |
78 | - Difference between `Advanced`and `Professional` mode was not clear.
79 | - In practice, the participant can't use the tool because they use Confluence. If they used GitHub and MADR, they would use the tool.
80 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/material-before-study/callout-for-participation.md:
--------------------------------------------------------------------------------
1 | # Callout for Participation
2 |
3 | Hello! We are three motivated students planning to perform a study to evaluate a web-based tool. During our research project at the University of Stuttgart, which was supervised by Oliver Kopp and Justus Bogner, we built a tool to manage and edit Architectural Decision Records (ADRs) on GitHub. [ADRs](1) are a simple format to document decisions made during the development of a software project. Our tool uses [MADR](2), which is a Markdown template for ADRs.
4 | We are looking for software professionals to test our tool and give feedback on the practical usage.
5 |
6 | All materials for the study are provided in English. For the study itself, the participant can choose between German or English.
7 |
8 | Please sign up at for a 45 to 60 min study.
9 | You do not need to prepare anything on your side.
10 | Your email address won't be published, however, your name will appear at that DFN page.
11 | Thus, choose a pseudonym if you like.
12 |
13 | ## Purpose of this Study
14 |
15 | The ADR Manager is a web-based tool to create and edit Markdown-based ADRs [MADRs](2) on GitHub.
16 | The purpose of this study is to evaluate the functional suitability and usability of the ADR Manager to support the creation and editing of ADRs. By involving software professionals who have experience with ADRs, we hope to gain insights to further improve the tool.
17 |
18 | The goal of this study is _**NOT**_ to evaluate the abilities of participants.
19 |
20 | ## Study Process and Analysis
21 |
22 | Participants will be notified about the study and will be sent the material.
23 | The study is split into two parts:
24 | First, the participant will use the tool to solve a small written task while thinking aloud.
25 | Second, there will be a short interview about the experience.
26 | Study time is estimated between 30 to 50 minutes.
27 | We kindly ask your permission to record the screen and audio during the entire study for transcription.
28 | The written transcript will be sent back to the participant for his/her final approval.
29 | This is the last chance to remove or redact statements from the study.
30 | After that, the recording will be destroyed and the potentially redacted and approved transcript will be the sole base for our qualitative content analysis.
31 |
32 | ## Privacy Policy
33 |
34 | Participation is strictly voluntary and participants can abort the study at any time without a reason.
35 | Everything that is said in the study is treated as strictly confidential and will not be disclosed to anyone outside our research team without the participant’s permission. Results are aggregated and anonymized before publication. In no way can individual statements be traced back to a participant or company. After the study, participants also have the possibility to exclude or redact statements before the analysis.
36 | Anonymized, redacted and approved case descriptions as well as the analysis will be made publicly available on GitHub. This study is part of a research project at the University of Stuttgart. Results might also be included in the final submission for [ICSE SCORE 2021](https://conf.researchr.org/home/icse-2021/score-2021).
37 | During the study, participants will use a GitHub test account created by us. ADRs created by participants will be deleted immediately after the study.
38 | The video recordings and unapproved case descriptions will _**NOT**_ be published and will be deleted until April 30, 2021.
39 |
40 |
41 | We would be very happy about your participation!
42 | If you have any questions, feel free to contact us.
43 |
44 | Daniel Abajirov, st155165@stud.uni-stuttgart.de
45 | Katrin Bauer, st161700@stud.uni-stuttgart.de
46 | Manuel Merkel, st155131@stud.uni-stuttgart.de
47 |
48 |
49 |
50 | 1: https://adr.github.io
51 | 2: https://adr.github.io/madr
52 |
--------------------------------------------------------------------------------
/src/components/EditorMadrCodemirror.vue:
--------------------------------------------------------------------------------
1 |
2 |
10 |
19 |
20 |
21 |
22 |
124 |
125 |
132 |
--------------------------------------------------------------------------------
/src/plugins/router.js:
--------------------------------------------------------------------------------
1 | import Vue from "vue";
2 | import VueRouter from "vue-router";
3 | import LandingPage from "../views/LandingPage.vue";
4 | import EditorView from "../views/EditorView.vue";
5 | import ErrorPage from "../views/ErrorPage.vue";
6 | Vue.use(VueRouter);
7 |
8 | const routes = [
9 | {
10 | path: "/",
11 | name: "Register",
12 | alias: ["/register", "/login"],
13 | component: LandingPage,
14 | meta: {
15 | title: () => {
16 | return "ADR Manager - Connect";
17 | }
18 | }
19 | },
20 | /** Route to the Editor (selects fitting sub-route) */
21 | {
22 | path: "/manager",
23 | alias: ["/editor"],
24 | name: "Editor",
25 | component: EditorView,
26 | meta: { requiresAuth: true },
27 | redirect: (to) => {
28 | if (to.params.organization && to.params.repo && to.params.branch && to.params.adr) {
29 | return { name: "EditorWithSpecifiedAdr" };
30 | } else if (to.params.organization && to.params.repo && to.params.branch) {
31 | console.log("Route to spec repo");
32 | return { name: "EditorWithSpecifiedRepo" };
33 | } else {
34 | return { name: "EditorUnspecified" };
35 | }
36 | }
37 | },
38 | // Sub-route 1: If the route does not specify a repo
39 | {
40 | path: "/manager",
41 | name: "EditorUnspecified",
42 | component: EditorView,
43 | meta: { requiresAuth: true },
44 | props: (route) => ({ ...route.query, ...route.params })
45 | },
46 | // Sub-route 2: If the route does not specify ADR but specifies a repo
47 | {
48 | path: "/manager/:organization/:repo/:branch",
49 | name: "EditorWithSpecifiedRepo",
50 | component: EditorView,
51 | meta: { requiresAuth: true },
52 | props: (route) => ({
53 | ...route.query,
54 | ...route.params,
55 | repoFullName: route.params.organization + "/" + route.params.repo,
56 | branch: route.params.branch
57 | })
58 | },
59 | // Sub-route 2: If the route does specify repo and ADR
60 | {
61 | path: "/manager/:organization/:repo/:branch/:adr",
62 | name: "EditorWithSpecifiedAdr",
63 | component: EditorView,
64 | meta: {
65 | requiresAuth: true,
66 | title: (route) => {
67 | return route.params.adr;
68 | }
69 | },
70 | props: (route) => ({
71 | ...route.query,
72 | ...route.params,
73 | repoFullName: route.params.organization + "/" + route.params.repo,
74 | branch: route.params.branch,
75 | adr: route.params.adr
76 | })
77 | },
78 | {
79 | path: "/*",
80 | name: "Error 404",
81 | component: ErrorPage
82 | }
83 | ];
84 |
85 | const router = new VueRouter({
86 | routes: routes
87 | });
88 |
89 | router.beforeEach((to, from, next) => {
90 | if (to.matched.some((record) => record.meta.requiresAuth)) {
91 | // this route requires auth, check if logged in
92 | // if not, redirect to login page.
93 | if (!localStorage.getItem("authId")) {
94 | next({
95 | path: "/login",
96 | query: { redirect: to.fullPath }
97 | });
98 | } else {
99 | next();
100 | }
101 | } else {
102 | next(); // make sure to always call next()!
103 | }
104 | });
105 |
106 | const DEFAULT_TITLE = "ADR Manager";
107 | router.afterEach((to) => {
108 | Vue.nextTick(() => {
109 | document.title = to.meta.title ? to.meta.title(to) : DEFAULT_TITLE;
110 | });
111 | });
112 |
113 | export default router;
114 |
--------------------------------------------------------------------------------
/src/plugins/parser/MADR.g4:
--------------------------------------------------------------------------------
1 | // Define a grammar called Hello
2 | grammar MADR;
3 |
4 | start :
5 | HEADING_PREFIX title NEWLINE wslbs
6 | ( STATUS_MARKER status (WS OPTIONAL_MAKER)? wslbs )?
7 | ( DECIDERS_MARKER deciders (WS OPTIONAL_MAKER)? wslbs )?
8 | ( DATE_MARKER date (WS OPTIONAL_MAKER)? NEWLINE wslbs )?
9 | ( TECHNICAL_STORY_MARKER technicalStory (WS OPTIONAL_MAKER)? wslbs )?
10 | ( CONTEXT_AND_PROBLEM_STATEMENT wslbs )?
11 | ( NEWLINE contextAndProblemStatement wslbs )? // Text without a heading is interpreted as context and problem statement
12 | ( DECISION_DRIVERS_HEADING (WS OPTIONAL_MAKER)? wslbs decisionDrivers wslbs )?
13 | ( CONSIDERED_OPTIONS_HEADING wslbs consideredOptions wslbs )?
14 | ( DECISION_OUTCOME_HEADING wslbs decisionOutcome wslbs )?
15 | ( PROS_AND_CONS_OF_THE_OPTIONS_HEADING (WS OPTIONAL_MAKER)? wslbs prosAndConsOfOptions wslbs )?
16 | ( LINKS_HEADING (WS OPTIONAL_MAKER)? wslbs links wslbs )?
17 | EOF
18 | ;
19 |
20 |
21 | title : textLine ;
22 |
23 | status: textLine ;
24 |
25 | deciders : textLine ;
26 |
27 | date : textLine ;
28 |
29 | technicalStory : textLine ;
30 |
31 | contextAndProblemStatement : multilineText ;
32 |
33 | decisionDrivers : list ;
34 |
35 | consideredOptions : list ;
36 |
37 | decisionOutcome : wslbs chosenOptionAndExplanation
38 | (wslbs POSITIVE_CONSEQUENCES_HEADING (WS OPTIONAL_MAKER)? positiveConsequences)?
39 | (wslbs NEGATIVE_CONSEQUENCES_HEADING (WS OPTIONAL_MAKER)? negativeConsequences)? ;
40 |
41 | prosAndConsOfOptions : (optionSection wslbs)+ ;
42 |
43 | optionSection :
44 | SUBSUBHEADING_PREFIX optionTitle NEWLINE
45 | (wslbs optionDescription)?
46 | (wslbs prolist)?
47 | (wslbs conlist)?
48 | ;
49 |
50 | chosenOptionAndExplanation : multilineText ;
51 | positiveConsequences : list ;
52 | negativeConsequences : list ;
53 |
54 | optionTitle : textLine ;
55 | optionDescription : multilineText ;
56 | prolist : (wslbs LIST_MARKER 'Good, because ' textLine) + ;
57 | conlist : (wslbs LIST_MARKER 'Bad, because ' textLine) + ;
58 |
59 | links : list wslbs ;
60 |
61 | list : (wslbs LIST_MARKER textLine?) + ;
62 |
63 | textLine : (any | WS) +? ;
64 |
65 | multilineText : (any | wslb) +? ; // Any (possibly multi-line) text
66 |
67 | any : ( WORD | CHARACTER | LIST_MARKER | HEADING_PREFIX | SUBSUBSUBHEADING_PREFIX) ;
68 |
69 | wslb : ( WS | NEWLINE ) ;
70 | wslbs : wslb *;
71 |
72 | /// Tokenization / Lexer rules
73 |
74 | WORD : CHARACTER+;
75 | CHARACTER : (~[\n\t\r\f ] ) ;
76 |
77 | WS : [\f\t ] ; // White Space
78 | NEWLINE : [\r]?[\n] ; // Line Breaks
79 |
80 | LIST_MARKER : NEWLINE ('* ' | '- ');
81 | STATUS_MARKER : LIST_MARKER 'Status: ';
82 | DATE_MARKER : LIST_MARKER 'Date: ';
83 | DECIDERS_MARKER : LIST_MARKER 'Deciders: ';
84 | OPTIONAL_MAKER: '';
85 | TECHNICAL_STORY_MARKER : NEWLINE 'Technical Story: ';
86 |
87 | HEADING_PREFIX : '# ' ; // Start of a Heading
88 | SUBSUBHEADING_PREFIX : NEWLINE '### ' ; // Start of a Sub sub heading (e. g. an option section)
89 | SUBSUBSUBHEADING_PREFIX : '###' '#'+ ' ' ; // Start of a sub sub sub heading (no special meaning, should be accepted in multiline text)
90 |
91 | // Headings
92 | CONTEXT_AND_PROBLEM_STATEMENT : NEWLINE ( '## Context and Problem Statement' | '## Context and problem statement' );
93 | DECISION_DRIVERS_HEADING : NEWLINE ( '## Decision Drivers' | '## Decision drivers' ) ;
94 | CONSIDERED_OPTIONS_HEADING : NEWLINE ( '## Considered Options' | '## Considered options' ) ;
95 | DECISION_OUTCOME_HEADING : NEWLINE ( '## Decision Outcome' | '## Decision outcome' ) ;
96 | POSITIVE_CONSEQUENCES_HEADING : NEWLINE ( '### Positive Consequences' | '### Positive consequences') ;
97 | NEGATIVE_CONSEQUENCES_HEADING : NEWLINE ( '### Negative Consequences' | '### Negative consequences') ;
98 | PROS_AND_CONS_OF_THE_OPTIONS_HEADING : NEWLINE ( '## Pros and Cons of the Options' | '## Pros and cons of the options') ;
99 | LINKS_HEADING : NEWLINE '## Links' ;
100 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/results/case-descriptions/case-description-07.md:
--------------------------------------------------------------------------------
1 | # Case Description 7
2 |
3 | ## Demographic and Professional Background
4 |
5 | * Role: enterprise architect
6 | * Domain: software and IT services
7 | * Years of work experience: 20 years
8 | * ADR experience: 10 years
9 | * Team size: 40 people
10 | * Used template: different templates that depend on project, no experience with [MADR](https://github.com/adr/madr)
11 | * Tools: Confluence
12 |
13 | ## Think-Aloud Protocol
14 |
15 | _Abbreviations_: In the following, each statement is started with a letter describing the context of the statement.
16 | * O = Observation: An observation by the researchers that the participant did not explicitly mention.
17 | * P = Participant: A statement of the participant.
18 | * I = Interference: The researchers helped or pointed out something that the participant had trouble with.
19 |
20 | Needed time: 10 min
21 |
22 | * Technical problem while connecting to GitHub: very long loading time and repositories did not load (possibly the Internet connection).
23 | * After disconnecting and connecting again, there were no problems anymore.
24 | * P: Participant gets confused by default text of the `because` field of `Decision Outcome`.
25 | * I: Organizers inform about different modes. Participant switches to professional mode.
26 | * O: Participant tries to enter several advantages and disadvantages in one field at the decision outcome.
27 | * O: Deciders are not directly clear.
28 | * O: The title, the date, and the status are filled in at the end.
29 | * O: The participant does not find the possibility to expand considered options.
30 | * O: The `Commit and Push` button was not found directly. P: The `Commit and Push` button could be highlighted more.
31 | * O: Push dialog was understandable.
32 |
33 | Notes:
34 |
35 | * Bug when putting a `/` in the title field (Has already been fixed)
36 |
37 | ## Interview
38 |
39 | ### Functional Suitability
40 |
41 | **Which provided functionality needs to be improved?**
42 |
43 | * All functions worked well and do not need to be improved. Only UI improvements and additional functionalities were mentioned.
44 |
45 | **Which additional functionality would you need to consider using the tool in your professional work?**
46 |
47 | * Field for vote.
48 | * Including diagrams or images, e.g. of a whiteboard.
49 | * Resubmission date.
50 | * Include opinions of deciders and who was responsible.
51 |
52 | ### Usability
53 |
54 | **How understandable was the user interface for you?**
55 |
56 | * Did not see modes at all in the beginning.
57 | * Possible solution: wizard for selecting a mode, when opening the tool and creating the ADR.
58 | * Save button should be bottom right or green and bigger.
59 | * Workflow was intuitive.
60 |
61 | **How efficiently usable was the user interface for you?**
62 |
63 | * Good except for a few small starting problems that were clear after the first use (modes, expandable options, push button).
64 |
65 | **Which mode would you use most often?**
66 |
67 | * Basic mode to record the info shortly after the meeting. Professional to elaborate everything.
68 |
69 | #### Would you switch between modes?
70 |
71 | * Yes.
72 |
73 | ### Final Verdict
74 |
75 | | Statement | strongly disagree | disagree | neutral | agree | strongly agree |
76 | | --------------------------------------------------------------------- | :---------------: | :------: | :-----: | :---: | :------------: |
77 | | 1. The functional suitability of the tool is fitting for its purpose. | | | x | | |
78 | | 2. The usability of the tool allows its convenient usage. | | | x | | |
79 | | 3. It is likely that I will use the tool in the future. | | | | x | |
80 |
81 | Additional comments:
82 |
83 | - Considered usage only if it will support BitBucket.
84 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/results/case-descriptions/case-description-05.md:
--------------------------------------------------------------------------------
1 | # Case Description 5
2 |
3 | ## Demographic and Professional Background
4 |
5 | * Role: lead architect and developer
6 | * Domain: quantum computing and AI
7 | * Years of work experience: 4 years
8 | * ADR experience: 6 years
9 | * Team size: 4-10 people
10 | * Used template: [MADR](https://github.com/adr/madr)
11 | * Tools: None specifically, mostly GitHub Editor
12 |
13 | ## Think-Aloud Protocol
14 |
15 | _Abbreviations_: In the following, each statement is started with a letter describing the context of the statement.
16 | * O = Observation: An observation by the researchers that the participant did not explicitly mention.
17 | * P = Participant: A statement of the participant.
18 | * I = Interference: The researchers helped or pointed out something that the participant had trouble with.
19 |
20 | Needed time: 18 min
21 |
22 | * There were technical problems when using the browser Safari, so the participant uses Chrome instead.
23 | * O: No problems while connecting to GitHub, adding a repository, and creating a new ADR.
24 | * O: Participant tries to fill in full descriptions, pros and cons of the options as Markdown in Basic mode (where the UI only expects option titles).
25 | * O: After switching to `Raw Markdown`-Tab and back the content is lost.
26 | * I: Organizers inform them about different modes.
27 | * O: Participant switches to Professional mode.
28 | * O: Participant understands UI concept of options (only) after they filled in a new option title in `Professional` mode and it automatically expands.
29 | * P: Participant would like "automatic" lists.
30 | * P: Icon of deciders confused participant.
31 | * They expected it to behave like the lists, i.e. that a new text field appears for additional deciders.
32 |
33 | ## Interview
34 |
35 | ### Functional Suitability
36 |
37 | **Which provided functionality needs to be improved?**
38 |
39 | * They liked that the interface was very simple and did not have too many functions.
40 |
41 | **Which additional functionality would you need to consider using the tool in your professional work?**
42 |
43 | * Support for referencing an ADR in a commit and showing the related commits when displaying the ADR.
44 | * Support for superseding / deprecation of ADRs and navigating from one ADR to another.
45 | * Partially satisfied by `Status` field, but misses possibility to reference other ADRs.
46 |
47 | ### Usability
48 |
49 | **How understandable was the user interface for you?**
50 |
51 | * Consistency: When there appears a new text field for lists, then it should do so for `Deciders`, too.
52 | * The modes are nice because they allow to start with quickly sketching an ADR and then writing more details. However, a workflow to use them naturally is missing.
53 | * Mini-HowTo for modes would help.
54 |
55 | **How efficiently usable was the user interface for you?**
56 |
57 | * Very efficient
58 | * It's nice that the user does not have to take care of the Markdown.
59 |
60 | **Which mode would you use most often?**
61 |
62 | * Basic mode for quick drafting and Professional for more detailed ADRs.
63 | * They most likely would not need Advanced mode.
64 |
65 | #### Would you switch between modes?
66 |
67 | * Most likely yes
68 |
69 | ### Final Verdict
70 |
71 | | Statement | strongly disagree | disagree | neutral | agree | strongly agree |
72 | | --------------------------------------------------------------------- | :---------------: | :------: | :-----: | :---: | :------------: |
73 | | 1. The functional suitability of the tool is fitting for its purpose. | | | | x | |
74 | | 2. The usability of the tool allows its convenient usage. | | | | x | |
75 | | 3. It is likely that I will use the tool in the future. | | | | | x |
76 |
77 | Additional comments:
78 |
79 | - Missing deprecation of ADRs.
80 | - Tab key for navigating between text fields would be nice.
81 | - Only regular usage if the tool will support GitLab.
82 |
--------------------------------------------------------------------------------
/cypress/e2e/adrManagerTest/PushNewAdr.cy.js:
--------------------------------------------------------------------------------
1 | import { REST_BRANCH_URL, REST_LIST_REPO_URL, REST_COMMIT_URL, TEST_BASE_URL } from "../../support/e2e";
2 |
3 | context("Committing, pushing, and remote-deleting an ADR", () => {
4 | it("Commit and push new ADR, then delete from GitHub", () => {
5 | const REPO_NAME = "adr/adr-test-repository-empty";
6 | const BRANCH_NAME = "testing-branch";
7 |
8 | function addRepositoryAndSwitchBranch() {
9 | cy.intercept("GET", REST_LIST_REPO_URL).as("getRepos");
10 | cy.get("[data-cy=addRepo]").click();
11 | cy.wait("@getRepos").its("response.statusCode").should("eq", 200);
12 | cy.get("[data-cy=search-field-for-adding-repository]").type(REPO_NAME);
13 | cy.wait("@getRepos").its("response.statusCode").should("eq", 200);
14 | cy.get("[data-cy=listRepo]").contains(REPO_NAME).click();
15 | cy.get("[data-cy=addRepoDialog]").click();
16 | cy.get("[data-cy=repoNameList]").click();
17 |
18 | // Select branch
19 | // Trigger loading of the branch
20 | cy.get("[data-cy=branchSelect]").trigger("click");
21 | // Select branch to commit to
22 | cy.get("[data-cy=branchSelect]").select(BRANCH_NAME);
23 | // Accept
24 | cy.contains("OK").click();
25 |
26 | // Make sure the branch was changed.
27 | cy.get("[data-cy=branchSelect]").contains(BRANCH_NAME);
28 |
29 | // Reloading the repository typically takes some time ...
30 | cy.wait(2000);
31 | }
32 | window.localStorage.clear();
33 | window.localStorage.setItem("authId", Cypress.env("OAUTH_E2E_AUTH_ID"));
34 | window.localStorage.setItem("user", Cypress.env("USER"));
35 | cy.visit(TEST_BASE_URL);
36 | addRepositoryAndSwitchBranch();
37 |
38 | // add new ADR
39 | cy.get("[data-cy=NewAdrFile]").click({ force: true });
40 | cy.get("[data-cy=titleAdr]").type("use x to accomplish y");
41 | // initiate commit dialog
42 | cy.get("[data-cy=pushIcon]").click();
43 | // check for dialog
44 | cy.get("[data-cy=btnOfDialogCommitForPush]").should("be.disabled");
45 | cy.get("[data-cy=mdiAlertNotSelected]").should("be.visible");
46 | cy.get("[data-cy=mdiAlertCommitMessage]").should("be.visible");
47 | // set commit message and commit
48 | cy.get("[data-cy=newFilesCommitMessage]").click();
49 | cy.get("[data-cy=newFileCheckBoxOuter]").contains(/[0-9][0-9][0-9][0-9]-use-x-to-accomplish-y.md/g);
50 | cy.get("[data-cy=newFileCheckBox]").check({ force: true });
51 | cy.get("[data-cy=mdiCheckSelected]").should("be.visible");
52 | cy.get("[data-cy=textFieldCommitMessage]").type("[E2ETest] Add a new ADR");
53 | cy.get("[data-cy=mdiCheckCommitMessage]").should("be.visible");
54 | // push to GitHub
55 | cy.get("[data-cy=btnOfDialogCommitForPush]").click();
56 |
57 | cy.intercept("GET", REST_BRANCH_URL).as("getCommitSha");
58 | cy.intercept("POST", REST_COMMIT_URL).as("commitRequest");
59 | cy.contains("OK").click();
60 |
61 | // Remove repository
62 | cy.get("[data-cy=removeRepo]").click();
63 | cy.get("[data-cy=removeRepoBtn]").click();
64 | cy.get("[data-cy=listRepo]").should("have.length", 0);
65 |
66 | // Re-add the repository
67 | addRepositoryAndSwitchBranch();
68 |
69 | // Check that element was added
70 | cy.get("[data-cy=adrList]").filter(':contains("Use X To Accomplish Y")').should("have.length.gte", 1);
71 |
72 | // delete the ADR
73 | cy.get("[data-cy=adrList]")
74 | .filter(':contains("Use X To Accomplish Y")')
75 | .find("[data-cy=deleteAdrBtn]")
76 | .each((el) => {
77 | el.click();
78 | cy.get("[data-cy=dialogDeleteAdrBtn] :visible").first().click();
79 | });
80 |
81 | // commit and push
82 | cy.wait(5000);
83 | cy.get("[data-cy=pushIcon]").click();
84 | cy.get("[data-cy=deletedFilesAdr]").click();
85 | cy.get("[data-cy=deletedFileCheckBox]").check({ force: true });
86 | cy.get("[data-cy=textFieldCommitMessage]").type("[E2ETest] Delete the ADR");
87 | cy.get("[data-cy=btnOfDialogCommitForPush]").click();
88 | cy.contains("OK").click();
89 | cy.wait("@getCommitSha");
90 | });
91 | });
92 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/results/case-descriptions/case-description-08.md:
--------------------------------------------------------------------------------
1 | # Case Description 8
2 |
3 | ## Demographic and Professional Background
4 |
5 | * Role: architect and developer
6 | * Domain: backend, data science
7 | * Years of work experience: 20 years
8 | * ADR experience: 10 years
9 | * Team size: 5-15 person
10 | * Used template: specific for each project
11 | * Tools: Wikiwebs, Sharepoint, Git with Markdown
12 |
13 | ## Think-Aloud Protocol
14 |
15 | _Abbreviations_: In the following, each statement is started with a letter describing the context of the statement.
16 | * O = Observation: An observation by the researchers that the participant did not explicitly mention.
17 | * P = Participant: A statement of the participant.
18 | * I = Interference: The researchers helped or pointed out something that the participant had trouble with.
19 |
20 | Needed time: 20 min
21 |
22 | * There were technical problems while connecting to GitHub. This was due to a `no script` plugin, as Heroku requires JavaScript.
23 | * P: Confusion when adding a repository. Where should the repository be taken from? Local?
24 | * O: Participant creates an ADR.
25 | * P: Spelling correction would be very helpful.
26 | * O: Participant fills in the fields in `Considered Options`.
27 | * O: Participant fills in the fields in `Decision Outcome`.
28 | * I: Organizers inform about modes because the participant believes they are done with filling in the ADR.
29 | * O: Participant fills in the fields in `Positive Consequences`.
30 | * O: Participant fills in the fields in `Negative Consequences`.
31 | * O: Participant fills in the fields in `Decision Drivers`.
32 | * O: Participant switches to `Raw Markdown`.
33 | * I: With the help of the researchers, the participant can find the additional fields in `Considered Options`.
34 | * O: Participant fills in the fields in `Good, because...` and `Bad, because...`.
35 | * O: Participant commits and pushes the ADR.
36 |
37 | ## Interview
38 |
39 | ### Functional Suitability
40 |
41 | **Which provided functionality needs to be improved?**
42 |
43 | * Needed functionality is there.
44 | * Additional free text field (if it doesn't break concept of ADRs).
45 | * `Convert` should give clearer information that content is lost.
46 | * Raw Markdown mode seems like you can write whatever you want but it is lost when switching to Editor, which is very frustrating.
47 |
48 | **Which additional functionality would you need to consider using the tool in your professional work?**
49 |
50 | * Include or link images in Markdown.
51 | * Reset content of a single file and repository.
52 | * Option to determine who edited the ADR and when. List of people who have said what.
53 | * Undo function
54 | * Function to see what has been changed and the changes between different versions. Show Git history of the ADRs.
55 |
56 | ### Usability
57 |
58 | **How understandable was the user interface for you?**
59 |
60 | * Sufficiently well
61 | * For new users, more explanations in the UI would be helpful, e.g. through explanations on hover
62 | * Modes should be explained.
63 | * Deletion of options should give a warning.
64 |
65 | **How efficiently usable was the user interface for you?**
66 |
67 | * Not really efficient, the participant will prefer to write raw Markdown with Emacs.
68 |
69 | **Which mode would you use most often?**
70 |
71 | * `Professional` mode, because it is simple enough.
72 |
73 | #### Would you switch between modes?
74 |
75 | * No, the `Professional` mode is enough.
76 |
77 | ### Final Verdict
78 |
79 | | Statement | strongly disagree | disagree | neutral | agree | strongly agree |
80 | | --------------------------------------------------------------------- | :---------------: | :------: | :-----: | :---: | :------------: |
81 | | 1. The functional suitability of the tool is fitting for its purpose. | | | | x | |
82 | | 2. The usability of the tool allows its convenient usage. | | | | x | |
83 | | 3. It is likely that I will use the tool in the future. | x | | | | |
84 |
85 | Additional comments:
86 |
87 | - Functional completeness (4), functional correctness (4), functional appropriateness (4)
88 | - Learnability (4), operability (4), aesthetics (3)
89 | - Templates are dynamic and the used tools depend on the team but, in general, the tool could be used in this field.
90 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/results/case-descriptions/case-description-01.md:
--------------------------------------------------------------------------------
1 | # Case Description 1
2 |
3 | ## Demographic and Professional Background
4 |
5 | * Role: Professor, software architecture lecturer
6 | * Domain: software quality and architecture, some experience in other fields (business information systems, autonomous systems)
7 | * Years of work experience: 20 years
8 | * ADR experience: 10 years, but not with [MADR](https://github.com/adr/madr)
9 | * Team size: _(question was not asked)_
10 | * Used template: none, free text in documentation
11 | * Tools: depends on project, e.g. Jira or other documentation like a READMEs
12 |
13 | ## Think-Aloud Protocol
14 |
15 | _Abbreviations_: In the following, each statement is started with a letter describing the context of the statement.
16 | * O = Observation: An observation by the researchers that the participant did not explicitly mention.
17 | * P = Participant: A statement of the participant.
18 | * I = Interference: The researchers helped or pointed out something that the participant had trouble with.
19 |
20 | Needed time: 18 min
21 |
22 | * O: No problems while connecting to GitHub, adding a repository, and creating an ADR.
23 | * P: Title field is confusing, as the field does not have a label.
24 | * O: Participant switches to Professional mode.
25 | * P: In general, there should be more labels and explanations for the fields.
26 | * O: Participant fills in `Decision Drivers`.
27 | * O: While filling in the `Considered Options`, participant does not see how to add the second option.
28 | * Note: The problem may be that the first option expanded automatically and thus there were many fields. After collapsing the option, the participant understood that the last field is for the next option.
29 | * O: Participant fills in the fields in `Decision Outcome`.
30 | * O: Participant notices that branch selection is bugged.
31 | * I: Organizers show where the `Commit and Push` button is, because the participant does not find it.
32 | * P: `Commit and Push` icon is confusing.
33 |
34 | ## Interview
35 |
36 | ### Functional Suitability
37 |
38 | **Which provided functionality needs to be improved?**
39 |
40 | * Connection to GitHub was easy.
41 | * Needed functionality is there.
42 |
43 | **Which additional functionality would you need to consider using the tool in your professional work?**
44 |
45 | * A plugin in the IDE would be better, as it wouldn't require a context switch and it would fit better to the participant's workflow.
46 | * Using free text with syntax highlighting and feedback for completeness would be better.
47 | * (Template) feature suggestion: Weighting decision drivers and pros/cons with stars to see which ones are more important.
48 |
49 | ### Usability
50 |
51 | **How understandable was the user interface for you?**
52 |
53 | * UI is confusing as there are too few labels. Possible improvements:
54 | * Labels for all test fields
55 | * Explanations, e.g. through explanations on hover
56 | * Maybe wizard for guidance
57 | * Good: interactive and modern
58 |
59 | **How efficiently usable was the user interface for you?**
60 |
61 | * Raw Markdown may be faster.
62 | * IDE plugin would be better.
63 | * The web application may be prettier in meetings.
64 |
65 | **Which mode would you use most often?**
66 |
67 | * Depends on the decision to be documented
68 | * Smaller decisions can be documented in Basic mode.
69 | * Most architectural decisions are complex enough that Professional mode is required. Particularly, the rationale behind the decision, e.g. decision drivers, are important to capture.
70 |
71 | #### Would you switch between modes?
72 |
73 | * Maybe
74 |
75 | ### Final Verdict
76 |
77 | | Statement | strongly disagree | disagree | neutral | agree | strongly agree |
78 | | --------------------------------------------------------------------- | :---------------: | :------: | :-----: | :---: | :------------: |
79 | | 1. The functional suitability of the tool is fitting for its purpose. | | | | x | |
80 | | 2. The usability of the tool allows its convenient usage. | | | x | | |
81 | | 3. It is likely that I will use the tool in the future. | | x | | | |
82 |
83 | Additional comments:
84 |
85 | - Usability facets: learnability (1), aesthetics (4 or 5)
86 | - They would use the tool only if it was a plugin for Visual Studio Code. They would maybe use the tool in meetings.
87 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/results/case-descriptions/case-description-02.md:
--------------------------------------------------------------------------------
1 | # Case Description 2
2 |
3 | ## Demographic and Professional Background
4 |
5 | * Role: software architecture lecturer, consultant
6 | * Domain: integration architectures in general, no specific domain
7 | * Years of work experience: 32 years work experience, 15 years as researcher, 7 years as lecturer
8 | * ADR experience: 20 years
9 | * Team size: varies a lot, both alone and in large teams
10 | * Used template: Y-Statements
11 | * [MADR](https://github.com/adr/madr) only in toy examples
12 | * Tools: plain text in Markdown, sometimes [embedded ADRs](https://github.com/adr/e-adr) when in combination with code
13 |
14 | ## Think-Aloud Protocol
15 |
16 | _Abbreviations_: In the following, each statement is started with a letter describing the context of the statement.
17 | * O = Observation: An observation by the researchers that the participant did not explicitly mention.
18 | * P = Participant: A statement of the participant.
19 | * I = Interference: The researchers helped or pointed out something that the participant had trouble with.
20 |
21 | Needed time: 18 min
22 |
23 | * O: No problems while connecting to GitHub and adding the repository.
24 | * P: Since the `New ADR` button is so big, it could be labeled `new architectural decision record`.
25 | * O: Participant copy-pastes option titles and understands that each option needs to be put in a different line.
26 | * P: Participant is unsure if they should save the ADR or whether it is auto-saved.
27 | * I: Organizers inform about modes.
28 | * P: `Basic, Advanced, Professional` should have a small explanation, maybe label it with `Usage Mode: `.
29 | * P: Participant copy-pastes consequences (i.e. list in one field).
30 | * O: After going to the Preview tab and back, they land in Convert-Tab. This tab was confusing. Participant did not immediately understand what to do there. Particularly, they did not know what is meant by "MADR-Editor".
31 | * P: Difference between `Advanced` and `Professional` mode seems too small.
32 | * P: Participant didn't find that they could expand options in Professional mode on their own, but they liked the concept of modes.
33 | * Expanding the option when clicking on pencil would be more intuitive.
34 | * O: No problems while pushing to GitHub.
35 | * P: The `Commit and Push` icon may be confusing.
36 |
37 | ## Interview
38 |
39 | ### Functional Suitability
40 |
41 | **Which provided functionality needs to be improved?**
42 |
43 | * Good: every part of Y-Statements exists in MADR.
44 | * It should also be possible to document changes over time.
45 |
46 | **Which additional functionality would you need to consider using the tool in your professional work?**
47 |
48 | * Sometimes, it's not XOR for the options
49 | * Support for changes over time: sometimes, one option is chosen as a fast solution but another option is planned to be implemented later
50 | * Combinations of options
51 | * Offline mode (often, documentation is done offline without Internet)
52 | * Import of existing ADRs
53 | * Automatic generation of a concise report as pretty presentation, e.g. Y-Statements can be put on one slide.
54 | * e.g. using PowerPoint or a white board like Miro
55 |
56 | ### Usability
57 |
58 | **How understandable was the user interface for you?**
59 |
60 | * Very well understandable, not too many hints and not too few
61 |
62 | **How efficiently usable was the user interface for you?**
63 |
64 | * Good in the example of this study
65 | * Copy-paste (particularly in lists) may be annoying over time
66 | * Visual Studio Code plugin may be better
67 |
68 | **Which mode would you use most often?**
69 |
70 | * Basic and Professional
71 |
72 | #### Would you switch between modes?
73 |
74 | * Yes.
75 |
76 | ### Final Verdict
77 |
78 | | Statement | strongly disagree | disagree | neutral | agree | strongly agree |
79 | | --------------------------------------------------------------------- | :---------------: | :------: | :-----: | :---: | :------------: |
80 | | 1. The functional suitability of the tool is fitting for its purpose. | | | | x | |
81 | | 2. The usability of the tool allows its convenient usage. | | | | | x |
82 | | 3. It is likely that I will use the tool in the future. | | | | | x |
83 |
84 | Additional comments:
85 |
86 | - Participant is likely to try out the tool, but unsure whether usage will be long-term.
87 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/results/case-descriptions/case-description-03.md:
--------------------------------------------------------------------------------
1 | # Case Description 3
2 |
3 | ## Demographic and Professional Background
4 |
5 | * Role: PhD Student, currently sole developer: lead developer, architect, and other roles
6 | * Domain: research, generation of unit test cases, open source
7 | * Years of work experience: 3 years
8 | * ADR experience: 2 years
9 | * Team size: 2-5 people
10 | * Used template: formless, sometimes with diagrams
11 | * Tools: pen and paper or text documents in Git
12 |
13 | ## Think-Aloud Protocol
14 |
15 | _Abbreviations_: In the following, each statement is started with a letter describing the context of the statement.
16 | * O = Observation: An observation by the researchers that the participant did not explicitly mention.
17 | * P = Participant: A statement of the participant.
18 | * I = Interference: The researchers helped or pointed out something that the participant had trouble with.
19 |
20 | Needed time: 13 min
21 |
22 | * O: No problems while connecting to GitHub, adding a repository, and creating an ADR.
23 | * O: No problems while filling in title, options, and selecting the chosen option.
24 | * P: The default text `(see below)` of the `because` field in `Decision Outcome` is confusing.
25 | * I: Organizers inform participant about modes.
26 | * P: Participant is unsure what the fields `Deciders`, `Technical Story`, and `Decision Drivers` are for. Particularly:
27 | * Should the `Deciders` field contain all deciders or just the recorder of the meeting?
28 | * What is the difference between `Technical Story` and `Context and Problem Statement`?
29 | * O: Participant finds possibility to expand options (by accident).
30 | * P: Preview of the formatted Markdown is good.
31 | * O: No problems while pushing to GitHub.
32 |
33 | ## Interview
34 |
35 | ### Functional Suitability
36 |
37 | **Which provided functionality needs to be improved?**
38 |
39 | * Given functions of the tool work well.
40 | * The text field for deciders was confusing. It should be like lists.
41 |
42 | **Which additional functionality would you need to consider using the tool in your professional work?**
43 |
44 | * Support for including images.
45 | * GitHub as host is great for the participant but their colleagues would require GitLab.
46 | * If the participant wanted to capture ADRs in teams, they would use the tool, because it gives an external structure.
47 |
48 | ### Usability
49 |
50 | **How understandable was the user interface for you?**
51 |
52 | * Modes were confusing. It was hard to understand that they were related to the editor.
53 | * More explanations for each sections would be helpful, e.g. a question mark next to title which shows an explanation on hover.
54 | * List items should have a dot at the start to show that it's a list.
55 | * Multi-line text fields (like `Context and Problem Statement`) should be bigger.
56 | * In the `Convert` tab, it's confusing what to do when one does not want to accept. Maybe a button saying `Cancel` or `Let me edit it` could be added that redirects to `Raw Markdown` tab.
57 | * "Would a short tutorial at the start be helpful?" --> A tutorial may overdo it, but a short motivational text which explains what ADRs are for would be helpful.
58 |
59 | **How efficiently usable was the user interface for you?**
60 |
61 | * Good, the UI is fast and clearly structured.
62 |
63 | **Which mode would you use most often?**
64 |
65 | * The participant would prefer to customize which fields are visible, e.g. they would use `Links` (from Professional mode) but not `Technical Story` (from Advanced mode). Ideally, all headings should be visible but collapsible.
66 |
67 | #### Would you switch between modes?
68 |
69 | * Maybe
70 |
71 | ### Final Verdict
72 |
73 | | Statement | strongly disagree | disagree | neutral | agree | strongly agree |
74 | | --------------------------------------------------------------------- | :---------------: | :------: | :-----: | :---: | :------------: |
75 | | 1. The functional suitability of the tool is fitting for its purpose. | | | | | x |
76 | | 2. The usability of the tool allows its convenient usage. | | | | x | |
77 | | 3. It is likely that I will use the tool in the future. | | | x | | |
78 |
79 | Additional comments:
80 |
81 | - Functional completeness (5), functional correctness (5), functional appropriateness (4)
82 | - Learnability (3), operability (5), user interface aesthetics (4)
83 | - Very dependent on the other members of a team
84 |
--------------------------------------------------------------------------------
/src/components/EditorConvert.vue:
--------------------------------------------------------------------------------
1 |
2 |
9 | Sorry, there were issues while parsing the ADR.
10 |
11 | If you want to use the MADR-Editor, our parser will generate the markdown on the right-hand side. You can
12 | edit your raw Markdown to make sure that no important content is lost while parsing.
13 | Note, that we only support MADRs matching the template at
14 |
15 | https://github.com/adr/madr/blob/master/template/template.md
16 |
17 |
18 |
19 |
20 |
Your ADR
21 |
Result
22 |
23 |
24 |
33 |
34 |
35 | Accept
36 |
37 |
38 |
39 |
131 |
132 |
140 |
--------------------------------------------------------------------------------
/docs/evaluation/user-study/results/case-descriptions/case-description-04.md:
--------------------------------------------------------------------------------
1 | # Case Description 4
2 |
3 | ## Demographic and Professional Background
4 |
5 | * Role: principal architect, data engineer
6 | * Domain: consulting
7 | * Years of work experience: 10
8 | * ADR experience: 5 years
9 | * Team size: 5-8 people
10 | * Used template: none, project-specific
11 | * Tools: none specifically
12 |
13 | ## Think-Aloud Protocol
14 |
15 | _Abbreviations_: In the following, each statement is started with a letter describing the context of the statement.
16 | * O = Observation: An observation by the researchers that the participant did not explicitly mention.
17 | * P = Participant: A statement of the participant.
18 | * I = Interference: The researchers helped or pointed out something that the participant had trouble with.
19 |
20 | Needed time: 14 min
21 |
22 | * O: No problems while connecting to GitHub, adding a repository, and creating an ADR.
23 | * O: Participant overlooks the field for the title and fills in other information first.
24 | * O: Participant first puts all options in one option field. Then gets confused when the `Chosen option` dropdown only shows it as one option.
25 | * I: Organizers inform about different fields in considered options list.
26 | * O: Participant gets confused by default text of the `because` field of `Decision Outcome`.
27 | * I: Organizers inform about different modes. Participant switches to advanced mode.
28 | * O: Participant gets confused by the name `0000-.md` of the file in the `Commit and Push` Dialog, then notices the title field of the MADR and fills it in.
29 | * I: Organizers inform about expandability of considered options, calendar function, status, and deciders in Advanced mode.
30 | * O: Icon of deciders confuses participant.
31 | * They expected it to behave like the lists, i.e. that a new text field appears for additional deciders.
32 | * O: There were no problems while committing and pushing (upload sign for push is clear).
33 |
34 | ## Interview
35 |
36 | ### Functional Suitability
37 |
38 | **Which provided functionality needs to be improved?**
39 |
40 | * Modes were confusing: when to use each mode?
41 | * It seems like you can always use Professional mode.
42 | * Does not see the advantages of the different modes.
43 | * Having fields that are only visible in one mode was confusing.
44 | * Support for copy-paste in lists.
45 | * As a professional tool, it would need auto completion for decision makers.
46 |
47 | **Which additional functionality would you need to consider using the tool in your professional work?**
48 |
49 | * Search for decisions as well as within decisions.
50 | * Linking decisions to other decisions, e.g. one decision often depends on others or is followed by others.
51 | * Including images
52 | * Either by pushing an image file to GitHub and linking it in Markdown or using rich text to create diagrams.
53 |
54 | ### Usability
55 |
56 | **How understandable was the user interface for you?**
57 |
58 | * User interface is easy to understand.
59 | * Having the `Commit and Push` button directly next to the `Remove repository` button may be dangerous.
60 | * Modes were confusing at first, but once you know the differences they are understandable.
61 | * The `Title` field was confusing at first. It should have a label like the other fields.
62 |
63 | **How efficiently usable was the user interface for you?**
64 |
65 | * If you know the workflow, the interface is good to use.
66 |
67 | **Which mode would you use most often?**
68 |
69 | * Professional mode
70 |
71 | #### Would you switch between modes?
72 |
73 | * Currently, participant would use basic mode for quick drafts, because the options expand automatically in advanced and professional mode.
74 | * However, with a few changes, the participant would only use the professional mode:
75 | * Default expansion of new option items slows down writing progress. If the considered options did not expand automatically in professional mode (description and pros and cons), there would be no need for basic mode.
76 | * The advanced mode would not be needed, since the links and the decision drivers do not take up so much space.
77 |
78 | ### Final Verdict
79 |
80 | | Statement | strongly disagree | disagree | neutral | agree | strongly agree |
81 | | --------------------------------------------------------------------- | :---------------: | :------: | :-----: | :---: | :------------: |
82 | | 1. The functional suitability of the tool is fitting for its purpose. | | | | x | |
83 | | 2. The usability of the tool allows its convenient usage. | | | | x | |
84 | | 3. It is likely that I will use the tool in the future. | | | x | | |
85 |
86 | Additional comments:
87 |
88 | - Strongly depends on client. As consultant, the participant may propose the tool to the client.
89 |
--------------------------------------------------------------------------------
/src/plugins/parser/MADRListener.js:
--------------------------------------------------------------------------------
1 | // Generated from MADR.g4 by ANTLR 4.13.0
2 | // jshint ignore: start
3 | import antlr4 from "antlr4";
4 |
5 | // This class defines a complete listener for a parse tree produced by MADRParser.
6 | export default class MADRListener extends antlr4.tree.ParseTreeListener {
7 | // Enter a parse tree produced by MADRParser#start.
8 | enterStart(ctx) {}
9 |
10 | // Exit a parse tree produced by MADRParser#start.
11 | exitStart(ctx) {}
12 |
13 | // Enter a parse tree produced by MADRParser#title.
14 | enterTitle(ctx) {}
15 |
16 | // Exit a parse tree produced by MADRParser#title.
17 | exitTitle(ctx) {}
18 |
19 | // Enter a parse tree produced by MADRParser#status.
20 | enterStatus(ctx) {}
21 |
22 | // Exit a parse tree produced by MADRParser#status.
23 | exitStatus(ctx) {}
24 |
25 | // Enter a parse tree produced by MADRParser#deciders.
26 | enterDeciders(ctx) {}
27 |
28 | // Exit a parse tree produced by MADRParser#deciders.
29 | exitDeciders(ctx) {}
30 |
31 | // Enter a parse tree produced by MADRParser#date.
32 | enterDate(ctx) {}
33 |
34 | // Exit a parse tree produced by MADRParser#date.
35 | exitDate(ctx) {}
36 |
37 | // Enter a parse tree produced by MADRParser#technicalStory.
38 | enterTechnicalStory(ctx) {}
39 |
40 | // Exit a parse tree produced by MADRParser#technicalStory.
41 | exitTechnicalStory(ctx) {}
42 |
43 | // Enter a parse tree produced by MADRParser#contextAndProblemStatement.
44 | enterContextAndProblemStatement(ctx) {}
45 |
46 | // Exit a parse tree produced by MADRParser#contextAndProblemStatement.
47 | exitContextAndProblemStatement(ctx) {}
48 |
49 | // Enter a parse tree produced by MADRParser#decisionDrivers.
50 | enterDecisionDrivers(ctx) {}
51 |
52 | // Exit a parse tree produced by MADRParser#decisionDrivers.
53 | exitDecisionDrivers(ctx) {}
54 |
55 | // Enter a parse tree produced by MADRParser#consideredOptions.
56 | enterConsideredOptions(ctx) {}
57 |
58 | // Exit a parse tree produced by MADRParser#consideredOptions.
59 | exitConsideredOptions(ctx) {}
60 |
61 | // Enter a parse tree produced by MADRParser#decisionOutcome.
62 | enterDecisionOutcome(ctx) {}
63 |
64 | // Exit a parse tree produced by MADRParser#decisionOutcome.
65 | exitDecisionOutcome(ctx) {}
66 |
67 | // Enter a parse tree produced by MADRParser#prosAndConsOfOptions.
68 | enterProsAndConsOfOptions(ctx) {}
69 |
70 | // Exit a parse tree produced by MADRParser#prosAndConsOfOptions.
71 | exitProsAndConsOfOptions(ctx) {}
72 |
73 | // Enter a parse tree produced by MADRParser#optionSection.
74 | enterOptionSection(ctx) {}
75 |
76 | // Exit a parse tree produced by MADRParser#optionSection.
77 | exitOptionSection(ctx) {}
78 |
79 | // Enter a parse tree produced by MADRParser#chosenOptionAndExplanation.
80 | enterChosenOptionAndExplanation(ctx) {}
81 |
82 | // Exit a parse tree produced by MADRParser#chosenOptionAndExplanation.
83 | exitChosenOptionAndExplanation(ctx) {}
84 |
85 | // Enter a parse tree produced by MADRParser#positiveConsequences.
86 | enterPositiveConsequences(ctx) {}
87 |
88 | // Exit a parse tree produced by MADRParser#positiveConsequences.
89 | exitPositiveConsequences(ctx) {}
90 |
91 | // Enter a parse tree produced by MADRParser#negativeConsequences.
92 | enterNegativeConsequences(ctx) {}
93 |
94 | // Exit a parse tree produced by MADRParser#negativeConsequences.
95 | exitNegativeConsequences(ctx) {}
96 |
97 | // Enter a parse tree produced by MADRParser#optionTitle.
98 | enterOptionTitle(ctx) {}
99 |
100 | // Exit a parse tree produced by MADRParser#optionTitle.
101 | exitOptionTitle(ctx) {}
102 |
103 | // Enter a parse tree produced by MADRParser#optionDescription.
104 | enterOptionDescription(ctx) {}
105 |
106 | // Exit a parse tree produced by MADRParser#optionDescription.
107 | exitOptionDescription(ctx) {}
108 |
109 | // Enter a parse tree produced by MADRParser#prolist.
110 | enterProlist(ctx) {}
111 |
112 | // Exit a parse tree produced by MADRParser#prolist.
113 | exitProlist(ctx) {}
114 |
115 | // Enter a parse tree produced by MADRParser#conlist.
116 | enterConlist(ctx) {}
117 |
118 | // Exit a parse tree produced by MADRParser#conlist.
119 | exitConlist(ctx) {}
120 |
121 | // Enter a parse tree produced by MADRParser#links.
122 | enterLinks(ctx) {}
123 |
124 | // Exit a parse tree produced by MADRParser#links.
125 | exitLinks(ctx) {}
126 |
127 | // Enter a parse tree produced by MADRParser#list.
128 | enterList(ctx) {}
129 |
130 | // Exit a parse tree produced by MADRParser#list.
131 | exitList(ctx) {}
132 |
133 | // Enter a parse tree produced by MADRParser#textLine.
134 | enterTextLine(ctx) {}
135 |
136 | // Exit a parse tree produced by MADRParser#textLine.
137 | exitTextLine(ctx) {}
138 |
139 | // Enter a parse tree produced by MADRParser#multilineText.
140 | enterMultilineText(ctx) {}
141 |
142 | // Exit a parse tree produced by MADRParser#multilineText.
143 | exitMultilineText(ctx) {}
144 |
145 | // Enter a parse tree produced by MADRParser#any.
146 | enterAny(ctx) {}
147 |
148 | // Exit a parse tree produced by MADRParser#any.
149 | exitAny(ctx) {}
150 |
151 | // Enter a parse tree produced by MADRParser#wslb.
152 | enterWslb(ctx) {}
153 |
154 | // Exit a parse tree produced by MADRParser#wslb.
155 | exitWslb(ctx) {}
156 |
157 | // Enter a parse tree produced by MADRParser#wslbs.
158 | enterWslbs(ctx) {}
159 |
160 | // Exit a parse tree produced by MADRParser#wslbs.
161 | exitWslbs(ctx) {}
162 | }
163 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # ADR-Manager  [](https://github.com/adr/adr-manager/blob/main/LICENSE) [](https://github.com/adr/adr-manager/commits/main) [](https://github.com/adr/adr-manager/issues) [](https://github.com/adr/adr-manager/stargazers)
2 |
3 | > A web-based application for the efficient creation and management of [architectural decision records (ADRs)](https://adr.github.io) in Markdown (MADR)
4 |
5 | ## Description
6 |
7 | [MADR](https://adr.github.io/madr/) is a Markdown template for quickly capturing architectural decisions.
8 | It offers a naming scheme and template to keep the layout of recorded decisions consistent.
9 | Each decision is stored in a separate file.
10 | The ADR Manager currently only supports the management of MADRs stored in the folder `docs/adr` in GitHub repositories.
11 |
12 | ## Quick Start
13 |
14 | You can find the tool at https://adr.github.io/adr-manager.
15 |
16 | ## Supported Browsers
17 |
18 | Currently, the tool has been successfully tested in Chrome, Firefox, and Opera.
19 |
20 | ### Usage
21 |
22 | 1. After opening the tool, connect to GitHub. The tool needs your permission to access your GitHub repositories and email address.
23 | 2. Add a GitHub repository. If your account does not have access to a repository with MADRs, you can simply fork one, e.g., or .
24 | 3. Now, you can edit any files in `docs/adr` of the GitHub repository.
25 | Edit existing ADRs or create new ones.
26 | One of the most important features is the MADR Editor that allows you to quickly draft a MADR while ensuring a consistent format.
27 | 
28 | 4. Do not forget to push your changes to GitHub, once you are done with editing the files.
29 |
30 | Some technical notes:
31 |
32 | - The `authID` (which enables the connection to GitHub) and changes to ADRs are stored in the local storage.
33 | That way they are not lost when you reload the page or restart the browser.
34 | However, changes will be lost when you either
35 | - Clear local storage or
36 | - Press the `Disconnect` button.
37 | - The general idea is that you directly push your changes to GitHub after editing.
38 | - During development, we may remove permissions for the OAuth App from time to time.
39 | Do not be surprised, if you have to give permissions repeatedly.
40 |
41 | ## Development
42 |
43 | ### Prerequisites
44 |
45 | - Node.js and npm
46 | - A GitHub account with access to a repository with MADRs
47 |
48 | ### Installation
49 |
50 | To run the project locally, follow these steps:
51 |
52 | 1. Clone this repository.
53 | 2. Install dependencies with `npm install`.
54 | 3. Compile and start the application with `npm start`.
55 |
56 | Note that, even when you run it locally, you need to connect to GitHub to use any functionality.
57 |
58 | ### Using End-2-End Tests Locally
59 |
60 | We use [Cypress](https://www.cypress.io/) for e2e testing.
61 | The CI pipeline provides the necessary Oauth `authId` as an ENV variable.
62 | Locally, however, you'll need to provide one yourself.
63 | You can either set `CYPRESS_OAUTH_E2E_AUTH_ID` and `CYPRESS_USER` containing the `authId` and `user` or create a `cypress.env.json` file and fill it with the following content:
64 |
65 | ```json
66 | {
67 | "OAUTH_E2E_AUTH_ID": "*********",
68 | "USER": "***********"
69 | }
70 | ```
71 |
72 | The value of `OAUTH_E2E_AUTH_ID` and `USER` needs to be a valid `authId` and `user` from an active OAuth session, which you can obtain in the local storage (Chrome developer console -> Application -> Storage -> Local Storage -> `http://localhost:8080` -> `authId`, `user`)
73 | The involved GitHub account also needs to have developer access to the repo `adr/adr-test-repository-empty`.
74 | Lastly, don't forget to start the app before running the e2e tests (`npm start`).
75 |
76 | ### Useful Commands
77 |
78 | The following commands are useful for development:
79 |
80 | ```bash
81 | # install dependencies
82 | npm install
83 |
84 | # build and start with hot-reload for development
85 | npm start
86 |
87 | # build and minify for production
88 | npm run build
89 |
90 | # run unit tests
91 | npm test
92 |
93 | # run e2e tests
94 | npm run e2e:test
95 |
96 | # open cypress GUI for e2e tests
97 | npx cypress open
98 |
99 | # run a single e2e test
100 | npx cypress run --spec ./cypress/e2e/adrManagerTest/
101 |
102 | # format code with prettier (do this before you commit and push)
103 | npm run format
104 | ```
105 |
106 | ### Backend Setup
107 |
108 | The project uses [OAuth] for the authentication to GitHub.
109 | If you do not want to use this instance, you can easily set up your own by following these steps:
110 |
111 | 1. Create an OAuth application on GitHub (see [here](https://docs.github.com/en/github-ae@latest/developers/apps/creating-an-oauth-app)).
112 | - Copy the Client ID and Client Secret of the app (you'll need them later).
113 | 2. Create a Github app on Firebase and in its configurations, set the Client ID and Client Secret as copied from the above Github app
114 |
115 | - Set the callback URL in Github Oauth app configuration to the one provided by Firebase.
116 |
117 | ## Project Context
118 |
119 | This project was started as an undergraduate research project at the Institute of Software Engineering of the University of Stuttgart, Germany.
120 | It was also submitted to the [ICSE Score Contest 2021](https://conf.researchr.org/home/icse-2021/score-2021).
121 | Since then, it has been given over to the [ADR organization on GitHub](https://github.com/adr), where it is maintained and extended.
122 |
--------------------------------------------------------------------------------
/src/components/EditorMadrStatusDateDecidersStory.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 | The date of the last update
9 |
10 |
11 |
12 |
13 |
14 |
15 | {{ displayedStatus }}
16 |
17 |
18 |
19 |
20 |
29 |
30 |
38 |
39 |
40 |
41 |
42 | The current status of the ADR
43 |
44 |
45 |
46 |
47 |
48 | mdi-account-multiple
49 |
60 |
61 |
62 | Everyone involved in the decision, e.g., separated with commas.
63 |
64 |
65 |
66 |
67 |
68 |
69 |
Technical Story:
70 |
71 |
72 |
73 |
74 | Technical context of the ADR, e.g., a ticket or issue URL
75 |
76 |
77 |
78 |
79 |
157 |
158 |
164 |
--------------------------------------------------------------------------------
/src/components/Editor.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
46 |
47 |
48 |
49 |
50 |
51 |
52 |
53 |
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 | {{ item }}
63 |
64 |
65 |
66 |
67 |
68 |
69 |
183 |
--------------------------------------------------------------------------------
/src/components/EditorMadr.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
19 |
20 |
21 | This is the Title.
22 | It should describe the solved problem and the solution concisely.
23 | The title is also used as file name, so keep it short and avoid using special
24 | characters.
25 |
26 |
27 |
28 |
29 |
30 |
38 |
39 |
40 | Some fields of this ADR are not displayed in the current mode.
41 |
42 |
43 | Switch to {{ minimumRequiredModeForAdr(adr) }} Mode
44 |
45 |
46 |
47 |
48 |
54 |
55 |
56 |
57 |
58 |
59 | Context and Problem Statement
60 |
61 | Describe the context and problem statement, e.g., in free form using two to three sentences.
62 |
63 | You may want to articulate the problem in form of a question.
64 |
65 |