Why pressure featuers you like your self?

[Ethan Blanton]

afceier spake unto us the following wisdom:
> 2. The removal of the _option_ to resize the text window.
> I thought first this was a bug, and wanted to confirm it on irc. I 
> got it confirmed that it was fully intended. Then I got a hostile 
> feeling since i didn't like the removal. For me the main problem is 
> that the whole IM window doesn't feel "right". Something is wrong, 
> and for me it is!

We are not hostile to those who do not like the new behavior, and I'm
sorry if that is the impression you got.  We *are* somewhat hostile to
those who are not willing to discuss the matter, but rather insist on
asserting their opinion over and over without attempting to help us
identify a resolution which works for them, but is NOT NECESSARILY
"revert to pre-2.4.0 behavior".

> That youre getting more features into the program is great. But that 
> you're removing the old once cause you personally like the new once 
> best is kinda lame. Why not make it an option? Why I and others like
> the old visual better doesn't really matter. We are all different and
> we have different taste. I don't see why giving us the options to
> choose is bad? And when i asked why you didn't make these
> features/changes as options. Things got hostile.

Yes, it does matter.  For MANY reasons.  I will enumerate just two,
but I'm sure you can think of more.

1.  Options are expensive.

    Each individual option may be simple or trivial, but they add up.
    Options to do with UI behavior are _particularly_ expensive, due
    to their frequent interactions with the vagaries of UI toolkit
    behaviors, etc.

    This expense takes the form, mostly, of subtle bugs and extra
    programmer effort.  We have had numerous examples of options which
    appear to be simple on the surface causing numerous bugs and
    undesirable behaviors.  A recent and memorable example of this was
    the option for persistent conversations -- I think we all agree
    that the ability to have conversations "open" without an open
    window is one which is appreciated by many users, but this
    seemingly simple feature has caused quite an avalanche of small
    and not-so-small bugs.  In fact, there is speculation that the one
    pixel high input area which some people are seeing stems from this
    very option.

    Anyone who tells you that options are not expensive is either not
    a programmer, or has never worked on a large program.  It is true
    that orthogonal options in a clean code base can be implemented
    with little cost in *many* circumstances, but even the most
    forward-thinking and competent programmers will be blind-sided by
    subtle interactions on occasion, especially when throwing
    third-party libraries and code into the mix.

2.  Progress is good

    The question is not whether Pidgin can remain exactly the same
    forever (it obviously can), but whether we *want* it to. This
    should be particularly understandable in the world of open source
    software, where people consider a project which has not released
    in as little as a few months "abandoned" and ripe for discard.  We
    want to make Pidgin better, we want to make it easier to use, and
    we want to make it more pleasant to use.  This means that
    statements like "I want the old behavior back", with no
    justification, are not useful to us.  On the other hand,
    explaining WHY you want the old behavior back, and what precisely
    it is about the old behavior which makes Pidgin better and more
    useful to you, allows us to improve our software.  It may be (as
    many users have found in the past) that the old behavior *isn't*
    really what you want, it simply afforded some particular
    functionality which the new behavior has lost.  If that
    functionality can be identified, we might even be able to provide
    it in a superior way which you find *more* pleasant and useful to
    use.

    The feature currently under debate is a great example of this.  We
    have had a couple of users who have explained *why* they need
    large input areas, and the circumstances under which this
    functionality is useful to them.  We have more or less agreed (I
    believe) that the new behavior is *not* sufficient for all use
    cases, and we *do* intend to improve it.  Using the "why" we have
    heard from some users, we will hopefully be able to do so in a way
    which cleanly adds the new functionality while preserving their
    requirements.

    Reverting to old behavior should be seen as a last-ditch effort
    which is giving up on an attempt to make Pidgin better.  It might
    be the right choice, but the change was made for a reason -- in
    this case, many people *like* and *want* input areas which
    automatically resize.  Numerous iChat and Adium users, for
    example, have specifically asked about this behavior in the past.

> I read the mail archive and other have had the same opinion as myself 
> and has gotten the same hostile attitude. They have to explain why 
> they like the old pre-change better. They have to actually explain 
> their TASTE! When instead of pressure the user into something new you 
> could just add the option for the "new/old"

Hopefully you understand now why that option is not our first resort,
and why we have asked for clarification.

> And when all is said and done. The user get in the face: Its open 
> source, make the changes yourself *case closed*. When most users 
> don't have the ability/skill to do so. Yes no one has had to pay you 
> for the software, but even so you're not making it for yourself 
> alone, cause then i and others wouldn't be using it as i write this.

You are missing the point here, too -- yes, it IS open source, which
means that we have every right and expectation to ask our users to
help out.  In this case, we're asking our users to sit back and think
about why they like or dislike certain behaviors, and to clearly and
logically explain their preference.  This is something which even
users who are _not_ programmers can easily do, if only they care to
spend the time.  For those who are unwilling to help us make Pidgin
better, I have no problem with suggesting that they pay the cost of
patching themselves.

In short, the attitude you exhibit here (of "you owe us the
reversion") is more abhorrent even than the attitude of which you have
falsely accused us.  No, we don't owe you a reversion.  No, you don't
owe us your input, either.  However, if you are unwilling to *provide*
your input, then you forfeit any right to even *ask* for a reversion,
much less assert your entitlement to a reversion.  Think of it like a
democracy; if you don't vote, don't complain about the results of the
election.

At the end of the day, it is *our* work and effort which makes Pidgin
what it is.  We will make Pidgin the best messenger we feel is
possible given our constraints.  We will even strive to make it the
best messenger our *users* feel is possible, in so far as they are
willing to work with us and our visions and the visions of our users
coincide.  To use an argument which is often thrown at Open Source
projects (in an ad absurdum fashion, I might add) when a user is
unhappy with a particular decision -- Open Source is all about choice.
If, at the end of the day, our vision departs with yours, then perhaps
our project is not the best fit for your needs.

In this case, I think everyone agrees that the new behavior is
insufficent.  Don't get me wrong, we're working on it.  What we do
_not_ agree is that a simple reversion to previous behavior or an
option to allow either the current or previous behavior is at all a
good idea.  It is, rather, a cop-out.  There were numerous flaws and
faults in the previous behavior which, at the very least, we should
fix in this process.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/support/attachments/20080305/73730336/attachment.sig>