[Sugar-devel] RFC: Kill the delayed menus for good

[Tomeu Vizoso]

On Thu, Oct 15, 2009 at 03:49, Michael Stone <michael at laptop.org> wrote:
> Tomeu wrote:
>>
>> On Wed, Oct 14, 2009 at 16:57, Michael Stone <michael at laptop.org> wrote:
>>>
>>> Tomeu wrote:
>>>
>>>> I'm more concerned about developers proposing big user experience
>>>> changes because they feel it's better.
>>>
>>> Yay, more roadblocks and stereotyping! :)
>>
>> You shouldn't take this personal, most of Sugar contributors including
>> me have done this in the past.
>
> <humor>I don't take it personally; I take it on behalf of oppressed
> contributors everywhere...!</humor>
> (In other words, judging the patch by its author rather than by its text
> and its effects does seem to me to be a rather risky business. Your
> choice, though.)

If you insist on thinking that I have something against you, then I
will stop having this discussion with you. I'm really tired of you
continuously bringing this as a problem but not hearing anyone else
caring about your troubles contributing.

I stand by what I said: substantial user experience changes will be
considered only after discussion involving the design and deployment
teams (which we are having now). This is not just for you but for
anybody else that proposes patches for the modules that I maintain.

Try going to a GNOME or KDE module and proposing that they accept such
a patch so people can test it, they are going to laugh at your face.

Maintenance is already a hard enough task, if the community thinks
that a maintainer should also be accepting all patches, releasing
them, packaging them, making soas spins, asking for feedback,
reverting them, etc. Then I will be glad to pass maintenance to
whoever is available to do these kinds of things.

Regards,

Tomeu

>> I'm just saying that now might not be such a good idea any more to
>> accept changes in the user experience without user feedback.
>
> Far better to accept the changes, get the user feedback on the changed
> versions, then revert the changes if they turn out to be inappropriate.
> Everyone will be happier. (That's my opinion, anyway.)
>
>>>  Are you actually saying that you'd prefer either
>>>
>>>  a) no patches or,
>>>  b) patches that I think make the system worse?
>>
>> Yup, this is certainly absurd.
>
> I'm glad that we agree.
>
>> If, say, Gary comes later and proposes a patch to revert yours, should
>> I accept it in fear that I may discourage him otherwise?
>
> Yes, but in awareness rather than in fear, (though only unless you have
> an overriding reason not to.)
>
> Being "concerned about developers proposing big user experience changes"
> does not seem to me to meet that criterion. To my mind, "overriding
> reasons not to" include "the patch is..."
>
>  * incorrect
>  * illegal
>  * an obviously bad idea
>  * a subtly bad idea
>  * more trouble than it's worth
>
> At best, it has been argued so far that merging the patch I showed to
> Bernie is a subtly bad idea because it leaves the obvious possible of
> refactoring of the context menu code to remove the use of the animation
> code unimplemented.
>
> In the middle, Eben expressed uncertainty on the basis of a specific
> vision and private memories. This shouldn't impede merging the patch; it
> should just encourage more testing and thought based on his experiences,
> vision, and thought experiment so that we get more data.
>
> At worst, it has been argued that merging the patch is an obviously bad
> idea because it was developed by a developer (me; who else was supposed
> to develop it?) engaged in critical dialogue with and reflection on the
> Sugar user experience (I do feel that it's better) via methods that I
> find congenial as opposed to by methods that I find prohibitively
> expensive.
> Did I miss any other positions in the debate?
>
>> C'mon, I'm just asking that when substantial changes to the user
>> experience are proposed, that we have some discussion that involves
>> the design team and the deployments. Is this really so off?
>
> I'd call it more "timid" than "off". Or at least "inappropriately
> deferential to the wishes of the design team and the deployments who
> talk to you at the expense of receiving more contribution by making
> contribution more dynamic and fulfilling and therefore at the expense of
> exploring more possible Sugar experiences".
>
>>>> Before I look at the patch I would like to know if there's agreement
>>>> from people close to our users that this behavior change is desired.
>>>> How can we get that?
>>>
>>> Well, trying it might be one good way to start. :)
>>>
>>> After that, shipping it in an explicit beta is another more heavyweight
>>> but nevertheless time-tested approach.
>>
>> You know how easy is making a spin of SoaS with such changes for
>> people to try out, or are you saying that you want me to do this work
>> for you?
>
> I'm saying three things; namely, that:
>
>  1. I trust that you and the other people on this list are empowered
>     and able to make reasonable UI decisions when presented with clear
>     alternatives,
>
>  2. Patches are an appropriate way of exchanging proposals for software
>     modification and a good medium for discussion of those proposals, and
>
>  3. Applying a 6-line patch to a jhbuild root, to a Sugar chroot
>     produced with my scripts, or to a live Sugar install is a hell
>     of a lot easier (and more valuable to know how to do) than my
>     cooking up a SoaS image just for interested people to try out said
>     patch.
>  (For the record, I'm more sympathetic to the SoaS argument with rainbow
> stuff but the rainbowish work that I'm doing at the moment lies in the
> area of network isolation and community-building [c.f. my new playground
> at sandboxing.org] rather than in Sugar integration.)
>
>>> Now, as for what "better" look like: ...
>>
>> I'm having trouble getting your proposal, maybe some mockups would help.
>
> A fair request, but one that is probably doomed to wait until someone
> with graphics and/or animation skills comes along to help me transform
> my words into pictures and movies.
> (Interested folks should please contact me; I'd be very happy to work
> with you on obtaining such visual materials.)
>
> Regards,
>
> Michael
>
> P.S. - For even more humor, count how many words have gone into this
> thread so far in comparison to the number of words in the patch!
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning