Personal tools
|
CMS20060930MeetingSummaryFrom techmeetSummary of 09/30 MeetingMeeting 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! Views |