Tempo IDE Tracker T-404-LOKA

Students Instructor Alexander Björnsson Áslaug Eiríksdóttir Snorri Hjörvar Jóhannsson Examiner Benedikt Hólm Þórðarson Karl Andrés Gíslason Acknowledgements

We would like to thank our product owners, Árni Geir Úlfarson and Stefán Einar Stefánsson for their patience with our questions and their invaluable feedback. Our contact at Tempo, Þórey Rúnarsdóttir for providing us with our workspace and proofreading our design document. Our gratitude also extends to our instructor, Áslaug Eiríksdóttir for her reli- ability, patience and willingness to lend us her time during this project. And our examiner, Karl Andrés Gíslason, for giving valuable critique through the course of this project.

We couldn’t have done this without you. Thank you for the semester. Háskólinn í Reykjavík T-404-LOKA

Contents

1 Introduction2

2 The Extensions3 2.1 The Product...... 4

3 Risk Analysis4 3.1 About...... 4 3.2 The Risk Analysis Table...... 6 3.3 Results and Encounters...... 7

4 Design8 4.1 The Project Stack...... 8 4.1.1 Project Management...... 9 4.1.2 Development Pipeline...... 10 4.1.3 The Extensions...... 11 4.2 The Design Document...... 11 4.3 READMEs...... 11

5 Work Method 11 5.1 Methodology...... 11 5.1.1 Meetings...... 12 5.1.2 Story Points...... 13 5.2 The Sprint Plan...... 14

6 Sprints 14 6.1 Sprint 0...... 14 6.2 Sprint 1...... 15 6.2.1 Sprint 1 Burndown...... 16 6.2.2 Backlog...... 16 6.3 Sprint 2...... 17 6.3.1 Sprint 2 Burndown...... 18 6.3.2 Backlog...... 18 6.4 Sprint 3...... 19 6.4.1 Sprint 3 Burndown...... 20 6.4.2 Backlog...... 20 6.5 Post Sprint / Sprint 3.5...... 21 6.6 Sprint 4...... 22 6.6.1 Sprint 4 Burndown...... 22 6.6.2 Backlog...... 23 6.7 Sprint 5...... 24 6.7.1 Sprint 5 Burndown...... 25 6.7.2 Backlog...... 25

3 Háskólinn í Reykjavík T-404-LOKA

6.8 Sprint 6...... 26 6.8.1 Sprint 6 Burndown...... 27 6.8.2 Backlog...... 27 6.9 Sprint 7 & 8...... 28 6.9.1 Sprint 7 & 8 Burndown...... 29 6.9.2 Backlog...... 29 6.10 Project Status...... 30 6.10.1 The Status of the IDEs...... 31 6.10.2 Sublime...... 32 6.10.3 Work Times...... 32

7 Continuous Integration 34 7.1 The Build Pipeline...... 35 7.1.1 Clean/Setup...... 35 7.1.2 Unit Tests...... 36 7.2 Testing and quality assurance...... 36 7.2.1 Deployment...... 37

8 User Interface 38

9 API 41 9.1 Atom & Visual Studio Code...... 41 9.2 Jetbrains IDEs...... 42

10 Conclusion 42

A Design Document 43

B User Documentation 47

C Project Backlog 50

References 53

1 Háskólinn í Reykjavík T-404-LOKA

1 Introduction

Tempo is the company behind one of the most popular extension in the Jira project management eco-system. Among it’s features is a timesheet management tool where users can record and log work hours. Recording of work hours is an important part of software development. Devel- opment teams typically keep record of the tasks they’ve completed, and how long it took them to complete them. By doing so, they can predict the amount of man hours needed to complete tasks similar to the ones kept in their records. The recording of work hours can be done through a simple work-clock found in many working environments, or timesheet solutions like the one presented by Tempo.

Done manually, human error can interfere with record-keeping, and inaccurate records can lead to misinformed decisions being made by a team. Further, in software development, developer diligence is required for the recording of work hours. If a developer does not keep record of his work hours, he will need to ﬁll any missing ﬁelds at some points with data gathered from, at worst, guesswork.

This project was commissioned by Tempo with the intent to automate the recording of work hours through their services by developing a suite of Integrated Development Environment (IDE) extensions.

2 Háskólinn í Reykjavík T-404-LOKA

2 The Extensions

The purpose of the extensions, going by the name Tempo IDE Tracker, is to allow users to automatically recording their work investment. This is made possible by building upon Tempo’s Tracker API. These trackers, seen in ﬁgure1, function similarly to stopwatches. They can then be tied to a Jira issue-key, which is then mapped to a Jira issue. One of Jira’s features is the creation of project backlogs and populating them with user stories, known and reported bugs, and tasks to be completed. Jira refers to each of these items as an issue, and generates for them an issue-key upon creation.

Figure 1: Tempo Trackers as seen on Jira

A common convention among development teams making use of Jira is to name their code-base in accordance these issue-keys. Using ﬁgure1 as an example, a developer might encounter a software bug and report it through Jira. This bug will then have an issue-key generated: TP-10. To work on ﬁxing this bug, the developer will then create a new code-base branch using his choice of version control system, and name said branch with the issue-key, TP-10.

The functionality of a Tempo IDE Tracker is therefore two-fold; to determine the branch name at any time; and to communicate with Tempo’s Tracker API to create, start and stop Trackers. The following is a storyboard of the extension in use:

1. The User: Opens his IDE.

2. The Extension: Starts a tracker named after the user’s branch.

3. The User: Switches branches.

4. The Extension: Stops any active trackers, and starts a new tracker based on the name of the current branch.

3 Háskólinn í Reykjavík T-404-LOKA

5. The User: Clicks the extension icon inside his IDE to signal that he doesn’t want his time tracked. Then heads oﬀ to a meeting.

6. The Extension: Stops any active trackers.

7. The User: Comes back from the meeting, sits down and clicks the extension icon to signal the he wants his time tracked again.

8. The Extension: Starts the tracker again.

For information regarding the extension’s UI, see Section8.

2.1 The Product The ﬁnal product and deliverables to the company includes:

The design and development of three extensions for Atom, Visual Studio • Code and the Jetbrains development environments. Jetbrains IDE compati- bility is as follows:

– IntelliJ IDEA – CLion – PyCharm – WebStorm – PhPStorm – DataGrip (with GitIntegration[1] installed)

Infrastructure for future development • Documentation • – Design Document 4.2 – User Manuals in the form of README.md ﬁles. 4.3

3 Risk Analysis

3.1 About An initial risk analysis was created and maintained through the duration of the project.

For the risk analysis an estimation was done on the probability of risk and the impact it could have on the project. These estimates were on the scale of 1 - 10. A risk factor was calculated by multiplying the risk and impact estimates to get

4 Háskólinn í Reykjavík T-404-LOKA a better view of which risks were the most important to address. Each risk was assigned a guarantor that would watch for the development of the risk and be the ﬁrst responder if it would come to pass.

5 Háskólinn í Reykjavík T-404-LOKA

3.2 The Risk Analysis Table

Description Response Probability Impact Risk Guarantor Factor Jira Service Un- Migrate over to 3 8 24 Snorri availability another project management tool (Asana) Project Scale Reduce project 2 9 18 Benedikt out of scope scope Team member Catch up in later 5 3 15 Snorri becomes ill sprints Team member Rest of team 4 3 12 Benedikt unreachable must pick up slack Losing a team Reduce project 1 10 10 Benedikt member scope Tempo API un- Work with sup- 1 10 10 Alexander availability port to get it ﬁxed Team member Try working 1 8 8 Snorri becomes ill over from home a prolonged and/or reduce period scope Dev machine Replace or re- 2 3 6 Team failure pair machine API token stor- Switch to an- 1 2 2 Alexander age security other encryption compromised service Version control Switch to an- 1 2 2 Alexander system fails other version control Build Machine Run setup 1 2 2 Snorri Crashes (Jenk- scripts ins)

Table 1: Risk Analysis

6 Háskólinn í Reykjavík T-404-LOKA

3.3 Results and Encounters Many of the risks mentioned were encountered in the lifetime of the project. During the ﬁnal sprints it was decided that the project was out of scope by one extension. That was the Sublime extension. This will be further discussed in section 6.10.2. The second risk that was encountered quite frequently was that team members were unreachable. This is understandable since a lot of work was done remotely and from diﬀerent time zones. This was remedied by having all members install the Slack app on their phones and laptops. Development machine failure and build machine crashes were two risks that were encountered frequently. Two team members’ laptops went out of order for long periods causing them to need to borrow laptops. The risk was mitigated by the fact that the version control system used by the team stores the entire code- base. The Jenkins Continuous Integration Machine crash was another risk that was encountered early in the development cycle. This was mitigated greatly by the scripted setup process for the machine. The downtime was about a day, but could have been a lot higher if this eventuality had not been prepared for.

7 Háskólinn í Reykjavík T-404-LOKA

4 Design

4.1 The Project Stack

This is a complete overview of the software stack for the project. The next few sections will go into further detail to explain the reasoning behind the software used.

8 Háskólinn í Reykjavík T-404-LOKA

4.1.1 Project Management

For the project management software suite, the Atlassian[2] eco-system was used. Atlassian boasts a large toolbox useful to software development and management. Among such tools that were used in the development life-cycle was Jira, Con- ﬂuence, Stride and Tempo. Jira[3] is designed around teams that use agile method- ologies to gain greater success in software development. This tool was used to keep track of the product backlog and record sprints. Additionally, the Tempo plug-in was used manage and keep track of work hours.

Conﬂuence[4] is a tool used for managing documentation. It automatically cre- ates a Wiki that includes all of the project’s written documentation. This includes user manuals, meeting notes, sprint retrospectives and sprint planning sessions. Conﬂuence was used to write down everything project related so that the whole team had full access to the documentation.

Stride[5] is another tool in the Atlassian toolbox. It is a remote meeting tool with video chat functionality. This tool was used frequently for remote meetings and collaboration.

Outside of the Atlassion eco-system, Slack was the primary communication platform between team members. It’s a powerful tool for remote co-operation and was used extensively in the project. Over 3000 messages were sent through Slack during the lifetime of the project.

9 Háskólinn í Reykjavík T-404-LOKA

4.1.2 Development Pipeline

In this project, an Amazon Cloud EC2 Virtual Machine[6] was used to host the continuous integration environment. An instance of Jenkins[7] was set up on this machine to serve as the build and test server. Every time some code is pushed to the main branch of any of the project’s GIT repositories, Jenkins will automatically pull the new code, build it and test it. If the code passes testing, the code is then deployed and released automatically. All of the scripts required to create this Jenkins instance are hosted on Github for easy reconstruction in case the machine crashes or needs to be moved.

For more information, see section 7 of this report.

10 Háskólinn í Reykjavík T-404-LOKA

4.1.3 The Extensions

A Tempo IDE Tracker uses information embedded in the name of the current working branch to determine a Jira issue-key. This information is then used to communicate with Tempo’s Tracker API to create, start and pause Trackers.

4.2 The Design Document The design document in AppendixA is a functional document meant for developers of the software. It was created to serve as a guideline for the current as well as future developers working on similar extensions. It establishes a "Deﬁnition of Done" whereby all necessary functionality for the extension to be considered complete is described. It also serves to make sure that the extension is uniform between IDEs. Design colors are included along with explanations for the interaction with the API.

4.3 READMEs User documentation exists in the form of README.md ﬁles saved within each extension’s repository. An example is included in AppendixB. These ﬁles contain information such as installation directions, and usage instructions.

5 Work Method

5.1 Methodology A relaxed version of scrum was used for this project. Instead of daily scrum, meetings were held twice a week on Tuesdays and Fridays.

11 Háskólinn í Reykjavík T-404-LOKA

A Slack channel was maintained where every member would answer the following questions each time they work on their own:

What did I do last time? • What am I doing today? • Is there anything standing in my way? • The sprints were 1-3 weeks long with scheduled team attendance three times a week. Sprint Planning was held at the start of each sprint and Sprint Retrospec- tives were held at the end of each sprint.

The source control management (SCM) tool of choice was Github. A pull request driven development methodology was used so that every member of the team was familiar with the entire code-base. This was our primary tool for code review, along with scheduled meetings.

As mentioned in section 4.1, the project backlog was set up in Jira, an agile software development tool. Along with Jira, Tempo was used, an extension for Jira, to keep track of time expenditure on the issues contained within the project backlog. Issues that were tracked included product features, bugs, meetings and documentation work. The reasoning behind picking Jira as the project management tool was that the functionality of the project required both of these services to function, therefore working with and experiencing these services was bound to give useful insight to the beneﬁt of the project. In table2 below, the Scrum Role setup can be seen.

Role Name Work Percentage Product Owners Árni Geir Úlfarson 0% Stefán Einar Stefánsson 0% Instructor Áslaug Eiríksdóttir 0% Scrum Master Snorri Hjörvar Jóhannsson 25% Team Benedikt Hólm Þórðarson 100% Alexander Björnsson 100% Snorri Hjörvar Jóhannsson 75%

Table 2: Scrum Roles

5.1.1 Meetings As a part of the projects work method, regular meetings were scheduled: Meeting every other week with product owner on Fridays; • 12 Háskólinn í Reykjavík T-404-LOKA

Scrum meetings twice a week on Tuesdays and Fridays; • sprint retrospective and Sprint Planning on Mondays after each sprint; • Meeting with instructor on Tuesday evenings (ﬂexible). • 5.1.2 Story Points There was a misunderstanding in how story points were used and how they function within the scope of the project. A lot of time was put into making them work but as they stand they are not the best measurement of value in the project.

In the beginning of the project the team set out with the wrong mindset. Each story point was given a value of 3 hours, which in retrospect was a mistake. Each story was ranked on the scale of 1-5 to depending on how long each story was assumed to take to ﬁnish. During Sprint 3, one of the projects Product Owners pointed out this mistake and the team had a hard time transitioning to a better system. Eventually the team decided to map the current scale of 1-5 to the Fi- bonacci sequence. Meaning that 1 became 2, 2 became 3, 3 became 5 and so forth. All the tools needed to make this work were already present, but this is deﬁnitely something to be kept in mind in future projects.

13 Háskólinn í Reykjavík T-404-LOKA

5.2 The Sprint Plan

Sprint Date Other Sprint 0 1. Jan - 29. Jan Project start Sprint 1 29.Jan - 11. Feb Graded Meeting (7-14 Feb) Sprint 2 12.Feb - 25. Feb Sprint 3 26.Feb - 11. March Graded Meeting (12-16 March) Sprint 3.5 12. March - 19. March Post graded meeting response sprint. Sprint 4 20.March - 3. April Sprint 5 4. April - 22. April Exam Sprint, Half Work Sprint 6 23. April - 30. April Sprint 7 1. May - 8. May Final Graded Meeting(3-8 May) Sprint 8 9. May - 11. May Final sprint. Graded meeting response sprint

Table 3: The sprint plan

6 Sprints

This section contains the retrospectives from each sprint. The retrospectives were written by the team after each sprint to highlight what went well and what could have gone better after each sprints.

6.1 Sprint 0 In this sprint we got our hands on the project. We got in contact with Tempo and they set us up with desks and got us started. We set up Jira and Conﬂuence along with tools like Tempo Timesheets and Stride. We also set up a Slack channel as a primary discussion board for our project. We created the basis for our backlog and started doing research on how to create extensions for various IDE’s.

Backlog is set at 198 story points.

14 Háskólinn í Reykjavík T-404-LOKA

6.2 Sprint 1 Story points at start: 198 Story points in the end: 178

This sprint spanned from 29th of January to the 11th of February. In this sprint we focused on research and getting our toes wet in development. We created our ﬁrst experimental extension to get a feel for Atom as an IDE. After that we began development on the Atom extension and the ﬁrst prototype is due next sprint. We also planned to get some semblance of a build pipeline up and running but we may have overestimated the time we have in this sprint because of documentation requirements for the graded meeting. The build pipeline was pushed to sprint 2.

One thing that we encountered was that we were building stories that were too epic in scope, and even though we had the story 90% finished, it would not register as finished. A direct result of this was that our story points were not able to show value and they had to be refactored. We decided on actively trying to fix this in future sprints.

We held a retrospective after this first sprint to discuss what went wrong. We are all learning as we go and this early sprint helped us a lot to hammer down what we want to do and what is unnecessary. We are using Confluence to document all our meetings and to take notes. These are some of the notes that came from this first retrospective:

What did we do well? • – We are way ahead of schedule for the coding part. – A lot of very good research and design decisions were made with the help of the product owner.

What could we have done better? • – Try to make better estimates on the time we have for each sprint. – We need to organize and write our user stories better. – We underestimated the time needed to create the documentation for the ﬁrst graded meeting.

15 Háskólinn í Reykjavík T-404-LOKA

6.2.1 Sprint 1 Burndown

6.2.2 Backlog

16 Háskólinn í Reykjavík T-404-LOKA

6.3 Sprint 2 Story points at start: 178 Story points in the end: 90

Sprint 2 started on the 14th of February and ended on the 25th. The goal for this sprint was to produce a working prototype for the Atom extension, as well as construct a fully functional build pipeline. Learning from some of the mistakes we made during Sprint 1, we can happily say that Sprint 2 was successful. We finished all of our stories except for a few unit tests that were pushed to Sprint 3. Starting this sprint we also started using a pull request work method and it has been working wonderfully. All team-members are happy with this change and em- braced this work method fully after getting over the initial implementation difficulties. We made some large decisions about our Atom extension this sprint. A main component was dropped when we realized that it was very inconvenient for the user to get working. We opted for an alternate solution that was much more user- friendly. We also made decisions on how the different components in our extension should relay information between themselves. Those decisions allowed us to work in greater parallel, thus speeding up the production of closely coupled components.

What did we do well? • – Prototype ready Code heavy sprint. ∗ Ambitious schedule that worked out. ∗ Made possible because of fortuitously sound design decisions. ∗ What could we have done better? • – Design documentation User stories still need a better factor of completeness and clarity. ∗ We now have a better idea of the products requirements. ∗ – Logging of work hours. – Logging of stories (ToDo/InProgress/Done). – Have team members more readily available on our media platforms for questions and answers.

17 Háskólinn í Reykjavík T-404-LOKA

6.3.1 Sprint 2 Burndown

6.3.2 Backlog As seen on the Sprint Backlog in figure2, the sprint was successful. We managed to finish every major story as well as to produce a viable prototype that will now go into in-house testing. there is still a need to refactor the story points to estimate time, but this is getting better with every iteration. A notable story in this sprint was the story TP-27 "As a dev, I want a running Jenkins instance, so that I can keep track of builds and tests". We had estimated that this story would be worth 3 story points, but due to platform specific difficulties, it ended up taking way longer time than estimated, using most of one team-members time for this sprint. In retrospect, we should have seen this story as it was and estimated it correctly.

18 Háskólinn í Reykjavík T-404-LOKA

Figure 2: Sprint 2 Backlog

6.4 Sprint 3 Story points at start: 90 Story points in the end: 40

We intended this sprint to be a polishing sprint for the Atom plug-in. We worked on making more unit tests and responding to feedback from the users of the extension.

What did we do well? • – Extension is Feature Complete Responded quickly to feedback ∗ Took the time to hold a big retrospective on the Atom extension ∗ as a whole. Worked on polishing our work method ∗ What could we have done better? • – Be more in-depth in our documentation – Respond better and faster to instructor feedback

19 Háskólinn í Reykjavík T-404-LOKA

6.4.1 Sprint 3 Burndown

6.4.2 Backlog It is worth mentioning that due to the rapid pace of feedback and ﬁxes, some tasks never made it into the backlog.

20 Háskólinn í Reykjavík T-404-LOKA

6.5 Post Sprint / Sprint 3.5 After releasing the Atom extension we decided to take a week to plan out our next steps. We responded to feedback from our instructors and widened the scope of our project.

As shown in Appendix A, we created a design document for the purpose of outlining how the extension should work in general terms. Our objective was to create the ’deﬁnition of done’ so that we could better track our progress. This document was reviewed by the product owner and got a green light. This will be a great resource for future developers at Tempo. The Atom extension is now feature ready and we will respond to feedback when needed. We planned out how we could manage to create three more extensions instead of two. Using the above mentioned design document we had the tools to do it. We decided that over the next few sprints we would be working semi-independently on one extension each.

Total story points after restructuring grew to 298 Total story points remaining: 157

21 Háskólinn í Reykjavík T-404-LOKA

6.6 Sprint 4 Story points at Start: 157 Story points in the End: 105

This sprint started on the 20th of March and ended 3rd of April. During this sprint we had to divert a lot of our attention towards ﬁnishing ﬁnal projects and studying for exams. We each started work on our own IDEs, Benedikt took on Visual Studio Code, Snorri took on Sublime text editor and Alexander took on Intellij.

What did we do well? • – Responded to instructor feedback as well as we could – Set up a ambitious work schedule

What could we have done better? • – Story management

6.6.1 Sprint 4 Burndown

22 Háskólinn í Reykjavík T-404-LOKA

6.6.2 Backlog

23 Háskólinn í Reykjavík T-404-LOKA

6.7 Sprint 5 Story points at start: 105 Story points in the end: 64

This sprint was reserved in part for the ﬁnal exams (10. April to the 17. April). We received a lot of feedback and made changes accordingly. We signiﬁcantly updated the design document to include the new changes and changed a few things according to our instructors feedback.

Visual Studio Code was oﬃcially feature ready by the end of this sprint.

Using the experience from VSCode, the Atom extension was re-factored to accommodate the new requirements and ﬁx some bugs that were discovered to exist both in Atom and VSCode. We received feedback that the user documentation was lacking. Which we took to heart and updated the README.md ﬁles extensively to give as comprehensive information as possible. It was scheduled to close a week earlier, but we decided to prolong the sprint until Snorri came home.

What did we do well? • – We worked hard on exams. – Managed to do quite a bit of work beside exams.

What could we have done better? • – Respected how much time exams would take.

24 Háskólinn í Reykjavík T-404-LOKA

6.7.1 Sprint 5 Burndown

6.7.2 Backlog

25 Háskólinn í Reykjavík T-404-LOKA

6.8 Sprint 6 Story points at start: 64 Story points in the end: 0 Feature Freeze

This sprint started on the 23rd of April, the day after Snorri came home from Estonia. It ended on 30th of April.

For the ﬁrst time in three months, all the members of the project met in person.

Having all of us working in the same building proved to be a great motivator and being able to bounce ideas off each other greatly sped up problem solving. As a result we gained a whole new view of the difference between remote collaboration and face-to-face collaboration. We gained a renewed enthusiasm for the project, and as a result we enjoyed the time spent working on the project much more than we previously did. Early on in the sprint we received a request to significantly change the functionality of the tool-bar icon. This change lead to the discovery of an edge-case bug, which led to a large scale rewriting of the Atom extension, and a less intensive refactoring of the Visual Studio Code extension.

The Sublime extension was shelfed after a meeting with the product owners. Further reasoning and explanation is found in Section 6.10.2.

What did we do well? • – Working prototype for IntelliJ is in alpha testing in-house – Very work heavy sprint – Final report and presentation heavily reworked – IntelliJ Javadocs were really good

What could we have done better? • – IntelliJ unit test integration – We should have dropped Sublime sooner. Way out of scope.

26 Háskólinn í Reykjavík T-404-LOKA

6.8.1 Sprint 6 Burndown

6.8.2 Backlog

27 Háskólinn í Reykjavík T-404-LOKA

6.9 Sprint 7 & 8 Story points remaining: 0 Code Freeze Documentation Freeze

Sprint 7 started on the 1st of May. This is the ﬁrst sprint after Feature Freeze. A lot of bug ﬁxing on the Jetbrains Extensions happened in this sprint and polishing of features.

The main point of this sprint was to get ready for the third and ﬁnal graded meeting which was 3rd of May. We polished our Documentation and reworked a lot of our Final Report in regards to Story Points, after feedback from our instructor. After the graded meeting we set our sights on responding to the feedback we got and get ready to hand the project over to our product owners. In Sprint 8 we continued this and are currently putting the ﬁnal touches on our report.

What did we do well? • – Responded quickly to feedback – Managed to reach target work hours – We managed to ﬁnish everything we set out to do.

What could we have done better? • – Be more careful not to burn out from work

28 Háskólinn í Reykjavík T-404-LOKA

6.9.1 Sprint 7 & 8 Burndown

6.9.2 Backlog

29 Háskólinn í Reykjavík T-404-LOKA

6.10 Project Status

Figure 3: Project Burndown based on the Original Scope

As shown in the ﬁgure3 above, the project scope had to be reevaluated. After ﬁnishing Atom it was evident that our scope was way too small. This resulted in a a total reconstruction of the scope and the overall work method.

Figure 4: Project Burndown after scope change

After sprint 3.5 in section 6.5, following the second graded meeting, the whole project was restructured to make it large enough to encompass a ﬁnal project. New stories were created that better encapsulated future development. The IDEs

30 Háskólinn í Reykjavík T-404-LOKA in question were IntelliJ (Jetbrains), Visual Studio Code and Sublime. Sublime was later deemed out of scope as shown on the chart

Figure 5: Time Burndown of the Project

The time burndown would not be necessary in normal development, but it was deemed prudent to include it in this report. It shows very well how much was worked over the course of the project. The entire backlog of the project can be found in AppendixC.

6.10.1 The Status of the IDEs Atom • – The Atom extension is feature complete and currently in the pipeline for official release. Visual Studio Code (VSC) • – The VSC extension is feature complete and currently in the pipeline for official release. Jetbrains • – The IntelliJ extension is feature complete and currently in the pipeline for official release. – Support for every other Jetbrains IDE has been added.

31 Háskólinn í Reykjavík T-404-LOKA

6.10.2 Sublime The Sublime extension was canceled after a meeting with the product owners. The work required to achieve the degree of completeness comparable to the other extensions reaches far beyond the project’s scope. To say a few words about the reasoning behind the decision: Sublime is not an IDE, so it already falls out of the original scope. It is a text editor that is very popular among developers. The reason for the cancellation of this Extension was that Sublime is more similar to text-only editors like VIM or Emacs. In order to satisfy the definition-of-done defined by the design document it would have been necessary to create a whole new front-end on top of Sublime. The scope of that undertaking would rival a final project in itself.

A lot of time went into the development of this extension and there exists a strong code base that may be resurrected at some point in the future.

6.10.3 Work Times

Figure 6: Work Hours by Name

32 Háskólinn í Reykjavík T-404-LOKA

Figure 7: Time By Group Breakdown

Figure 8: Work Hours Per Member Per Category

33 Háskólinn í Reykjavík T-404-LOKA

7 Continuous Integration

Jenkins is a popular extension-based CI (Continuous Integration) tool[7]. It was used during the course of the project to build, test and deploy the extensions.

The Jenkins server was set up on the Amazon AWS Cloud [8]. Scripts were built through the Amazon CLI so that the Amazon machine and the Jenkins instance can be easily and quickly reproduced in case of machine failure. All scripts are stored on Github and are kept up to date.

The scripts can be used to create an EC2[6] instance quickly and easily as well as set up Jenkins. After running these scripts, the only thing left to do is to do minor conﬁguration in Jenkins itself and it’s ready to go.

34 Háskólinn í Reykjavík T-404-LOKA

7.1 The Build Pipeline

The build pipeline in Jenkins is set up in 3 stages.

1. Clean/Setup

2. Unit Tests

3. Deployment

7.1.1 Clean/Setup In the setup stage the extensions are set up as cleanly as possible. Starting with clearing the git and package manager cache. This is to make sure that no update to a 3rd party package has broken the build. Setup scripts are used to build the software. Atom uses Atom Package Manager (APM), while Visual Studio Code uses Node Package Manager (NPM). At the end of this stage a message is sent to the Slack channel that a build has started.

35 Háskólinn í Reykjavík T-404-LOKA

7.1.2 Unit Tests In the unit test stage the code is ﬁrst run.

Atom • – Atom as a program needs a head/GUI to run, which causes problems for the headless/bash-only machine. This is solved by using a tool called Xvfb. Xvfb is a way to create a virtual display port which runs on the machine internal memory. It makes it possible to create a headless instance of Atom, from which tests can be run. If a test fails an alert is sent out on Slack notifying that there is a Red build and all focus goes into ﬁxing the build. With the help of Xvfb, the machine can now run the unit tests and if they all succeed, the pipeline enters the next stage.

Visual Studio Code • – Visual Studio Code is built on the same platform as Atom, meaning that it needs to run headlessly as well. The setups are very similar.

Jetbrains • – It was the original intention to run the Jetbrains IDEs on our CI server, but due to monetary problems, this was not possible. At the time of writing, Jetbrains does not maintain a public repository for their li- braries. As such, all compilations require a Jetbrains IDE installed. The server space needed for this exceeded the budget.

7.2 Testing and quality assurance Unit testing proved to be notoriously difficult. Since the extensions mainly relied on relatively simple components whose interaction determined how the extension would behave. Mocking this interaction turned out to be problematic because it required that an instance of the IDE running the graphical interface in headless virtual state. (see section7) For these reasons, unit tests gradually were pushed to the side, with the team rather favoring path-testing. A simple flowchart9 was created to display the appropriate states of the extensions and how it should react to different stimuli.

36 Háskólinn í Reykjavík T-404-LOKA

Figure 9: The behavioral diagram of an extension

7.2.1 Deployment In the deployment stage, the intention is to automatically publish the code peri- odically to the package manager in question. Like APM for atom, NPM for Visual Studio Code and Extension Browser for IntelliJ. While in development, the users will use the git repository and will be notiﬁed of updates as they come. The extensions are all in the pipeline of getting released, meaning that once they get the green light from Tempo, it will be easy to integrate automatic deployment.

37 Háskólinn í Reykjavík T-404-LOKA

8 User Interface

Figure 10: Atom running with the extension active in the bottom left

Figure 11: Visual studio code running with the extension active in the bottom left

On activating the extension without having a Tempo API token saved, the extension will prompt the user for his api token. The token interface includes a text-box for inputting the token. It also has a check-box allowing the user to select either the normal tempo API endpoint, or an early-access-program. It will only ask the user for his access-token once, so as to not to needlessly bother the user.

38 Háskólinn í Reykjavík T-404-LOKA

Figure 12: IntelliJ running with the extension active in the bottom right.

Figure 13: The input prompt where the user can enter his token (Atom).

From the very start of the project, it was decided that the main design goal for the user interface was minimalism. This design goal is achieved by having a small Tempo icon at the very bottom of the editor window, accompanied by the current issue key. This icon will be gray if the tracker is paused, and Green or red otherwise depending on the state of the extension. If the branch is invalid, then the icon is red, and if the access token is invalid the icon is red as well.

Figure 14: Green Icon & green issue key.

The branch name will be green if the tracker is on, and the branch name starts with a valid JIRA issue key. If the user clicks the icon while it’s green, the extension will attempt to stop all active trackers.

39 Háskólinn í Reykjavík T-404-LOKA

Figure 15: Grey Icon & grey issue key

The issue-key and icon will be grey if the extension is paused.

Figure 16: Red icon & red issue key

The branch name will be red, if it does not start with a valid issue key as seen in ﬁgure 16 or if the extension has detected an invalid issue key. If the user unpauses the extension when the extension is in an invalid state, the extension displays a notiﬁcation.

40 Háskólinn í Reykjavík T-404-LOKA

9 API

An API (application programming interface) is an interface for a service that allows for the creation of programs that interact with said service. Tempo provides an API for creating, accessing and modifying tracker objects on their end. To interface with this API, we use the HTTPS protocol to send requests to the API endpoints exposed by Tempo. The HTTP protocol is the protocol that drives the world wide web. It stands for hyper-text-transfer-protocol and it works in a request-response manner. Ie, clients can request information from resources (servers) and the servers respond with the requested information. The Tempo API is designed to respond to HTTPS requests. HTTPS behaves identically to HTTP, with the added caveat of transport-layer encryption. Our extension supports the use of two diﬀerent API endpoints, one for the general API, accessible to Tempo’s general user-base, and one for the early access program, which requires special user privileges. The early access program is a bleeding-edge version of Tempo’s API that is ahead by ten days of the general API. Any requests made to the endpoints need to include the user’s access token as well as an optional JSON payload representing a tracker object if the intention is to create a tracker or modify an existing one. JSON (JavaScript Object Notation) is commonly used when remote APIs respond with information about objects. The protocol method prescribed with the request tells the API what action to take. Possible action include querying or updating of tracker objects. The API will typically respond with a JSON representation of a tracker object, depending on the nature of the request. For more information including API endpoint URLs, possible requests to be made to the API, as well as the tracker JSON structure, see section IV. API Communication in the design document located in AppendixA

9.1 Atom & Visual Studio Code Both Atom and Visual Studio Code extensions make use of the Axios library[9] for communicating with the API. The library simpliﬁes asynchronous request handling immensely by providing us with functionality for creating requests. Any requests made return a Promise object[10] which allows us to handle API responses asynchronously. While both extensions make use of the same library, the implementation had to be slightly altered due to the diﬀerence between Atom and Visual Studio Code.

41 Háskólinn í Reykjavík T-404-LOKA

9.2 Jetbrains IDEs The extension makes use of the Apache HttpComponents library [11] because it provides an easy way to create and send HTTPS requests. Response handling is done synchronously, meaning the extensions will halt until a response is received, or on events such as a connection time-out. The extension also makes use of Google’s Gson library[12] for deserializing API responses into tracker objects.

10 Conclusion

During Charlie Day, an in-house hackathon, programmers at Tempo created a prototype of the Tempo Timesheet support for the Tempo IDE Tracker. The ﬁnal product will look similar to that shown in ﬁgure 17.

Figure 17: A suggestion of work as it would appear in the Tempo Timesheet.

In it, the user is prompted with a ’suggestion of work’. The only manual steps necessary for including the user’s work in their timesheet, from start to ﬁnish, is to either accept or deny. The project as a whole is in the pipeline for release along with a bigger update to Tempo Timesheets in the near future. The extensions and other work relating to the project have shown the product owners a viable use case for their Tracker System in the form of automatic tracking of work hours.

In conclusion, the team is of the opinion that the project is complete. All project speciﬁcations were met and surpassed

42 Háskólinn í Reykjavík T-404-LOKA

The continuous integration will not be used in the future, but having the setup scripts will help Tempo set up the extensions in their own system. The design document will continue to grow and be kept alive for as long as these extensions stay in development.

A Design Document

See next page

43 Tempo IDE Tracker Extension Design Document

Benedikt H. Thordarson Alexander Bjornsson¨ Snorri H. Johannsson´

Abstract— This document describes a general structure and for, the same functionality, design and user experience is design of Tempo IDE Tracker Extensions (TIT) . The extensions expected. track the time that a user spends working on a Jira issue by observing the current working Git branch and communicating II.FUNCTIONALITY with the Tempo API to create, start and stop time trackers. A TIT must be able to: The tracked time periods then appear as suggestions of work Prompt the user for his access token on first startup. when the user enters his work-hours. • Allow the user to change his access token. • I.INTRODUCTION Store the access token persistently. • Jira [2] offers project management solutions to Agile Allow the user to opt for Tempo’s Early-Access • teams. Program. Among such solutions is the creation of issues that cor- Determine the name of the current working branch. • respond to tasks that need to be completed. The issues have Determine whether the branch name corresponds to a • a corresponding issue-key matching the regular expression valid issue key. below Detect when the user switches branches. • Communicate with the Tempo REST API. • ([a-zA-Z][a-zA-Z_0-9]+)-[1-9][0-9]* Convey tracker state to the user. (see UI design III) • A. Functionality Descriptions Fig. 1. A regular expression matching a valid Issue-Key On first startup, if the user has not entered his access • A Regular expression is ”a string of text that allows you token, the extension should prompt the user for his to create patterns that help match, locate, and manage text.” token. The extension should not attempt to discern whether or [1] • Regular expressions are useful for determining whether or not an issue with a matching issue key exists on Jira’s not a string follows a certain pattern. side. The extension has three states: Tempo [3] is the developer of one of the most popular Jira • extensions, and offers a unique way to track time expenditure 1) Tracking and resource management. Tempo allows the user to create 2) Paused Trackers that can be linked to existing issue-keys in Jira. 3) Invalid has an (Application Programming Interface) that When the user switches branches to a branch while the Tempo API • enables engaging with trackers programmatically. extension is in the tracking state, the extension should It is standard for developers to use version control systems stop all active trackers, and attempt enter the tracking (VCS) such as Git. [4] Git, among other VCS allows for state on the new branch. the creation of . Branches are a separated version When the user switches branches while the extension branches • of project code-base which allow developers to implement is in the invalid state, the extension should attempt to changes to code without risking the overall project. Branches start a tracker for the new branch. are identified by their unique . A popular If the user switches branches while the extension is in branch-names • convention is to name branches in accordance with Jira issue- the paused state, the extension should not start or stop keys. any trackers. Developers usually do most their programming work via On startup, the extension should attempt to enter the • special text-editors specifically tailored towards programm- tracking state. ing. Such text-editors are called (Integrated Develop- Tracker toggling events, such as on clicking the UI IDEs • ment Environment). There are multiple IDEs around and new icon, should result in the exensions changing states from ones are constantly being released. IDEs sometimes allow tracking to paused, or vice versa. users to create , otherwise known as , that The extension should not enter the state unless extensions plugins • tracking alter the functionality, or provide a new service for the user the current branch name corresponds to a valid issue of said IDE. key, matching the regular expression in figure1. If The Tempo IDE Tracker this document refers to, said condition fails, or if the access token fails to henceforth referenced as TIT, is non-specific to IDEs. Me- authenticate with Tempo’s API, the extension should aning that for each every IDE the extension is developed enter the invalid state. When the extension enters the state, it should • tracking query the API for trackers with issue-keys correspond- Fig. 3. The icon in gray, indicating that the extension is in the paused ing to the current branch name to check if such a tracker state. (Atom on the left, Visual Studio Code on the right) already exists for the issue. – If such a tracker already exists, the extension should either start restart the existing tracker, depending on whether or not the tracker is active. Fig. 4. The icon in red coloring, indicating an invalid state. (Atom on the left, Visual Studio Code on the right) – Otherwise the extension should create a new active tracker assigned with the issue-key. When the extension enter the state, it should • paused Generalized rules for the extension: request a list of active trackers and stop each tracker. 1) If the extension is in a paused state, the icon should If the user changes his access token the extension should • be gray. (See figure3) attempt to stop all active trackers before changing 2) If the extension is in an invalid state, the icon should the access token, as the user may not be represented be red. (See figure4) anymore by the new access token. Afterwards it should 3) If the extension is in a tracking state, the icon & act as if the user switched branches. issue-key should be green. (See figure2) The extension should attempt to stop all active trackers • when deactivated, such as on IDE closing. The first rule trumps the rest. When the extension is taken out of the paused state it should follow the remaining 2 rules III.UI DESIGN accordingly. The extension should have a minimal design. It should The hex-values for the colors can be seen in tableI prompt the user for his tempo access token and whether or IV. API COMMUNICATION not he wants to use the early access program with a modal. The input box should not display the user’s tempo access Communication is done through HTTPS requests to either token in plain-text. the normal URL (figure5), or the early access program URL The extension should do this exactly once, as not to bother (figure6) should the user choose so.w the user. The modal should include a check-box for the EAP (Early https://api.tempo.io/trackers/v1/ Access Program), and an input for the tempo access token. The only always-visible UI should be a small icon placed Fig. 5. API endpoint. in a visible-yet-inconspicuous place. The icon should optim- ally be the tempo logo, but if that is not possible, a similar https://eap-api.tempo.io/trackers/v1/ icon, such as a clock is sufficient. This icon is responsible for both communicating the extension’s status to the user and Fig. 6. Early access program API endpoint. receiving a click-event to toggle the tracker on or off. Next to the icon, the issue key corresponding to the current working For Authentication, any request must set the Authorization branch should be displayed in the same color scheme as header field as shown in figure7. To ensure that the response the token. The issue key follows the same specification for to queries to the API is in the form of JSON, the Content- color, and click as the icon. If the branch name does not start type header should be set as shown in figure8. with a valid issue key the error message ”Branch name is invalid”should instead be displayed. The icon and branch name should have a color scheme Authorization: bearer {ACCESS TOKEN} consistent across all IDE’s. The color scheme is as follows. Fig. 7. The Authorization HTTP header field as it should be in requests Color Hex-Value to the API. The ACCESS TOKEN is the user’s Tempo access token Green #43B02A { } Red #E24C4C Gray #555555 TABLE I Content-type: application/json COLORSCHEMETABLEFOREXTENSION UI Fig. 8. The Content-type HTTP header field as it should be in requests to the API.

A. Creating trackers Fig. 2. The icon in green, indicating that the extension is tracking. (Atom Send POST request to the user-chosen service. on the left, Visual Studio Code on the right) The payload of the POST request must be in the form outlined in ﬁgure9 In developing this extension, we are not interested in 1 { reading, or writing to this ﬁeld. 2 "issueKey": String 3 "issueId": String, REFERENCES 4 "description": String, [1] www.computerhope.com/jargon/r/regex.htm What is a Regex (regular 5 "isPlaying": boolean, expression) ? (Accessed 23.04.2018) 6 "createdDate": Date [2] https://www.atlassian.com/software/jira The #1 software development tool used by agile teams (Accessed 23.04.2018) 7 } [3] https://www.tempo.io/ Tempo Project Management Stack (Accessed 23.04.2018) [4] https://git-scm.com/ Source Control Management Tool (Accessed Fig. 9. The JSON representing the POST payload required to create a 23.04.2018) new tracker

1 {

2 "id": String,

3 "userId": String,

4 "description": String,

5 "issueKey": String,

6 "issueId": String, 7 "isPlaying": boolean, 8 "time": Object,

9 "createdDate": Date

10 }

Fig. 10. The JSON representing the structure of a tracker

Only the createdDate, isP laying & issueKey fields need to be set, the rest can be NULL. createdDate is a string containing the current time. isP laying can be set as true to have the tracker start as soon as it’s created. issueKey should be the issue key corresponding to the current branch. The response to a successful call will be JSON of the form outlined in figure 10 B. Getting a list of trackers Send a GET request to the appropriate URL. The response to a successful call will be a JSON list of objects in the form outlined in figure 10 To get a tracker corresponding to an issue-key, place the issueKey as a query parameter in the URL. GET URL ?issueKey= your issue key here { } { } The response to a successful call will contain a JSON of the form outlined in figure 10 C. Toggling a tracker Send a PATCH request to the appropriate URL, appended with the id of the tracker. PATCH URL / trackerId { } { } The response to a successful API call will be a JSON of the form outlined in figure10 D. Clarifications In figure 10, the fields issueKey and issueId are not • equal. The issueId is the ID of the issue itself in JIRA. Háskólinn í Reykjavík T-404-LOKA

B User Documentation

See next page

47 1 Atom README.md 1.1 Tempo IDE tracker This plugin starts & stops Tempo time trackers according to your git activity in the Atom IDE.

To use this plugin you must have a Jira account running Tempo time- tracking This plugin also exists for visual studio code

1.1.1 Usage The extension works in the background, stopping and starting Tempo trackers as you change branches. It relies on the branch names start with the corresponding issue keys. So that the software can then turn the trackers into suggestions of work. The state of the plugin can be seen in the bottom left icon. There are 3 states of the icon: Green: The extension is tracking time on the issue key displayed next to • the icon. Grey: The extension is paused, but ready to start tracking on the issue • key displayed next to the icon. Red: The branch name is not valid. • 1.1.2 Install Instructions Clone the Repo • Enter the newly cloned directory with the command line. • From the command line in the plugin directory, run apm install to install • the neccesary packages From the same command line, run apm link • this will link the package to your Atom IDE. • In atom you will be able to see the plugin under packages. • Enter your API key • You are ready set and go for launch! • If the token & branch name are red, the reason is most likely that your • tempo Token is invalid. Or that the branch name is invalid.

> git clone git@github.com:tempo-io/tempo-atom.git > cd tempo-atom > apm install > apm link

1 2 Visual Studio Code README.md 2.1 Tempo IDE tracker This plugin starts & stops Tempo time trackers according to your git activity.

To use this plugin you must have a Jira account running Tempo time- tracking. It relies on the branch names start with the corresponding issue keys. So that the software can then turn the trackers into suggestions of work. This extension also exists for Atom

2.1.1 Usage: This extension observes which branch you are working on and starts and stops Tempo timetrackers with an issue key corresponding to the branch name. For this extension to work properly the branch name needs to start with a valid issue key. A valid branch is therefore of the form: ’TP-126’ or ’AR-1’ or ’XX-20- example’. An invalid branch would look something like ’BRANCHNAME’ or ’TP- 12EXAMPLE’ or ’12-TP’ Click on the clock in the bottom panel to start/stop trackers.

2.1.2 Installation To install this on your system. Copy the extension folder into your local extension folder. Windows: %USERPROFILE% .vscode extensions MacOs/Linux: $HOME/.vscode/extensions\ \ And from the command line in the new directory, run $npm install.

2.1.3 The UI: The UI of this extension (without the token prompt) exists entirely in the left bottom of the screen as a small clock. The color of the clock signiﬁes the state of the plugin. Green means that the plugin is active and tracking. Grey means that the plugin is inactive. Red means that the branch name or access token is invalid and the extension is not tracking.

Startup: This extension should prompt you for your access token at ﬁrst startup. If that doesn’t happen go to the Command palette and search for Enter your Tempo Access token. Similarly you can also remove the token this way by searching for Remove your Tempo Access Token.

2 Háskólinn í Reykjavík T-404-LOKA

C Project Backlog

See next page

50 Issue key Summary Issue Type Created Resolved Days to Resolve Resolution Epic Link TP-2 Research Epic 29-Jan Done TP-1 Meetings Epic 29-Jan Done TP-3 As a user, I want the plugin to give feedback when an issue exists Story 30-Jan 9-Mar 38 Done TP-4 TP-4 As a user, I want the plugin to track a given issue, when I create or switch to a branch Epic 30-Jan Done TP-9 As a user, I want to be able to restart an existing tracker on my issue. Story 30-Jan 26-Feb 27 Done TP-4 TP-8 As a user, I want the plugin to be able to detect when I switch branches Story 30-Jan 26-Feb 27 Done TP-4 TP-7 As a user, I want the plugin to be able to start a tracker Story 30-Jan 24-Feb 25 Done TP-4 TP-6 As a user, I want to be able to stop a tracker Story 30-Jan 24-Feb 25 Done TP-4 TP-5 As a user, I want the plugin to give feedback when an issue doesn't exist Story 30-Jan 9-Mar 38 Done TP-4 TP-13 As a user, I want to be secure Epic 30-Jan Done TP-12 As a user, I want the plugin to be able to stop a tracker when I switch branches Story 30-Jan 24-Feb 25 Done TP-4 TP-11 As a user, I want to be able to manually start/stop the tracker using an UI element Story 30-Jan 24-Feb 25 Done TP-4 TP-10 As a user, I want the plugin be able to switch trackers when I switch branches Story 30-Jan 26-Feb 27 Done TP-4 TP-18 As a user, I want to be able to Change my Tempo API Token Story 30-Jan 22-Feb 23 Done TP-13 TP-17 As a user, I want my API token to be secure Story 30-Jan 24-Feb 25 Done TP-13 TP-16 As a user, I want to be able to store my Tempo API Token Story 30-Jan 8-Feb 9 Done TP-13 TP-15 As a user, I want to be prompted on setup to enter my Tempo API Token Story 30-Jan 23-Feb 24 Done TP-13 TP-14 As a user, I want to be able to easily authenticate with JIRA (With token in settings) Story 30-Jan 24-Feb 25 Done TP-13 TP-20 Documentation Epic 30-Jan Done TP-19 As a user, I want to be able to install the plugin on the Atom IDE as a package Story 30-Jan 13-Mar 42 Done TP-4 TP-21 Continuous Integration Epic 30-Jan Done TP-23 As a dev, I want my build to be automatically deployed Epic 30-Jan Done TP-22 As a dev, I want my code to build automatically Epic 30-Jan Done TP-24 Scrum work Epic 30-Jan Done TP-25 As a dev, I want an up and running AWS account, So I can create EC2 Instances Story 30-Jan 16-Feb 17 Done TP-22 TP-26 As a dev, I want to be able to create EC2 instances automatically via script Story 30-Jan 16-Feb 17 Done TP-22 TP-28 As a dev, I want scripts for AWS, so that I can control my AWS via terminal Story 30-Jan 14-Feb 15 Done TP-22 TP-27 As a dev, I want a running Jenkins instance, so that I can keep track of builds and tests Story 30-Jan 23-Feb 24 Done TP-22 TP-29 As a dev, I want my Risk Assessment to be finished Story 30-Jan 6-Feb 7 Done TP-20 TP-31 As a dev, I want a Design Document Story 30-Jan 8-Feb 9 Done TP-20 TP-30 As a dev, I want the work plan to be finished and up-to-date Story 30-Jan 8-Feb 9 Done TP-20 TP-32 As a dev, I want an up-to-date Progress Report Story 30-Jan 8-Feb 9 Done TP-20 TP-33 As a user, I want my token to be sent safely Story 30-Jan 24-Feb 25 Done TP-13 TP-34 Integrate KEYTAR Sub-task 6-Feb 6-Feb 0 Done TP-35 Unit Test keytar Integration Sub-task 6-Feb 24-Feb 18 Done TP-38 User can enter a new Tempo APO TOKEN Sub-task 6-Feb 6-Feb 0 Done TP-37 User can remove his Tempo API TOKEN Sub-task 6-Feb 6-Feb 0 Done TP-36 User can enter Tempo API TOKEN Sub-task 6-Feb 6-Feb 0 Done TP-41 unit test token Chang Sub-task 6-Feb 24-Feb 18 Done TP-40 Unit Test token entry Sub-task 6-Feb 24-Feb 18 Done TP-39 Unit Test token removal Sub-task 6-Feb 24-Feb 18 Done TP-43 plugin can detect branch change Sub-task 6-Feb 6-Feb 0 Done TP-42 Plugin can discover current branch Sub-task 6-Feb 6-Feb 0 Done TP-45 Unit test branch discovery Sub-task 6-Feb 26-Feb 20 Done TP-44 plugin can detect repository change Sub-task 6-Feb 6-Feb 0 Done TP-47 unit test repository change Sub-task 6-Feb 26-Feb 20 Done TP-46 unit test branch change Sub-task 6-Feb 26-Feb 20 Done TP-48 as a user I want a UI icon in the bottom left of the screen Story 13-Feb 23-Feb 10 Done TP-88 TP-50 as a user, i want the icon to toggle the plugin on and off if clicked Story 13-Feb 24-Feb 11 Done TP-88 TP-49 As a user i want the UI icon to be green if a tracker is on. Story 13-Feb 24-Feb 11 Done TP-88 TP-52 the UI icon when clicked sends an event to the main program Story 13-Feb 22-Feb 9 Done TP-88 TP-53 Remove keytar integration Story 22-Feb 22-Feb 0 Done TP-88 TP-54 Fix error which occurs when you run two jobs at the same time in Jenkins Bug 23-Feb 24-Feb 1 Done TP-21 TP-57 First job after every Merge fails/freezes in Jenkins Bug 25-Feb 9-Mar 12 Done TP-58 have the current branch name be displayed beside the tempo-icon. Task 26-Feb 26-Feb 0 Done TP-60 as a user i want to be able to choose whether i use the early access program of tempo or the normal one. Story 27-Feb 27-Feb 0 Done TP-88 TP-61 the api class can use either the eap base uri or the normal tempo api uri Task 27-Feb 27-Feb 0 Done TP-62 the user can choose whether the plugin uses the normal tempo-api or the EAP version Task 27-Feb 27-Feb 0 Done TP-65 Graded Meeting Report Task 27-Feb 13-Mar 14 Done TP-66 Random Failures in Jenkins Bug 27-Feb 9-Mar 10 Done TP-67 branch name, when clicked has the same effect as clicking the icon, Task 1-Mar 1-Mar 0 Done TP-71 The epic encompassing IntelliJ development Epic 19-Mar Done TP-72 The epic encompassing VSCode development Epic 19-Mar Done TP-73 The epic encompassing Sublime development Epic 19-Mar Done TP-88 The epic encompassing Atom development Epic 19-Mar Done TP-111 As a user, I want my access token to be stored persistently, so that I only need to enter my access token once Story 20-Mar 3-Apr 14 Done TP-71 TP-110 As a user, I want to prompted upon first startup to enter my access token, so that I can easily configure my plugin Story 20-Mar 4-Apr 15 Done TP-71 TP-120 As a user, I want to prompted upon first startup to enter my access token, so that I can easily configure my plugin Story 20-Mar 31-Mar 11 Done TP-72 TP-119 As a user, I want to get feedback if authentication failed, so that I can take action to re-enter my access token Story 20-Mar 27-Apr 38 Done TP-71 TP-118 As a user, I want the plugin to automatically switch trackers when I switch branches, so that time is being tracked for the work I'm currently performing Story 20-Mar 27-Apr 38 Done TP-71 TP-117 As a user, I want the UI icon to convey the state of the plugin, so that I'm made aware of whether or not my time is being tracked Story 20-Mar 25-Apr 36 Done TP-71 TP-116 As a user, I want the UI icon to be interactable, so that I can manually toggle a tracker in a simple manner Story 20-Mar 25-Apr 36 Done TP-71 TP-115 As a user, I want to be able to stop all trackers, so that I stop tracking my time when I'm not at work Story 20-Mar 27-Apr 38 Done TP-71 TP-114 As a user, I want the plugin to be able to start a tracker, so that I can track my time when I'm at work Story 20-Mar 26-Apr 37 Done TP-71 TP-113 As a user, I want to be able to change my access token, so that I can track time for different teams and projects Story 20-Mar 3-Apr 14 Done TP-71 TP-112 As a user working at Tempo, I want to have the choice to use the Early Access Programme, so that I can track my time while working in-house Story 20-Mar 23-Apr 34 Done TP-71 TP-129 As a user, I want to get feedback if authentication failed, so that I can take action to re-enter my access token Story 20-Mar 13-Apr 24 Done TP-72 TP-128 As a user, I want the plugin to automatically switch trackers when I switch branches, so that time is being tracked for the work I'm currently performing Story 20-Mar 13-Apr 24 Done TP-72 TP-127 As a user, I want the UI icon to convey the state of the plugin, so that I'm made aware of whether or not my time is being tracked Story 20-Mar 13-Apr 24 Done TP-72 TP-126 As a user, I want the UI icon to be interactable, so that I can manually toggle a tracker in a simple manner Story 20-Mar 31-Mar 11 Done TP-72 TP-125 As a user, I want to be able to stop all trackers, so that I stop tracking my time when I'm not at work Story 20-Mar 13-Apr 24 Done TP-72 TP-124 As a user, I want the plugin to be able to start a tracker, so that I can track my time when I'm at work Story 20-Mar 13-Apr 24 Done TP-72 TP-123 As a user, I want to be able to change my access token, so that I can track time for different teams and projects Story 20-Mar 3-Apr 14 Done TP-72 TP-122 As a user working at Tempo, I want to have the choice to use the Early Access Programme, so that I can track my time while working in-house Story 20-Mar 13-Apr 24 Done TP-72 TP-121 As a user, I want my access token to be stored persistently, so that I only need to enter my access token once Story 20-Mar 31-Mar 11 Done TP-72 TP-137 As a user, I want the UI icon to convey the state of the plugin, so that I'm made aware of whether or not my time is being tracked Story 20-Mar 13-Apr 24 Done TP-73 TP-136 As a user, I want the UI icon to be interactable, so that I can manually toggle a tracker in a simple manner Story 20-Mar 1-Apr 12 Done TP-73 TP-133 As a user, I want to be able to change my access token, so that I can track time for different teams and projects Story 20-Mar 23-Mar 3 Done TP-73 TP-131 As a user, I want my access token to be stored persistently, so that I only need to enter my access token once Story 20-Mar 23-Mar 3 Done TP-73 TP-130 As a user, I want to prompted upon first startup to enter my access token, so that I can easily configure my plugin Story 20-Mar 23-Mar 3 Done TP-73 TP-141 Run configuration failing after removing old_plugin Bug 4-Apr 23-Apr 19 Done TP-71 TP-142 old_plugin instantiating despite ignore status Bug 4-Apr 23-Apr 19 Done TP-71 TP-143 the user should be prompted only once for his access token Task 17-Apr 17-Apr 0 Done TP-88 TP-144 only the issue key is displayed beside the icon if the branch is valid. Error message otherwise Task 17-Apr 17-Apr 0 Done TP-88 TP-146 the user should be prompted only once for his access token Task 17-Apr 18-Apr 1 Done TP-72 TP-145 only the issue key is displayed beside the icon if the branch is valid. Error message otherwise Task 17-Apr 18-Apr 1 Done TP-72 TP-148 make the readme.md file look good Task 19-Apr 23-Apr 4 Done TP-72 TP-147 Make the readme.md files look good Task 19-Apr 23-Apr 4 Done TP-88 TP-150 plugin should not display the token as plaintext Task 20-Apr 20-Apr 0 Done TP-72 TP-149 plugins should not display the tokens in plaintext to the user. Task 20-Apr 20-Apr 0 Done TP-88 TP-151 Touch up the ATOM implementation Task 20-Apr 23-Apr 3 Done TP-88 TP-152 Read the final report & identify stuff that needs to be clarified Task 21-Apr 23-Apr 2 Done TP-20 TP-153 IntelliJ - Change config text field to a password field Task 23-Apr 23-Apr 0 Done TP-154 Update atom to meet the new specifications Story 23-Apr 23-Apr 0 Done TP-88 TP-155 update vscode to new specifications Story 23-Apr 23-Apr 0 Done TP-72 TP-156 Maven integration Task 23-Apr Deleted TP-71 TP-157 Create javadoc-style comments Task 26-Apr 30-Apr 4 Done TP-71 TP-158 Write unit tests for running through Intellij's maven framework Task 27-Apr 7-May 10 Done TP-71 TP-159 Nullpointer ref on editor start Bug 27-Apr 27-Apr 0 Done TP-160 Configuration dialog postpones project opening Bug 27-Apr 27-Apr 0 Done TP-71 TP-161 Persisting state no longer persisting Bug 27-Apr 27-Apr 0 Done TP-162 Git4Idea integration Task 30-Apr Deleted TP-71 TP-164 Get Presentation ready for Graded Meeting Task 30-Apr 7-May 7 Done TP-20 TP-163 Get Report ready for Graded Meeting Task 30-Apr 7-May 7 Done TP-20 TP-166 Investigate integration with other Jetbrains IDE Task 30-Apr 30-Apr 0 Done TP-71 TP-165 Create a Live Demo Task 30-Apr 7-May 7 Done TP-20 TP-167 plugin.xml additional information Task 30-Apr 7-May 7 Done TP-71 TP-168 Write README.md Task 30-Apr 1-May 1 Done TP-71 TP-169 Create serialization functions for Tracker objects Task 30-Apr 7-May 7 Done TP-71 TP-170 GitInfo pathing not cross-platform Bug 30-Apr 7-May 7 Done TP-171 Reading from HEAD failing on MAC/Linux Bug 30-Apr 30-Apr 0 Done TP-71 TP-172 As a user, I want to get feedback if authentication failed, so that I can take action to re-enter my access token Story 1-May Deleted TP-175 As a user, I want the plugin to be able to start a tracker, so that I can track my time when I'm at work Story 1-May Deleted TP-174 As a user, I want to be able to stop all trackers, so that I stop tracking my time when I'm not at work Story 1-May Deleted TP-173 As a user, I want the plugin to automatically switch trackers when I switch branches, so that time is being tracked for the work I'm currently performing Story 1-May Deleted TP-176 As a user working at Tempo, I want to have the choice to use the Early Access Programme, so that I can track my time while working in-house Story 1-May Deleted TP-177 Strange bug creating new project in a paused state results in crashing Bug 2-May 7-May 5 Done TP-71 TP-178 New bug Bug 2-May 7-May 5 Done TP-72 TP-179 Fix README in VSC Story 3-May 7-May 4 Done TP-73 Háskólinn í Reykjavík T-404-LOKA

References

[1] Git Integration plugin. url: https://plugins.jetbrains.com/plugin/ 3033-git-integration. [2] Atlassian. Software Development and Collaboration Tools. url: https:// www.atlassian.com/. [3] Atlassian. Jira | Issue & Project Tracking Software. url: https://www. atlassian.com/software/jira. [4] Atlassian. Conﬂuence - Team Collaboration Software. url: https://www. atlassian.com/software/confluence. [5] Atlassian. Stride is the complete team communication solution. url: https: //www.stride.com/. [6] Amazon EC2. url: https://aws.amazon.com/ec2. [7] Jenkins. url: https://jenkins.io/. [8] Amazon Web Services (AWS) - Cloud Computing Services. url: https : //aws.amazon.com/. [9] Axios. url: https://github.com/axios/axios. [10] JS Promise object. url: https://www.promisejs.org/. [11] Apache HttpComponents. url: https://hc.apache.org/. [12] Gson. url: https://github.com/google/gson.