Message: 6 Date: Tue, 4 May 2004 07:41:09 -0700 From: evan@wikitravel.org Subject: [Wikipedia-l] Information To: wikipedia-l@Wikimedia.org Message-ID: 20040504144109.GA10352@pigdog.org Content-Type: text/plain; charset=us-ascii
Anthere said:
- When a soft improvement is done to fit legal
requirements, please, could it be discussed on foundation-l to check if that complies with the legal requirements ?
I'm wondering if you're still obliquely talking about the contributors list. I'd love to hear that you read and understood my response to your questions.
I have understood your explanations Evan. Well, I hope I did :-)
I understood I think that your features were currently on wikimedia 1.3 (not yet released, and time of release not known). I understood there were meant to provide a mean to comply with gfdl (or Wikitravel license) requirements, which requires this contributors list; This is good. I understood adding a real name field is meant to provide possibility to some editors, to have credit (for their edition on articles), while keeping a little bit more of privacy as participants (pseudo displayed). I understood you developed these thinking a lot of Wikitravel, and that these are disabled for Wikipedia right now.
Here are my feelings on these two features themselves :
I personally do not think adding a "real name" field is a very good idea for Wikipedia; I do feel that if people want public recognition, then, they should register under their real name. If they prefer to sign comments under a pseudonyme, then, they can have a nickname; This already exist. This said, I understand your opinion, which is to say that people might want public recognition, but not want to work on wikipedia under their real name. It just seems a bit unefficient to me, that we have * one field for real name * one field for pseudo name (which may be real or not real) * one field for nick name (which may be real or not real) But if people want that, and feel it is great to have this real name field on Wikipedia, then there is no reason why your work should stay only on Wikitravel and not be benefiting on Wikipedia. I do not want to undermine your efforts here, it is great that people improve the mediawiki ;-) But the fact is, we currently do not know if people would like it or not...
Perhaps, one thing that I heard may be problematic, is simply that "real name" is basically any name you put here. There is no control whatsoever of what our identity is. That means that adding this real name thing is also a door to a sort of sneaky vandalism. I am not sure I understood this well, so please tell me if I am wrong here. See, if a bad user add your real name to his preference pages, he will do bad edits, which will appear under your name; If these are not easily trackable, this user could spoil a lot of articles, but making bad edits, which will then appear to be your edits (edits under your real name). We could then get credit for really bad moves. While if tomorrow, a user appears under your real name, you might see it quite quickly, and perhaps you could do something about it.
If we use such a feature, in the clear objective to give credit to people, then we must 1) have a way to change this attribute (ie, to edit the attribution page) 2) easy way to track this (ie, the credit given to a real name should for example be visible in recent changes)
I am not sure you understand what I mean. Just tell me if not.
The second point is about the list of contributors appearing in the article page. It is not obvious wikipedians would agree with this, as someone mentionned, they never asked for this. Still, we need (perhaps) a way to have a list of contributors (expecially for printed versions). For this reason, your feature is very likely useful. I know not if the current proposition is best, but it is probably better than nothing. Hence, I think it important to be discussed. Again, I do not want to undermine your efforts here, I do believe this is an important legal point, and it is really nice that someone works on it. It is just that I regret this is not adverstised more widely.
I agree that it's a good idea for there to be more communication between the Wikimedia community and the volunteer developers. I think there are a lot of areas that could be improved -- streamlining the way bug reports and feature requests work is one of them.
I agree with all what you are saying Evan. Though I understand very little of technical things, I have to follow loosely wikitech, or sometimes hang around mediawiki just to know what is going on; I deeply regret this. Because as I can't understand details, I would prefer just one lign formula of what is going on. Something I could quickly understand. Just sometimes to know that good people are taking care of something, and one line to say what is going on, is enough for happiness. One line, and a link to the relevant place is usually enough. If the person is interested, he can follow the link for more.
---------
Example (I try to be practical here). When a down time is planned for technical reasons, what we saw recently is appearing usually at the last minute "servers will be down in a few minutes"
* setting up a feature that allow this little red message appearing on wikipedia to be in the current language and not english per default (If necessary, we can set a collection of preformated messages, so that the little messages on top may be automatically translated very quickly)
* instead of writing "will be down in a few minutes", writing something a bit more specific ** starting down time expected between 19h and 20h UTC (I guess everyone knows it may be fluttery, but it is more precise than "in a few minutes") ** expected down time for technical update : 5 hours (we also know that it may last longer if things go bad, but saying expectation is around 30 mn compared to expectation is around 5 hours IS information and IS important. If expected time is 5 hours, people do not hang around bugging developers to know more, they just go to the restaurant instead) ** indicate the reason why the servers are down (simply, just say, installing new "this") ** put this message several hours before hand, 12 hours for example.
There is no need to go in length and to be very specific, just warning people before, and giving them a bit of info will show you care, will keep them reassured, and will avoid that they come messing the mediawiki channel :-))))
-----------------------
Recently, I looked at the bug report on fr:, and I saw an awful mess, that was going up to october 2002, where we were switched to phase III. There was no way to know what was still valid, and what was not (it has been cleaned now). Similarly, I have little idea what is on mediawiki1.3. Most of the time, it does not matter; we just know you all do the best, and likely it is the best. And best that everyone takes care of what he can understand, and not of what he can not understand. Still....yup...more communication would be real nice.
Is there somewhere a page listing what is currently planned on mediawiki1.3 so that I can add the link to goings-on on meta ?
Having a community leader like yourself take the initiative to make this work well would be a great help to everyone.
hum, perhaps. But I know so little of technical things, that I really cannot help here. It is also up to you guys to use the channels that we try to outline. Most of the time, when you report an information, it has no feedback whatsoever, but once in a while, it has. So, it is worth doing it. But people should try to make effort to report information they have. Please.
I'd also like to say that I feel comfortable right now adding features or fixing bugs in MediaWiki that may or may not be useful for Wikimedia projects. There's an awful lot of code in MediaWiki that's not enabled for Wikipedia. I've tried to make a point of:
- Noting these changes on tech lists and marking them as non-Wikimedia
ones. 2) Making them disabled by default. If you think there's a problem with having features in MediaWiki that are disabled for Wikimedia projects, that's a development direction issue that should probably be discussed. I'd be somewhat unhappy doing a private fork of MediaWiki, since I'd like to give back any improvements to the code as a thank you to the Wikimedia community. But of course I'd be happy to make the effort if that was what the community wanted.
I think most people would find a mediawiki fork very unfortunate. Those working on improvements are precious; it is perhaps not good to divide efforts. Anyway, that is up to the team to say what would be best. I have myself no idea how much of the code is for Wikipedia, and how much for other projects. What I mean is that if you announce it on wikitech, then it is probable that it is also meant potentially for Wikipedia; And if it is potentially for Wikipedia, we must find a way for people to know about it, and say "yes, right, we need that" or "no, not at all" or "why not if we change this...".
What I mostly mean to say Evan, is that you did nothing wrong, quite the opposite. You did good things for Wikitravel, and potentially interesting things for Wikipedia. That is all. I do not entirely agree with them, no big deal. What I am bugged with, is that feeling that there are higher barriers to information flow than before. That is logical, we are more numerous, bigger, people may focus more and more on a limited number of fields, and have less and less chance to catch up by chance a discussion on a specific issue. What is bad is that that may lead to a feeling of frustration, when decisions are taken, or features implemented, that someone has never ever heard about. That is not a transparent process. Would have they known, these people might have said nothing at all (silence might mean they do not care, or silence mean they just agree), but they would have chosen not to say anything.
Now, is there a page reporting what is going on on mediawiki 1.3 for example ? * minor fixes * major fixes * and *mostly* features
----
personal warning red line
Personal downtime starting today Duration expectation : a few days Reason : my computer is basically RIP. I am paralyzed at the idea of trying to save all its content, reinstalling system, defragmenting, reinstalling software, fixing updates, prefs, extensions, putting back net connection specifs and co :-(
Anthere
--------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs
Anthere wrote:
- setting up a feature that allow this little red message appearing on
wikipedia to be in the current language and not english per default (If necessary, we can set a collection of preformated messages, so that the little messages on top may be automatically translated very quickly)
Yes, agreed! Please collect translations here for the moment: http://meta.wikipedia.org/wiki/Server_outage_message
Suggestions for other messages to add are welcome there.
Now, is there a page reporting what is going on on mediawiki 1.3 for example ?
- minor fixes
- major fixes
- and *mostly* features
http://meta.wikipedia.org/wiki/MediaWiki_roadmap and http://test.wikipedia.org/wiki/Main_Page
-- brion vibber (brion @ pobox.com)
Anthere-
first, a note: please use foundation-l for project wide discussions.
I personally do not think adding a "real name" field
I also think it is unnecessary, especially in light of the fact that many thousands of edits are merely assigned to numbers.
Mostly I want to keep the sign-up form as simple as possible. But I have no problem with Wikitravel activating it. Of course we must be wary of "feature clutter".
- instead of writing "will be down in a few minutes", writing something a
bit more specific
That's of course desirable, but oftentimes specifics will not be available, and sometimes shit happens without anyone expecting it. We seem to be particularly unlucky when it comes to server stability.
However, it will be difficult to have both - informative *and* internationalized messages. Because I don't think we can get someone to translate "There are problems with the Squid proxy server on coronelli, a new machine is being set up and will hopefully be installed by 20:00 UTC; in the meantime, cached pages will remain available" into Maori within 5 minutes (just making up an example, don't know what the actual problem was today).
Recently, I looked at the bug report on fr:, and I saw an awful mess, that was going up to october 2002, where we were switched to phase III. There was no way to know what was still valid, and what was not (it has been cleaned now).
Not sure what you mean here, bugs are managed using the SourceForge bug tracker and closed when fixed.
Regards,
Erik
--- Erik Moeller erik_moeller@gmx.de wrote:
Anthere-
first, a note: please use foundation-l for project wide discussions.
This is exactly what I said very recently. Till recently, wikipedia-l was the list to discuss project wide discussion. Now, we are beginning to cross post, because we do not see where this discussion is supposed to take place.
Typically, discussion over list of contributors, is related to gfdl, so should go to foundation, while discussion over a message to display during down time is rather wikitech or wikipedia-l.
In short, Erik, the difference between wikipedia-l and foundation-l is now difficult to define. Either we define it much better, or we should just remove a list.
- instead of writing "will be down in a few
minutes", writing something a
bit more specific
That's of course desirable, but oftentimes specifics will not be available, and sometimes shit happens without anyone expecting it. We seem to be particularly unlucky when it comes to server stability.
Obviously, this is not for urgent situation.
However, it will be difficult to have both - informative *and* internationalized messages. Because I don't think we can get someone to translate "There are problems with the Squid proxy server on coronelli, a new machine is being set up and will hopefully be installed by 20:00 UTC; in the meantime, cached pages will remain available" into Maori within 5 minutes (just making up an example, don't know what the actual problem was today).
Nod. Perhaps between this type of message and short information, there can be a middle ? Perhaps part of the message could be language specific and part in english ? Not everyone speaks english.
Recently, I looked at the bug report on fr:, and I
saw an awful mess, that
was going up to october 2002, where we were
switched to phase III. There was
no way to know what was still valid, and what was
not (it has been cleaned
now).
Not sure what you mean here, bugs are managed using the SourceForge bug tracker and closed when fixed.
Simple. Users who report bugs, do it on the pump. Soon enough the pump is clogged; Only a couple of people do make the effort to try to clean it up. Now, there is a bug report page on each wikipedia. So, it would be nice if users reported bugs on the bug report page, instead of the pump. So, we sent them to the bug report page. And there, all they could see is a 70 ko page, with first messages 18 months old, and absolutely no idea whether the problems reported has been fixed or not; And the place was actually so clogged, that they report bugs that are already reported. That is a loss of time. I am wondering if that bug report page is very wise, and if we should not just redirect it simply to SourceForge.
__________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover
Anthere wrote in part:
Erik Moeller wrote:
first, a note: please use foundation-l for project wide discussions.
This is exactly what I said very recently. Till recently, wikipedia-l was the list to discuss project wide discussion. Now, we are beginning to cross post, because we do not see where this discussion is supposed to take place.
Typically, discussion over list of contributors, is related to gfdl, so should go to foundation, while discussion over a message to display during down time is rather wikitech or wikipedia-l.
In short, Erik, the difference between wikipedia-l and foundation-l is now difficult to define. Either we define it much better, or we should just remove a list.
Arguably, <wikipedia-L> should only be for issues that relate to the Wikipedia encyclopaedia projects, while anything that equally affects Wiktionary, Wikisource, etc sould go to <foundation-L> instead.
OTOH, what I thought was the purpose of <foundation-L> is to discuss matters related to the Wikimedia Foundation, while anything about the Wikimedia projects themselves would go to <wikipedia-L> as before.
Now, we could create a /new/ list <wikimedia-L> (with an "m"). Then people posting to <wikipedia-L> could be told "Hey, this affects Wiktionary too! Take it to <wikimedia-L>.", while people posting to <wikimedia-L> could be told "Hey, this is only about Wikipedia! Take it to <wikipedia-L>.". And people posting to <foundation-L> could be told "Hey, this is about the project content, not Foundation management! Take it to <wikimedia-L>.", while people posting to <wikimedia-L> could be told "Hey, this requires official action by the Foundation! Take it to <foundation-L>.".
What fun that would be! ^_^
-- Toby
On Wed, 5 May 2004 11:41:49 -0700, Toby Bartels toby+wikipedia@math.ucr.edu wrote:
Now, we could create a /new/ list <wikimedia-L> (with an "m"). Then people posting to <wikipedia-L> could be told "Hey, this affects Wiktionary too! Take it to <wikimedia-L>.", while people posting to <wikimedia-L> could be told "Hey, this is only about Wikipedia! Take it to <wikipedia-L>.". And people posting to <foundation-L> could be told "Hey, this is about the project content, not Foundation management! Take it to <wikimedia-L>.", while people posting to <wikimedia-L> could be told "Hey, this requires official action by the Foundation! Take it to <foundation-L>.".
What fun that would be! ^_^ -- Toby
Since we're using MailMan, don't we have some special options for predefined topics filters somewhere? You could merge everything into one list and rely on those to tag different iteme.
wikipedia-l@lists.wikimedia.org