Hello. I have a question about the use of a bot.
After some trials-and-errors, we wikipedians in Japanese 'pedia are now starting to use an outside BBS (prepared by one of the active wikipedians) for our discussion of basic policies and other site-wide issues. And in conjunction with it, we are wondering if it is okay to use a bot to automatically update a page within wikipedia (something like [Wikipedia:Discussions_at_WikipediaBBS]) which displays info. on recent postings occuring at the BBS.
Now I think I should explain two things - why we (some of us) think outside BBS is good, and why the bot is helpful for that.
1. Why we think outside BBS is good
For discussion purposes, we have three options. Meta, talkpage, and some dedicated pages in the Wikipedia namespace.
Meta is not user-friendly because its interface is in English.
We tried talk pages, but there happened too many discussions of overlapping topics, and it was hard for latecomers to join, because the discussions are taking place in many places (some unknown to the newcomers), hard to reconstruct the dialogue spanning multiple talkpages. It is also difficult for anybody to revisit the past discussions and decisions, because the records are scattered.
Then we tried Wikipedia:Village_pump as a place for discussion and decision-making regarding site-wide issues - naming conventions, spelling conventions, disambiguation policies, admin selections, basic style and layout issues, and so on. Some are re-doing of what people did in English wikipeida, some are more or less unique to Japanese wikipedia. We faced some problems again. The major ones are (a)32kb limit for some browsers, and (b) too many issues to be discussed within the limited space (though we used subpages, etc.). I can also point out that (c) there are several yet-to-be understood bugs/troubles related to display and character encoding (some characters turn jibrish, some characters automatically get deleted, some characters are visible only in editing box, and at least a few more), and outside BBS is a good place to discuss about the problem without being annoyed by the very problem we talk about. Some others pointed out (d) Wikipedia is slow or down too often these days, and it is better to have outside place we can work on.
While at least some of us think that we can improve the way we use Wkipedia:Village_pump and make it workable, (and of course I cannot deny that there is a possibility that the BBS turn out to be problematic in other ways,) many of active users think we would try the BBS for now.
2. Why the bot is helpful
2. Why a bot is helpful
Bot is good for two reasons. It saves users time by automatically creating the content that the user would want to post. It helps others (those of us who do not always check on the BBS) to stay informed of what's going on in the BBS.
As it is preliminary designed and implemented, the bot does two things: (a) automatically create a page content for a specific page something like [[Wikipedia:Discussions in the Wikipedia BBS]] and (b) with a click of a mouse, the user will be taken automatically to the edit mode of the page (now in wikipedia) with the auto-generated content. -The content is not saved/posted at this stage. The user still has to confirm the content by pressing the "save" button.
In other words, the bot does not automatically update any content. It generate the content that users can save.
I am aware that some of you are quite against the use of bot. So I offer some defense here.
First, the Special:Recent_changes will not be flooded. The bot works only with a human confirming the content. The pace of the activities cannot be faster than that of humans.
Second, the way it works, it cannot be abused by some mal-intended users to overload the server.
If no objection, some of us would complete the bot and show to admins for the final check.
Many thanks,
Tomos
_________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
It should be ok ;-) im not an op, but there have been other...far more useless bots (50,000 pages of extremely homogenous and trivial US census data).
Anyway, before you do bot, maybe there is now enough reason to finally get a good discussion code into wikipedia.
I feel that phpbb (which is GNU ) is the best open source bb out there, and I know for a fact that its very international friendly.
How about you confirm that it handles japanese to your liking.
If not, then you can still work with the phpbb people to make it better or use the other board that you are already using.
If so, then we're set, and this start snowballing people into action. --- Tomos at Wikipedia wiki_tomos@hotmail.com wrote:
Hello. I have a question about the use of a bot.
After some trials-and-errors, we wikipedians in Japanese 'pedia are now starting to use an outside BBS (prepared by one of the active wikipedians) for our discussion of basic policies and other site-wide issues. And in conjunction with it, we are wondering if it is okay to use a bot to automatically update a page within wikipedia (something like [Wikipedia:Discussions_at_WikipediaBBS]) which displays info. on recent postings occuring at the BBS.
Now I think I should explain two things - why we (some of us) think outside BBS is good, and why the bot is helpful for that.
- Why we think outside BBS is good
For discussion purposes, we have three options. Meta, talkpage, and some dedicated pages in the Wikipedia namespace.
Meta is not user-friendly because its interface is in English.
We tried talk pages, but there happened too many discussions of overlapping topics, and it was hard for latecomers to join, because the discussions are taking place in many places (some unknown to the newcomers), hard to reconstruct the dialogue spanning multiple talkpages. It is also difficult for anybody to revisit the past discussions and decisions, because the records are scattered.
Then we tried Wikipedia:Village_pump as a place for discussion and decision-making regarding site-wide issues - naming conventions, spelling conventions, disambiguation policies, admin selections, basic style and layout issues, and so on. Some are re-doing of what people did in English wikipeida, some are more or less unique to Japanese wikipedia. We faced some problems again. The major ones are (a)32kb limit for some browsers, and (b) too many issues to be discussed within the limited space (though we used subpages, etc.). I can also point out that (c) there are several yet-to-be understood bugs/troubles related to display and character encoding (some characters turn jibrish, some characters automatically get deleted, some characters are visible only in editing box, and at least a few more), and outside BBS is a good place to discuss about the problem without being annoyed by the very problem we talk about. Some others pointed out (d) Wikipedia is slow or down too often these days, and it is better to have outside place we can work on.
While at least some of us think that we can improve the way we use Wkipedia:Village_pump and make it workable, (and of course I cannot deny that there is a possibility that the BBS turn out to be problematic in other ways,) many of active users think we would try the BBS for now.
Why the bot is helpful
Why a bot is helpful
Bot is good for two reasons. It saves users time by automatically creating the content that the user would want to post. It helps others (those of us who do not always check on the BBS) to stay informed of what's going on in the BBS.
As it is preliminary designed and implemented, the bot does two things: (a) automatically create a page content for a specific page something like [[Wikipedia:Discussions in the Wikipedia BBS]] and (b) with a click of a mouse, the user will be taken automatically to the edit mode of the page (now in wikipedia) with the auto-generated content. -The content is not saved/posted at this stage. The user still has to confirm the content by pressing the "save" button.
In other words, the bot does not automatically update any content. It generate the content that users can save.
I am aware that some of you are quite against the use of bot. So I offer some defense here.
First, the Special:Recent_changes will not be flooded. The bot works only with a human confirming the content. The pace of the activities cannot be faster than that of humans.
Second, the way it works, it cannot be abused by some mal-intended users to overload the server.
If no objection, some of us would complete the bot and show to admins for the final check.
Many thanks,
Tomos
Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Wikipedia-l mailing list Wikipedia-l@wikipedia.org http://www.wikipedia.org/mailman/listinfo/wikipedia-l
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
At 03:52 AM 5/6/03 +0000, Tomos wrote:
Hello. I have a question about the use of a bot.
After some trials-and-errors, we wikipedians in Japanese 'pedia are now starting to use an outside BBS (prepared by one of the active wikipedians) for our discussion of basic policies and other site-wide issues. And in conjunction with it, we are wondering if it is okay to use a bot to automatically update a page within wikipedia (something like [Wikipedia:Discussions_at_WikipediaBBS]) which displays info. on recent postings occuring at the BBS.<snip> While at least some of us think that we can improve the way we use Wkipedia:Village_pump and make it workable, (and of course I cannot deny that there is a possibility that the BBS turn out to be problematic in other ways,) many of active users think we would try the BBS for now.
- Why a bot is helpful
Bot is good for two reasons. It saves users time by automatically creating the content that the user would want to post. It helps others (those of us who do not always check on the BBS) to stay informed of what's going on in the BBS.
As it is preliminary designed and implemented, the bot does two things: (a) automatically create a page content for a specific page something like [[Wikipedia:Discussions in the Wikipedia BBS]] and (b) with a click of a mouse, the user will be taken automatically to the edit mode of the page (now in wikipedia) with the auto-generated content. -The content is not saved/posted at this stage. The user still has to confirm the content by pressing the "save" button.
In other words, the bot does not automatically update any content. It generate the content that users can save.
I am aware that some of you are quite against the use of bot. So I offer some defense here.
First, the Special:Recent_changes will not be flooded. The bot works only with a human confirming the content. The pace of the activities cannot be faster than that of humans.
From what you describe, the bot should not cause any problems. The objections to bots are that they overload either Recent_changes or the processors, neither of which will happen here.
The Cunctator wrote:
Hmm...when did I recommend that Wikipedia use a BBS?
How's that going, Jimbo?
It's being ignored for absolutely no good reason.
What BBS software are the Japanese using? Where is it hosted? Is it something that we could/should host for them, and also set up for English-speakers?
I love using email, and so that's one of the main reasons I haven't gotten off my butt to look into this. But that's not a very good reason.
--Jimbo
The Cunctator wrote:
Hmm...when did I recommend that Wikipedia use a BBS?
How's that going, Jimbo?
It's being ignored for absolutely no good reason.
What BBS software are the Japanese using? Where is it hosted? Is it something that we could/should host for them, and also set up for English-speakers?
I love using email, and so that's one of the main reasons I haven't gotten off my butt to look into this. But that's not a very good reason.
It is a very good reason. The Japanese may do whatever the want, but I strongly advise against using a BBS for Wikipedia discussions.
1) Mailing lists are, by their very nature, decentralized. Any post is replicated on hundreds of machines. This automatic replication makes censorship very hard and a total loss of data unlikely.
2) Archives like the ones generated by Mailman can be imported into email clients and searched locally at high speed. I have frequently made use of that feature to build high quality archives. The search function of most BBS systems, on the other hand, is far from optimal (I've seen many BBS which claimed to have a search, but where this search never worked).
3) Mailing lists keep a track record. It is easy and fast to see all posts by a particular member, or everything written by yourself. With a BBS, you first have to figure out if such a feature exists, then wait for the server to perform some search. Server is down? Too bad, you'll never get that post you wrote 3 months ago now.
4) Mailing lists allow everyone to participate without a free online connection. In many developing nations, Internet access is paid by the minute, and reading and replying to posts online costs money. Mailing lists can be conveniently read, responded to and archived offline.
5) Mailing lists allow the use of a variety of email clients which all have advantages and disadvantages. Everyone can use the software of their choice, with a user interface that suits them, without being forced to make use of an arbitrary web interface. This is of importance to handicapped users, for whom special email clients exist.
6) Good email clients make quoting and threading transparent and easy to use. They interpret the reference ID in a message and thereby allow you to quickly navigate to the parent post that a message has responded to. Quoting and writing within a real text editor is also a lot more convenient than writing within a browser window.
7) Bulletin board systems are slow. This is related to 4) -- in a BBS I have to wait for each individual thread to load, for the "post reply" screen to load, for sorting options to affect my display etc. -- as with all web interfaces, you have a high additional latency as every aspect of the interface is generated "on demand".
8) Bulletin board systems have a higher noise level. They allow no easy client-side filtering, as many email clients do. Many BBS encourage the use of fonts, pictures, animated smileys, overlong signatures etc., often leading to very hard to read threads.
9) Every BBS is different. Everyone is familiar with email, but learning to use a BBS always requires making yourself familiar with its particular user interface and functionality.
10) Mailing lists can be easily moderated, even in groups. BBS usually have after-the-fact moderation, where individual posts are censored or threads are locked. On a mailing list, posts can be pre-approved and individual members banned. With a BBS that does not use some ID confirmation method, we'll have the same banning problem we have on Wikipedia proper -- totally open access is not always a good thing. And if email confirmation is required, this only advantage of a web-based BBS goes away.
A motivated and informed writer could certainly expand the above list to 10 times this length. Any of the advantages that people cite for bulletin boards -- such as easier participation -- can be easily replicated with mailing lists. For example, the Wikipedia mailing lists are available through the portal
and can be accessed with a newsreader or webbrowser. In other words: Not only can mailing lists be read with an email or webmail client, they can also be read with a newsreader or BBS-style interface! Now try reading a BBS with an email client or newsreader.
I will not participate in any BBS. Of all the forums that the Internet offers, bulletin boards are among the worst.
Regards,
Erik
As i recommended to tomos, phpbb is the best open source (GNU) out there (phpbb.com). I will use their bb to illustrate counterpoints:
--- Erik Moeller erik_moeller@gmx.de wrote:
- Mailing lists are, by their very nature, decentralized. Any post is
replicated on hundreds of machines. This automatic replication makes censorship very hard and a total loss of data unlikely.
Whatever. paranoia. backups?
- Archives like the ones generated by Mailman can be imported into email
clients and searched locally at high speed. I have frequently made use of that feature to build high quality archives. The search function of most BBS systems, on the other hand, is far from optimal (I've seen many BBS which claimed to have a search, but where this search never worked).
phpbb is solid and well tested for years now: http://phpbb.com/phpBB/search.php
- Mailing lists keep a track record. It is easy and fast to see all posts
by a particular member, or everything written by yourself. With a BBS, you first have to figure out if such a feature exists, then wait for the server to perform some search. Server is down? Too bad, you'll never get that post you wrote 3 months ago now.
http://phpbb.com/phpBB/search.php?search_author=theFinn
- Mailing lists allow everyone to participate without a free online
connection. In many developing nations, Internet access is paid by the minute, and reading and replying to posts online costs money. Mailing lists can be conveniently read, responded to and archived offline.
you can 'watch' topics via email with phpbb. And i could easily hack in a reply-via-email option. There are many bbs/mailing lists out there...
- Mailing lists allow the use of a variety of email clients which all
have advantages and disadvantages. Everyone can use the software of their choice, with a user interface that suits them, without being forced to make use of an arbitrary web interface. This is of importance to handicapped users, for whom special email clients exist.
and special web-browsers....you wouldnt believe how much complaint of "aural" goes on in the mozilla.
- Good email clients make quoting and threading transparent and easy to
use. They interpret the reference ID in a message and thereby allow you to quickly navigate to the parent post that a message has responded to. Quoting and writing within a real text editor is also a lot more convenient than writing within a browser window.
http://phpbb-hpmods.sourceforge.net/phpBB2/posting.php?mode=reply&t=34
Thats my bb on sourceforge for a patch i made a while ago... try the [quote] feature, its quite clean.
- Bulletin board systems are slow. This is related to 4) -- in a BBS I
have to wait for each individual thread to load, for the "post reply" screen to load, for sorting options to affect my display etc. -- as with all web interfaces, you have a high additional latency as every aspect of the interface is generated "on demand".
I agree flat out.
- Bulletin board systems have a higher noise level. They allow no easy
client-side filtering, as many email clients do. Many BBS encourage the use of fonts, pictures, animated smileys, overlong signatures etc., often leading to very hard to read threads.
A good administrator of phpbb can produce very clean sites. Its very configurable and skinable
- Every BBS is different. Everyone is familiar with email, but learning
to use a BBS always requires making yourself familiar with its particular user interface and functionality.
You must not have heard of phpbb...it has quite an active development community both on the web, and on irc.freenode.net #phpbb
- Mailing lists can be easily moderated, even in groups. BBS usually
have after-the-fact moderation, where individual posts are censored or threads are locked. On a mailing list, posts can be pre-approved and individual members banned. With a BBS that does not use some ID confirmation method, we'll have the same banning problem we have on Wikipedia proper -- totally open access is not always a good thing. And if email confirmation is required, this only advantage of a web-based BBS goes away.
??? wikipedia has groups, individual user permissions, and IP based blacklisting...
Now its my turn.
phpbb allows for structure of topics. This would easily allow it to become the talk section for each article on top of its other duties.
as you can see from http://phpbb.com/phpBB/ there are 500,000 articles, well more than wikipedia ;-) and 160 users online at the time im writing this. you tell me of the performance?
However, if we can find a file-based bb that allows structure and is well developed, then that would be ideal.
Im also not aggressively inclined toward having a bbs, i just wanted to shed some light.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Don't get me wrong: developers of PHPBB & Co. are doing a good job -- but for our purposes, email is a much better solution.
-+- Erik Moeller erik_moeller@gmx.de wrote:
- Mailing lists are, by their very nature, decentralized. Any post is
replicated on hundreds of machines. This automatic replication makes censorship very hard and a total loss of data unlikely.
Whatever. paranoia.
You wouldn't say that if you had seen archives of hundreds of your posts disappear without prior notice -- not necessarily out of malice, maybe the bandwidth bill simply got too high. Mailing lists provide protection against such incidents. Even if you no longer have copies, one of the hundreds of subscribers will.
- Archives like the ones generated by Mailman can be imported into
clients and searched locally at high speed. I have frequently made use of that feature to build high quality archives. The search function of most BBS systems, on the other hand, is far from optimal (I've seen many BBS which claimed to have a search, but where this search never worked).
phpbb is solid and well tested for years now: http://phpbb.com/phpBB/search.php
Doesn't counter my main argument -- you have to rely on a central server for search, which is much slower and usually has less features, and when it isn't available, you can't search.
- Mailing lists keep a track record. It is easy and fast to see all posts
by a particular member, or everything written by yourself. With a BBS, you first have to figure out if such a feature exists, then wait for the server to perform some search. Server is down? Too bad, you'll never get that post you wrote 3 months ago now.
Doesn't counter the argument above.
- Mailing lists allow everyone to participate without a free online
connection. In many developing nations, Internet access is paid by the minute, and reading and replying to posts online costs money. Mailing lists can be conveniently read, responded to and archived offline.
you can 'watch' topics via email with phpbb. And i could easily hack in a reply-via-email option. There are many bbs/mailing lists out there...
Doesn't counter the argument above -- working offline is inevitably less convenient with a web-based solution.
- Mailing lists allow the use of a variety of email clients which all
have advantages and disadvantages. Everyone can use the software of their choice, with a user interface that suits them, without being forced to make use of an arbitrary web interface. This is of importance to handicapped users, for whom special email clients exist.
and special web-browsers....you wouldnt believe how much complaint of "aural" goes on in the mozilla.
Sure, but this is a big difference: An aural or braille web browser will read to the user everything that is on the screen in the order in which it appears on the page. Depending on the UI, this can make it very, very hard to navigate within a page. An aural email client is tailored for that specific purpose, all navigational elements are *part* of the aural interface. And let's not forget that a single button without an ALT tag can make a web UI unusable ..
- Good email clients make quoting and threading transparent and easy
to use. They interpret the reference ID in a message and thereby allow you to quickly navigate to the parent post that a message has responded to. Quoting and writing within a real text editor is also a lot more convenient than writing within a browser window.
http://phpbb-hpmods.sourceforge.net/phpBB2/posting.php?mode=reply&t=34
Thats my bb on sourceforge for a patch i made a while ago... try the [quote] feature, its quite clean.
Not as clean and fast as email, sorry. And yet another interface the user has to learn.
- Bulletin board systems have a higher noise level. They allow no easy
client-side filtering, as many email clients do. Many BBS encourage the use of fonts, pictures, animated smileys, overlong signatures etc., often leading to very hard to read threads.
A good administrator of phpbb can produce very clean sites. Its very configurable and skinable
And it's yet another problem you don't have to worry about when using a list.
- Every BBS is different. Everyone is familiar with email, but
learning to use a BBS always requires making yourself familiar with its particular user interface and functionality.
You must not have heard of phpbb...it has quite an active development community both on the web, and on irc.freenode.net #phpbb
What does this have to do with the above? Whether an individual BB has an active community is irrelevant, it is still just one of many systems out there.
- Mailing lists can be easily moderated, even in groups. BBS usually
have after-the-fact moderation, where individual posts are censored or threads are locked. On a mailing list, posts can be pre-approved and individual members banned. With a BBS that does not use some ID confirmation method, we'll have the same banning problem we have on Wikipedia proper -- totally open access is not always a good thing. And if email confirmation is required, this only advantage of a web-based BBS goes away.
??? wikipedia has groups, individual user permissions, and IP based blacklisting...
IP-blacklisting is unreliable because most IPs are dynamically assigned. It is also only available for non signed in users in the current configuration. Groups? Wikipedia has no groups. It also has no "individual user permissions" besides a simple is_sysop flag.
phpbb allows for structure of topics. This would easily allow it to become the talk section for each article on top of its other duties.
What a nightmare! The talk section for articles within a completely different system -- no more wiki style refactoring, no more proper archiving, no more single user experience. Thanks, but no thanks. Not that the talk pages cannot use improvement -- they would certainly benefit from some BBS-style functionality. But the wiki nature needs to be preserved.
as you can see from http://phpbb.com/phpBB/ there are 500,000 articles, well more than wikipedia ;-)
"Me too" is not an article. Have you counted the individual comments on all of Wikipedia's Talk pages? I thought not.
and 160 users online at the time im writing this. you tell me of the performance?
I haven't said anything about the performance other than about web- inherent latency, but now I will: The performance of a BBS is tied directly and fundamentally to the speed and availability of a central server. As you may have noticed, our central servers aren't exactly in the best form right now. A mailing list requires very little overhead -- no database, no webserver, just a script that tells the mailer daemon what to do. It could be run on a 233 Mhz PC. A PHP bulletin board on our main server will slow other Wikipedia processes down.
Im also not aggressively inclined toward having a bbs, i just wanted to shed some light.
Where there's light there is darkness ..
Regards,
Erik
On Tue, 2003-05-06 at 12:59, Erik Moeller wrote:
Don't get me wrong: developers of PHPBB & Co. are doing a good job -- but for our purposes, email is a much better solution.
The short response to Erik's reference for email over a BBS is essentially that for a power-user, with the talent, knowledge, and time to configure and use "good email clients" which make "quoting and threading transparent and easy to use", email is preferable.
The reality is that is not the case for most people.
The more important reality is that there should not be an additional barrier to entry in finding and using the discussion forum (currently in email form) above the barriers to entry to becoming a Wikipedia editor (which are web access, going to Wikipedia, clicking on "Edit this page" and possibly creating a user account).
Because the the discussion forum is currently in email form, there are several additional barriers to entry.
This is bad, and will never be a Good Thing.
Another basic, basic thing: since we're discussing Wikipedia matters, we really should be able to make links to Wikipedia entries in the discussion forum. We can't usefully do that with email.
But instead of having the argument about why a BBS would be better than an Email list, I recommend setting up a BBS, and letting practice decide.
The Cunctator wrote:
The short response to Erik's reference for email over a BBS is essentially that for a power-user, with the talent, knowledge, and time to configure and use "good email clients" which make "quoting and threading transparent and easy to use", email is preferable.
The reality is that is not the case for most people.
I don't accept that mailing lists present an additional barrier for most people. Almost everyone uses mailing lists -- from Yahoo groups on up -- and most people understand the concept implicitly. The user interface is one that they are already familiar with, i.e. their comfortable normal mail software, as opposed to a brand-new and generally idiosyncratic user interface for a bbs.
Because the the discussion forum is currently in email form, there are several additional barriers to entry.
But I don't think these barriers are very large, and not as large as the barriers to using a BBS.
But instead of having the argument about why a BBS would be better than an Email list, I recommend setting up a BBS, and letting practice decide.
I'm open to this idea, and I'm keenly interested in what the Japanese speakers are doing, and why they are doing it. I wonder if their reasons are similar to yours, or if they have other, unique reasons, having to do with Japanese language support in email or something like that.
Unless there's a way to gateway email conversations into a bbs, then the bbs is almost certainly doomed to failure, just due to inertia.
--Jimbo
Cunc-
The short response to Erik's reference for email over a BBS is essentially that for a power-user, with the talent, knowledge, and time to configure and use "good email clients" which make "quoting and threading transparent and easy to use", email is preferable.
The reality is that is not the case for most people.
While I agree that most people aren't "power users", most people are familiar with at least the basic functionality that their email client offers. So I do not see the "barrier to entry" you see. If someone cannot follow the instructions "reply to this email to confirm your subscription", it is questionable whether they can participate at all.
The more important reality is that there should not be an additional barrier to entry in finding and using the discussion forum (currently in email form) above the barriers to entry to becoming a Wikipedia editor (which are web access, going to Wikipedia, clicking on "Edit this page" and possibly creating a user account).
The mailing lists are for policy nerds, techies and masochists. Article- related discussions already take place on the respective talk pages, and for user help there's the Village Pump. I've already stated that I agree the discussion system on talk pages needs improvements - give me money and I will fix it.
Another basic, basic thing: since we're discussing Wikipedia matters, we really should be able to make links to Wikipedia entries in the discussion forum. We can't usefully do that with email.
http://www.wikipedia.org/wiki/The_Hitchhikers_Guide_to_the_Galaxy
Do you see an URL above, or has the string been magically converted into noise by your email client? What seems to be the problem?
But instead of having the argument about why a BBS would be better than an Email list, I recommend setting up a BBS, and letting practice decide.
Not necessary, the arguments against a BBS are sufficiently strong. The last thing we need is another forum, even if it's just experimental.
Regards,
Erik
The mailing lists are for policy nerds, techies and masochists. Article- related discussions already take place on the respective talk pages, and for user help there's the Village Pump. I've already stated that I agree the discussion system on talk pages needs improvements - give me money and I will fix it.
Heh...give me an admin account and *I( will fix it.
check this out:http://zesty.ca/criticons/
Then I summarized most of the issues here: http://meta.wikipedia.org/wiki/Talk_media (also on top level meta homepage).
discussion should continue on both media.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
The mailing lists are for policy nerds, techies and masochists. Article- related discussions already take place on the respective talk pages, and for user help there's the Village Pump. I've already stated that I agree the discussion system on talk pages needs improvements - give me money and I will fix it.
Heh...give me an admin account and *I( will fix it.
Define "admin account" and explain what you want to do with it. Set up a PHPBB? Yeah, right. If you want to improve the Talk page code, go for it:
http://wikipedia.sourceforge.net/
We await your patch at wikitech-l@wikipedia.org.
Regards,
Erik
??? wikipedia has groups, individual user
permissions, and IP based
blacklisting...
IP-blacklisting is unreliable because most IPs are dynamically assigned. It is also only available for non signed in users in the current configuration. Groups? Wikipedia has no groups. It also has no "individual user permissions" besides a simple is_sysop flag.
Wikipedia has language groups.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
wikipedia-l@lists.wikimedia.org