CMS20060917MeetingSummary
(available here for now for easy download: http://ana.aktivix.org/indymedia/cms)
it is noted that for the ppl who werent in the past meeting, if they want to also test/check some cms or even some of the ones ppl are reporting here, they can do so, please add your names to the wiki...
agenda: 0) Introduction 1) organizational topics, 2) reportback on cms research, 3) planning for next round of cms research 4) priorization of the features
Zapata: I fear some misconceptions exist about the nature of this project, for this I have prepared some clarification;
http://dev11.mir.dnsalias.net/clari.html
txopi asks about dada's situation.
Zapata has heard rumours that the sole developer of dada doesn't answer any emails anymore. Jonhattan confirms this: The dada list is dead; I haven't hear anything about migration plans but a little in imc-drupal-dev
boston asks how much do you think the ability to migrate the data itself should be a part of this very initial consultation?
Zapata: I would assume we will not have a big problem writing migration scripts to the cms we'd choose. given that, I would suggest we take this into account in a next phase, for instance when we have a shorter list of candidates
alex: was it actually consensus at techmeet to not start from scratch, but use an existing cms? ryan: i think the reason it keeps coming up is because one of the requirements we talked about was a bigger developer base, so not necessarily an existing cms; so, also discussed were adopting a framework; like a web framework that could be extended into something indymedia could use. so, i dont think there is a set decision about new/scratch cms/framework etc, but a requirement that was decided on is expanding the developer base (for example, by adopting a cms project which has an existing base)
Zapata: I think using an existing cms has more chance of succeeding; new projects often do not finish, but of course we may not find a suitable existing cms
ekes: If the base line is to create a mir sf-active clone from existing cms then we probably don't need to talk to the users - much. If there is the chance it is to do more than mir and sf-active now, and using a framework would give that scope (and some other cms') then involving people constructively will make it possible to find out what cms' there are there, and what people actually use.
Zapata: I think we should start focusing on a replacement but, we should keep in mind that IMCs will want new features and take that into account; that's why there are the two lists of features/requirements. I think the involvement of general users will become more important once there's a short list etc
It is agreed that the WhoWeHave will be changed for a WhoWeAre
there 2 lists:
imc-cms@lists.indymedia.org and cms@techmeet.org
some might be in one and some in another and some in none. during the past week we have discussing bout this and we all decided that we should pick one list for hte project; the diferencies here aren't just the domain, but also the lists configurations.
there's also cms@lists.indymedia.org which is pending for removal
toya proposes to discard that to not make more mess
five sort-of-parameters are listed in http://lists.indymedia.org/pipermail/imc-cms/2006-September/0912-ng.html correction: http://lists.indymedia.org/pipermail/imc-cms/2006-September/0912-ng.html
cms at techmeet imc-cms at l.i.org
- public archives: NO YES
- users can see full subscriber list: NO YES
- anonymous IPs: ??? YES
- other listwork ??? YES
- listed on lists.i.org NO YES
users can see full subscriber list: YES YES
gdm proposes: list should have public archive, should be available (i.e. at least linked from l.i.o), users visible but in non-spam format is advantage. also to use the list on lists.indy - but to have the list admins from the techmeet list also be admins if they want - i.e. Zapata and ryan (i think it is). also to make sure that everyone recognises we are appreciative of the effort to make the cms list as well by ryan, and this mainly seems to have been a miscommunication somewhere. so thank you ryan :-)
proposal agreed.
agenda item 2. reports on the cms review process so far
https://lists.indymedia.org/imc-cms http://lists.indymedia.org/mailman/listinfo/imc-cms both urls are correct ;)
ekes proposes: techs are telling their collectives that they are looking at making a like for like replacement of their cms mir/active/dada and that this will look and operate simlarly and that soon when some alternatives are there there will be questions asked like those about the alternatives
Zapata: perhaps it's better to do this at a later stage in the project. e.g. if we don't find a cms, then the solution may be different. naturally, we'll depend on the willingness of imc's to switch to any solution we make and for this I would say we should have all the existing features. but even if we can't achieve all existing features, we'll still have to realize the current situation isn't sustainable and we'll thus have to change it
doing now... 1 - is the cms reports 2 - a list of the things we should think of to do this project because from both we can have a base to move on
1. cms reports
ryan:ok so first, this site is worth checking out for us -> http://www.opensourcecms.com/; its only php/mysql cms'es but they keep a bunch of demo site's operating so you can check each one out.
ryan: update with sf-active is -> this one can give us a chance to evaluate how much of a web framework we are looking for, whereas something like drupal would allow us to extend an existing application framework with modules, sf-active represents a project which would extend a *web* framework. in this casekes notes drupal cache doesn't have my additionse, its PEAR. anyway, sf-active developers have been talking about tagging a release soon, talking about a timeframe of like 10-14 days, i think. then i can present to this group a survey of what PEAR offers and how hard it would be to extend this for an indymedia site
ryan re: plone, i set it up on a box in my house but i can move it to a box with an external ip. at the last meeting, pietro commented about plone being resource-intensive and this cant be understated. it consistently underperforms in high traffic situations, which may be enough for us to disregard it right away. but i'll have the CMS reports done in this coming week. and also, i started to evaluate mambo so i'd like to add that to my list
qwerty: plone does need a modern CPU at least 2GBs of RAM for production sites, but scales well for high traffic. this is certainly a disadvantage but it has many other technical advantages and shouldn't be dismissed just for that reason IMO toya: about plone: this thing with the traffic depends a lot on how u set it up. u can have somethign infront of hte zope doing cache. this resolve this part of t he problem
boston: I use it at work and we dealt with millions in Katrina donations without having the site go down. I would like to see ryan's traffic numbers. I believe using the Five and CacheFu products would work for high traffic, though there are very valid concerns about system resources.
qwerty has also set up high traffic sites with plone. The 4th ESF site [athens.fse-esf.org] is one example
boud: WhatWeHave and WhatWeWant: http://lists.gnu.org/archive/html/samizdat-devel/2006-09/msg00005.html
get started on ruby (oo language like C++/java): http://lists.gnu.org/archive/html/samizdat-devel/2006-09/msg00007.html
ruby 1.6 http://rubycentral.com/book/ ruby 1.8 updatetoya: about plone: this thing with the traffic depends a lot on how u set it up. u can have somethign infront of hte zope doing cache. this resolve this part of t he problem
samizdat was created as a response to a prevous list of WhatWeHave/WhatWeWant type discussion among indymedia etc people
Zapata proposes to read links above them before the next meeting and discuss them then
angdraug: Rails is not friendly to multiple site per one code deployment
summary analysis: http://24.172.120.164:8080/2006/09/17/bricolage.html
Devin: this is the first time I've used Bricolage, and have really just had time to dip by toes in, so I reserve the right to be completely wrong about everything here and advise that I am surely wrong about at least some things.
According to the documentation Bricolage was created to manage the content work flow for print newspapers, and has expanded to web and RSS/XML. But the way in which the content creation/edit/management is seperated from the published and publicly available content seems to be a big point, with some advantages and what I perceive to be fatal disadvantages.
Having the content creation management in one place and then having it "pushed" to a second server where it is formated and made available to the public has advantages in easy replication/redundancy, quick load time of content which does not have to do database lookups.
This sort of separation does not seem to be a good fit for our uses, though. It seems like the old paradigm of "I publish, you read" as opposed to user participation. Having the published content on a different server and in a system not directly connected to the database seems like it would create real barriers to setting up a system when users can easily comment on articles from each page, rate articles, have that kind of interactivity. Again, I haven't really tried to set this up so there may be solutions to it, but my feeling is that we would have to create this and it would end up being a hack which by-passed most of the functionality of Bricolage work-flows.
Zapata acknowledges the disadvantage this separation has but... in indymedia practice enough can still be achieved... take for instance imc uk... perhaps it's a general idea for more people to look at a bunch of existing codebases in practice... this does not require looking into coding, but only in looking how a site works...
The Drupal page on Sarava is http://techmeet.sarava.org/English/CMSSurveyReportDrupal
boston: OpenSourceCMS has a demo of the latest stable version at http://www.opensourcecms.com/index.php?option=com_content&task=view&id=132
First round for Drupal was great. While there's still a little more homework to do I was able to get most of it done and ekes was kind enough to fill in a lot of the blanks, so please check it out when the techmeet site comes back online. Naturally some of it is also up for discussion, but from initial glances it's really looking like we can say 'yes' in Drupal to all the features we have as well as the majority of features we'd like to have. In addition (and this still needs work) I believe there are several additional modules that would be of interest to IMCistas.
In short, I think feature-wise we're in really, really fantastic shape. The stuff that will require serious discussions will probably revolve around the backend: db optimizations and redundancy, multi-site support, traffic concerns, upkeep and data migration.
ekes notes drupal cache doesn't have his additions: Durpal notes from google cache before my additions:
Zapata: I have started to look at zope, installed it, read documentation (the content management framework that is). as this is a framework, as txopi has said during the last meeting, we might need a slightly different process for it. haven't gotten around to filling in the report, as sarava.org was out today :-( will get back to this in the net meeting
zope goes together with plone and is all in python
when Zapata refers to zome, means ... zope + the contement management framework, without plone. i.e. a framework, not a full cms
PseudoPunk has installed joomla and didn't find more time to work with it yet
txopi: i haven't finished it :-) i will finish during this week and then send a message to the mailing list and i propose to use the score column to evaluate each of the features (as i have been doing in wordpress report). we also have to prioritize the features, and then we could calculate and index who can give us an aproximate value with: feature1's priority * cms's score on feature1 + ...2 + ...3. score column is just for the final stage of the survey. also, the reports that have used the score column have used 0-3 scale. there is also 0-5 proposed, but not used yet
Zapata: priorities might be discussed more easily when we have a bunch of finished reports, we're only just starting and need to build a feeling for the surveys
boud is concerned about the social side of plone/zope - Zope calls itself a corporation, and its customers are not the sort of groups that we really would want to become too dependent on: http://www.zope.com/customers/products_and_services_customers.html Bank of America, US Navy, United States Navy / GE Jet Engines Workflow http://www.zope.com/customers/case_studies/navy_ge.html US Marines http://www.zope.com/customers/case_studies/marine_corps_institute.html http://www.zope.com/customers/case_studies/martest.html http://www.zope.com/customers/training_customers.html Lawrence Livermore National Laboratory, United States Department of Defense
yah nasa uses zope/plone this point has been made before It can be mentioned in the introduction of the surveys of said cmses but generally, open source can be used by anyone, including big bad corporations, that's the nature of open source. it's also being used by many NGO's, by the European Social Forum and the World Social Forum [wsf2007.org], and we are starting a indy media project in Greece that it will be based on plone with additions for open publishing. we will have a prototype release very soon boud: Zope seems especially proud of its military/corporate clients - it's not just that anybody can use the software. As for NGO's, ESF and WSF, AFAIK it's only under a lot of pressure and educational efforts that they have sort of understand the importance of the political aspects of software.
ZPL = GPL. gpl means free for anyone to use, so it is hard to decide a sofwtware over who is using it or not http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
point for next meeting: are we going to use the 0-3 score, no score? Need to be homogeneous now or we will have to need to homogeneise later. Zapata adds that the reports will be different
people with new cmses that might be worthy of a review?
kwadronaut could do spip (not spipindy addon) for next sunday init clould look at mephisto and radiant ruby-on-rails-CMSs PseudoPunk'll do joomla as promised ryan -- mambo toya joomla boston was looking at Drupal boud : joomla = pseudopunk yossarian will try eribium ruby-on-rails cms Devin Bricolage jebba has offered the use of his vserver space for people that need a place to experiment with cmses
People from Oceania have complained about the present meeting time so it is agreed to change it in order to accomodate better.
mailing list: we'll use imc-cms@lists.indymedia.org
next CMS meeting september 23rd 2100 UTC in #cms | Please Read: http://techmeet.sarava.org/English/Notes | http://cats.revolt.org/cats-vii/indymedia/ | http://techmeet.sarava.org/English/CMSProposal
if saturday night isn't convenient for the europeans, we'll just rotate the meeting or so