Community
Participate
Working Groups
The "Estimated Time" field in the Mylar task Planning Pane does not reflect the Jira "Original Estimate" field of a task. Updating either value does not change the other. Perhaps this is by design? I believe that a new task should grab the "original estimate" field from Jira as a starter value. I believe the values should remain sync'd after that -- but perhaps that's debatable. Jira Version: 3.7.1-#185 Mylar Plug-in v1.0.1 From Jira page: "Original Estimate" field An estimate of how much work remains until this issue will be resolved. The format of this is ' *w *d *h *m ' (representing weeks, days, hours and minutes - where * can be any number) Examples: 4d, 5h 30m, 60m and 3w. Loving Mylar - bang-up job guys!
Need to mark this helpwanted for now, since the Jira Connector is currently supported by community contributions. Note that this is closely related to bug 144620.
Part of activity improvements that we're considering for 3.0.
Steffen, is this a duplicate of bug 214039 or there are plans to keep estimate field on Planning tab in sync?
Deferring: This needs further generalization on the framework level.
Why do bugs related to Mylyn / JIRA worklog integration always end with someone suggesting 'further framework generalization' and then we hear no more about them?
Having this added would really save a lot of time in dealing with JIRA tickets. Thanks
Ideally, it would be nice it the time spent field was editable as well as the estimate. The reason we need this is for Scrum/Agile processes. We would like to record our progress on a daily basis without necessarily marking the task complete. This would show a more accurate burndown chart and keep my developers from having to login to JIRA everyday to do that update. Thanks, Lou
Here is a workaround script to input the worklog into jira with just a few keystrokes: http://slnc.me/script-for-frustrated-time-conscious-mylyn-jira-users/
This would be a real asset on my team, since this is the only time we actually need to open a browser and go to the JIRA site.
Our concern is that if we don't provide a lot of additional UI in the form of reporting and controlling any activity capture, it will be too easy to misuse such activity tracking automation in a way that causes privacy concerns. Since the reporting UI is such a big task on it's own, and because it's already provided by commercial extensions such as Tasktop, without additional resources it will need to remain out of the scope of Mylyn.
So does this concern apply equally to Bugzilla or Trac ? But that aside, privacy sounds like a very odd reason, surely you should provide the facility to turn this on or off within Mylyn config and the privacy issue is then up to how the team uses it. It sounds like your presuming to tell people what information they can or cant share around the team.
I too think that privacy concern is a bad "justification" to close this one :) After all the only interesting point in measuring time per activity/task is to be able to see team (i wouldn't care to measure my own time if working alone) performances, statistics, productivity etc ... but not in Mylyn (the issue trackers can already handle that kind of reporting features). I think the goal of this bug is "just" to implement a framework in Mylyn and its connectors to allow time synch with the issue trackers out there (JIRA, BZ, Trac, etc ...)
I'm not sure I understand the privacy issue either. Would it not make sense to have a section where one can log work done, there exists the ability to start/Stop progress and close issues but not log work done. This seems to be one of the few remaining reasons to have to leave the IDE and open a browser. I don't think it should be automatic, but at least available, maybe have a section similar to the existing Actions area where the time spent on a task (as logged by Mylyn) is prepopulated, having it make adjustments based on time already logged would be nice too, but even just a very simple log work done ability would be grand. Thanks, Brent
In my point of view, the privacy issue is not an inherent problem, but a practical one. In other words, I think the proposed functionality is a great idea. However, implementing it in a way that does not cause privacy problems is a huge task. Consider the scenario where you want to report time for all the tasks that you worked on in a given week. Given that Mylyn's time tracking only tracks time within the Eclipse workbench, you'll encounter the following problems; * For some tasks, you will need to add time spent in other applications and in meetings * You may have accidentally had one task active when working on another * You may want to add comments on where time was spent * You may be asked to re-generate a time report or submission if someone else and not you caught any of the above problems As such, when we did the design for this we considered the following functionality to be a requirement of getting this right: 1) Need to track time spent in the operating system and other applications, not just Eclipse (i.e., OS-specific instrumentation) 2) Need to provide a rich reporting view, with at least the features of: http://www.tasktop.com/videos/1.2/introduction/reporting/ 3) Need to provide additional explicit controls for adjusting time tracked and any submissions to the repository The 1-3 listing is a very significant amount of work that we decided belongs value add extensions to Mylyn, since time tracking of this sort is more of an enterprise/commercial feature, and not a core feature for open source and Java programming, or improving support for one of our existing task repositories. Since we're always interested in improving the split between the open source and commercial portions of the task-focused interface, I'm interested in feedback on the assumptions above, or on the feature set that people need to work with time tracking effectively.
Let me describe how we track our time: We have an external tool which tracks the time on several projects. Normally, we have an accumulator project, and after a while, move the time to the specific project we are working on. As a repository we use Trac with a plugin which accumulates time entered into a special user defined field "Add hours". So if my external time tracker has accumulated some time, I move this time to the relevant project and enter the minutes or hours into the Trac user-defined fields, add a comment to describe what I have done and submit the changes. So if it is possible to enter some value into a specific JIRA field to add it to the work log on submit, this is basically the same behaviour. IMHO, this should be the absolute minimum possible with the JIRA connector: Avoid leaving Eclipse to enter some value via some Web browser. Another, separate point would be to extend the Mylyn time tracking in such a way that no external time tracker is necessary. Here of course some simple functions would suffice: - Start/Stop recording the time - Adjust the time by providing some configurable buttons -/+1, 5, 10, 30, 60mins or some slider or both - Transfer accumulated time to some task repository specific field (configurable) and reset accumulator Mik, do you think this is too far out of scope? This is not very sophisticated, IMHO. With regard to the original bug description, __automatic__ synchronization of the Mylyn time is not really required in the first place. Manual operation without using any browser/external tools is sufficient.
Having an editable input field in the issue details pane that automatically reflects the time spent in the issue as MyLyn currently tracks it would be enough. If the user manually changes that input field time then automatic updating of the input field would stop for that issue and it would only reflect the last time entered by the user. Finally when the user marks the issue as resolved and saves changes MyLyn would create a new worklog entry for it after solving it. Remaining estimate time would need to be set to 0 too because it has already been solved. What the script I mentioned before does is the only functionality that I was expecting from this feature request since the beginning, quickly add a worklog to an issue when you mark it as solved. Mik's special situations described in #14 are basically nonexistent for us. We fix so many small-sized issues that a small error or two doesn't matter too much and if they do matter they happen so seldomly that we can just go to JIRA and update the worklog associated with the issue. I think those special situations described belong more to TaskTop or other non software-development related uses of MyLyn.
I think the detailed, cross-application system is a neat idea and I agree that it would be a lot of work. I think most people commenting here aren't looking for near that size or quality, just a method of submitting work done, and maybe having some pre-population of the time spent field based on the timer for the task. We, and I'm sure a lot of other companies use JIRA for tracking bugs and some other software tasks, but certainly not everything we do. We use JIRA time logging for future estimating and to help track project/story progress it doesn't tie into our HR time tracking systems. Maybe this is an unusual usage, but I doubt it and as such a simple time submission mechanism would be helpful. Thanks, Brent
Thanks everyone for your input. We are going to start planning Mylyn 3.2 soon, will discuss this during our regular dev planning call this Thursday, and report back.
I think Brent, Lou, and several others hit the nail on the head: For my team, having some method of adding work log entries to a task from within Tasktop/Mylyn is essential. Automated logging (through activation) is frosting (not to mention error-prone), but manual logging is a requirement. After all, the purpose (for us) of using Tasktop/Mylyn is to avoid the need to pull up the JIRA web interface in a browser. With no time logging abilities, that need is not avoided. Also, I want to mention that, for us at least, time logging should not be done only when the task is resolved; rather, time logging should occur on a daily basis so that we have a running progress indicator.
Thanks for the feedback Doug. We have discussed this and propose the following split in terms of what's in scope for time tracking within Mylyn: * Facilities for editing of all task attributes that are available in the web interface are within the scope of Mylyn. This includes the ability to edit the work log for both the JIRA and Bugzilla connectors. * Automation for time tracking and any reporting views are out of scope of Mylyn for the reasons discussed in comment#14. What this means to those interested in this functionality: * You can expect work log editing to be available with Mylyn 3.2, see bug 262799 * If you want automation features, you can get them from commercial extensions to Mylyn. See http://www.tasktop.com/time-tracking/ for details. How does this sound to those interested? I realize it would be nice to get everything for free, but we have to have a reasonable scope of the open source tool features, since the closed source extensions are what funds the vast majority of the open source development, and since the Mylyn framework and APIs are our top priority.
Honestly what i see from the decision to not to implement time-tracking synchronization, is that alternatives/patches/add-ons to Mylyn are going to show-up sooner or later. Like i said previously: to me the whole point of time-tracking myself, is to be able to do it team-wide and to have aggregate metrics and so on. If i can't i'm not going to even use it. You (Tasktop) can/must certainly make some profit out of your work. But in my opinion, to do it in a semi-opensource model, you should give the users some value-added features (e.g. time-synch) for free and keep some to sell (reporting, statistics, metrics, advanced productivity information). In your proposal, you are keeping the whole added value of Mylyn to sell. So i figure people will try to find alternatives (in my company we are already).
I have no problems with the proposed split. I tend to think automated time tracking would be something I would disable anyway (too much potential for error for exactly the reasons cited in <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=173880#c14">#14</a>), so once manual work log entry is possible from within Mylyn I will be happy葉here will then no longer be any need for me to pull up JIRA in a browser.
I think the proposed split is exactly what is needed. Manual logging is essential for most users and should be seen as an integral part of any open source solution. As Doug says automated logging is frosting, and although I think we would certainly use this we have development partners who may not have the option of investing in a commercial solution such as TaskTop but still want to tie into our issue tracking process. Looking forward to MyLyn 3.2!
I agree with Doug and Duncan. Having the functionality is what we're after. I am a very happy Tasktop user and have no problem paying for a commercial product that automates manual processes and gives me added niceties like reporting, etc.
*** Bug 291262 has been marked as a duplicate of this bug. ***
The Mylyn JIRA Connector has moved to Atlassian. All unresolved Mylyn bugs assigned to the JIRA component, which includes this bug, have been copied to https://studio.atlassian.com/browse/PLE and marked as resolved on bugs.eclipse.org. The new location of this bug report can be found in the URL field. Please see this FAQ entry for further details: http://wiki.eclipse.org/Mylyn/FAQ#What_happened_to_the_Mylyn_JIRA_Connector.3F .
