[Users] [Bulk] Re: Claws config needs much better documentation

[Sitaram Chamarty]

On Tue, Jul 31, 2012 at 8:44 AM, Michael Gmelin <freebsd at grem.de> wrote:
> On Tue, 31 Jul 2012 06:58:39 +0530
> Sitaram Chamarty <sitaramc at gmail.com> wrote:
>
>> On Tue, Jul 31, 2012 at 6:03 AM, Michael Gmelin <freebsd at grem.de>
>> wrote:
>>
>> > In general to me it's still more of a philosophical question - do
>> > you want to make the software behave like other mail clients do by
>>
>> If the devs don't want to make this change fine, but it should be for
>> reasons specific to the feature, not "do you want to make the software
>> behave like other mail clients do...".
>>
>
> I think that Claws is better with this feature enabled. Therefore it
> should be the default, so users learn about it. I'm not certain if you
> actually think that this is a useful feature at all or not, your
> argument was that it might surprise users in a bad way - while I think
> having to move mail once from Trash to Inbox is not a big deal and I
> got surprised in a good way.  I also think that this feature could be
> improved, but not by disabling it by default (and it seems like it
> used to be implemented differenly, which makes a lot of sense).
>
> Brief overview of the debate:
>
> 1. Is the feature useful to a significant number of users?
>    I think "yes", you think ?

On low bandwidth networks, certainly.  On that note, maybe the devs
can consider moving this to the per-account options, with a note
telling the user to read [somewhere].  Keep the current default but
now it's a little more "in your face" (since account setup options are
more likely to be looked at than general preferences.

> 2. Is it a bad surprise or even dangerous?
>    I think "no", you think "yes"

Yes.  Incidentally the only one I found so far in claws.

On the other hand, if you want to use it as a twit filter to keep away
clueless users then that's fine.  Put in some warnings to warn them
off and then tell them take a hike if they complain.

[I'm not against such a policy.  I actually say stuff like that in
several parts of the documentation for gitolite; not everything needs
to be newbie-friendly].

> 3. Should features be disabled by default to make migration easier for
> users
>    We both think "if it's a bad surprise", but we seem to have different
> definitions of what "bad" means - to me this is an inconvenience for a
> migrating user and I don't think a program should sacrifice its default
> feature set to avoid inconvenience for new users.

I disagree but that's fine.  See above on making it more prominent at least.

> This *is* specific to this feature - if the feature in question
> was that claws by default erased your HOME directory on invalid password
> entry I would strongly suggest to not make this the default.

This would be a valid point if the example was a feature that *does*
(or even *could**, in future) exist in claws as an option.  We're
debating default behaviour, not what would clearly be a bug.  As it
is, you're just indulging in reductio ad absurdium.

> At the same time the general question of where you draw the line
> between inconvenience, bad surprise and dangerous is also part of this
> discussion. It's different for every project and depends on the project
> goals, target audience, if/who you want to compete with, etc.
>
> I guess we can agree to disagree :)

Why does the word "compete" even come up here?  Stick to goals and
target audience.

> [removed comments, I'm sorry if the discussion seemed like a waste of
> your time].

This email you just sent wasn't a waste of my time to read/respond ;-)