v2.3.8

CONDEC-1028: Fix that projectKey was undefined in rationale backlog (…

v2.3.7

CONDEC-1028: Improve decision grouping, automatic text classification…

v2.3.6

Improvements

• WI: Show knowledge from default branch, not just from feature branches from git (CONDEC-981)
• WI: Enable to filter and configure link recommendation view (CONDEC-1006)
• WI: Refactor dashboard code and add documentation in github (CONDEC-996)
  • How to enable navigation from metrics plots in dashboard to detail views?
    • We pass knowledge elements from backend to frontend via REST and use the URL attribute for navigation from metric points to detail views!
      • Passing the entire knowledge elements also enables to use other attributes such as summary/name and type of the element
    • rejected: We used to only pass the keys of the knowledge elements from backend to frontend.
      • Parsing of keys to URLs in cumbersome, does not allow to use other attributes such as summary/name and type of the element
  • Where to calculate metrics on the knowledge documentation?
    • We calculate the metrics on the knowledge documentation in the backend in Java! Move metric calculation for branch metrics into backend to unify metric calculation: Add REST API for branch metrics and BranchMetricsCalculator
      • Metric calculation can be easily tested via unit testing
• WI: Show more positive aspects in quality check tab (CONDEC-1000)
  • How to present the results of quality checking in the quality check view?
    • Show criterion check results in table in quality check view!
      • unresolved: Positive and negative check results can be presented.
  • When should we check whether the linked knowledge for a knowledge element fulfills the DoD?
    • rejected: We used to check whether the linked knowledge for a knowledge element fulfills the DoD all the time.
      • Requires a ot of computation resources
    • Only check the linked knowledge for elements that fulfill the DoD in any other criteria!
      • Saves computation resources in comparison to checking the linked knowledge all the time.
• WI: Enable to export knowledge subgraph as markdown text (CONDEC-1010)
  • How to sort the exported knowledge elements?
    • Sort elements by key when exporting them to Word and JSON!
      • Keeps the order in Jira issue text
      • Can be different to for example the order in the indented outline.
    • We could change the REST API to return an ordered list created with e.g. a depth first iterator.
      • Would take more computation effort
• WI: Enable to show link recommendations within the knowledge graph views and during CIA (CONDEC-1005)
• WI: Exclude wrong links during transitive linking (CONDEC-1016)
• WI: Implement that mock PluginSettings stores and returns the gitUri for the TEST project (CONDEC-518)
  • How to mock the git URI for the mock git repo?
    • Enable to store default settings in MockPluginSettings class for unit testing!
  • Should we have one or more git repositories for testing?
    • We used to have more than one mock git repositories for testing!
    • We have one mock git repositories for testing!
      • This is more efficient than recreating the test git repository all the time.
      • The mock git repository can be easily accessed using the Plugin Settings (see ConfigPersistenceManager class).
      • Changes to the git repository (e.g. new commits) during testing has an effect on the test cases that follow. The order of test cases is arbitrary.
• WI: Add documentation for decision guidance in github (CONDEC-985)
• WI: Improve just-in-time prompts for developer nudging (CONDEC-938)
  • How much information about each feature should the unified prompt show?
    • The unified prompt should show only enough information as is required to understand what needs to be fixed!
      • The developer can see what is wrong and fix it on a separate tab
      • The developer has to switch context to fix the problems
    • The unified prompt should show as much information as possible!
      • Too much information could make the developer more likely to close the prompt without reading it
    • The number of decision guidance suggestions for each related decision problem should be shown!
    • The amount of recommended links/duplicates should be displayed!
    • The elements that are not validated should be displayed with their summaries and classifications!
    • The required rationale coverage and the current coverage should be shown!
• WI: Pass latest update author via REST API for usage in the ConDec Confluence meeting agenda (CONDEC-1008)
• WI: Simplify duplicate recognition functionality (CONDEC-1004)
  • ![I...

v2.3.5

New Features

• SF: Create release notes (CONDEC-537)
  • Which decision knowledge elements are included in the release notes?
    • rejected: We include decision problems (issues) and decisions into release notes!
      • A decision can better be understood if also alternatives and arguments are provided.
    • We include all decision knowledge elements (also arguments and alternatives) into the relase notes!
• SF: Show release notes (CONDEC-682)
• SF: Group decisions (CONDEC-692)
• SF: Manage decision groups (CONDEC-693)

Improvements

• WI: Enable change impact highlighting in knowledge graph views (CONDEC-955)
  • Where should change impact analysis be enabled?
    • Remove separate change impact analysis tabs and enable change impact highlighting in jstree, vis, and matrix views instead!
    • Enable change impact highlighting in knowledge graph views!
    • rejected: Add a separate tab for change impact analysis!
• WI: Set documentation (creation, last update) time and author of code files and decision knowledge elements from code correctly (CONDEC-969)
  • How to set the creation date, the date of last update, and the author of knowledge elements from code?
    • Set creation and updating time of ChangedFile using the list of the commits in that the files was changed and their commit times!
    • Update code files in the knowledge graph with correct commits attribute after reading it from git!
    • Set author of code files and decision knowledge from code comments as the author of the last commit that changed the file!
• WI: Improve graph creation and management (CONDEC-976)
• WI: Improve release notes creation (CONDEC-979)
  • Which parameters should be query and which parameters should be path parameters in the REST API?
    • Make id a PathParam in REST API!
      • Complies with the REST API convention
  • How should we present the status of a decision knowledge element in the release notes?
    • Write element status in markdown text of release notes if it is not a "normal" status, e.g. if challenged, rejected, discarded, and unresolved!
  • How can we create the markdown String for the release notes content?
    • Iterate the knowledge graph using a DepthFirstIterator to create the markdown String for the release notes content!
  • How can we sort release notes entries by their rating?
    • Make ReleaseNotesEntry implement the Comparable interface for easy sorting!
• WI: Show reason for failed definition of done check in rationale backlog (CONDEC-946)
  • How should the violated criteria of the definition of done (DoD) be visualised?
    • Show the details in a tool tip.
      • The information is shown instead of the description of the knowledge element.
      • Can see the information directly in the graph.
      • Can show the information for all knowledge elements in the graph/tree.
    • Show the details in a quality check tab.
      • Can only show the information for knowledge elements that are also Jira issues.
      • The user can see the information without having to mouse over an element.
      • Has to navigate to tab to see the information.
    • Colour the elements/nodes of the knowledge graph/tree that violate the DoD in red!
      • Colouring the nodes red can make it difficult to read the content of the nodes if the text has already been coloured.
      • The user can see which elements violate the DoD for all linked elements at once.
      • The user can directly see the elements that violate the DoD in all tree/graph views.
• WI: Refactor grouping of decisions (CONDEC-977)
• WI: Create BasicConfiguration class to bundle basic plug-in settings in one class (CONDEC-950)
  • How should the plug-in be activated?
    • rejected: The plug-in is disabled per default (opt-in policies) and can be manually activated by the rationale manager!
    • Enable ConDec per default (opt-out nudging)!
• WI: Improve options for validation of elements (CONDEC-954)
  • Where should the information about automated text classifications be displayed?
    • Display information about text classifications in a tab combined with information about other smart features!
      • This would be hard to use.
    • Display information about the automated text classifications in a just-in-time prompt!
    • Display informat...

v2.3.4

Improvements

• WI: Refactor extraction of code files from git and decision knowledge from code files (CONDEC-945)
  • How can we prevent long loading times for creating and presenting the knowledge graph?
    • Use parallelStreams and separate threads to prevent long loading times for creating and presenting the knowledge graph!
      • Works well from a user point of view.
      • Unit testing is not deterministic anymore and tests sometimes fail for an unknown reason.
  • How can we support working with subclasses of KnowledgeElement (e.g. ChangedFile, PartOfJiraIssueText, Recommendation, ...)?
    • Work with generics to support working with subclasses of KnowledgeElement (e.g. ChangedFile, PartOfJiraIssueText, Recommendation, ...)!
• WI: Update SMILE library for text classification and online training of text classifier (CONDEC-855)
  • Which libraries should we use for automatic text classification?
    • Remove weka and meka dependencies because it is not needed anymore, we do text classification with smile (Statistical Machine Intelligence and Learning Engine)!
• WI: Improve decision guidance (CONDEC-840)
  • How can a recommendation be traced to its knowledge source?
    • We show the icon of the knowledge source next to each recommendation!
      • Obvious with no user interaction!
    • We could add tooltips on each recommendation to show their respective knowledge source!
      • Users who don't know that tooltips exist would not find them.
  • How could we improve usablity of the evaluation of knowledge sources?
    • Let the user decide which metrics are relevant!
      • The user has to know how the metrics are calculated.
      • The user can decide what to see
    • We add descriptions to each metric!
      • The description is more detailed and the user can understand the feature better.
• WI: Integrate linking support and duplicate detection into one single view (CONDEC-936)
• WI: Improve generation and support for transitive links (CONDEC-911)
  • How can we filter the knowledge graph regarding link distance?
    • rejected: We filter the knowledge graph regarding link distance as follows: 1) Get a subgraph with the correct link distance. 2) Apply all other filter criteria, e.g. knowledge type on the knowledge elements of the subgraph. 3) Get a subgraph with the correct link distance including only the elements that remain after step 2!
      • Filtering other criteria than link distance is quick because it is not done on the entire graph.
      • Link distance filtering is done twice before and after filtering the other criteria.
    • Try to work with jGraphT's distanceAndPredecessor map to avoid redundant link distance filtering.
      • This is not working. Since the distanceAndPredecessor map only contains one predecessor link for an element, we cannot decide whether the element should be kept after filtering.
    • We create a subgraph matching the link distance filter first. Then, we remove all links and verteces not matching the filter criteria and we add transitive links (if enabled)!
  • How can we replace filtered nodes/elements in the knowledge graph with transitive links?
    • Use ShortestPathAlgorithm of jGprahT library to get SingleSourcePaths from a knowledge element within a certain distance in the graph, use the GraphPaths to create transitive links!
• WI: Implement change impact analysis (CIA) algorithm and views (CONDEC-890)
  • What parameters and filter criteria should be considered during change impact analysis (CIA)?
    • We use a rule-based and a dependency/traceability-based change impact analysis (CIA) approach!
    • We enable change impact analysis (CIA) in the knowledge graph views so that all the filter criteria can be applied during CIA!
  • Where should developers be enabled to perform change impact analysis?
    • rejected: We could add a new tab for CIA in the Jira issue detail view!
      • Central entrypoint for developers
      • Problem with knowledge elements in comments and descriptions and code files from git.
      • Change impact analysis is shown directly at the current work item/requirement.
    • rejected: We could add a new tab for CIA in the project's decision knowledge view!
      • CIA is possible starting from every knowledge element, also knowledge elements in comments and descriptions and code files from git.
      • Central entrypoint for requirements engineers
    • We could extend the current views on the knowledge graph with the possibility to perform CIA!
      • CIA is possible starting from every knowledge element, also knowledge elements in comments and descriptions and code files from git.
      • ![Pro](https://raw.githubusercontent.com/cures-hub/cures-condec-jira/master/src/main/resources/images/argum...

v2.3.0

Deploy via Travis CI