Sorry I failed to send this to the list the first time
--- Birgitte SB birgitte_sb@yahoo.com wrote:
Date: Fri, 1 Feb 2008 10:20:18 -0800 (PST) From: Birgitte SB birgitte_sb@yahoo.com Subject: Re: [Foundation-l] Fwd: Wikimedia-wide global blocking mechanism? To: effeietsanders@gmail.com
I will grant you that it easier in the short-term to not use an opt-in system. However I strongly disagree that in practice the results would be the same as requiring opt-in. Even the most wonderful idea can have disastrous results because of poor communications. I can agree with the principles of this idea, but I also also think that such changes in principle require comprehensible notification. If you are not willing to bother with the communication(either through annoucements or using opt-in), you are setting yourselves up for failure. Personally I think opt-in is more workable than blanket notifications in local languages. Using an opt-in system will mean it will take some time for the system to reach full effect. But you should still get the feature you desire, and I believe you will save yourselves a great deal of difficulty in the long run.
Frankly I am surprised your argument against opt-in is that it would be easier for the stewards to do otherwise. If someone does not wish to bother communicating with small wikis and wikis which have trouble with English, I wonder why they ever thought to become a steward.
Birgitte SB
--- effe iets anders effeietsanders@gmail.com wrote:
no or barely a community. Most of the wiki's are small sized, and many show little activity. It is much easier, and would in practice be almost the same, to just automatically opt in projects...
BR, Lodewijk
2008/2/1, Birgitte SB birgitte_sb@yahoo.com:
The problem with opt-out is that a wiki must
know
this
even *exists* in order to opt-out. So if you
are
capable of notifing all the village pumps in a language they can comprehend, this is
reasonable.
If
you are not capable of that, opt-out is not reasonable. If this is mainly for wiki's with
no
community, then allow stewards to "opt-in" such wiki's. If they have no community, they will not object.
Birgitte SB
--- effe iets anders effeietsanders@gmail.com
wrote:
Hi,
I agree with your concerns. However, currently
a
similar system is already active, proxyblocker. This system
blocks
some (I dont know how many) proxies, detected somewhere in 2005.
Dont
worry, no new blocks are being added, but some are still in place.
The
user just gets a message that he is blocked by proxyblocker. We
could
pick a logical name to appear in the message, that would
point
to
meta. Maybe CrosswikiBlocker, or VandalbotBlocker or
something.
Opt-in is not workable. This new thing is
mainly
for
wiki's with no community. You can only opt in if you have a community. Hence, opt in would not work. After all, the stewards mainly
have
to block bots on wiki's with no or almost no normal edits. when
there
are people around, and they have sysops and a community,
they
can handle it themselves generally. However, I would plea
for
opt-out.
For the unblocking, I do not think that should
be a
major issue, if we would choose for a maximum of a block in the
range
of 1 day-1week. In that case, the chance that someone is affected
by
that block, but is not the person who was doing the malicious
edits, is
quite slim. Furthermore, that person will survive to wait
a
day
or a week, no big harm done. If it proofs to be a major blocker
for a
specific community, ie they would only have one IP for
a
whole country or something, they could opt out.
BR, Eia
2008/1/31, Birgitte SB
--- Andrew Gray shimgray@gmail.com wrote:
On 31/01/2008, Birgitte SB
wrote:
> This is the key problem. I think that
unless
we
are > capable of notifing all wikis of about
the
workings of > this process in a language they are
proficient
taking > blocks Wikimedia wide will cause a lot
of
harm.
Of > course an opt-in system would be very
workable.
Would logging it in the local block-log
system
be an
acceptable method of notification?
I was more thinking first about a
notification
that
this ability even *exists* before addressing notification individual blocks. However
regarding
individual blocks what language are you
proposing
the
local log entry be written in?
The only reasonable way to do this is to
have
the
log
entries be a consistent pre-arranged formula
that
links to a local page explaining the system
in
the
local language. The best way to ensure that
all
this
is set-up is to use an opt-in system that
requires
these things be set-up before blocks .
Anything else means some wiki(s) will wake
up
one
day
to realize there are inexplicable blocks in
place.
Likely with logs entries they cannot read.
And
very
likely when they start making inquiries no
one
will be
able to explain what has happened to them
own
language
leading to further misunderstandings.
Seriously make a system to handle these
blocks
and
require every wiki wishing to join the
system
file
a
bug and things will go much more smoothly.
If
the
stewards find they are doing tedious manual
blocks
on
a certain wiki, they can encourage the that
wiki
to
file the bug.
Birgitte SB
____________________________________________________________________________________
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Thanks for refraining from personal attacks.
Please realize the number of Wikimedia Wiki's. Also consider that this number is constantly increasing, and that a serious part of these wiki's have no or little community. I don't see why we should not fight vandalism on wiki's with no community. It just does not make sense.
I am talking here about *short term* blocks of proven vandal bots that are going through a high number of wiki's. These bots will not add anything good to the wikimedia wiki's, and are only destructive. Blocking here is stopping that bot from continuing, and I think that falls within the scope of what a steward is supposed to be for.
I have no problem with communications. As you might be able to find on metawiki and mailinglist archives, I am for instance highly doubtful for giving automatically bot rights to people on every wiki once they cleared a certain meta procedure. So it is not like I am a bad steward that hates small communities or something, no, I really base this on arguments and considerations. Please let me try again to explain why I think this is better.
The current situation is that as soon as a vandal bot is detected, there are two options. Either preventively block the IP on *every* small wiki, which means: go to the wiki, log in, grant yourself admin rights, block, remove the rights. A lot of work. Both result in long blocks, because we do not like the bots to come back tomorrow, it's too much of work for that. I think everyone agrees that this situation is bad and should be improved.
This improved blocking mechanism would enable the stewards to stop these bots the moment they are spotted. The can be stopped for a short term, so that the proxies remain opened for the communities that wish/need that. The vandalism would be prevented, and that would save a lot of cleaning work as well. It would be an automation of the current procedure.
However, it is imaginable (not likely imho though) that smaller wiki's object to this procedure. They might want the bot to come in, or maybe have an actually good reason, that is somewhat hard to predict. To come to their (possible) wishes, it might be decided that we could do some opt-[in/out] system. I think that an opt-in system will be much worse in terms of manpower, time and vandalism then opt-out. A lot of the wiki's that form the main target group of this tool have not the ability to make such a choise. Either because there is no or barely a community, either because they cant work out procedures. It would also give a lot of extra work for the devs. They would have to optin every community that would like to join.
To form consensus, it would require a while to ague within the community, if present at all, which would not only mean a delay, but again a lot of extra work. Yes, extra work is a valid argument for me. Also stewards are volunteers, and have other better things to do then cleaning up vandalism when not needed. If it is needed, fine, I'll do my job if I'm in, but I'd rather see a better way of fixing things then manually.
So besides that it is a load of extra work for stewards, devs and other vandalism-cleaners (SWMT) it would also mean that a bunch of wiki's which died slowly in the past for whatever reason, will remain to suffer from vandalism, even when there is no need to.
Opt-out is maybe a little less "independant" but just as effective. If a community has objections, they will note them soon enough. Just like you want to send messages to opt-in, we could also send messages to opt-out if they want to. There is no fundamental difference between those messages, the only difference is the momentum. The difference is also that they will have to do a little work to get the vandalism bots again. It would also mean less processing manpower for developers, and a system that is both immediately active and running, but also a system that is better in the long run, as more wiki's will join that have no or barely any community.
Best regards,
Lodewijk
2008/2/1, Birgitte SB birgitte_sb@yahoo.com:
Sorry I failed to send this to the list the first time
--- Birgitte SB birgitte_sb@yahoo.com wrote:
Date: Fri, 1 Feb 2008 10:20:18 -0800 (PST) From: Birgitte SB birgitte_sb@yahoo.com Subject: Re: [Foundation-l] Fwd: Wikimedia-wide global blocking mechanism? To: effeietsanders@gmail.com
I will grant you that it easier in the short-term to not use an opt-in system. However I strongly disagree that in practice the results would be the same as requiring opt-in. Even the most wonderful idea can have disastrous results because of poor communications. I can agree with the principles of this idea, but I also also think that such changes in principle require comprehensible notification. If you are not willing to bother with the communication(either through annoucements or using opt-in), you are setting yourselves up for failure. Personally I think opt-in is more workable than blanket notifications in local languages. Using an opt-in system will mean it will take some time for the system to reach full effect. But you should still get the feature you desire, and I believe you will save yourselves a great deal of difficulty in the long run.
Frankly I am surprised your argument against opt-in is that it would be easier for the stewards to do otherwise. If someone does not wish to bother communicating with small wikis and wikis which have trouble with English, I wonder why they ever thought to become a steward.
Birgitte SB
effe iets anders wrote:
I am talking here about *short term* blocks of proven vandal bots that are going through a high number of wiki's. These bots will not add anything good to the wikimedia wiki's, and are only destructive. Blocking here is stopping that bot from continuing, and I think that falls within the scope of what a steward is supposed to be for.
This seems like shifting the goal posts. As I understood the issue from the many messages in this thread it would apply to human editors as well as bots. How do you propose to distinguish whether a vandal is a human or a bot? What is the process for establishing that it is a "proven" vandal bot? How can you guarantee that the process will not be used against human editors who have merely been caught up in a pissing match with the admins in a particular project?
The current situation is that as soon as a vandal bot is detected, there are two options. Either preventively block the IP on *every* small wiki, which means: go to the wiki, log in, grant yourself admin rights, block, remove the rights. A lot of work. Both result in long blocks, because we do not like the bots to come back tomorrow, it's too much of work for that. I think everyone agrees that this situation is bad and should be improved.
If communities are going to insist that a steward desysop himself every time he goes into a project to perform routine anti-vandalism it's easy to see that it is more objectionable that they perform acts automatically without ever logging themselves in. Perhaps it would be preferable that once a steward has properly given himself sysop rights he retain those rights unless there is a specific objection from the community. That would be far more acceptable than any kind of automated process.
Ec
Ray Saintonge wrote: If communities are going to insist that a steward desysop himself every time he goes into a project to perform routine anti-vandalism it's easy to see that it is more objectionable that they perform acts automatically without ever logging themselves in. Perhaps it would be preferable that once a steward has properly given himself sysop rights he retain those rights unless there is a specific objection from the community. That would be far more acceptable than any kind of automated process.
I'd be fine with that too, but it's really a moot point. This still requires a steward (or team of them) to go to each wiki individually to make the blocks - hardly the most efficient method. This proposed mechanism would simply automate the process, saving time and manpower. When dealing with a large number of spambots, or a persistent cross-wiki vandal [1], manpower is often a prime concern. Can we also try to remember that, as with the change pagemove upon autoconfirmed, we're talking mainly about wikis with a community not able to effectively fend off the spammers etc. I wrote [2] at the time that Heller would be proud of the requests to have wikis with no community ask to opt-in for such a measure; I think the same thing needs to be said here. Mike.lifeguard
[1] http://meta.wikimedia.org/w/index.php?title=User:Drini/daylog&oldid=8618... [2] http://meta.wikimedia.org/w/index.php?title=Metapub&diff=prev&oldid=...
--- "mike.lifeguard" mike.lifeguard@gmail.com wrote:
Ray Saintonge wrote: If communities are going to insist that a steward
desysop himself every
time he goes into a project to perform routine
anti-vandalism it's easy
to see that it is more objectionable that they
perform acts
automatically without ever logging themselves in.
Perhaps it would be
preferable that once a steward has properly given
himself sysop rights
he retain those rights unless there is a specific
objection from the
community. That would be far more acceptable than
any kind of automated
process.
I'd be fine with that too, but it's really a moot point. This still requires a steward (or team of them) to go to each wiki individually to make the blocks - hardly the most efficient method. This proposed mechanism would simply automate the process, saving time and manpower. When dealing with a large number of spambots, or a persistent cross-wiki vandal [1], manpower is often a prime concern. Can we also try to remember that, as with the change pagemove upon autoconfirmed, we're talking mainly about wikis with a community not able to effectively fend off the spammers etc. I wrote [2] at the time that Heller would be proud of the requests to have wikis with no community ask to opt-in for such a measure; I think the same thing needs to be said here. Mike.lifeguard
[1]
http://meta.wikimedia.org/w/index.php?title=User:Drini/daylog&oldid=8618...
[2]
http://meta.wikimedia.org/w/index.php?title=Metapub&diff=prev&oldid=...
As I said before [1], stewards should be allowed to opt-in the wiki's with no community. Disscussions only need to happen if there is an active community. I also don't mind opt-out if everyone gets comprehensible notification about the system and how to opt-out.
The idea that people check the wiki's block logs on a regular basis and would even know what such block would signify if they saw them is unreasonable. The only time people completely uniformed about this system are going to discover it, is when they are already experiencing a problem. And they will speculate amoung themselves about what these blocks mean and come up some strange bad faith ideas. And once they are alll worked up about this, they will confront the stewards with these bad faith accusations. And it will be quite hard to explain things to them at that time. Do none of you remember all the other times we have been through situations like this?
The recent messages on this thread show that those responding to me are twisting what I say without even considering the compromises I suggest. So I am done commenting on this. Just don't pretend I was suggesting something as foolish as a wiki with no community come to a local consensus on opting in, because I was not.
Birgitte SB
[1]http://lists.wikimedia.org/pipermail/foundation-l/2008-February/038322.html1
____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Hello,
Birgitte SB wrote:
As I said before [1], stewards should be allowed to opt-in the wiki's with no community. Disscussions only need to happen if there is an active community. I also don't mind opt-out if everyone gets comprehensible notification about the system and how to opt-out.
If the stewards would be able to decide themselves to opt-in a wiki without community approval, then this is quite the same as the opt-out proposal by Lodewijk.
IMHO, when this system is technically ready, there should be a discussion in each wiki which has a community, at least to inform the wiki that 1. the new feature exists, 2. the wiki has the choice to opt-in or -out. Now if no community is able to take such a decision, and the stewards take it for them, your proposition is quite the same as Lodewijk's. It only gives more power to stewards, which they should not have.
Regards,
Yann
The idea that people check the wiki's block logs on a regular basis and would even know what such block would signify if they saw them is unreasonable. The only time people completely uniformed about this system are going to discover it, is when they are already experiencing a problem. And they will speculate amoung themselves about what these blocks mean and come up some strange bad faith ideas. And once they are alll worked up about this, they will confront the stewards with these bad faith accusations. And it will be quite hard to explain things to them at that time. Do none of you remember all the other times we have been through situations like this?
The recent messages on this thread show that those responding to me are twisting what I say without even considering the compromises I suggest. So I am done commenting on this. Just don't pretend I was suggesting something as foolish as a wiki with no community come to a local consensus on opting in, because I was not.
Birgitte SB
--- Yann Forget yann@forget-me.net wrote:
Hello,
Birgitte SB wrote:
As I said before [1], stewards should be allowed
to
opt-in the wiki's with no community. Disscussions only need to happen if there is an active
community.
I also don't mind opt-out if everyone gets comprehensible notification about the system and
how
to opt-out.
If the stewards would be able to decide themselves to opt-in a wiki without community approval, then this is quite the same as the opt-out proposal by Lodewijk.
IMHO, when this system is technically ready, there should be a discussion in each wiki which has a community, at least to inform the wiki that
- the new feature exists,
- the wiki has the choice to opt-in or -out.
Now if no community is able to take such a decision, and the stewards take it for them, your proposition is quite the same as Lodewijk's. It only gives more power to stewards, which they should not have.
Regards,
Yann
Trusting the stewards to opt-in what they judge to be a wiki with no community and taking this feature live on all wikis at once is not the same proposal. Both proposals make dealing with vandalism on inactive wikis easier, but my proposal prevents the problems that might occur with more active wikis due to poor communication.
Birgitte SB
____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Trusting the stewards to opt-in what they judge to be a wiki with no community and taking this feature live on all wikis at once is not the same proposal. Both proposals make dealing with vandalism on inactive wikis easier, but my proposal prevents the problems that might occur with more active wikis due to poor communication.
Birgitte SB
____________________________________________________________________________________
Why can not we DEFINE a wiki with no community? For instance, either (a) no sysops; or (b) no edits by existing sysop(s) within the last month? These wikis would be opted-in authomatically, and others only if the community votes to opt-in. If the community is formed, the wiki can vote for opting out.
Cheers, Yaroslav
Without going into too many details here we're talking about specific scenarios where an IP address is to be blocked. An example would be as follows:
Some idiot called "Poopforshoes" comes along on en.wikinews and starts vandalising articles on the site. He's quickly blocked and someone notices we've had *very* similar vandalism in the past. A CheckUser reveals a dozen or so similar usernames with the same modus operandi, no uninvolved users on the IP, so the IP is blocked long-term and the details passed on to Checkuser-l. When we start getting another handful of wikis telling us this has happened to them with the same IP we want a global - and consistent - block.
I have no opinion on how this could impact SpamBots, or if it would even be appropriate in such cases. What I would like to see is something that doesn't involve someone adminning themselves on 700 or so wikis to issue a long-term block.
Brian McNeil
-----Original Message----- From: foundation-l-bounces@lists.wikimedia.org [mailto:foundation-l-bounces@lists.wikimedia.org] On Behalf Of Yaroslav M. Blanter Sent: 04 February 2008 17:42 To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] Fwd: Re: Fwd: Wikimedia-wide globalblocking mechanism?
Trusting the stewards to opt-in what they judge to be a wiki with no community and taking this feature live on all wikis at once is not the same proposal. Both proposals make dealing with vandalism on inactive wikis easier, but my proposal prevents the problems that might occur with more active wikis due to poor communication.
Birgitte SB
____________________________________________________________________________ ________
Why can not we DEFINE a wiki with no community? For instance, either (a) no sysops; or (b) no edits by existing sysop(s) within the last month? These wikis would be opted-in authomatically, and others only if the community votes to opt-in. If the community is formed, the wiki can vote for opting out.
Cheers, Yaroslav
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Birgitte SB wrote:
Trusting the stewards to opt-in what they judge to be a wiki with no community and taking this feature live on all wikis at once is not the same proposal. Both proposals make dealing with vandalism on inactive wikis easier, but my proposal prevents the problems that might occur with more active wikis due to poor communication.
I agree. This is a commonsense approach. When such steps are taken with sensitivity to a community's circumstances they could work quite well. What's frightening is those individuals who would take such tools as an opportunity to impose their views on a community where they have not previously shown any interest at all. In Wikisource it's not unusual for a fresh immigrant to assume that the same rules apply as in en:wp. We can and should be less understanding when we are dealing with bots, but if these proposals were about bots they should not have been framed in more general terms.
Ec
2008/2/4, Birgitte SB birgitte_sb@yahoo.com:
As I said before [1], stewards should be allowed to opt-in the wiki's with no community. Disscussions only need to happen if there is an active community. I also don't mind opt-out if everyone gets comprehensible notification about the system and how to opt-out.
The idea that people check the wiki's block logs on a regular basis and would even know what such block would signify if they saw them is unreasonable. The only time people completely uniformed about this system are going to discover it, is when they are already experiencing a problem. And they will speculate amoung themselves about what these blocks mean and come up some strange bad faith ideas. And once they are alll worked up about this, they will confront the stewards with these bad faith accusations. And it will be quite hard to explain things to them at that time. Do none of you remember all the other times we have been through situations like this?
The recent messages on this thread show that those responding to me are twisting what I say without even considering the compromises I suggest. So I am done commenting on this. Just don't pretend I was suggesting something as foolish as a wiki with no community come to a local consensus on opting in, because I was not.
Birgitte SB
[1]http://lists.wikimedia.org/pipermail/foundation-l/2008-February/038322.html1
I think that a minimal notification would be to explain the situation in several languages on the userpage of the username that appears as the blocker. See for instance the [[user:Proxyblocker]] on several projects. However, we should do that then on every project of course. If a user would be "hit" by such a short duration block, (s)he could easily check why, what and by whom, where to protest and how to opt out. Of course we would never be able to cover all 250 languages, but we could of course aim to at least have it translated in 20-30 languages, maybe centralized to have an updated version all the time. Additional to that a message on the village pumps as far as available would of course be needed etc.
The blocks would in my view be quite short (long term blocks we would have to handle in the old fashioned way?) so if a user is frustrated by it, xe should be able to complain about it the next day.
Btw: about the question what is a bot: If it sounds like a duck, if it looks like a duck, if it smells like a duck, you can act as it would be a duck. Of course we don't bother whether it is *really* a bot, or some moorhuhn that is editing vandalism very fast, it's about the type of "contributions" I was referring to of course :)
BR, Lodewijk
effe iets anders wrote:
Btw: about the question what is a bot: If it sounds like a duck, if it looks like a duck, if it smells like a duck, you can act as it would be a duck. Of course we don't bother whether it is *really* a bot, or some moorhuhn that is editing vandalism very fast, it's about the type of "contributions" I was referring to of course :)
I have yet to see evidence that we have any ducks among our editors. :-)
The problem is that failure to give precise definitions opens the door to unwarranted extrapolations. We know from experience that rule-wallahs are more than willing to apply rules to situations well beyond what the original rule intended.
Ec
On Feb 2, 2008 2:47 PM, mike.lifeguard mike.lifeguard@gmail.com wrote:
Ray Saintonge wrote: If communities are going to insist that a steward desysop himself every time he goes into a project to perform routine anti-vandalism it's easy to see that it is more objectionable that they perform acts automatically without ever logging themselves in. Perhaps it would be preferable that once a steward has properly given himself sysop rights he retain those rights unless there is a specific objection from the community. That would be far more acceptable than any kind of automated process.
I'd be fine with that too, but it's really a moot point. This still requires a steward (or team of them) to go to each wiki individually to make the blocks - hardly the most efficient method. This proposed mechanism would simply automate the process, saving time and manpower. When dealing with a large number of spambots, or a persistent cross-wiki vandal [1], manpower is often a prime concern. Can we also try to remember that, as with the change pagemove upon autoconfirmed, we're talking mainly about wikis with a community not able to effectively fend off the spammers etc. I wrote [2] at the time that Heller would be proud of the requests to have wikis with no community ask to opt-in for such a measure; I think the same thing needs to be said here. Mike.lifeguard
Well, once the spambot has detected, it only takes a bot to blok it everywhere so the hard part is detecting them, andI don't think we should be doing right trusting a bot to detect vandalism and issue blocks everywhere
Maybe I'm misunderstanding something. But I really don't mind checking personally that what I'm about to block deserves it indeed
On Feb 4, 2008 9:59 AM, Pedro Sanchez pdsanchez@gmail.com wrote:
Well, once the spambot has detected, it only takes a bot to blok it everywhere so the hard part is detecting them, andI don't think we should be doing right trusting a bot to detect vandalism and issue blocks everywhere
[snip]
WMF hosts over 700 wikis. Do you really think it is easy to setup and maintain a admin-flagged bot account on all of them?
I agree that there are two issues here, deciding what to block globally, and actually carrying it out. Lets not reject something that solves the latter because we don't have a complete solution for the former.
Whole story: http://www.bangkokpost.com/Business/06Feb2008_biz51.php
- The Wiki Mission for Thailand will attempt to involve travellers in improving and editing all of the information about Thailand on Wikipedia.org and Wikitravel.org.The TAT also aims to help members of the local travel and tourism http://www.bangkokpost.com/Business/06Feb2008_biz51.php# industry by allowing them to post details of their travel products, deals and related information online. More details are available at the TAT's main online portal, http://www.tourismthailand.org
Waerth ha scritto:
Whole story: http://www.bangkokpost.com/Business/06Feb2008_biz51.php
- The Wiki Mission for Thailand will attempt to involve travellers in
improving and editing all of the information about Thailand on Wikipedia.org and Wikitravel.org.The TAT also aims to help members of the local travel and tourism http://www.bangkokpost.com/Business/06Feb2008_biz51.php# industry by allowing them to post details of their travel products, deals and related information online. More details are available at the TAT's main online portal, http://www.tourismthailand.org
As soon as they do not spam their websites (or other commercial websites) and respect NPOV, I think it's a great idea. We have to make sure they know the rules. Cruccone
On Wednesday 06 February 2008 16:25, Marco Chiesa wrote:
Waerth ha scritto:
Whole story: http://www.bangkokpost.com/Business/06Feb2008_biz51.php
- The Wiki Mission for Thailand will attempt to involve travellers in
improving and editing all of the information about Thailand on Wikipedia.org and Wikitravel.org.The TAT also aims to help members of the local travel and tourism http://www.bangkokpost.com/Business/06Feb2008_biz51.php# industry by allowing them to post details of their travel products, deals and related information online. More details are available at the TAT's main online portal, http://www.tourismthailand.org
As soon as they do not spam their websites (or other commercial websites) and respect NPOV, I think it's a great idea. We have to make sure they know the rules.
One very useful and simple thing they could do is to simply release a bunch of content under GFDL. Anyone has the idea on how could this be suggested to them?
On 06/02/2008, Nikola Smolenski smolensk@eunet.yu wrote:
One very useful and simple thing they could do is to simply release a bunch of content under GFDL. Anyone has the idea on how could this be suggested to them?
Someone needs to approach them and say "PICTURES! LOTS OF PICTURES! PLEASE!"
We could also do with their assistance filling out general encyclopedic material, e.g. every reasonably noteworthy Thai political leader ever.
- d.
We could also do with their assistance filling out general encyclopedic material, e.g. every reasonably noteworthy Thai political leader ever.
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Well, I have added the page "Ananda Mahidol" to my watchlist, just in case. Otherwise, it would be great of course if they add encyclopaedic information.
Cheers, Yaroslav
2008/2/6, David Gerard dgerard@gmail.com:
Someone needs to approach them and say "PICTURES! LOTS OF PICTURES! PLEASE!"
Except that they probably dont have a clue about copyright, authors and free licenses, and they will just freely license everything they have in their posession (also if they just bought the image, without transfer of copyright etc), as quite some PR agencies seem to try at least on nlwiki...
BR, lodewijk
effe iets anders wrote:
2008/2/6, David Gerard dgerard@gmail.com:
Someone needs to approach them and say "PICTURES! LOTS OF PICTURES! PLEASE!"
Except that they probably dont have a clue about copyright, authors and free licenses, and they will just freely license everything they have in their posession (also if they just bought the image, without transfer of copyright etc), as quite some PR agencies seem to try at least on nlwiki...
BR, lodewijk
Last time I walked on Silom (today to eat taco's) copyright seemed no issue Lodewijk ;) Wanna buy CD 100 baht?
Waerth
wikimedia-l@lists.wikimedia.org