Personal tools
|
CMS20060910MeetingSummaryFrom techmeetCMS20060910MeetingSummaryCMS 2006 09 10 MeetingLog - summary (available here for now for easy download: http://ana.aktivix.org/indymedia/cms)the goal of this meeting will be to:
Agenda: 1. Introduction 2. A clarification on the proposal, including a definition of the goal and opportunity for Q&A 3. Definig the first tasks: organization, CMS survey 4. Structuring the CMS requirements lists 5. Establish CMS review procedure 6. CMS brainstorm 7. CMS review assignments 8. Mailing list, Wiki 9. Next meeting intro from Zapata: During the techmeet in Sao Paulo, a group of indymedia-affiliated techies have discussed a proposal on the future of indymedia CMSes, given the structural understaffedness of the various codebases as well as the fact that, feature-wise, the world outside is way ahead of us (see for instance sites such as youtube). the idea is to, instead of developing multiple indymedia-specific CMSes, to look for a single non-indymedia CMS and focus on customizing it for indymedia. a more detailed proposal text is available on http://techmeet.sarava.org/English/CMSProposal (old link) People should read that in order to follow futher discussions. Zapata has already asked several people not present in sao paulo what their opinion was... and would also like to give the opportunity to people here to vent their opinions, ask questions and so on. txopi wonders if it is clear that althought we choose a cms outside the customization work probably will be quite big, and when new versions and features are added tho the codebase, the manteinance work will be similar to the work we/zapata is doing to mantain this indymedia's cms Zapata responds that the amount of customization work will depend a lot on the exact CMS we would choose, but naturally, we won't find a CMS that will be fit for all CMSes straight out of the box. One part of the proposal is also that we would join forces... i.e. developers / admins /templaters from different codebases would work together on 1 project, and generally, the bertagazreal benefits from this proposal will be reaped in the future, not in the present. The maintainenance work in the future will, hopefully, be a lot less than what we do now: right now we also must maintain basic CMS functionality, not just indymedia-specific functionality "non-indymedia" CMS means CMSes other than mir/sf-active/dada? question: will we exclude mir/sf-active/dada from the list of candidate CMSes, or will we exclude all CMSes which are listed on http://docs.indymedia.org/view/Devel? ryan doesn't think it necessarily excludes indymedia CMS'es. a key requirement is a wide developer base, Zapata is more pessimistic, indymedia CMSes really lack the vitality of a sustainable project, but it's ok to consider them anyway I guess bertagaz asks what is the opinion of sf-active people about that? Would they join this initiative? Keep developping sf-active? I'm not sure they are here ATM... PseudoPunk if the cms proposal comes through I jump on the train for sure. so will ryan init thinks that it will be very hard to find a matching existing CMS, we would have to adapt our "fork" each time the original code changes. We have accumulated a lot of knowledge about what it is exactly that WE need. There is a lot of mistakes, we would not do again. So maybe it'll be less work to start a new codebase from scratch, using existing frameworks, like Zope or Ruby-on-Rails. But the evaluation will show that. (speaking of "web-frameworks" I thought of zope/RoR not php.) Zapata notes a perfect match will be impossible to find, but hopes as close a match as possible will be very useful. I wouldn't think we should fork the cms, we should find a CMS where customizations are easily made and are maintainable across different versions of the CMS. The knowledge we have accumulated we can employ both in the customizations but also in the original CMS, if applicable: nothing stops us from contributing to the CMS. zope is definitely a candidate. There's a lot of reflection and re-organization that might be done, but... the future of indymedia will include the need for a CMS. zak thinks a lot of this will become clearer once we actually begin matching the features of existing CMSes to our requirements. but is not sure what we need is *that* out of the ordinary, that any patching won't be that widescale, and that a lot of it will be just about providing an easy way to get the site structures we want, plus a few security measures like removing ip logging
Concern about being carried away by the tide of a project with wide developer base and goals different from ours - also concerned about technical goodies getting ahead of social features of our software
one of the reuslts of the low sustainability of the current efforts is that we do not have a lot of time to add features and are thus lagging behind commercial efforts such as youtube, which is certainly a reason why a lot of our target audience uses youtube to post their activism videos RobBoston: Getting Web 2.0 architecture integrated is as necessary (like YouTube, as you did say) as security if we are to remain a viable new source. It's responding to user wants in addition to needs. But that security and sustainability is alleviated if we pick up an existing CMS. Zapata I'm a lot more pessimistic on rewrites from scratch: those tend to be open-ended projects with little certainty of completion. also, I would like to stress that I'm looking for a pragmatic and practical solution to get out of the very stressfull situation we are (or at least I am) in CMS maintainenance and support is really very time consuming for me now, and I hope we can create a different situation that will be easier to sustain txopi: i think it is too soon to decide anything about start from the scrach vs. customize an existing cms, i think we should analyze what we want exactly and how much the existing cms's fit out needs after doing that we can decide if it is worth to start from zero or not Zapata: I agree with txopi that, may the search for an existing CMS prove fruitless, we may consider rewriting one from scratch (or start from an existing indy CMS). however, finding an existing non-indy well maintained CMS will be highly preferable imo init: I think that the "mir"-problem (to few coders) is mostly a java problem, I think new technologies like web-frameworks enable much more ppl to help with development. Zapata: with indy CMS I mean the CMSes we actively develop, and we being mostly me and the sf-active people. dada is, if I understand correctly, without maintainer at the moment. the state of sf-active, a php solution, disproves your point I'd say, though I admit, being java-based doesn't make mir's situatiuon any easier ryan: to be fair, sf-active might have messed up by trying to write our own framework instead of using a wider-developed one assess what resources we have? as in, who wants and is able to work with what technologies? Devin will work on whatever decided if possible; very experienced in perl, fairly in php, enjoying learning ruby boud: If we use the term "we" in this way, then it seems to me that "we" = sf-active/dada/mir people and excludes many other indymedia developers/admins/templaters - IMHO if we do not look at the whole indymedia network, then we are already reducing who "we" are and reducing the number of us who can work together. Maybe i'm just being pedantic, but it seems to me important to remember that we're a big wide network. Zapata: this proposal has been made because of a concrete situation: a situation that is unsustainable. this happened to be my personal situation. I discussed it with others, and they seemed to agree I didn't discuss it with everyone, but ofcourse anyone who wants to join is welcome. I do not however feel the need to come to a solution that is acceptable or desirable by everyone the proposed action going forward with an evaluation: Zapata: there would seem to be two important steps to take
I would suggest to do 2. in the following manner:
On the structure:
http://techmeet.sarava.org/English/CMSWhatWeWant ryan: what we did in sao paulo is tried to be comprehensive in deciding on "must-have" functionality, so this can be the basis of evaluating candidate CMS'es also http://techmeet.sarava.org/English/CMSWhatWeHave zapata has made a template of what this will look like http://techmeet.sarava.org/English/CMSSurveyList http://techmeet.sarava.org/English/CMSWhatWeHave first Zapata: the list of current features so, in sao paulo we compiled two lists. the "what we have list": the features existing in the current indy CMSes we know (mostly mir and sf-active). the idea is that these features are absolute requirments: we'll have to have them before we can switch. of course these do not need to be present in the CMS per se, we might make them part of the customziation process but ofcourse the more there are out-of-the-box, the better and, it should of course be conveniently possible to add them if they aren't already there the second list consists of existing wishes by IMCs, we'd like to have them in the near future so... let's walk through the items on http://techmeet.sarava.org/English/CMSWhatWeHave one at a time, clarify them, perhaps change them... and at the end, perhaps add new requirements though, I think important for the process to keep this list as brief as possible, since more requirements to cover also means a harder search/customization process, etc requirements: please note and have it CLEAR: This isn't a wishlist, this is what we have. these are all essential features since we already have them 1. anonymous open publishing Devin: this seems assumed, yet some dada installs store hashed IPs which could easily be cracked by feds, etc. so anonymous vs. anti-abuse measures needs prioritization, clarification Zapata: indeed the anonymous requirement is an excellent example of something that is very indymedia-specific, and very important for us, which explains why it's at the top of the list ;-) 2. "distributed content storage" - meaning, the mir mirroring feature - be renamed "easy mirroring capability" if one looks at mir right now, it's easily possible to make multiple mirrors... by simply using an apache and rsync combination. this facilitates the ability to deal with a lot of hits. I, however, think a new cms doesn't necessarily have to do it in the same manner: I would be satisfied with a possibility to make multiple "light" mirrors, not necessarily static mirrors. "easy mirroring capability" summarized "if one machine is taken by surprise out of the network, no imc will suffer downtime as a result" proposal was to merge concept of scaling into "easy mirroring" and to "good performence on affordable hardware" zak: while mir has the ability to create multiple caches of the html pages easily, these aren't sufficient to recreate the site if the primary server goes down, which would be provided by, for example, mysql-style database replication of the underlying content storage. for some cmses, a set of squid accelerators could provide a similar performance boost to the mirroring setup Zapata: this feature is, if I'm correct, on the "what we want"-list, since we don't have it right now init: Producing flat-html files is the one "top-feature" of mir, applied right, you can do much more with it than just mirroring, Just move the whole document-root to a CD-ROM (or zipfile) and use it for offline browsing. ...and it helps bridging the digital devide. I have been looking for that in many other CMSs none does it out of the box. would be sad to lose that zak:it's useful, and have used it for offline demos myself in the past. however, like most things, it also comes with drawbacks -- the most apparent being the long regeneration time required after redesigning a set of templates Zapata: I would say that storing an imc on a cd is nice, but not a day-to-day requirement. indeed, very few cmses have this feature, but as zak says, there are drawbacks as well. I would still say that "easy mirroring" without requiring static mirrors is what we need, since this will cover the most important use of mir's static mirror feature, while your use can still be done by using a clever wget script or something similar chrisc: Bricolage, the Perl CMS, which runs www.theregister.co.uk and salon.com generates static content, however it don't have user accounts, anon publishing etc: http://www.bricolage.cc/ 3. syndication -out/in Zapata: most indymedia sites offer rss feeds, which are in high demand by users. some indymedia sites also import rss feeds; for instance indymedia.org uses it to come to a feature wire with features from all the different indymedia sites around. 4. search Alster: You're saying the features we already have are essential. I don't think this is the case for all of them. We sure have a lot of featuresin some of the CMS' currently being used by IMCs which are not essential ... and offten not being used either. so it would be better to make sure we have a deep looka t all the features currently provided by the several cms and sort out those which really are considered essential. I'm more afraid we're missing some which we already have, which are essential, but we're not aware of it, and which we may be missing in the future requirements list zak: i think we had "any other existing features" for discussion after this list anyway, so perhaps we can look at that further then? boud: we haven't got up it yet, but it seems to me that "send article to a friend" may not be essential - it seems turned off in most indymedias (i vaguely remember seeing it in use a few years ago) (maybe it was turned off because it was abused?) end Zapata: I'll now list a number of features that I suspect are not controversial...
It should be possible to host multiple IMCs on a single server
It should be possible to post images and videos, as these are used frequently by our user base
It should be possible to organise content (i.e. postings) by category, region, type, etc
Our often improvised equipment should be able to host the IMC sites
IMCs should be able to organise their postings in a custom way. Also it should be easily possible to add indymedia customizations. "customisability" is over-broad term compared to others in list Zapata: true, but it's also a broad requirement... one of the sources of this requirment was mir's feature of flexible producer creation and templating. perhaps I should work on a text to clarify it more concretely... I'll work on that... in the meantime, let's go on
The ability to present an IMC site in multiple languages for the navigational aspects, including the ability to easily add a supported language chrisc thinks the CMS must do UTF-8, but these days I think most do already...
PseudoPunk notes l10n is important too: 24h/12h times, d/m/y vs m/d/y, ...
The ability to allow users to anonymously translate postings These last features exist and both features are used frequently, though internationalization is the more widely used
The ability to comment / add clarification / updates to an article is an essential feature on most IMC sites
Unfortunately, a lot of IMC's have to deal with a lot of abuse: spam, trolling, ddos attacks. The CMS should offer the tools to deal with this.
moderation of open postings is one of the least favourite tasks in indymedia collectives. This should be as easy as possible. Think about removing spam postings, hiding racist postings entirely from sight (as is required in some countries)
A lot of IMC sites have a calendar where people can post there activism events on - mm sf-active has a calendar built-in. it's not in mir
Most IMCs work with an open newswire and a middle (feature) column with postings by the editorial collective.
We need a well documented CMS.
may not be that important
It should be possible to deal with varying number of hits on sites. If the G8 comes to town, an IMC site may suddenly have to deal with hits an order of magnitutde bigger. The CMS should make it possible to deal with this. scaling is a part of two aforementioned requirements imo Zapata would suggest removing the last too. Devin and zak, gus, txopi, Alster agree txopi: mir, sf-active and other have a lot more features zak: on scaling... i think it's a very broad term, as there are lots of ways in which a solution might scale or not. for instance, mir scales very well in terms of number of passive visitors due to the static mirroring capability, on the other hand, some of the producers don't scale that well as the size of the site increases so i think we have to be specific on what ways our existing solutions scale well re: affordable hardware -- experience with traven doesn't suggest we necessarily have that at the moment Other features we have (some of then were in the WhatWeWant list) are present in dada right now
in oscailt
requirements and/or areas of evaluation http://techmeet.sarava.org/English/CMSSurveyList we would like to fill out this page with CMS'es and "evaluation owners" the evaluation owners would set up a demo of the CMS, allow others access to it on request, and then report-back to this group. report-back about how the CMS did with each requirement/area of evaluation a template for this seen here -> http://techmeet.sarava.org/English/CMSSurveyReportTemplate so, we should go through this list and make sure these things are clear and consistent keeping in mind what this list is gonna be used for. lets stop there for a second we're talking about the list on http://techmeet.sarava.org/English/CMSWhatWeWant
the idea here is that we would allow user registration so, users could own a username and authenticate with it which would allow users to have identities that are protected. also, the idea was kicked around that it would be interesting to have the option of network-wide logins; i.e. if nessie registers at sf.indymedia.org, he can then go to germany.indymedia.org and log in as nessie with the same password. so, we want to evaluate CMS'es and understand how they handle user logins http://techmeet.sarava.org/English/CMSWhatWeWant angdraug: if we do network-wide logins, we sould do it jabber-style txopi it think worlwide login isn't so inportant as in a pool that someone did a years or so ago, the imc readers use to read in general just one imc see http://en.wikipedia.org/wiki/OpenID ryan: well, for instance, drupal supports this out-of-the-box ira 1
means that users should log into the site and we can control if they are admins and can edit the newswires or if they are users and have publishing/etc rights only we need to evaluate the moderation system for newswires and give a good reportback on that to understand all of our options related to rankings/users and admins moderating/etc what really means "user moderation - open editing" - is already part of WhatWeHave (samizdat) something wikilike: let the users moderate articles by making everything edittable like this: 1) sf-active allows admins to moderate articles as local, global, open, etc 2) so, what kind of admin moderation can we set up with each CMS 3) also, what are the options with users ranking articles, like 1-10 ratings of quality 4) also, what are the options with users editing their own articles
including: 1) ability for users to maintain a profile about themselves (page you edit the profile with) 2) ability for users to keep track of articles/media they have published and edit it later after logging in 3) ability to have "friends" or a network with other users 4) ability to have their own page, i.e. sf.indymedia.org/users/username which contains profile, list of articles they've published, their friends, etc (page others see the profile on) 5) ability for other users/admin to contact author? alex: i think indy should focus on anymous open publishing - not turning indymedia into myspace ryan: anonymous publishing is not going to go away. but there are other initiatives, crabgrass tries to be exactly a "myspace for activists" to add what was discussed in sao paulo alex: this raises a whole bunch of security issues here, and besides that, i think this should be discussed broader than just from techies. i'm all for eche checking out possibilities to give users more direct power for their and other articles and even comments but that's a big discussion, too ryan: this was discussed in-depth in sao paulo: first, i think sf-imc has locally decided to go this route and is gonna start implementing something ahead of schedule of cms development. second, security is definitely a concern. cops get paid money to develop social network maps of activists and we would be creating these maps for them. so, user education would have to be part of this. third, anonymous publishing is not displaced by this feature set. fourth, why this is wanted -- open publishing as we implement it now on IMC was innovative in 1999, it was innovative in 2000, but it is no longer innovative by itself. indymedia has been eclipsed by commercial open publishing websites which provide a richer feature set. so, it is disappointing but common to see many indymedia people now publishing on youtube or flickr, because the functionality is better, not only for media publishing, but for connecting with other people they know, sharing media, categorizing their media as a community, etc. the feeling in sao paulo was: if indymedia is going to continue to be relevant and useful for media-savvy activists, we have to catch up with corporate websites that are beating us feature-wise. all that said, i think the point is it will be up to each local IMC, whether they want to implement social networking functionality on their local IMC but if this is not even an option, then we have problems continuing to be useful as the open publishing world continues to innovate beyond us txopi: i think social network like features can be very apreciate for some users; the social filtering systems can be usefull for big cmi's. i think open publishing and this features are absolutely compatible, but the priority of them is completely different of course. as ryan explained, this features must be optional but i think quite people will use them. the fact that commercial servers use them is, i think, circunstantial Alster: the ideal system would be very modular, as such allowing to deactivate some (or maybe even all) of the (social) networking features. This will not be possible for all features, (for example: user accounts + action tracking + permissions). For this reason, I think social networking functionality should be listed as a very appreciated, but not as a required functionality. zak: i'm not that keen on the social networking stuff myself -- it's not really what indymedia is about to me. however, if there are IMCs which specifically want it (and it appears there are) it should be on the list. completely agree with alster that it should be an "optional extra" if implemented. RobBoston: Need to explain how to turn it off if desired, I say let's aim for including the features- important to document it. ryan: at techmeeting in sao paulo, the consensus was it should be available for local imc's and that without it, we're woefully behind everyone else
txopi: perhaps it isn't a very needed feature right now chrisc: good rss feeds, inc audio ones should cover pod casting? we should add rss/syndication evaluation; pod/vodcasting should be part of rss requirements, both incoming and outgoing rss; rss was already on the WhatWeHave list
zak: this is not necessarily a feature of the cms itself, but often of the database layer. eg mysql actually makes this quite easy angdraug: some CMSs are so complicated backups go beyond DB layer Devin: cms issues are things like: can the code handle distributed authentication (session cookies)
tracking of all previous versions of an article as it's edited, like wiki, cvs, subversion etc skep: some edits have to be made to black some private data/persnal data..so version control has to be used carefully..
chrisc: will we want accounts to be associated with a email address as an anti-spam measure? I assume we will... we can advise people to use email accounts with TLS like riseup.net for secutity and anonminity. i can't immediately see how we can't have email addresses with user accounts
which sfa and mir support now maxigas: we had a quite detailed plan worked out in theory in dijon, but i wouldn't explain it here. zak thinks this is the "customisability" we talked about in WhatWeHave ryan: we should figure out how the skins work (cookies, javascript, etc) as part of evaluating chrisc: customizable skins can be done via setting cookies with SSI or JS so I would see this as a templating issue and I would expect that we could make any CMS do this using CSS, so it's no big deal since it shouldn't be a problem kwadronaut: i note that accessibility should be taken care of too: js and css can't always be used for people using text browsers or audio translation (eg blind people) RobBoston: ideally, we'd like to begin with valid XHTML code underneath, otherwise it's going to be some ugly CSS work. txopi: if the content if done right, xhtml without css can be the "theme" for bling people chrisc: in addition to users setting CSS via cookies for customising the look you can set cookies with SSI for customising the content - the UK site does this even though we have static content - users can set the open or filtered newswire as their default on the uk site. i think that static pages with SSI still have enough flexibility to work maxigas: if the content doesn't work out, i think it's possible to write css esp. for blind people. ryan: yeah, the point here is just that we want to evaluate how skins are done with the CMS chrisc: and that a totally dynamic site might still be preferable for mirroring but i realise that this is drifting onto things discussed before...
Devin: I see more than one types of customizing possible here, some more important than others. CSS mod of site colors - less important maybe; abilty to select more/less on areas/topics (eg google news) more important. just note to include some detail on broad terms in specs as we write them
a couple CMS'es have it - info: http://en.wikipedia.org/wiki/GIS boud thinks we definitely need to do better than google news
which could be expanded to include a broad understanding of each CMS'es different "widget/media" handling
angdraug doesn't like licensing options: we should be as permissive about our content as possible. licensing quircks of GPL vs GFDL vs CC - do we want to be involved with? ryan: some local imc's do want this feature, though zak: this is something on uk's wishlist, although i understand angdraug's reservations txopi: there is a mailing list in indymedia to try to search the best license(s) for indymedia - we haven't reached any consensus, but it is clear that cc has a problem of compatibility list: http://lists.indymedia.org/pipermail/imc-license/ chrisc imc-license txopi: licensin options like dada is good, but it also helps people to chooose a lot different licenses wich is bad for imc's
kwadronaut notes that there is a gismailinglist on indymedia too, for interested people, not 1 message yet...http://lists.indymedia.org/mailman/listinfo/imc-maps ryan: each CMS'es functionality related to processing images on the server-side
txopi: p2p could be used also for static content storage (instead of db redundancy). if instead of using rsync for mirrors, we set a friend-to-friend network, we could create a very powerfull mirroring system difficult to silent
ryan: so, how the CMS provides this and if it is javascript, an applet, etc chrisc: there are free js wysiwyg editors that work wit texareas, and these could probably be added to any cms via the admin templates, so it's not a big deal imho
ryan: i think most people know what tagging is and can evaluate how its implemented in the CMS'es
boud: "easier install" should mean that the CMS gets into the standard distributions (debian, gentoo, i guess also redhat, etc.) so that people can type: aptitude install [IMC-CMS], answer a few questions and then they have a running system with reasonably safe default values, just like apache for example
chrisc: distro packages are more important than being able to install without root. install without root also implies no controlls over logging. i'm happy for root access to be needed to install indy cms's
http://techmeet.sarava.org/English/CMSWhatWeWant maxigas: it would be good to have some button to export a printable fanzin from the latest articles of the site via a one-button interface. feaute name = newspaper print export. ryan is gonna put something together for sf-active, and plone Zapata suggests zope, plone, dhrupal and proposes to start with a limited list and expand in a next meeting txopi wordpress ryan i would install plone somewhere, actually A-Kaser typo3 RobBoston Drupal ryan: everyone finds their own dev server :) Devin will do bricolage and invite help from others init typo3, I can write something about it, but in short, forget it, end of software-lifecycle... like a tanker dead in the water, worst of all, php. gdm might be able to offer dev vserver soon so we have a common understanding of requirements and we have the start of a list of cms evaluations/evaluators that list now is: ryan - plone and sf-active (php/pear) txopi - wordpress Zapata http://techmeet.sarava.org/English/CMSSurveyList Alster/A-Kaser - typo3 http://techmeet.sarava.org/English/CMSSurveyList zope Zapata http://www.opensourcecms.com/ lists a lot of online-demos of CMSs 10 volunteers here: http://techmeet.sarava.org/English/CMSSurveyList 25 people here: http://techmeet.sarava.org/English/CMSWhoWeHave Views |