-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wow!
Thank you all for the comments! A couple of (careful) conclusions: //1//- Monitoring website behaviour might be useful (2 comments including mine), but we prefer not to use Google (2 comments). I have looked at some alternatives, taken in consideration that the cherokee-project website generates apache compatible log files and came across: * http://awstats.sourceforge.net (cgi/perl based, no database needed. Basically, it is creating visual appealing views of the logfiles.) * http://piwik.org/ (needs php and mysql..) * Of course there is webalizer http://www.webalizer.com/ (C, w3c logfile formats) Anyone wants to say something on that? //2//- Per version documentation, structured and with the option to leave comments. A big concern here is that spam will flow the documentation. I understand the project had some really bad experiences in the past. I will work out a plan for this and when it is more concrete, present it here on the list. Thanks again and I know my homework for now ;-) Kind regards, Milo van der Linden Miguel Angel Ajo Pelayo wrote: > 2008/7/24 Alvaro Lopez Ortega <[EMAIL PROTECTED]>: > >>> - - Google Analytics in the website footer. This way the community can >>> track visits, get an overview on the number of downloads and get some >>> insight in pages that are atractive to the public. I would love to >>> hear >>> pro's or con's for this. >> I cannot see the point, actually. Let's imagine we had the data today; >> What would we do with it? How would it become useful for the project? >> > > That things can always help a lot about web usability, and getting to know > your users: > > - Where do they come from: region, websites, search engines (keywords) and > so on... > - The way they use the website, and exit pages... (that really helps a lot) > > >>> - - Documentation per version on the website. I am a big fan of >>> postgreSQL. They have a pretty nice documentation section, with TOC >>> and >>> organized per version. Users and developers can also post comment to >>> the >>> different pages of the documentation. I would like to create a similar >>> structure for the documentation section for cherokee. Good >>> documentation >>> is a great push towards adaption of a open source product by a bigger >>> audience. Anyone want to comment on this? >> I like the idea of supporting comments on the documentation pages. >> Though, I'm quite afraid of the whole lot of work that fighting the >> spammer herds would require us. We have had a few really bad >> experiences in the past (with forums, trac and bugzilla). >> > > > I give a +1 to this kind of idea, commented documentation is great (I think > we all know the php.net example, I love their documentation system). > Although fighting SPAM in the right way is the first thing we should think > about. > > > >> As soon as we get a good enough anti-spam mechanism, I'll be all for it. > > > I would sugest the akismet API / and this http://www.stopforumspam.com/ > (forum spamer's black list) > or some kind of externalized catcha (this is the only effective way I got to > stop spam in my forums). > > >> >>> - - Structure the documentation in a logical way: >>> - Installation >>> - per platform >>> - Configuration >>> - general >>> - advanced >>> - Plugin's/Components >>> - .more >> +1 >> >> -- >> Greetings, alo. >> http://www.alobbs.com/ >> >> _______________________________________________ >> Cherokee mailing list >> [email protected] >> http://lists.octality.com/listinfo/cherokee >> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIiK14iCYTRyqLCBURAilGAJsGFksW0iQO3a2jfJwFWm2ruaA/rACgrAeH kfrSMLURZ1DUHHHK9rjig4s= =ug5z -----END PGP SIGNATURE----- _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
