Community
Participate
Working Groups
When I create a new local task it comes be by default scheduled for today. If you just want to create a local task to populate a context and forget to clear this setting, the task will be marked as red on next day. Shouldn't be better to make it not scheduled by default? Or at least make this a preference?
Willian: we are not quite ready to make this a preference, because we want to encourage use of the planning facilities and make the "Focus on Workweek" mode the 'default' for the Task List. And when in this mode a new task won't show if it is not scheduled. However, we're trying to make it more flexible and I'll leave this open to consider for 1.0. For new repository tasks we just added a "Personal Planning" section that allows you to clear the planning date. For now the work-around for personal/local tasks is to hit "Clear" after creating it.
UI seems clear enough now without needing the preference, since it is easy enough to hit "Clear". But resolving for later because we may want to reconsider if we have usage data indicating that many users hit "Clear" every time that they create a task.
I hit clear most times :) Mik, I see here 2 use cases: 1 - For you and other commiters that work most of time on Mylar, it makes sense to always schedule the task (because there is a great possibility that the bug will be investigated by yourselves. The same apply to me when I open some bug for my own product on my company. 2 - For me and other users, it does not makes sense to schedule the task because we are very likely to *** NOT *** resolve it by ourselves. It is very unlikely that a customer will submit a patch to fix a bug in my product (ahh, it would be great if they do this :). IMHO, I see case (2) as the most predominant. I'm OK regarding the "resolved later", unless it becomes a "resolved never" :)
Fair enough, but for 1.0 I'm hoping that case 2 is easy enough with that single "Clear" click until we figure out how to integrate this preference (e.g. it could be a check box that enables the Schedule For), and is sticky across editors so that if you uncheck it once it stays unchecked. I'm quite happy with resolving this in that way since it avoids forcing people to go to the prefs dialog. While I don't think think that RESOLVE LATER is RESOLVE NEVER, we have not yet demonstrated that ;) So reopening, and we now have a very reasonable way to implement (after 1.0).
Rob: this is similar to the check box I've suggested to control reopening the editor on submit.
(In reply to comment #4) > Fair enough, but for 1.0 I'm hoping that case 2 is easy enough with that single > "Clear" click until we figure out how to integrate this preference (e.g. it > could be a check box that enables the Schedule For), and is sticky across > editors so that if you uncheck it once it stays unchecked. I'm quite happy > with resolving this in that way since it avoids forcing people to go to the > prefs dialog. > I'm still favorable to make it "not scheduled" by default, since I feel that case (2) will be the most used, and for case (1), it is very likely that you won't resolve it today, so you'll have to change the value anyway. So, IMHO, NOT making a preference and just leaving "not scheduled" by default would be the best simple option for the 2 cases. > While I don't think think that RESOLVE LATER is RESOLVE NEVER, we have not yet > demonstrated that ;) So reopening, and we now have a very reasonable way to > implement (after 1.0). > Yes, I was just joking with the common Platform's practice. See: bug#157642.
Hi, I'd like to bring back this bug to consideration. It is really annoying to have to clear the scheduled date every time I open a bug on eclipse.org. This setting is useless when I'm wearing my bug-reporter hat.
+1. I think scheduling only makes sense for developers who are working on particular project, and ratio of those developers to the people who report bugs is quite low. So, it should be either defaulted to none, or there should be a preference.
+1. I'm not sure if the ratio of people reporting bugs is higher, because my understanding is that most industry developers do not report bugs. However, this needs to be optional. It will be very straightforward to implement by making the schedule option sticky, which should cover the common cases (users who switch between wanting to have bugs scheduled and not scheduled may end up using this option). Anyone who wants this feature interested in providing a patch?
It turns out that there is still some design discussion left around this, so I'm removing the helpwanted status until we have a clear implementation plan. Also, it is related to other planning preferences. Rob and I chatted about this and we figure that one of the following should be most simple: 1) Make the option sticky in the editor. Tradeoff is that it can't be configured per repository. 2) Make the option configurable with repository settings (e.g. one repository used mostly for team tasks vs. another used for bug reporting). 2) Make the option on a new Planning/Scheduling section of preferences. We were leaning towards a combo of (1) and (3) and avoiding the UI complexity of per-repository settings.
I'd say (2) would be more transparent then (3). You just need to make "sticky" setting unique to the repository (or better repository + project + component).
Yes, (2) has those benefits, but I would like to point out that the benefit is not without cost because results in a considerably more complex UI: * We need to have a Planning section in both Task Repository Properties and Preferences, or have a complicated Planning section under Preferences that allows per-repository configuration. * When users see the setting in a New Task editor they need to understand that it can be different for different repositories. In other words, there would need to be more users who benefit from the "schedule for some repositories" setting than users who benefit from the additional simplicity of the "always/never schedule setting". Eugene: I'm not asking you to acknowledge the importance of this reasoning because I know that you have a preference to more powerful and sophisticated UIs, but as with all other UI decisions complexity will be a key factor in deciding how this is resolved.
It seems like you are still misunderstanding my suggestion. The behavior I am suggestion don't require any settings or preferences, but task editor will just have sticky settings that would match to the last choice for given project/component. With initial values set to "none" most of the users won't see the difference, and you'll need to choose those settings once for each component when creating new tasks in the task editor and then will practically have the current behavior after that. To me it will be the most natural, simplistic and adaptive UI.
If this is purely automatic, and not explicitly visible in a preference, there is the UI burden of users needed to understand the policy (bullet point 2 in comment#12). If we were convinced that it is completely obvious then we wouldn't have to worry about it as much. But I'm not convinced, and we also have to consider the case that some repositories could want to have scheduling on by default and others off, adding to confusing if there is no explicit setting.
I think just repository will be confusing, so it better be repo/project/component. I don't think preference would be useful nor will help with awareness because users don't look into the global preferences and it don't really make sense to have such setting at the repository level, because it is only specific to task editor UI. As for the visibility, we could use existing awareness features, including UI decoration and tool tips on those widgets, as well as the standard help system.
Is it posible to set <choose date> and 0 as default for the personal planning? I agree with Comment #6 that you have to clear or change it anyway. So no one uses the default of the current date and 1 hour as time. To clear the default would speed things up because in the most cases the user doesn't use the current default because the bug is for someone else.
Tobias: it depends on the use case, since we know of some cases where the date and estimate are used the majority of the time. So we'll probably just make it stick per-repository, i.e. if you clear it, it will stay cleared for that repository the next time that you create a new task.
Going to jump in here and describe my ideals as a user: * Per-repository defaults are good for me, since I want e.g. Mylyn bugs to never have any schedule information on them since I'm not a Mylyn committer, however I do want to have defaults for my local tasks and my company repository tasks. Project and component settings are a level of micromanagement that would drive me insane, and I wouldn't use them. * A good way to provide an intuitive UI for this would be to have a 'Set Defaults...' [link/flag/button/pick your UI widget] which would then open up the defaults for that repository. Sticky settings might get confusing - if I normally set local tasks for next day and 1 hour, then when I create one task that's a few weeks out the next time it'll show me the same thing. I'd consider that less useful than a default that I have control over. Also, placing the option to change defaults where the data is entered provides immediate visual feedback about how to change something if it's annoying me as a user.
I looked at bugs reported on Mylyn project and here are number of reported bugs for top 10 reporters: 1748 - other 613 reporters 900 - eu@md.pp.ru ??? 857 - mik.kersten@tasktop.com <<< 424 - steffen.pingel@tasktop.com <<< 324 - robert.elves@tasktop.com <<< 239 - wmitsuda@gmail.com ??? 138 - shawn.minto@tasktop.com ??? 45 - raphael.ackermann@gmail.com 42 - mm105@xs4all.nl 41 - murphy@cs.ubc.ca 39 - cpuidle@gmx.de As you can see, most of the bugs is reported by the people who won't work on those bugs, so current Mylyn personal planning defaults are only valid for 3..5 people and invalid for over 600 other reporters. I like the idea of explicit "set default" button and would like to work on patch for this if Mik is fine with that. The only open question if those defaults should be set per project or per repository. Personally I use at least 3 large issue trackers where I only work on a few projects but submit issues to quite few other projects in the same repository I don't work on, so per-project setting seem more useful, though I will be happy with pre-repository defaults set to blanks. Please let me know.
My opinion is that per-repository is a good start, and we can increase granularity to per-project if the feedback is that it would be useful. I definitely think that per-component is too much though.
+1 on Eugene's idea.
(In reply to comment #21) > +1 on Eugene's idea. You probably want to say Ryan's idea... :-)
Doesn't matter :) I'm still shocked by knowing now that I opened 239 bugs on Mylyn since 12/2005. This gives ~1 bug opened each 3 days! And ~70% got resolved :)
+1 For making this customizable.
Just a reminder, that I am still awaiting answer on question in comment #19
Hi Eugene, If it was my opinion you were waiting for, check comment #20. Otherwise, who are you waiting for an answer from?
(In reply to comment #26) > If it was my opinion you were waiting for, check comment #20. Otherwise, who are > you waiting for an answer from? Sorry about confusion Ryan, I was asking those who are in power to make decisions here.
We'll have to wait for Mik's thoughts on this since he is offline this week.
I think that the simplest and most obvious thing we can do is to make the scheduled date and estimate sticky in the task editor per-repository. In other words, if you file a bug against bugs.eclipse.org and uncheck the scheduled date, all subsequent new task editors for bugs.eclipse.org would have the scheduled date unchecked. The option would be on by default for all task repositories, since scheduling is an important part of the Task List UI. The UI in the new task editor would likely need to change some in order to make this more obvious (e.g. we could have a Personal Planning section with a single check box).
(In reply to comment #29) > I think that the simplest and most obvious thing we can do is to make the > scheduled date and estimate sticky in the task editor per-repository. Fantastic! Is that different from what been suggested on comment #13 ?
Regrettably, I don't see getting to this in time for 3.0. Lets revisit early in 3.1. Raising priority so we address this early in the cycle.
Is there plans to address this issue? The approach suggested in comment #29 should be rather trivial to implement and this is one of the most annoying inconveniences in Mylyn reported over two years ago. Thanks.
Yes, it is likely that this feature will get added in an upcoming release but we could not allocate sufficient resources for the current milestone.
*** Bug 499871 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/79243
Gerrit change https://git.eclipse.org/r/79243 was merged to [master]. Commit: http://git.eclipse.org/c/mylyn/org.eclipse.mylyn.tasks.git/commit/?id=f53818a10879eb46747383a6a533845c6e037cf2
This bug has been dead for some time, but it's come up a few times in discussions lately, we've decided to add a preference to Mylyn Tasks which allows developers to globally set the time to scheduled new tasks for. The options are Today, Tomorrow, This Week, and Unscheduled. The default setting will be This Week to avoid disrupting anyone relying on the current functionality. Though having per repository, or per project settings are an interesting idea I suggest we don't pursue them now and close this bug with the changes that have been made. If we want to revisit the idea of having a sticky per repository setting as in comment #29 it could work fine with the work that was done as it simply sets the baseline for all repositories.
Sounds good to me!
