Let me address my concerns step by step, as you obviously still don't grasp
what the major issue is.
Brandon wrote:
>
> Here's what happened:
>
> * I was asked to look at the bug as part of my 20% code review.
> * I applied Erwin's patch (manually) and then played with changing
> colors around to see what worked and what didn't.
> * I tested everything in various color-blindness tools.
> * I came to the conclusion that we could ONLY use yellow and blue because:
> - Orange and blue vibrated next to each other.
> - Yellow and purple vibrated next to each other.
> - The use of green or red in any combination was not going to work
> for a jillion reasons
> - Blue and Purple turned into the same color with colorblindness
> filters on.
> - Ergo, Yellow and Blue, with orange-ish highlights.
Why didn't you test the original blue/green? What were your findings on
that? You should have applied the colors as present in the patch, as these
were the colors agreen upon in the original commit, which were blue for
deleted content, and green for added content. Those had been tested by
various users, both color-blind and not.
> The yellow is *unchanged*
Which is the first issue I raised as a response to your commit; Noting wrong
with yellow per se, but the OLD yellow completely clashes with the NEW blue
that was originally intended and taken from the French colors. The yellow
completely overpowered the blue, as the hue and brighness levels are totally
incompatible. David Levy concurred with that assesment.
Does the "designer" in your sig denote any connection in graphic design? I
suspect not, as your choice in the combination of the yellow and blue
*combined* breaks just about any rules in web design. THAT is what I have
been trying to convey; NOT that yellow is wrong, but that is is the WRONG
yellow.
> The blue is basically Erwin's blue except I might have tapped it
> around a bit to bump up contrast in certain places; I don't remember
> exactly.
>
> So. What was *supposed* to be a 15 minute task has now turned into a
> drama - over something I don't really care that much about anyways.
You have yourself to blame for that. If you don't care that much, why are
you forcing your commit and subsequently try to stifle any follow-up
discussion by re-closing the bug report? We actually had a fruitfull
discussion before you came along. I even changed my patch to incorporate the
yellow you introduced.
> This was an open bug. I was asked to address it. I did. That's the end
> of the story.
You were asked to REVIEW my patch, not to make unilateral changes and then
ignore any criticism on your changes might generate. If this were an edit in
Wikipedia's Common.css, you would have been reverted in a heartbeat.
To see what I'm talking about, have a look at
https://www.mediawiki.org/wiki/File:R106884-diff.png. The top line shows the
original proposed colors, the bottom line is Brandon's patch currently in
trunk. The ones in between are my versions based on Brandon's patch, after
taking several users' comments into account.
The only thing I care about is that the best code ends up in MediaWiki, and
not code that every project would want to override as soon as it is
deployed. Now, what I would simply like is for everyone just to look at the
colors and say which one they like best. That's all...
--
Erwin Dokter
Just gave Oren Bochman (User:OrenBochman, commitname oren) extensions
access. He expects to work on the Lucene-search extension, adding
morphology support for search in different languages, and dumpHtml bugs.
Welcome, Oren!
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Thanks for your reply, Antoine.
Antoine Musso wrote:
>
> I have looked at your patch this afternoon. Your colors are not that
> much different from Brandon one. It is clearly not worth it to spend
> hours and hours in discussion just to add 1% of red in a yellow color
> or 0.5% of green in the blue color.
I wish they were that minor, I would not have peeped, but the difference is
quite big; My blue and yellow have saturation levels of 31 and 41
repectively, Brandon's yellow has 85... That's more then double. Perhaps
because I am blessed (or cursed) of having a calibrated Trinitron CRT
monitor in front of me, that will painfully expose any flaws in colors and
levels. Amidst the masses of cheap LCDs, this can be a pain.
> Please note any project can alter those colors locally. What I really
> wanted was to get reasonably sane default for fresh MediaWiki install.
So do I, that's why I'm trying to get this done properly. I don't consider
these values 'sane'. And this is in no way criticism on Brandon as a person,
but I admit I was a bit miffed at his subsequent behaviour at trying to
close the issue.
> Note: revisions are not definitives. We can always amend them later on.
Until 1.19 is suddenly branched off... game over. Is there an expected
timeframe or announcement for when this might happen?
--
Erwin Dokter
On Thu, Dec 22, 2011 at 11:04 AM, Chad <innocentkiller(a)gmail.com> wrote:
> I highly doubt we'll get guaranteed backlash over
> such a minor shift in diff colors.
Heh....ha ha ha ha....(*uncontrollable laughter*)
Sorry, we will, but not because we should. Pretty much any design
change anyone makes runs a substantial risk of endless bikeshedding.
While there are only a handful of people that care about the
difference between database query strategies or parameter ordering in
functions, pretty much everyone who interacts with the product will
have an opinion about what it will look like. The colors, the
ordering of the layout, the whole bit.
Calling it a bikeshed argument probably diminishes the importance of
it a bit too much. The colors are important. What the user interface
looks like matters a great deal.
The question, though, is what is the best way of dealing with user
interface design issues? Many of us know that as non-designers, while
we may have opinions on these things, they probably don't matter.[1]
To make matters worse, there are going to be a lot of things that are
truly a matter of taste. So, someone is going to need to make the
call, because there's no way to arrive at "The Truth". We can do what
most open source projects have done all along, which is to leave it up
to the last developer that touches the code. That's a fine way of
guaranteeing that what we end up with is going to be a hodge-podge of
a lot of really bad stuff, combined with a few things that would be
good if they were applied consistently and we committed to that
particular direction. However, those good things won't be so good
since they won't be applied consistently, since it'll be the taste of
whoever happens to be around that will be applied.
No one has declared Brandon the dictator of these things, nor has
anyone declared that we're throwing consensus out the window.
However, it's hard to imagine Brandon being able to do anything other
than this type of conversation if every decision he makes needs to be
justified and discussed to the level that this diff color discussion
happened. Furthermore, Brandon ends up dealing with the consequences
for design decisions that he isn't consulted on, which is why we need
to make sure that we consult him, and be prepared to go along even if
we disagree. The "right" answer is often the most consistent answer,
and our odds of achieving consistency go up if we defer to one person
for issues that are matters of taste.
There's a few other issues tagged "design" in code review, and there
are likely to be more:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/design
Brandon is going to be weighing in on those as well, possibly making
changes in the code based on his opinions on those. Can we please, oh
please, not spin up a monster debate about each of those others?
Please?
Thanks
Rob
[1] http://www.codinghorror.com/blog/2006/11/this-is-what-happens-when-you-let-…
I'd like to ask for more eyes and participation in an issue that is in an
apparent stalemate.
It all started with revision 105280
(https://www.mediawiki.org/wiki/Special:Code/MediaWiki/105280), where
Hashdar commited a new color scheme for diffs based on the French scheme.
When this generated some flack for making "green the remove-color", I
submitted a patch that reversed the colors
(https://bugzilla.wikimedia.org/show_bug.cgi?id=33139). This was met with
general approval.
Before it could be applied though, Brandon steps in with another patch
(https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106884) that mixed
the old yellow with the new blue, that looks absolutely horrible; a view in
which I am not alone. I immediately submitted a new patch that adjusted the
colors and levels, which is now under discussion.
However, today Hashdar closed my bug/patch as Resolved, as he considers the
matter closed. As the matter is clearly not, I reopened it. Now I would like
to invite as many devs as possible to chime in at r106884 (3rd link) to
evaluate the various options. Because if the current revision stands, and
subsequently makes in into MediaWiki, we will have a default diff color
scheme that will generate a guaranteed backlash form any project that uses
MediaWiki.
I'm not one to complain fast, but I now understand why develpers without
commit access just turn around and walk away; if submittd patches that have
approval are summarily overruled by those with commit access, there is
really no point in continueing to submit patches.
--
Erwin Dokter
Hello,
Last summer, Timo installed a JavaScript testing system on the toolserver.
This system let us easily run our JavaScript tests on a subset of browsers
with close to no human interaction. It saves up a lot of time.
We have reinstalled the system from scratch to one of the WMF server, and
you can point you browser at the following URL to start executing tests:
http://integration.mediawiki.org/testswarm/
The dashboard is at:
http://integration.mediawiki.org/testswarm/user/MediaWiki/
Each line is a MediaWiki (trunk) revision. Each column a browser.
For each combinaison, the cell is colored in:
- gray : no test run yet, not all tests run
- green : all tests successful
- red : at least one test failed! Revision is broken :)
When clicking on the left revision, you will obtain the test results
for each module. The tests results are saved there so you can look
at the diff and eventually rerun them.
--
Antoine "hashar" Musso
Brandon Harris wrote:
>
> It's the exact same yellow as before, guys. The *exact* shade.
>
> This is the exact definition of a "bikeshed" argument. Feel free to
> move along.
But that is exactly the problem; you left in the *old* yellow against a much
mellower blue. If that blue was as bright as the old green, it would be much
less of a problem. I don't know how expert you are in CSS and web colors,
but there should really have been more attention to matching all colors
used. In this case, it was a rush job wich resulted in mismatched colors.
And again, I am not alone in this assesment; you patch did not generate a
single approving comment, whereas my proposal did several.
But every time I try to raise the issue, you or Hashdar are just
unilaterally closing any ongoing discussion; I do not expect this behaviour
from developers. You are forcing your bad patch against consensus, plain and
simple. No bikeshedding here.
--
Erwin Dokter
Ryan wrote:
> What was the purpose of changing colors? Aesthetics? If yes, this is
> bikeshedding. If there isn't a really good reason to change the
> colors, don't. If you are changing the colors so that they are more
> accessible for color blind users, for instance, then this is a
> legitimate change.
>
> If your wiki has decided they want to bikeshed the colors, then your
> community can make consensus and change the colors in your wiki's CSS.
> The software is used by third parties. On-wiki consensus doesn't apply
> for a change that will modify the color for all users of the software.
The reason for the initial change is indeed to increase accesability. And
the discussion I refer to was *not* in Wikipedia, but in the comment section
of the commits in question. We had a very nice scheme ready for commit, when
Brandon came in and simply ignored everything.
But... I have now submitted a new bug report (33335) with patch that
outlines any change in detail. So the old discussion is moot as far as I am
concerned. Please review and comment there.
--
Erwin Dokter
Hey,
Is there some comprehensive documentation on how to log events (such as
edits, uploads, ect)? I found some logging related classes such as LogPage,
but no documentation that tells me what kind of things are supposed to be
possible with all this code. I'm looking into how to create some logging
thing for setting changes, and do not want to end up duplicating already
existing things that I could perfectly well use (even though I suspect I
might not be able to re-use it at all since this new stuff needs to keep
into account permissions and is not article-centric).
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
As you probably know if you have to deal with the US or Europe at all,
we're approaching a traditional holiday season. Guillaume Paumier, Mark
Hershberger, Rob Lanphier, many developers, and I will be taking some
time off towards the end of the month and into the new year, so we'll be
far less available and responsive between 24 December and 3 January.
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
