The BarCamp Wiki
Christopher St John
started locking my pages as they are vandalized, how do people
feel about locking all the pages as they are moved to the news
archive?
-cks
--
Christopher St. John
http://artofsystems.blogspot.com
Chris Messina
Chris Messina
Citizen-Participant &
Open Source Advocate-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412.225.1051
IM: factoryjoe
This email is: [ ] bloggable [X] ask first [ ] private
Frederic Baud
there may be an issue with making hard for legitimate participants to
modify those pages.
Do we have contacts with PBWiki to suggest feature requests to make
life easy for administrators?
Since these are manual defacements, could be simple things like:
1) preventing non-administrator to insert more than X times an
external link into different pages
2) give a simple way for an administrator to identify all the pages
modified by a user and do bulk reverts
3) etc
Just to be sure, what's the news archive? PreviousBarCamps page?
Frederic
Chris Messina
http://getsatisfaction.com/pbwiki
As for PreviousBarCamps and News Archive, they served a purpose once,
when I spent more time maintaining them... seems like, possibly, we've
outgrown the current structure of the wiki for single individuals to
prevent spam...? Thoughts?
Chris
--
Bryan Bishop
> The defacement and vandalism is getting to be depressing. I've
> started locking my pages as they are vandalized, how do people
> feel about locking all the pages as they are moved to the news
> archive?
How about a captcha system? See the recaptcha mod for mediawiki and
maybe something similiar can be implemented.
- Bryan
________________________________________
Bryan Bishop
http://heybryan.org/
Chris Messina
much and will mostly frustrate legitimate users.
It's hard to balance technology solutions with simply better policing
by the community... maybe we should add a page describing ways that
people can help garden the wik? Christopher, maybe start by
documenting some of the things you do to garden the wiki?
Chris
--
David Weekly
Do we have contacts with PBWiki to suggest feature requests to make
life easy for administrators?
Yes.
David Weekly
Founder & CEO, PBwiki
--
Did you know that more businesses use PBwiki than any other hosted wiki service?
Christopher St John
>
> Given that it's humans doing the editing, I don't think that'll help
> much and will mostly frustrate legitimate users.
>
> It's hard to balance technology solutions with simply better policing
> by the community... maybe we should add a page describing ways that
> people can help garden the wik? Christopher, maybe start by
> documenting some of the things you do to garden the wiki?
>
That should be done, of course, but it's only going to work in concert
with some of the other things discussed (like locking down old pages)
There's an awful lot of spam, and if you get behind just a bit it becomes
overwhelming. I just don't think it's practical to expect a small group
of humans to compete against an army of spam farmers using automated
attack tools (although it sounds like a fun movie :-) )
A big technical win would be the ability to detect (and reject) display=none
inline css, which seems to be a favorite trick. Detecting it after the fact is
nice, but still requires manual cleanup (see below)
Manual cleanup would be easier if the response time were faster. In fact,
that's the single biggest impediment to gardening right now: it can take up
to a minute to view the history for a page, and hitting "edit" gets you the
hiccup message maybe 20% of the time (or more on a bad day). I don't
want to sound too critical, I understand that the BarCamp wiki is a (very)
edge case as pbwikis go, but as far as technical fixes go speedier editing
and management would definitely help.
Chris Messina
new events so that the size of the wiki/history would be splintered
and would ideally improve response times?
I guess that would require a bit of engineering overhead and while I
don't expect PBWiki to do custom development for us, it would be nice
if we could be on the edge of improving PBWiki's scalability and spam
fighting...
David, any thoughts?
Chris
--
Frederic Baud
much more efficient in fighting spammers (true for every tool, e.g. as
a Drupal administrator, I see a lot of features I could use).
On the process side, there could be delegation of administrative
rights at the geographic level to trusted individuals and have any
administrator detecting a spammer on their pages warn the others.
Is there a simple ban feature in PBWiki? That would make enforcement
easier if geographic administrators could ban a user as soon as he
defaced one of their pages.
Frederic
Bryan Bishop
> Given that it's humans doing the editing, I don't think that'll help
> much and will mostly frustrate legitimate users.
The way that the recaptcha system is set up on mediawiki installations
is that it's only a once-per-login deal, and one at registration too,
or if you are an anonymous editor then one every time you edit a page.
And if a bot registers and a human logs it in, then you can ban those
usernames. I have always liked those "What's 2+2?" catpchas, actually.
Bryan Bishop
> Manual cleanup would be easier if the response time were faster. In
> fact, that's the single biggest impediment to gardening right now: it
> can take up to a minute to view the history for a page, and hitting
> "edit" gets you the hiccup message maybe 20% of the time (or more on
> a bad day). I don't want to sound too critical, I understand that the
> BarCamp wiki is a (very) edge case as pbwikis go, but as far as
> technical fixes go speedier editing and management would definitely
> help.
Alright, how about this? We are mostly programmers here, right? That
sort of lag is a serious problem on nearly any wiki. Most of these
wikis are using a MySQL database backend, or PostgreSQL, for which the
following will work as well -- let's write a quick perl client to
interface with the remote databases, and have it fetch the history of
the last 500 pages, and a quick comparison between the two articles
(maybe the 'diff' information, which would require some serverside
processing first), and then a quick yes/no interface for "keep the
changes" ("revert?"). This would require the community to designate a
certain person for cleanup duty, yes, but otherwise a good fix.
And if we do the captcha system, we would instead ask to ban a certain
user or not, or put up the user for later review, etc. We could dump
usernames on a certain page and ask the community for yea/nay.
Frederic Baud
illustrating the technical features PBWiki has to implement to make
the life of administrators and legitimate users easier. I have been
banging my head with spam problems on my MediaWikis deployments and
have nothing close to the attraction that BarCamp can represent for
spammers (just offering an easy prey because of MediaWiki). It is sure
- as the use of PBWiki is growing - that the current problems of
BarCamp's wiki are just a mild version of what's going to happen soon.
So I believe that David has here a good opportunity to improve
PBWiki's reliablity before paying customers face similar woes.
David, thank you for your help on this.
Cheers,
Frederic
On Mar 14, 11:04 pm, "Chris Messina" <chris.mess...@gmail.com> wrote:
> I wonder if it would be easier to some how "spawn" off new wikis for
> new events so that the size of the wiki/history would be splintered
> and would ideally improve response times?
>
> I guess that would require a bit of engineering overhead and while I
> don't expect PBWiki to do custom development for us, it would be nice
> if we could be on the edge of improving PBWiki's scalability and spam
> fighting...
>
> David, any thoughts?
>
> Chris
>
Chris Messina
anything useful in it perhaps for externally reviewing/comparing
changesets in bulk?
Chris
Sent from a typo-prone iPhone.
David Weekly
David Weekly
Manual cleanup would be easier if the response time were faster. In fact,
that's the single biggest impediment to gardening right now: it can take up
to a minute to view the history for a page, and hitting "edit" gets you the
hiccup message maybe 20% of the time (or more on a bad day).
Quick update - our Head of Operations and CTO are digging into this fulltime after having verified the issues (although not quite at 20%). Barcamp does provide a pretty impressive edge case in terms of overall activity, so I can verify that pretty much no other wikis on our system are seeing these issues, but solving them well for Barcamp will help make our system overall more performant (and less susceptible to DDOS). Thanks for your patience while we dig on this!
Eric Skiff
barcampnyc primarily because it seemed much faster and less error
prone, if that helps shed any light on the issue.
-eric
Sent from my iPhone - please excuse any typos.
Frederic Baud
I think that there are a couple of quick features that could make life
easier.
While I"m just watching a fellow under the name jix defacing BarCamp's
wiki, I think that it could be efficient to have some kind of "citizen
action" where someone like myself could report bad behavior through
the interface and the corresponding user would be banned of doing
anything for a fixed time like 1 hour. While we may have abuses of
such a feature, I think it could be interesting to test similar things
on BarCamp's wiki. Then it has to be the choice of the administrators
of any wiki to enable or not this kind of feature.
We have mainly seen manual defacements so far, and I'm a firm believer
in human policing features to stop the nuisance of this limited number
of individuals. Providing the tools should allow to easily fix this
problem.
But in a near future, I think we'll have to face more and more bots
targetting PBWiki. The infamous Del.Blogger was an exemple of such a
bot on BarCamp's wiki. Could be interesting to anticipate this by
offering easy recovery features to administrators (like multiple
deletes of a specific user - like Del.Blogger changes).
Thank you for your actions,
Frederic
Frederic Baud
and the likes, we have a collection of spammers inserting (fortunately
invisible) links on the pages.
While things have just been irritating so far, this could become
really devastating if we do not have protection against pure
vandalism.
David, any thoughts?
Cheers,
Frederic
Chris Messina
David Weekly
and link to an offending change, that would help us ban those bastards
and also improve our pattern-matching for automated detection of spam
edits.
We're really sorry there are abusers here; we're making a best effort
to keep them out, though, and think you'll find our public wikis get
substantially less abuse for their traffic levels than many other
equivalent systems (e.g. forums).
-David
On Tue, Apr 22, 2008 at 2:44 AM, Frederic Baud <freder...@gmail.com> wrote:
>
--
Chris Messina
Frederic Baud
offenders lately (don't know how we could get his IP address and that
won't be really meaningful anyway because of ISP proxies).
David, when you click on the name of a user on the "Changes" page,
could be nice to access a page where you could choose between
"mail" (the current default) and "report an abuse" that would mail the
IP address to your support team. Plus, I've always been concerned with
having my email address appearing on this page because of the bots
that could snap it up for future mail spams.
Cheers,
Frederic
On Apr 23, 1:41 am, "Chris Messina" <chris.mess...@gmail.com> wrote:
> Thanks David -- the homepage was vandalized again about 20 minutes ago:http://barcamp.org/sdiff.php?first=FrontPage&second=FrontPage.2008-04...
> And previously:
>
> http://barcamp.org/FrontPage.2008-04-21-22-20-15
>
> etc.
>
> David, how do we find the offending IP addresses?
>
> Chris
>
>
>
>
> > If folks could email supp...@pbwiki.com with the offending IP address
> > and also improve our pattern-matching for automated detection of spam
> > edits.
>
> > We're really sorry there are abusers here; we're making a best effort
> > to keep them out, though, and think you'll find our public wikis get
> > substantially less abuse for their traffic levels than many other
> > equivalent systems (e.g. forums).
>
> > -David
>
Frederic Baud
I really think we "do" have a problem. Spammers are currently probably
the largest contributors on the BarCamp wiki. I can't anticipate that
things will turn for the better without any drastic actions. It's
really getting time consuming to check pages I'm most involved in,
just to know if they have not been defaced by the bunch of misfits who
are currently predating the site. I can't believe that there are no
quick actions like "preventing a single user to modify more than 4
different pages per hour" that could be implemented fast. If you
can't, then "we" do really have a big problem.
Cheers,
Frederic
On Apr 23, 7:54 pm, Frederic Baud <fredericb...@gmail.com> wrote:
> Right, zepter with email address dzep...@o2.pl is one of the worst
Christopher St John
let's say, 6 months. Is there any way to have a lock message that
says something like "This page has been locked due to defacement
by spammers. If you need to edit it, please email a Wiki admin at
x...@yyy.com and they will unlock it for you" And then have a mini
mailing list with a dozen volunteer admins who can do the unlock?
Or, even: "Please email x...@yyy.com with "unlock <pagename>"
in the subject line and the page will be unlocked in about 5 minutes
or so". (And have a bot to do the work)
Or even "press this button and the page will unlock in 15 minutes"
(if less work required, need to make the wait longer).
Would the second two disrupt the spammer's workflows sufficiently
to deter them? They're amendable to automation, but it may not be
worth solving just for the BarCamp wiki...
Frederic Baud
If we do not get any additional functions from PBWiki quick, I agree
that we should try to find a solution with what we currently have on
board: the standard Apollo 13 exercise. We could start locking some
old pages to reduce the appeal for spammers, and try controlling them
for the pages that are currently in use. But we may need to put
warning message by hand because we won't have the automatic messaging
function. We could instead link the message to a specific page where
we would list the volunteer wiki-admins that can be contacted.
I must say that I would rather have the quick implementation like "no
more than 4 different pages per day", I'm sure this will immediately
reduce the flow of spams to a very manageable level.
Cheers,
Frederic
Christopher St John
>
> I must say that I would rather have the quick implementation like "no
> more than 4 different pages per day", I'm sure this will immediately
> reduce the flow of spams to a very manageable level.
>
I'm -1 on that change, it might reduce the flow of spam but it would
increase the number of admin requests (it's reasonably frequent
that someone needs to edit multiple pages), which nets me 0 in
terms of time saved.
Christopher St John
>
> and also improve our pattern-matching for automated detection of spam
> edits.
>
For the BarCamp wiki there's just one pattern right now, and it's highly
accurate (legit users don't do it) and easy to detect:
<span style="display:none"><ul><li><a href="http://spamas.html">
Buy Spam Online</a></li></ul><ol><li><a href="http://spam.html">
Buy Spam Online</a></li></ol></span></span>
<u style="display: none">
<a href="http://crud.tr" title="mırc, mirc" target="_blank">mirc</a>
<a href="http://crap.tr" title="mırc, mirc" target="_blank">mirc</a>
<a href="http://asshat.com" title="mırc, mirc" target="_blank">mırc
</a>
anything with the string style="display:none" can safely be assumed
to be spam. If you want to get more specific, anything with display as
none that contains a link might be more accurate (but is there ever a
reason to have invisible content on a wiki page?)
Chris Messina
Frederic Baud
I don't feel that defacement is subsiding, quite the contrary.
While I'm a bit disappointed that by now we don't have new functions
in PBWiki to help fighting this. I can understand that PBWiki has some
paying customers to serve first. But I still think that BarCamp's wiki
is a nice shop-window, and I must say that the window does not look
really clean today.
I think that we are many that will appreciate that Chris, Christopher
or anyone with administrative rights take some stark decisions so we
get less of these spammers that start to entirely disrupt the use of
the wiki.
Cheers,
Frederic
Jeroen Vermeulen
> I don't feel that defacement is subsiding, quite the contrary.
>
> While I'm a bit disappointed that by now we don't have new functions
> in PBWiki to help fighting this. I can understand that PBWiki has some
> paying customers to serve first. But I still think that BarCamp's wiki
> is a nice shop-window, and I must say that the window does not look
> really clean today.
>
> I think that we are many that will appreciate that Chris, Christopher
> or anyone with administrative rights take some stark decisions so we
> get less of these spammers that start to entirely disrupt the use of
> the wiki.
Sorry, I haven't followed this, but if it's running on Apache, have a
look at mod_security. This lets you block requests (including posts)
based on lots of criteria. What's worked wonders for me is blocking
anonymous posts that contain URLs, and forwarding them to a page that
explains how to "mask" a URL so that it will get through (but of
course make it useless to spammers who just want clicks or Google
rankings for their sites).
Combine it with fail2ban, a log reader that lets you block repeat
offenders at the firewall level, and you've got a really powerful
defense.
Jeroen
Christopher St John
>
> Sorry, I haven't followed this, but if it's running on Apache, have a
> look at mod_security.
>
So:
Which appears to be a complete fake BarCamp, set up to collect SEO
spam links. Which sets the bar kinda high for technological solutions.
It's just the tip of the iceberg. I started going through the pages in
alphabetical order, and it looks like as many pages are fake or vandalized
as not.
Holding new pages for moderation seems like it would be a good start,
but as far as I can tell you can't do that with PbWiki. In fact, PbWiki really
doesn't have the tools or infrastructure to handle really large blogs and
they don't seem to be focused on that area (not meant to be a jab, it's
fair enough that we're on their primary business path)
I think it's probably time to start looking around for alternatives that better
fit the needs of BarCamp. Not sure what to do in the mean time...
Frederic Baud
of PBWiki. What version is BarCamp running on: Silver, Gold or
Platinum?
I agree that if PBWiki is not going in that direction and is not
interested in making developments for sites like BarCamp's, it is
probably sensible to move to another tool before things collapse. I
suppose it could make sense to create a RequestForProposal page where
everyone could list the features that would be necessary and a list of
nice to haves. We could then ask some wiki hosting sites if they are
ready to host BarCamp's site for free, what features they do provide,
and what features they are ready to put in their road-map.
My 2 cents,
Frederic
David Weekly
> in PBWiki to help fighting this.
We've been very responsive to the BarCamp community and trying to
produce a wiki solution that serves you well. And I think you'll find
that PBwiki is absolutely the best wiki host for BarCamp and has far
less spam and maintenance overhead than hosting it yourself and trying
to throw Apache modules at the problem.
All of the spam attacks we've seen are coming from regular humans -
Chris Messina is right to note that adding CAPTCHAs would do nothing
to lessen the burden. And while we'll be adding rel=nofollow (and
already added in display:none blocking for BarCamp), history at other
sites seems to indicate that does little to deter spammers from
continuing to attempt to plaster their URLs all over a site. We can
look at implementing a URL blacklist for editing or other mechanisms
and are open to your suggestions. But I think you should be careful
about assuming that moving to another solution is going to make your
spam problems any better at all.
PBwiki has been providing BarCamp this service for years at no cost,
with no advertising, offering the full premium version and full
support to the community. Many of the core PBwiki employees are on
this list. We're here for you.
Feel free to comment on or off list on ideas you have on reducing spam
on BarCamp.
Sincerely,
David Weekly
Founder, PBwiki
Christopher St John
>
> Feel free to comment on or off list on ideas you have on reducing spam
> on BarCamp.
>
1) the option to filter any edit with display="none" (or variants thereof)
would eliminate 90% of the current defacement.
2) the ability to filter out specific url's would eliminate the majority of
the rest (since most of the spam points to the same sites again
and again)
3) the ability to retroactively apply spam controls to existing pages
would be huge.
4) pagination of the users list would help (there are thousands, so
converting somebody to read-only can take several minutes)
David Weekly
> would eliminate 90% of the current defacement.
This is already done for <div>'s (it was implemented for BarCamp)
which is why the spammers switched to using <noembed> and <u
style="display: none">. We're updating our filters as I write this.
> 2) the ability to filter out specific url's would eliminate the majority of
> the rest (since most of the spam points to the same sites again
> and again)
A good suggestion, though I would worry that tinyurl, etc, would make
this a challenging race to win.
> 3) the ability to retroactively apply spam controls to existing pages
> would be huge.
And a dangerous bulk-shoot-self-in-foot tool. But we'll think about this.
> 4) pagination of the users list would help (there are thousands, so
> converting somebody to read-only can take several minutes)
Absolutely agreed on this. We're revamping our user management system
to be able to better manage thousands of participants (needed for
site-wide corporate deploys anyhow), so you should see some
improvement in this in the coming weeks.
-David
Christopher St John
>
>> 2) the ability to filter out specific url's would eliminate the majority of
>> the rest (since most of the spam points to the same sites again
>> and again)
>
> A good suggestion, though I would worry that tinyurl, etc, would make
> this a challenging race to win.
>
hmm, is there ever a legit reason to use a tinyurl in a wiki? i'd be willing
to block those entirely on the barcamp wiki, but it would obviously have
to be configurable. but it's an arms race, and nobody expects
a long-term solution, just ammunition to get through this battle :-)
>> 3) the ability to retroactively apply spam controls to existing pages
>> would be huge.
>
> And a dangerous bulk-shoot-self-in-foot tool. But we'll think about this.
>
just identifying the pages might be enough. a "potential
spammed pages" report or something, then give the ability for a human
to select and bulk-delete. or something. i'm pushing on this one because
i did a quick run though a sample of the existing wiki pages via the "all
pages" report and got really depressed...
i especially like solutions that help an admin use their human judgement
rather than totally automating. power-tools to make humans stronger rather
than robots to replace them. in the longer-ish term i think that's the only
possibility, because as the fakecamp pages show, that's what the spammers
are doing...
and, of course, as always, thanks. i've tried to be careful not to sound
ungrateful, it's just that cleaning up spam puts me in a bad mood :-)
David Weekly
sending Nathan (our CTO and the guy that does the anti-spam filters)
the spam-diffs. This should help us improve our spam filters to better
weed out these a**holes.
-David
--
Christopher St John
>
> I've just now spent some time cleaning up some Barcamp pages and
> sending Nathan (our CTO and the guy that does the anti-spam filters)
> the spam-diffs. This should help us improve our spam filters to better
> weed out these a**holes.
>
ok, this one may just be me failing to rtfm, but is there a way to turn off
comments entirely? there doesn't appear to be a legitimate use for them
on this wiki (since the comments on page content should generally go
inline), and they're an attractive nuisance.
Frederic Baud
Here is already a quick list compiled from my earlier comments (so
excuse the conversational aspect of some of the points that I just
copied and pasted).
1) preventing non-administrator to insert more than X times an
external link into different pages
2) give a simple way for an administrator to identify all the pages
modified by a user and do bulk reverts
3), I think that it could be efficient to have some kind of "citizen
the interface and the corresponding user would be banned of doing
anything for a fixed time like 1 hour. While we may have abuses of
such a feature, I think it could be interesting to test similar things
on BarCamp's wiki.
single user to modify more than 4 (or any number set by the
administrator)
Frederic
On Jun 19, 9:31 pm, "Christopher St John" <ckstj...@gmail.com> wrote:
Christopher St John
>
> I've just now spent some time cleaning up some Barcamp pages and
> sending Nathan (our CTO and the guy that does the anti-spam filters)
> the spam-diffs. This should help us improve our spam filters to better
> weed out these a**holes.
>
Dave,
I appreciate your effort, but you've got to understand that
some simple hardcoded spam filters are just not sufficient. I've
locked the front page semi-permanently, and it looks like we're
going to need to lock down the entire Wiki for the forseeable future.
Better bulk-editing tools are desperately needed, as well as the
ability for Wiki admins (not just PbWiki staff) to edit the spam filters
to respond quickly (and retroactively apply them, regardless of the
risk of newbies shooting themselves in the foot)
But's that's just the beginning.
I'll try to find some time to research how "industrial strength" Wikis
like Wikipedia handle this sort of thing (I suspect it's mostly human-
level process plus the technology needed to monitor and enforce
the process, but I'd like to know the details). It might be an option
moving forward that allows a truly open wiki without the current
mess.
-cks
Christopher St John
>
> I'll try to find some time to research how "industrial strength" Wikis
> like Wikipedia handle this sort of thing
>
In retrospect, I see that this sounded like it was suggesting that PbWiki
is not "industrial strength". That suggestion would be both factually
incorrect (I see that PbWiki has more total pages than Wikipedia)
and not at all what I meant.
A better way to put it would be to say that I believe that the requirements
of the BarCamp Wiki are more similar to a massively collaborative system
like Wikipedia than to the Wikis normally supported by PbWiki. I base this
on the way, for example, the admin tools are obviously optimized for a
different page/user mix than the BarCamp Wiki has.
Which is fine, since PbWiki is a great solution for many, many people.
I just worry that it's unreasonable to ask PbWiki to totally revamp so much
of its admin interface to support just the one Wiki, especially when the
changes are needed very quickly. It just doesn't seem fair to ask that
level of change when PbWiki has already been so generous with time and
resources.
Bryan Bishop
> Better bulk-editing tools are desperately needed, as well as the
> ability for Wiki admins (not just PbWiki staff) to edit the spam
> filters to respond quickly (and retroactively apply them, regardless
> of the risk of newbies shooting themselves in the foot)
For bulk editing tools I recommend directly interfacing with the
database or some very well thought-out scripting frontends. I'm not
aware of anybody implementing this on large wikifarms, but allowing
shell access and modifying of the local database accounts wouldn't be
too terrible. Sourceforge does it, for instance.
- Bryan
________________________________________
http://heybryan.org/
Frederic Baud
Looking at the defacement on the last couple of days, I'd think that
point 4 could be quite efficient in limiting the impact to a
relatively manageable level (e.g. a guy under the "pseudo" francisabey
has recently been inserting links in way more than 4 pages in a single
hour).
Cheers,
Frederic
Christopher St John
>
> http://api.pbwiki.com/ - have at you. :)
>
I requested API access for the BarCamp Wiki a couple days ago,
but haven't heard back. Other than mailing a...@pbwiki.com is
there anything else I need to do?
Frederic Baud
Any chance that PBWiki will implement something like point 4 anytime?
If yes, when can we expect it?
Current defacement is making things really hard and I'm experiencing a
lot of support costs continuing using the wiki to promote events I co-
organize under the current conditions (and I'm not talking about
registrations because I believe this no longer makes sense to maintain
official lists on the wiki and personally use eventbrite for handling
a safe registration process).
Thank you for your answers,
Frederic
Dr. Peter Troxler
mailing list just before yours: http://upcoming.yahoo.com/group/75/
also: slighly annoying to have your issues on this mailing list all
the time -- and it does not help to increase credibility of barcamps
either
just my 2p ;-)
/ Peter
Dr. Peter Troxler
[ k n w l d g ]
---------------------------------------
the ability to think differently
is more important
than the knowledge gained.
--------------------------------------------------------------
DISCLAIMER:
This email is intended for the personal and private use of the
individual addressee(s) named above and may contain information that
is confidential, privileged or unsuitable for overly sensitive persons
with low self-esteem, no sense of humour or irrational religious
beliefs. If you are not the intended recipient, any dissemination,
distribution or copying of this email is not authorised (either
explicitly or implicitly) and constitutes an irritating social faux-
pas. If you are indeed the indended recipient, you should still take
the utmost care in redistributing this email in order not to make this
item of your personal use public too widely. Unless the word
absquatulation has been used in its correct context somewhere other
than in this warning, it does not have any legal or grammatical use
and may be ignored. No animals were harmed in the transmission of this
email, although the kelpie next door is living on borrowed time. Those
of you with an overwhelming fear of the unknown will be gratified to
learn that there is no hidden message revealed by reading this warning
backwards, so just ignore that Alert Notice from Microsoft. However,
by pouring a complete circle of salt around yourself and your computer
you can ensure that no harm befalls you and your pets. This email
constitutes a marginal contribution to global warming and the sender
has taken utmost care to counteract such less desired side-effects of
electronic communication by planting a virtual tree with every email
sent. These trees come from certified and managed nurseries and can be
deleted together with this email without causing any harm to humans or
the environment whatsoever other than the sacrament of oblivion. If
you have received this email in error, please add some nutmeg & egg
whites, whisk and place in a warm oven for about 42 minutes.
--------------------------------------------------------------
disDISCLAIMER: This disclaimer has been monkeyed from the Internet and
is distributed under a copy-left agreement. For more information
please consult http://yourauthor.org
--------------------------------------------------------------
<<-
Christopher St John
>
> why don't you just bin it and use what other ppl use, see post on this
> mailing list just before yours: http://upcoming.yahoo.com/group/75/
>
Upcoming isn't really a replacement for the Wiki.
> also: slighly annoying to have your issues on this mailing list all
> the time -- and it does not help to increase credibility of barcamps
> either
>
That's what this list is for, no? I mean, if you don't want to read about
organizations/community issues, this probably isn't the right list to
be subscribed to...
-cks
Frederic Baud
> > mailing list just before yours:http://upcoming.yahoo.com/group/75/
>
> Upcoming isn't really a replacement for the Wiki.
>
less than 5 other tools, including Upcoming, Eventbrite, FaceBook,..
At other occasions, we also used Crowdvine, Google groups,...
I think it makes sense to use as many tools as necessary, to reach as
many people as possible. But the thing is that we need a tool to serve
as a hub when organizing a BarCamp; and a wiki is probably the most
flexible tool for doing that.
To give the respective use that we see in the different satellite
tools we use - without implying that each one is the only or the best
for doing it - I think that:
- Eventbrite is quite good for handling registration and communication
with people who do register
- FaceBook is quite good to communicate with people that are in the
network of the event or close to people in the network
- Upcoming is quite good to let people who are not in the network of
the event yet, know that they could be interested
- Crowdvine is quite gook to let people who plan to attend discover
common interests and synchronize prior to the event
Plus, I believe that registering all the BarCamps under the
barcamp.org domain creates a lot of value, and this is why we have
this spammer problem
> > also: slighly annoying to have your issues on this mailing list all
> > the time -- and it does not help to increase credibility of barcamps
> > either
>
> That's what this list is for, no? I mean, if you don't want to read about
> organizations/community issues, this probably isn't the right list to
> be subscribed to...
>
you will never ever hear from me again. :-)