emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Let's stick to one list for now


From: Jeff Horn
Subject: Re: [O] Let's stick to one list for now
Date: Mon, 28 Feb 2011 15:23:19 -0500

On Mon, Feb 28, 2011 at 12:53 PM, Dan Davison <address@hidden> wrote:
> Julien Danjou <address@hidden> writes:
>
>> On Mon, Feb 28 2011, Bastien wrote:
>>
>> The point is that there's no gain in telling people to add "[DEV]" since
>> they will forget (I will), and there is _no_ lose by splitting a list. I
>
> Hi Julien,
>
> No, I disagree with that. The two lists would have distinct compositions of 
> the
> reader audience and that does have downsides. For example,

I would also like to re-emphasize my disagreement with Julien's
opinion. There is something to lose by splitting the list, as I
mentioned in the main thread: the mixture was entirely useful for me,
and *quite* pedagogical. I think the readership would be asymmetric in
the case of a split list. Research in behavioral economics suggests
people should be given sane defaults to prevent a harmful status quo
bias. I don't think most users ever attempt to read devel lists.

I'd also like to register a theory as to why users don't read devel
lists, and why this works for some other software: devs condescend to
handle user issues. Most open source software is created by people who
need the tool for personal use. They aren't necessarily interested in
your corner cases. For org-mode, this isn't the case; I've never felt
anything but welcomed by the people who usually develop. A split list
might also hurt this natural connection devs have with org-mode users.

Relationships are *especially* important where there aren't market
forces (read: price) to discipline developers into listening to users
demands. That's the truth about any platform (two-sided) market with a
zero price.

This may sound admittedly contrived, and a bit pumped up in regard to
the size of the effect. But there is a difference between small,
noticeable, and highly personal changes and a "_no_ lose" scenario.
Top-down policies have to be made with these small effects in mind,
with an eye toward unintended consequences of a change.

(Strawman alert. Begging Julien's pardon...)

"But," Julien might say, "my concerns count just as much as yours, and
I don't really like managing all this user mail." That is true. But
you are a power user and have many tools at your disposal to automate
mail handling. There is a relatively easy end solution. A top-down
change messes with the community ecosystem. Future users' concerns
should count for something, even if not a full measure.

-- 
Jeffrey Horn
http://www.failuretorefrain.com/jeff/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]