"Michael H. Pryor" <michael@fogcreek.com> wrote on 08/21/2004 10:25:49 PM:
>
> Mark wrote:
> > Why not just try to support more usage models?
> > Finally, as that other poster pointed out a few days ago,
> > there might be admins that want absolutely everything to
> > have a bug ID associated with it, even basic repository admin tasks.
>
> IMHO it's because adding features has a cost associated with it, namely
> complexity. As software designers, sometimes we really *do* know better
> than users.
No offense, but that is just BS. I am a developer too, and that is also
one of my favorite lines to give to users when I do not want to do
something. This feature is not adding complexity. First off, none of
these feature are exposed in the UI as settings. They are properties that
have to be set on folders in the repository. Someone has to explicitly
want and enable this feature. A hapless user does not have to learn and
understand these settings on a preference page. Second, the code to
implement this feature would be vritually identical to code already added
to verify if the issue ID is numeric. This code should actually be
simpler. So let's retire the bloated/complicated code argument shall we?
> Out of control admins
> shouldn't be given the ammo to be able to subject their devs to crazy
> requirements. If they need to force devs to do that, it should be a
policy,
> not a mandate provided by the software because there are always
exceptions.
So then you have decided that someone who needs this feature is "out of
control". Nevermind the fact that this feature causes no harm to the
people that do not want it and do not turn it on. But for someone that
needs it, you would rather have a system where good intentioned users can
forget to fill out the bug ID field, forcing the admin to discover this
fact later, and then manually rewrite the log message in the correct
format from the command line? Doesn't Fogcreek have any customers in
regulated indiustries like Health Care or Finance? I suspect a large
percentage of our customers would have a feature requirement like this.
However, as I have said, I think the number one reason is to make the
feature more usable for those people that want the preponderance of their
work to have an issue ID associated. If they do not care if every commit
has an issue ID, then they should not care if they user enters a '0' or
some other value like 'N/A'. But again, they could also not go out of
their way to turn this feature on.
> Generally, I don't agree with the idea of "why not just add a switch to
> support every possible mode?" because then you end up with unusable
> software. If adding features is expanding the usage of the tool, then
> that's wonderful, but if it's because the developer couldn't decide the
> answer to a question (in this case 'should bug id's be mandatory?') then
> it's not so wonderful.
I agree with your first argument, I just do not think it applies here.
This is a question with no right answer. Why does Tortoise allow the user
to specify their own diff/merge tools? Why does Tortoise allow the user
to control where decorators are used and how they behave? Answer, because
there is no single answer. I have already given several reasons why I
think someone would legitimately want this feature, all you have said is
that you would not want it yourself. Neither would I. I think that point
is irrelevant.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Aug 22 17:23:44 2004