On Tue, Jun 02, 2009 at 11:30:13PM +0100, Lee Baylis wrote: > Regarding whitespace, here is a list of files I currently have local > changes in: You should not have much trouble if you have stuff in git and then rebase to include my white space changes with --whitespace=fix. Alternatively apply a patch with -l. If you do run into a lot of problems let me know. > I'll start where Maurice left off in his mail of 13/12/8: > > Maurice van der Pot wrote: > > Apart from the change to a percentage that you already said you were > > going to do, I have a few more comments: > > > Despite saying I would do this, I've been thinking about it with > reference to my resource units patches and I think we need to revisit > this decision. > > To quickly recap, this bug relates to whether there should be a > percentage sign on the dialog when ASSIGNING a resource to a task, > against the 'units' entry. ... > However, I also think it is better from a user perspective to think > about units - If, as a user, you have decided the maximum number of > units is not going to be 100 for whatever reason (e.g. 134), I think you > are more likely to want to specify the number of these units (e.g. 34) > when performing allocations to tasks, instead of guessing at a > percentage of your new maximum (34 units out of a maximum of 134 would > be 25.373%). I think I may have been misunderstood when we were talking about this before. Not only the thing when assigning should be a percentage, but also maxunits itself. So max percentage would be 500% for a team of 5 people. Actual percentage when assigning would by default also be 500%. The only changes wrt the current situation would then be: - it shows a % somehow everywhere in the GUI - 100 is no longer the max for max units (- anything over max units would be overallocation, can't remember if it works like that already) All calculations would still be the same as before, only this time when a user stumbles upon this feature it will be immediately clear what this feature does (even if he/she may not be able to think of a use case). > In light of this, perhaps the better solution to bug #387985 is to > explain the flexibility of these fields in more depth, either in the > manual or with a tooltip, instead of just tagging '%' in the GUI. I think tagging the % everywhere should match your proposal, except we do not use arbitrary 'units' anymore. I think the arbitrary units were actually causing the confusion. > > - The value of available units defaults to 0. Should that be 100? > > > I did consider making it 100, but in the end my feeling was that the > principle of least surprise probably meant it was better left at zero > for now -- the reason being that the units field has *existed* on > resources for some time in xml (it has just not been possible to set), > and that it has been set to zero by default in existing xml files. > > If we change the default to 100, opening a legacy planner file will lead > to this value being zero for all existing resources. If a user then > creates a new resource in the legacy file, it would be set to 100. There > will then be resources with different maximum units, which is probably > not what the user expects and may cause confusion (especially once I > submit patches which start making use of this variable). > One alternative is that we attempt to automatically update the available > units values saved in legacy planner xml files, but I don't think we > have the right to do this -- I feel it should be left to the user to > alter their work. > > Any thoughts? In any case, it is still an easy fix if we decide that > having 100 by default is a better route to take. I think the principle of least surprise for current code trumps the principle of least surprise for backwards compatibility. I would definitely go for a conversion. It would be strange if you set the number of units to X in resource creation and it would be 0 when you assign the resource to a task. I was hoping we could use the mrproject-version property for that. Ideally I'd like a notification when a project is imported from an older version. The user can then either save to the new format or export back to the old format. I plan to keep these changes in a branch for a while, so we won't have to solve everything right now. > > - Available units should also be added as a column to the resource view > > > Similar to the point above, the trouble with this item is that people > using planner already have a config file saved in their .planner > directory which does not include the available units column in the > resource view's 'visible columns'. So, whilst my patch actually *does* > expose the column in resource view, people who have ran planner before > on their machine still have to manually update their .planner files by > clicking on view, 'edit visible columns'. > > New users of the planner application, however, will automatically see > the available units field, as demonstrated by deleting your .planner > directory and restarting planner. > > I don't really have any ideas about how we might fix this without > automatically updating people's .planner directory entries, and again, I > don't think it is right for us to mess with the contents of that > directory -- perhaps the best we can do is mention in the changelog the > need for users to manually edit their visible columns? Agreed. If the configuration item for the column was already present before, we shouldn't change it. We should make sure that we don't make the same mistake in the future. No adding of configuration items until the user-visible feature is ready. > > - Eventually the number of available units should also be exported to > > HTML, but that can stay on the TODO list for now. Speaking of which, > > it may be useful to add such a file to the repository. It could > > contain things like this that we postpone for now but need to solve > > for the next release and that do not have a bugzilla entry. > > > OK, I can do this - do you just want a plain text file or should we do > something following GNOME todo list XML standards like the output of gtodo? Just a simple text file should be enough IMHO. Maurice. -- Maurice van der Pot Gentoo Linux Developer griffon26 gentoo org http://www.gentoo.org Gnome Planner Developer griffon26 kfk4ever com http://live.gnome.org/Planner
Attachment:
pgpdX1g1hohoV.pgp
Description: PGP signature