On 11/12/06, Simetrical Simetrical+wikitech@gmail.com wrote:
On 11/12/06, Sebastian Moleski sebmol@gmail.com wrote:
On 11/12/06, Simetrical Simetrical+wikitech@gmail.com wrote:
On 11/12/06, Brion Vibber brion@pobox.com wrote:
I've reverted r17507 and r17518 after getting massive complaints immediately after they went live in today's site update.
I'd like to ask that people please try to refrain from changing core styles like this without testing it against the actual site usage; for instance the prominent main pages of English and German Wikipedia and their site-specific CSS/JS.
We've gone through this dance enough times in the last few weeks I think we should all be able to realize that it's kind of disruptive and should be avoided.
Sorry, sorry . . . it's rather poor of me to constantly forget about custom styles when most of what I'm committing is UI stuff. Unfortunately some disruption is inevitable for this kind of stuff, which I suppose suggests it should be condensed and spaced out to the extent possible, with ample forewarning every time a batch is going to be committed. Maybe I should make a branch where this kind of potentially disruptive stuff can be committed, and then we can let stuff accumulate there for a couple of months and until we announce all the changes and merge to trunk? Does that sound like a good idea?
Changes to the layout should be proposed before they are made. They need to be tested with current wiki dumps on the largest projects so the actual effects of the changes can be determined. Once that is done, common and skin custom stylesheets can be adapted. And only after all that's done, they should be committed.
The current way of doing things is a nightmare from a customer service position because users will notice that something's wrong, some of them will ask at the VP or equivalents, and very few will even know what the problem is or what caused it. So some of those few end up running to IRC to find a developer who can help fix things by either reverting or explaining. All the while, discussion continues, often at a level quite beyond what one would expect based on the triviality of the actual issue. Then accusations are made that somebody was arbitrarily deciding "major things" without process.
Unfortunately, I'm not making this up. This actually all happened when the category trees were added and the way category pages were displayed changed. Ridiculous? Absolutely. Yet ample reason to work so it doesn't happen again.
I don't think it's a good idea to jump through hoops when adding new features. That's just silly. Clear announcement is necessary when a change will *break preexisting functionality* such as user customizations. I don't think discussion or announcement is necessary for the implementation of http://bugzilla.wikimedia.org/show_bug.cgi?id=1578, for instance.
On 11/12/06, Luiz Augusto lugusto@gmail.com wrote:
Not related to this specific change, but since some weeks ago someone changed something and now every table displayed in some namespaces in some wikis is... white.
Examples
http://pt.wikisource.org/wiki/Especial:Newpages http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost
They were like that forever until I bugged the devs to supply a patch, but that broke other things so I reverted it later. It's due to a flawed implementation of non-main-namespace coloring that many wikis have adopted, not a software issue: in Monobook the backgrounds of all namespaces are white.
Adding the following to MediaWiki:Monobook.css *should* fix it (filling in the correct color instead of #F8FCFF, which is the color used by enwiki):
table { background-color: #F8FCFF; } .ns-0 * table { background-color: white; } _______________________________________________
This brings up a dev/QA related question.
Is it possible to run multiple instances of Mediawiki all talking to the same database (table sets, etc), assuming that the db formats haven't changed between the Mediawiki versions used in those instances?
What I'm thinking is that a beta.en.wikipedia.org instance wouldn't be so bad, if it had the same data on the back end.