There have been some concerns about disk IO levels caused by Apache
logging. Although I haven't seen any evidence that there is a real
problem, I've gone ahead and enabled the apache BufferedLogs flag.
Buffered logs causes apache to buffer up log entries a bit and write
them in bursts rather than one at a time. This may decrease disk
usage, or it may do nothing. It should not cause harm, but it might be
a little confusing to someone trying to watch the logs in real time.
Thanks.
If there is the rule not to ask for user account data, of course
I'm going to follow that, even if i might mean that one of my
planned tools canot be hosted on toolserver.
This is my current state of thought:
(1) [Historic facts. Skip if in hurry] When we made the transit
from the Ripuarian Test Wikipdia on http://dergruenepunk.de/ to
the wWikimedia Server cluster, we had to transfer user accounts,
including credits for edits.
I created a little tool, that asked for user name and password on
BOTH servers, tried to simultanously login on both of them, and,
if sucessfull, noted only the two user names on each server as
being owned by the same person.
I hated the idea of having to ask for passwords. I had the tool
on https capable server though, so they were fairly save, and of
course never stored anywhere but in memory or http requests.
I have no idea, how the identity of the users could have been
established otherwise - assuming that hashed and seeded passwords
could not be copied from one server to another, leaving alone the
fact, that none of the admins had the necessary access privileges
to do that.
(2) I am planning a tool to 'bulk' insert redirects for spelling
variants, such as /colou?r/ i.e. /(color|colour)/ or slightly more
complicated ones. ;-) There are way more than 100 dialects in the
Ripuarian Wikipedia, and currently the only way to handle their
variations is by sets of redirects.
I was planning to grant registered users access to the tool, and
have the tool insert redirects in their names, so as to establish
proper credit for the work, and possibly trace troll activity,
respecively allow admins and experienced users to individually
support users making mistakes.
Also here, I do not like the idea of asking for passwords and
having to pass them on, but cannot imagine how else the (imho
valid) goal could be reached otherwise.
I have no problem to use another host for that tool, should that
be an acceptable option, but hat is not my intention in the first
place, of course.
Not attributing generated redirects to the proper user is imho
a bad idea. Tell me why I'm wrong ;-) Allowing only admins, etc.
it too big a burdon, and does not remove the need to authenticate.
Greetings.
Purodha
>> (1) [Historic facts. Skip if in hurry] When we made the transit
>> from the Ripuarian Test Wikipdia
>> [ .... ]
> I think, we can a exception for this, when this tool has a planed
> timespace of running and you pledge to not save these passwords in
> any form.
The relevant part of the tool is only a few lines of php code,
verification should be easy. It is history right now;
if someone needs it for another transit of the kind, it's
available for the asking to be downloaded, or installed on
toolserver.
>> (2) I am planning a tool to 'bulk' insert redirects
>> [ .... ]
> mm, I don't think it's a good idea to run a bot in a user-context,
> because it is harder to block, when it's out of controll. The secound
> point is, that it fake the edit-count of a user.
> So if you realy like to run this tool, please use another server.
I feel good discussing ideas a bit before implementing potentially
weak solutions. :-)
I think the edit count issue already rules my aproach out.
Control was imho not such a big issue, I've already been
planning to drastically limit the bot to so many edits per hour,
per user, per ip, etc. independent of each other. Since a simple
regexp creating 'all possible combinations of ...' on a mid-size
word already can easily lead to ten thousands of expansions, and
almost all of those are never used in real life, carefully choosen
limitations and rejects are needed.
Anyway, automatically and systematically creating redirects is an
issue to be solved somehow. Just see, we are in a dialect
continuum betwen German [[de]], Low German (Plattdüütsch) [[nds]],
Netherlands [[nl]], Limburgs [[li]], Luxemburgish [[lb]], and
Pälzsch [[pfl]], only the latter has not an own Wikipedia yet.
For example, we've got most of the spelling variants of the month names
from either, plus several in between, times 366 day articles -- it
would be insane to leave all these redirects to be manually typed
by volonteer editors.
Not having them is creating complaints, and duplications, so that
is not an option either.
Now I am thinking of having 'job queue' pages for a bot
editing under his own name, and admins having to move
requests from a "suggested" (unprotected or semiprotected) to an
"accepted" (protected) page, while the bot moves them from
"accepted" to "done", or just removes them from "accepted".
Users should be given the chance to enter request lists and/or
regexps, thus they can be credited properly, but usually make one
edit only for a set of bot-created redirects.
Two ways of organizing come to my mind:
A: have users put their suggestions on [[Target_Article/redirects]]
which the bot detects when created or altered, which can be
kept forever, or
B: have users put suggestions on [[User:redirbot/suggesions]]
e.g. in a format like:
== year month ==
* [[Target Article]] [[alias1]] [[alias2]] ... [aliasN]]
(alias* can be regexps)
where entries are removed, when they become obsolete for whichever
reason.
In either case the associated talk pages can be used to solve
questions.
I currently prefer approach B. (Leaving less drivel behind)
Ideas and comments?
Thank you.
Purodha
Even to strict ruling german courts, there is no problem
accumulating and publishing data on persons, that is "easily
accessible for everyone" by conventinal means. E.g. looking up how
many entries a person has in the public phone book and reporting
the count (without the phone numbers) would not be objectable.
That said, I do not assume that giving the magnitude of edits would
be a general problem. Especially not for admins, who are by
understandable and publicly available and agreed-upon rules
required to have a certain 'reputation by numbers' of edits, etc.
and thus must have implicitly accepted the rules, when they
choose to go for a voting.
Imho it would be sufficient to state in the [[Wikipedia:Admin]]
pages, that admins are subject to some public scrutinity and
control which means ... etc. (don't run for a pubic office, if
you don't like the implications, including some pubic attention
to your person)
Btw. German law has a notable exception (somewhat wider than
anglo-saxon, or EU understanding of the same) in that, what they
call "eine Person der Zeitgeschichte" - a person of contemporary
history - has considerably less rights to privacy than others.
That means, when you are in a public office, or run for one, or
are a well known actor, artits, tv-personality, trade unionist,
lobbyist, economic leader, scholar, author, etc. you cannot
prevent media reporting on you. You can demand truthfullness,
fairness, and to some extent decency, but you cannot e.g. (as every
nobody can) control which photographs they use, provided they
where taken on public ground, in public, or at a press-covered
appearance, etc.
In a lesser extend, the same idea could imho be applied to admins,
as far as their role as admins is concerned, and the data directly
related to, or describing, their work as admins.
Of course such ideas need to be laid down, discussed in the
various communities, and accepted. I assume that some diversity
will arise from that process. I think the international
foundation can and should point to the need and somehow collect
pointers to the individual rule sets a they become available, and
possibly destill some very basic principles from them and publish
these in simple sentences, but the foundation cannot determine the
rules - neither do they have the man power nor the knowledge, and
it's not their job. A need may arise to moderate needs or ideas
of various communities, when compatibility is questionable, so as
to find a workable overall solution. This might be done, or
initiated / coordinated by the foundation, details and fine print
likely to be treated by a specially appointed international expert
group, though.
My opinion (tm).
Purodha
I am new to this list, reading it through the web archive only
until I have a faster system for e-mail filtering.
Some facts about me: Developing software since more than 30
years in various fields, consulting in various related fields.
Networking almost as long, both with humans & computer to computer.
Interested in ethical questions of it use. Interested in improving
existing and implementing new possibilities, most specifically
visionary approaches, or things that are deemed impossible.
In doubt, I prefer more powerful, and parameterizable, solutions ;-)
I am educated a mathematician, physicist, and (a bit) linguist.
Interested computer assisted translation and machine tranlation.
There are more than a dozen languages that I feel lucky to be able
to understand few words of when reading (although I may not grasp full
meanings of most sentences!) fluent speaking only English, German, Kölsch.
Last 10 years, I've been involved in Web design and programming,
and ISP work, like maintaining and using dedicated and shared
servers (mostly LAMP)
Administrator of the Ripuarian Wikipedia, supporter and tester of
WiktionaryZ.
Editor of the German, English, Plattdüütsch, Simple English, and
Ripuarian Wikipedias, plus occasionally of other Wikipediae and
Wiktionaries, and more.
Beginner / learner of MediaWiki / WikiData hacking, bug reporter.
Projects begun or planned for toolserver, see separate posts, or
http://meta.wikimedia.org/w/index.php?title=Toolserver/New_accounts&oldid=4…
last paragraphs.
Ask, if you want to know more.
Purodha Blissenbach
Hi all.
After a short talk with River and DaB, I have added a new rule to
<http://meta.wikimedia.org/wiki/Toolserver/Rules>:
If you operate a bot from zedler, it must comply to the rules of each
wiki it accesses. It must not edit anonymously - it may get blocked,
and all other scripts on the toolserver along with it.
A few days before, DaB had added another one:
It is not allowed to ask a user for his/her password of one of the
wikimedia-projects.
A system for user authentication using wiki accounts is under development.
As a reminder: DO read the rules page I linked to above. If you already
have, do it again. Thank you.
-- Daniel
--
Homepage: http://brightbyte.de
Hi all,
#wikimedia-toolserver IRC logs are now available online at <http://
tools.wikimedia.de/~tim/cgi-bin/irc_log>. These logs are constantly
updated by TDSBot, so hopefully these logs will provide a way to play
catch up to information missed. It should now also be possible to
grep through the logs for a question you may have, to see if it's
already been answered (grep hemlock? :-))
To address privacy concerns, you must complete a quick verification
process to ensure that you are indeed who you say you are. From there
on in, you just have to click on the log in link and log in. All
passwords are stored in a MySQL table using sha-1 and a salt.
Thanks,
Tim Abdulla
i have removed your .forward file because your gmail account is not
accepting mail and zedler's mailq is full of mails trying to be sent to
it. please mail zedler-admins@ with a working email address.
- river.