Re: New Website for opengroupware.org project

Mario Minati <[email protected]>
Newsgroups gmane.comp.cms.opengroupware.discuss.general
Message-ID <[email protected]>
Hi chris,
first of all this new effort on the webpage is not ment as moaning about 
your work. I didn't manage to use the docs plone in a right way the last 
one and a half years, probably because I have difficulties of 
understanding the order in the system. We are useing a wiki system in 
our company for documentation and administration and are very happy with 
the fast and easy way of sharing informations.

I believe you that more could be accomplished by investing more time.
More comments inline...


chris h schrieb:

>On June 26, 2005 08:47 am, Helge Hess wrote:
>  
>
>>Hi Mario,
>>
>>On 26. Jun 2005, at 13:02 Uhr, Mario Minati wrote:
>>    
>>
>>>The inspiration of this effort came during a meeting between Helge
>>>and me on the LinuxTag in Karlsruhe (Germany) on Saturday.
>>>      
>>>
>>Just to restate some of the requirements I mentioned:
>>a) it should be possible to preserve the current page layout, not
>>    necessarily 1:1, but it should be close
>>    
>>
>
>this can be done via plone...perhaps not the existing install version as it 
>now very dated but can easily be done. The entire home page and versions are 
>kept in one user account (which can now be shared via groups and is 
>accessible via webdav, ftp and xml-rpc) and via a redirect in apache becomes 
>xxxxx.opengroupware.org or just simple opengroupware.org
>  
>
You mean linux user account not plone user account, right?

>  
>
>>b) only accounts should be allowed to edit pages
>>    
>>
>
>as above.
>
>  
>
>>c) it should scale sufficiently well (millions of hits!),
>>    maybe this could be solved with Squid or something
>>    
>>
>
>see http://plone.org/about/sites/
>
>  
>
>>d) it should have something like user home pages like on docs
>>    
>>
>
>as above.
>  
>
>>Optional:
>>e) it would be good if it would allow something like folders for
>>    organizing stuff (yes, I know this isn't necessarily Wiki)
>>    
>>
>
>this exists 
>
>  
>
>>f) a change review process would be great
>>    
>>
>
>this exists
>
>  
>
>>g) protecting certain pages for modifications would be nice
>>    
>>
>
>this exists
>
>  
>
>>h) ability to use HTML for content would be nice
>>    
>>
>
>this exists
>
>  
>
>>Our hardware: currently the sponsored hardware driving the website is
>>a Dual 800 MHz PIII with 1 GB RAM.  It also hosts Bugzilla and
>>Subversion.
>>    
>>
>
>good enough....:)
>
>  
>
>>>First I would like to name some of the problems with the current
>>>website:
>>>1. Difficult to maintain. Helge told me that it takes up to one
>>>hour until modifications are online, due to the design of the
>>>current system (pages are hosted in a svn).
>>>      
>>>
>
>move this into plone or zope as straight html pages 
>then it would take minutes to maintain remotely
>
>  
>
>>Si.
>>
>>    
>>
>>>2. Maintainence through community is difficult, because of 1
>>>      
>>>
>
>This is correct. There are two issues here. My lack or time/dedication 
>whatever and the interfacing with Skyrix staff on the admin side due to 
>everyone work load has been slow at times. However Skyrix support in general 
>as been outstanding. 
>
>  
>
>>Big issue.
>>
>>    
>>
>>>3. Documentation Plone doesn't seem to work properly, due to
>>>database problems (indexes need to be rebuilded sometimes)
>>>      
>>>
>
>No it simple needs to be re-indexed. About ten minutes work but it needs to be 
>coordinated with skyrix admins to get access at three levels. (ie firewall 
>ports) Once this is sorted its simply a matter of hitting a re-index button 
>and it should take approx 20 minutes to re-index the site by itself. 
>
>  
>
>>I don't know the exact issues. I think Chris wanted to upgrade the
>>Plone but we didn't found the time to properly set things up for him.
>>    
>>
>
>Yup.
>
>  
>
>>Anyway: first I would focus on fixing the main site. Migrating Plone
>>should be a second step.
>>    
>>
>
>there are two issues with the main site. From a NA perspective its strange in 
>terms of design. Secondly, its needs to be translated into gramatically 
>correct english. This is where a hosting it in zope or plone would be ideal 
>as it has built in versioning. You need to assign (find) dedicated language 
>translators so that once the orginal material is loaded everyone 
>automatically gets an email on content changes and then begins the 
>translation process. Once complete and signed off, the material is released 
>for publication to a specific date and time, all done automatically in either 
>zope or plone, and of course in the language of choice. 
>  
>
Who could set up that system including the automatisms? Is there any 
Zope/Plone knowledge at Skyrix or could you do that Chris, if Skyrix 
could provide some kind of SSH access to that machine?

>  
>
>>>Helge and Jens Münster (Skyrix) liked the idea and you hopefully too.
>>>      
>>>
>>Yes *if* it is possible to preserve the visual identity of the
>>project. Eg
>>
>>   http://www.mono-project.com/Main_Page
>>
>>and also most Plone sites are bad examples for that (ours included).
>>    
>>
>
>Not necessarily true. Its simple a matter of effort/time as the base install 
>is less time consuming then too create new templates. 
>
>See: http://plone.org/about/sites/
>
>  
>
>>>As I am using a TWiki (http://www.twiki.org/)
>>>      
>>>
>>...
>>    
>>
>One of the main reason I chose not to use a wiki system (even in zope or plone 
>for which several are available) is for the following reasons:
>-groups are not supported well
>  
>
What do we need groups for? The wikipedia project is working quite well 
with the buildin groups (anonymus, user, admin and a few more) that are 
provided by the MediaWiki system.

>-versioning is not supported well
>  
>
MediaWiki has a complete versioning and saves all previous versions 
(compressed if you wish). You can link directly to old versions (at 
least in the new 1.5 release). You can see diffs in a two column style. 
Concurrent writing is taken care of.

>-security can become problematic.
>  
>
What do you mean with security? Someone writing crab/spam or a kind of 
attac on the server?

>  
>
>>>- On my machine (P2, 233Mhz, 96MB RAM) it takes around 10 secs to
>>>calculate a page.
>>>      
>>>
>
>Well that really not an issue in this case. 
>
>The primary issue is that lack of manpower and talent...:)
>
>  
>
>>Thats slow. But the machine is _really_ old, we have 10times the RAM
>>and 8times the cycles ;-)
>>
>>The most important thing to know is this one:
>>    
>>
>>>- I am not sure if a squid proxy could bring the load down, because
>>>each page is generated dependig on the users preferences. Ok squid
>>>would help for the people which are not logged in and are browsing
>>>as guest users.
>>>      
>>>
>
>Squid can easily be setup and is part of a typical commercial install. Out of 
>the box, zope and plone can easily address several 100 hits pre second. There 
>is tons of literature on this available. 
>Eg: 
>http://plone.org/documentation/tutorial/optimizing-plone/view?searchterm=optimizing 
>but there is much, much more available. 
>
>eg:
>http://www.upfrontsystems.co.za/Members/jean/optimizing-plone
>
>eg: and of course what serious sites do...clustering on distributed servers 
>which is stock in zope/plone.
>http://www.zope.org/Products/ZEO/ZEOFactSheet
>
>The issue with our project pages is _not technology selection_ rather 
>staffing, commitment and did I mention talent...:)
>  
>
That is exactly why I brought the discussion up. Wiki usage is very easy 
and very fast and that would make it easier to maintain the webpages and 
that is my wish encourage more users to bring in their experiences and 
knowledge.
One condition would be (with wiki or plone) to create a well planed 
structure to organise the informations.

>
>  
>
>>Guest users should be the far majority of the trafic.
>>
>>    
>>
>>>- In c't 2003/25 page 202 (german computer magazine) is a test of a
>>>few wiki engines and they also named scalability and search speed
>>>as one of the drawbacks of Twiki.
>>>      
>>>
>
>Yes this is correct. 
>
>Thanks for bringing this issue up (and reading all this material) Its been 
>bugging me for a long time now. Here are the issues as I see them;
>
>1. The issues are not technology rather lack of personal and talent. 
>2. There is currently only one volunteer maintaining the community docs and 
>sites and one very dedicated skyrix staff...tks Frank...:) There are lots and 
>lots of contributors on the content side...thanks to all of you for that as 
>well.
>3. The following issues need to be organized, planned, scheduled and assigned; 
>		- home page,
>		- user docs
>		-user manuals
>		-appropriate translations of the same via an editorial process
>  
>
I think we should address one challenge after the other. I tried to 
concentrate on the webpage first.

>4. From a technology perspective if you were to draft a requirements document 
>(please dont example only) and do a proper eval of what is available, you 
>will find that zope/plone in the appropriate hands will meet or exceed all 
>your requirements in the most time effective manner. What is currently 
>missing is time, talent and assigned staff(volunteers)
>  
>
You may be right, that many or all of the problems could be solved 
within a zope / plone setup.
But that is where I see problem for my self. I don't want to start learn 
zope and how this application server works and how to solve problems. 
I'm looking forward to do some in OGo, but I also see that something has 
to be done with the website and _I_ would like to use a system which is 
easy to maintain and easy to use.
Well I think the last sentence might also be right for Plone. I'm not an 
expert, not even a beginner :)

Regards,
Mario Minati
-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.