Skip to main content
Jump to: navigation, search

Difference between revisions of "Mylyn/Activity Tracing For Mylyn"

(Mookup)
(Details)
Line 12: Line 12:
 
== Details  ==
 
== Details  ==
  
The Deliverables should be a tested and documented component, which works fine. The code to this project, I want contribute in form of a patch. This component needs unit tests and integrations tests. Result:
+
Implementation steps: <br>
  
 
+
#Show the commit informations in a TableViewer, which is embedded in the task editor.
1.  Show the commit informations in a TableViewer, which is embedded in the task editor.
+
#Extend the Tableviewer for the additional build and review data. The TableViewer displays now all needed data.
2.  Extend the Tableviewer for the additional build and review data. The TableViewer displays now all needed data.
+
#Embed the additional data in the comment stream (task editor).
3.  Embed the additional data in the comment stream (task editor).
+
#Optional: Dashboard, which aggregates data about several tasks.
4.  Optional: Dashboard, which aggregates data about several tasks.
+
  
 
== Mookup ==
 
== Mookup ==

Revision as of 16:54, 24 April 2012

This is the wiki page for the GSOC2012 project Activity Tracing for Mylyn.

Student: Timur Achmetow
Mentor: Steffen Pingel
Bug ID: BUG 376233

About

Description from the mentor: The Mylyn task editor is the hub for task-focused collaboration. Yet, there are many other artifacts and activities that are part of the development workflow that are visualized in different views in the IDE. A unified activity view that aggregates tasks, builds, reviews and commits either in a dashboard or embedded in the task editor would nicely enhance traceability and visibility.

This additional data could show for example in the task editor or in a dashboard (new view). The new view helps the user to trace the selected tasks. One use case for this view could be, show the files, which are changed with the last commit. So the user have later the possibility to see, which files with this task are changed. Similar use cases are the build and review traces, who the user want see, if the selected task have an association with the build server task or a finished review task. So can die developer see, which changes have broken the build. With these additional data the task editor gets more connection to other developer tools.

Details

Implementation steps:

  1. Show the commit informations in a TableViewer, which is embedded in the task editor.
  2. Extend the Tableviewer for the additional build and review data. The TableViewer displays now all needed data.
  3. Embed the additional data in the comment stream (task editor).
  4. Optional: Dashboard, which aggregates data about several tasks.

Mookup

Example.jpg

Architecture

Milestones

M1 / May 01: Studying the documentation and existing code and prepare toolchain M2 / May, 20: Create a design and mockup M3 / July, 15: Mid term: Show commit information in task editor M4 / July, 30: Show builds and code reviews in the task editor M5 / August, 13: Embed activity data in the comment stream M6 / August, 20: Pencils down: Documentation complete

Related Links

Back to the top