![]() |
Telelogic SYNERGY (steve huntington) | ![]() |
Topic Title: "Unusing" tasks from a Project Grouping Topic Summary: Should be possible to disable this! Created On: 20-Apr-2005 05:48 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
With 6.4 it is now possible for every developer to remove individual tasks from his project by clearing the checkbox "Used" for these tasks in the properties of the project grouping (in the "Baseline & Tasks" panel).
For those of us still thinking in terms of 'folders' and 'reconfigure properties': This means that as a developer I am now able to filter the content of manual and query-based folders provided by the reconfigure template, which the build manager has set up for everybody. If I don't want a certain task, I can "unuse" it and it will not be considered during reconfigure. (So far I could only add additional tasks using my miscellaneous folder unless I switched to manual reconfigure properties). I understand that is sometimes useful (at least for "Collaborative D."), but considering development projects with a larger number of developers this unuse sounds very dangerous. One developer will remove this task from his configuration, the next developer will remove that task and later people forget about their unused tasks. Finally everybody ends up with a different subset of the tasks provided by the build manager and therefore a different set of files for the build. The chances are very high, that this will lead to more build problems and unexpected results due to different configurations. The build manager will then be the one who has to do the additional troubleshooting. To avoid these kind of problems some mechanism to limit this "unuse" possibility seems to be essential. Perhaps it could be done on a reconfigure template level. Then the build manager could allow or disallow this option e.g. based on the purpose of projects (e.g. allow for "Collaborative D.", disallow for "Insulated D."). Or it could be done based on folder templates, so that it is possible to unuse e.g. task provided by the "All completed tasks" folder, but not tasks from the "All integration tested task" folder. |
|
![]() |
|
![]() |
|
It seems to me the best (only?) valid uses of this feature is for temporary testing with ceratain tasks removed (especially useful for Build Managers). If this is the case, then perhaps a solution would be some sort of "nag message" either each time the project is brought in focus in the project view, or each time Update Memebers is run. The nag message could remind the user that he/she still has excluded tasks (with a choice to cancel or continue with the operation in the case of Update Members).
Of course, this could also be reported as a "Conflict", but that would not be as obvious (and would be easier to ignore). |
|
![]() |
|
![]() |
|
There is a "nag message". At the beginning of the update output, it will list the tasks not being used like so:
Not including the following tasks: Task T#135 Fix Task for 132: merge misc dir Task T#145 New Task for tdugger Task T#146 New Task for tdugger Task T#147 Fix Task for 146: New Task for tdugger ------------------------- Senior Software Engineer User Interface Development Lead Telelogic North America, Inc. |
|
![]() |
|
![]() |
|
Providing the ability for the build manager (or CM administrator) to disable the feature that allows developers to add and remove tasks is an interesting concept. In fact, we debated this exact issue during the Release 6.4 design phase, and we had a preliminary design that had such a switch on the reconfigure template, as Robert suggests. However, the argument against such a feature, and the one that finally prevailed, is that we thought that for every customer who wants such a feature, there would be ten customers who would object to the added complexity of the product that such a feature would entail. Plus, as Troy mentioned, we added the "nag messages".
|
|
![]() |
|
![]() |
|
I don't consider information dumped to the log 'nag messages'. These are too easy to miss or ignore. A nag message (and, IMHO, a better soltion here because of the potential downside - builiding/releasing the wrong code) is one that pops up and forces you to reply (or at least click "OK" or "Cancel").
|
|
![]() |
|
![]() |
|
Just a little clarification. The messages that Troy mentioned are not just dumped to the log. They appear in the message view, which is popped open upon initiation of the Update operation. Of course, we don't prompt the user for confirmation.
|
|
![]() |
|
![]() |
|
quote: I don't think this one toggle in SYNERGY/CM Classic would really be considered "added complexity" by other users. In this case the consequences of not having this option are quite severe, especially for customers with large projects. And if you don't want to bother other users, which don't see why some need this switch, then you could implement this just as a flag on the reconfigure template object (e.g. like 'allow_task_release_any' for the base model). |
|
![]() |
|
![]() |
|
Even if you consider it added complexity, it is adding the complexity where it belongs: at the template set up time.
As some know, I've long been an advocate of having the ability of a Build Manager (or Team Leader) be able to configure MANY options available to users when those users are working on the Project/Team (such as releases available in the selection list, reconfigure option settings, etc.). This addes potential complexity (but really does not have to if users just want to use out-of-the-box settings, or even the ability to define settings and then copy/share the settings with other projects/teams) for the Build Manger or Team Lead, but has the benifit of reducing complexity for everyone else on the Team. This also helps ensure that everyone on the team is using the tool in a (more) similar fashion. So, adding ways for a Build Manager to control/reduce the options available to the developers (or at least providing tempaltes for users) can actually have a net effect of reducing complexity. Very good examples of this were the introduction of the folder templates and reconfigure templates. The addition of these features added complexity (potential complexity, since the out-of-the-box templates can work quite well) for the Build Mangers, but reduced complexity for Developers. Overall, this created a MUCH better process of using the tool. |
|
![]() |
|
![]() |
|
On the Project Grouping Properties dialog, the "Baseline and Tasks" tab shows at a glance whether all of the tasks are used without the need to scroll through what might be long list, and the "Use All" button will be enabled. The developer only has to press that button to add in any that were previously unused.
The ability to unuse a task is very useful during normal development. If I make a change that appears to break something, I can quickly unuse my task, perform an update members and retest. That helps to validate whether it is my change that has broken something. After that, I simply go to the Project Grouping Properties dialog and press Use All, perform an update, and start debugging to see how I've broken it. Prior to such a feature, the developer would have to examine the task and manually perform a use of the predecessor version for each of the task's associated objects. There was nothing in the product to prevent a developer from doing this. One thing that you might like to consider implementing is querying for developer's project groupings that have unused tasks. That way, the build manager could periodically review whether developers have forgotten that they "temporarily" unused a task in their environment. We had a number of goals in 6.4. One of the prime goals was to allow build managers to perform daily activities using the Java Client. This is in line with a larger goal to retire the Classic Client GUI. We did not have the bandwidth to achieve this in a single release. So please remember that 6.4 is simply one step along an evolutionary path that may take another 1 or possibly 2 releases before we achieve that goal. I'm sure there will be many suggestions for new features and improvements. We had already conducted usability testing earlier in the release cycle, and made some design changes and improvements. We will certainly consider suggestions and enhancement requests during the requirements planning for future releases after 6.4. |
|
![]() |
|
![]() |
|
I've submitted an enhancement request for a feature that would allow the build manager to restrict the ability for developers to add and remove tasks. The CR number is R#21750. This will be considered for a future release.
|
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.