[Foundation-l] hiding interlanguage links by default is a Bad Idea, part 2

Aryeh Gregor Simetrical+wikilist at gmail.com
Tue Jun 8 19:17:05 UTC 2010


On Mon, Jun 7, 2010 at 3:15 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> Unfortunately, we're still
> able to speak about the community and the UX teams as distinct
> entities.  This division will continue so long as the relationship is
> viewed in the context of "decision"/"feedback" rather than as a
> dialogue between peers.
>
> . . .
>
> This isn't how our communities usually work in any case.
>
> Bold. Revert. Discuss.  is a common modality.
>
> I think that the group assembled here would largely agree that it
> would have been acceptable for the UX team to make the change— even
> with little to no public discussion, then not interfere with the
> community to reverting it when non-trivial objections were raised,
> then engage in a discussion about the ultimate disposition of the
> feature.
>
> This pattern allows a significant majority of changes to happen
> without significant conflict and without the impediment of excessive
> discussion.
>
> . . .
>
> I think it's remarkable that we've given people the authority to make
> changes who still find our process surprising or remarkable.

I emphatically agree with all of the above.

On Mon, Jun 7, 2010 at 6:31 PM, David Levy <lifeisunfair at gmail.com> wrote:
> Agreed.  So why are you dismissing people's arguments on the basis
> that they stem from such judgement (while simultaneously passing
> similar judgement of your own)?  You can't have it both ways.

I am not.  It would be perfectly fine if objections to the change
stemmed from judgment, provided the judgment was sound.  In some cases
(not all), I don't think it was.  I provided arguments for why I
thought the result of my own judgment was better.

To make an analogy to a more clear-cut case, suppose someone proposes
a database schema change to fix a particular bug.  Suppose Domas says
"that wouldn't give acceptable performance".  That one statement of
Domas, with no further support, would outweigh quite a lot of
countervailing evidence and argument, although not a limitless amount.
 As soon as he says that, the burden of evidence falls very strongly
on anyone who disagrees.  Why?  Because Domas has worked
professionally as a MySQL database engineer for years, and has proven
by his actions as a community member that his expertise in that field
is sound.  His judgment outweighs other people's, because he's simply
more qualified.

Now, let me point out two key differences between that case and this:

1) Domas has a track record of years of contributions in this field
within the community, and his expertise is well known to anyone who's
familiar with MediaWiki development.  He has built a deserved
reputation within the community.  The usability team might be expert
in usability, but typical community members can't tell, because its
operations and evidence are mostly hidden in practice.  (Maybe they're
posted somewhere, but nobody sees them.)  As such, the community will
rightfully demand better explanations when it's overruled by the
usability team than by Domas.

2) If a lot of people objected, some kind of clear-cut explanation for
Domas' decision would be given.  He might not give details to people
who asked him stupid questions, but some other developers would ask
him more intelligent questions if they didn't understand, and he'd
answer them.  Everyone qualified to understand the issue in the first
place would be able to get a fairly good explanation in the end.  As a
result, the community would be more informed and would better
understand future decisions, and their respect for Domas would
increase.  In this case, we ended up with no good explanations from
the usability team, so no one came out any wiser, and the community
has not gained any further respect for the usability team's expertise.

I don't mean to imply that my judgment here (or anyone's) counts
nearly as much as Domas' judgment on MySQL issues.  My point with this
analogy is to show that in some cases, it's totally legitimate for
someone to pass judgment while rejecting other people's judgment --
this objection of yours is not valid by itself.

> It's entirely reasonable to vigorously disagree with others'
> arguments, of course.  But when the rationale is "they are not backed
> by data," it's unreasonable to exempt the user experience team and
> yourself from this standard.

Compare to the analogy I gave above to Domas.  If Domas says something
about the DB, then yes, his judgment overrules almost anyone else
unless they have data or other strong evidence.  Not everyone's
judgment counts the same.  (But in this case, the usability team
should be justifying its judgment explicitly and at length, so that
the community comes to respect its judgment.)

> As previously noted, perceived clutter draws complaints.

I cannot think of any time when I've seen someone propose that
MediaWiki interface elements be removed unless they're patently
useless, except for a few developers who occasionally go out of their
way to cut down on clutter.  If there have been any, they were
probably right after the clutter was added, so people complained
mostly because it changed and gave clutter as a justification.

> Of course not.  But for reasons explained throughout the discussion,
> many of us regard this feature as immensely important and feel that it
> should not be demoted in the absence of data indicating that the
> change is beneficial.

I agree with the "be bold, revert, discuss" methodology that's being
employed now.  However, I don't think that data in favor of a change
should be an absolute requirement in the face of objections (even
strong ones), unless there's data against the change.  (Which there
isn't really here.)  The judgment of sufficiently trusted parties is a
legitimate substitute for data.  Obviously the community does not view
the usability team as sufficiently trusted in this case, and that's
fine, but I want to be clear about the general principles.




More information about the wikimedia-l mailing list