CMS20060930MeetingSummary
Meeting 2006 Sep 30 Summary (downloadable version on http://ana.aktivix.org/indymedia/cms)
CMS meeting saturday september 30th 1400 UTC in #cms
Please Read: http://techmeet.sarava.org/English/Notes
http://cats.revolt.org/cats-vii/indymedia/
http://techmeet.sarava.org/English/CMSProposal
Last Meeting logs: http://sindominio.net/~txopi/20060917-irc-log-cms.log
the agenda would be something like: 0 introduction (see separate file - ana.aktivix.org/indymedia/intros 1 reports on activities last 2 weeks 2 plan activities for the next week: other cmses, other people reviewing them 3 schedule a next meeting
small note: we're nowhere near making decisions... this is a general discussion with a certain amount of structure
2 updates from the last week
toya: in brasil 3 kids started this cms from zero is with php and perl it includes some other features that envolves jabber to give more features for the users the whole goal of this project is to have virtual communities builded with those features on a cms that inst centralized..which can be moved around easily. they are working on a presentation about it.
ryan: in san francisco we have a dev server we are putting zope/plone/etc on, then people can play with the installation/demo/whatever. it could be used for other installations but for at least the next 10 days or so, we want it to be only zope. they heard bout indymedia idea of working on a cms and that is why they asked me to put this up on this meeting ;)
ryan: deadline for finishing sf-imc changes to sf-active (adding captcha and moving sf-imc into sf-active) is october 11th midnight, so it wont be until after this that the sf-active cms report is done
Zapata intends to get back into this project in the coming weeks
kwadronaut asks people to be specific in their reports, giving examples etc, not "this will be in the next release comments", for easy comparison afterwards
ryan would add deadline for adding new CMS'es to evaluate, or a deadline for CMS'es to be evaluated, and if someone hasnt evaluated a CMS by that time, we find someone else to do it? ryan: at some point, we have to come up with a timeline or things will drag on forever
Zapata proposes an informal deadline for reports... like after n weeks there should be some sort of social control process - need any help, should someone else take over
how easy the migration would be from the existing ones to it should be a topic on the evaluation - for a second round with a short list of cmses
boud: we forgot a set of criteria for evaluating cmses: open-minded developer community to the list of requirements or "social criteria of the development communities of the software package and the underlying language/packages [java/zope/ruby]" and possible long term dependencies, getting too close to the US army, and so on (i know GPL is free), but i think we need to at least list these criteria and have them available for decision-making(pointed that it is already there, under "healty community")
http://sindominio.net/~txopi/20060910-irc-log-cms.log
Zapata: "social criteria of a development community" is even more subjective than the other features, so I would suggest we do not spend too much time in this phase on this, but leave it to the short listed cmses
magduv: ru-imc once migrated from Active to Dada couple years ago and we are still not in good form, and we would think twice before next migration.. and probably other collectives who experienced migration too
dannyp: specifically with the case of dadaIMC, the strain it puts on database servers makes it a difficult choice for collectives to host long term. This is why sites like New York and DC have problems under high load despite having large amounts of computing power available to them. if the new CMS is easy to host and has reasonable technical requirements, then I imagine that collectives that currently host dadaIMC would be eager to encourage migration to the new. We need to be evaluating, from the beginning, is this sustainable in terms of technical resources (computing power, developers) - discussion of things like platforms and languages can't happen too soon IMO.
ryan: a lot of these topics, they should be pushed into the second phase of evaluation although people doing evaluations are of course free to report on them in advance so that we find out in the first phase
Zapata: indeed the scalability and performance characteristics are on the list
kwadronaut proposes oscailt to to evaluate and will write e-mail to collectives that use it and update wiki:
http://techmeet.sarava.org/English/CMSSurveyList
It is agreed that we will try to run multi-lingual meetings once a month and english meetings the other weeks
ryan: there is a big developer base in italy that we are losing by not outreaching to them jebba notes autistici is doing lots of work....
ana will summarise previous #cms meetings and translate summary to spanish...
toya will try to bring the brazukas
summaries page:
http://techmeet.sarava.org/English/English
to set up meetings: http://www.timeanddate.com/worldclock/meeting.html
Next meeting: 1700 UTC, october 8th
ryan: i think we need to develop 1) a good internal analysis on that and 2) an easy way to convey it to users
next CMS meeting october 8th 1700 UTC in #cms | Please Read: http://techmeet.sarava.org/English/Notes | http://cats.revolt.org/cats-vii/indymedia/ | http://techmeet.sarava.org/English/CMSProposal
(an animated conversations on whether we like more, captchas or link spammers, ensues - informal discussion)
captchas don't work, and the beginnings of the captcha-beating industry are already developing. having more administration be inline would also make it easier for collectives to do the actual task, and closing stories to new comments at a certain age would reduce the number of potential places for spammers to target. these solutions will also make it easier to deal with right-wing trolls and the like, who will not be deterred by captchas
captchas work, i work with criminal internet scumbags, i've lived with criminal internet scumbags: they hate captchas and it has effectively stopped the spam attack
they have also, in most cases, effectivelly stopped visually impaired users, they are not the only solution for dealing with spam, nor are they a permanent solution - there are already reports of companies in economically oppressed portions of the global south using human labor to solve captchas
trolls are best dealt with with 1. easier hiding of comments (inline administration), and possibly 2. bayesian analysis, CAPTCHAs don't even begin to address trolls
if they have to pay people a few cents an hour, that constitutes a barrier...
yes, that's true. but it's not foolproof, and the industry is growing, and I don't think we're far from seeing more and more linkspammers willing to pay that
anyhow, my point is, don't allow CAPTCHAs to make you lazy about implementing real, long-term solutions for content regulation and to remember that CAPTCHAs are not accessible (many of them aren't, that is)
i still find it a great idea to have a *publish on all indymeidias* *button. making better use of syndication will hopefully reduce the desire of non-spammers to post to multiple IMCs... ...or to put it another way, if we make better use of syndication, hopefully collectives will feel comfortable hiding things that don't belong on their local
if anything, user accounts are an increased measure against link spam, because it allows personal filtering and trusted users, which are more sophisticated solutions to spam than captcha's are
captcha's are working for us (sf-imc): spam protection through identity keys (via user accounts). it's interesting to see these solutions you showed us; what's nice with slashdot's model, is that anonymous cowards can still get modded up to be seen. were it not for modding up ACs, I'd never read an AC's post... my concern is that any identity-based solution might make it harder for anonymous contributions to be seen
ur constraints against IP logging make some things harder for us. It won't surprise me if this is one of the few things we'll need to roll our own for, but it's not like we'd be the first to use bayesian analysis
spammers use tor
the most effective systems to detect spam (into email, blog's comments...) is to analize the content- not agents, ip, etc. bayesian analysis!