Re: xxx.OGo.org Websites

I am also writing inline.

chris h schrieb:

>On June 27, 2005 12:15 pm, Michael Brown wrote:
>
>Ok now we are getting to an area that interests me. Comments in line.
>  
>
>>>Unfortunately wrong. Plone has no builtin staging,
>>>so all submitted
>>>content is immediatly online for anonymous access.
>>>This is what makes the workflow superflous and
>>>basically useless.
>>>      
>>>
>>Again, I beg to differ.  On my instance here, I can
>>block content that is "visible" from being seen
>>anonymously.  This is a permission problem, again
>>probably due to the version of Plone on the Docs
>>website. 
>>    
>>
>
>No this was setup intentionally due to the lack of volunteer editors to 
>approve content. It cannot be done effectively by one volunteer editor and 
>1500 plus accounts. You need at least three editors who are mailed upon 
>content creation to approve content. 
>  
>
Helge told me that there a 3000 users in the plone, but the more 
interesting question is how many submissions do we count in a day / week?

>  
>
>>I know this for sure, because I'm running 
>>two  browsers on my workstation as I work on my new
>>site (one logged in as manager, one anonymous).
>>
>>    
>>
>>>I know that Chris likes Plone and Zope. So do I. But
>>>one also has to be
>>>aware of the drawbacks, not just the features -
>>>especially in our kind
>>>of setup.
>>>      
>>>
>>I agree.  But currently we're comparing apples and
>>oranges.  Docs is running an older version of Plone,
>>which has lots of these issues fixed.  Plus, I don't
>>think that when Docs was first commissioned the whole
>>workflow was really thought through; it was
>>commissioned to become a knowledge repository.
>>    
>>
>
>Correct. Docs was commissioned to provide a very simple and effective solution 
>for archiving user info at the time of OGo's initial release. There was 
>simply far too much confussion as to how to set thing up, the basic install 
>process and all that. As manuals started to be contributed a separate site 
>was created with different workflow and authorization levels to allow those 
>interested in working on detailed manuals to have an online workspace and 
>repository. Both workflow and stagging are very restricted on manuals.ogo.org
>  
>
Would be nice if all of that could be consolidated in administrative system.
I am just killing my idea of a wiki :-|

>  
>
>>>We don't have a Plone infrastructure for the issue
>>>in question. The
>>>docs installation (currently!) solves none of the
>>>issues I raised for
>>>the main site.
>>>      
>>>
>>Ok, I don't quite understand this point.  Who's
>>running the Docs Plone server then?  Another Plone
>>site (seperate from Docs) can be created, using an
>>updated version of Plone, and then we could look at
>>migrating Manuals into the core www.opengroupware.org
>>site.
>>    
>>
>
>Wrt to Helge's comments, my only point was that simple zope can meet the 
>requirements here even if you move to a wiki format. There is Zwiki for that. 
>
>The adavantage here is that the user interface and levels of access are 
>simpler and more controlled with zope then with standard wiki systems. This 
>is particularily important IMHO for non technical office staff who typically 
>want to take responsibility for a sites section or area. 
>
>  
>
>>>I know that Plone/Zope has a lot of features. But
>>>missing features is
>>>not our issue right now. We first need to get the
>>>basics right.
>>>      
>>>
>>I agree that the basics will need to be addressed,
>>    
>>
>
>This discussion has now matured to the point that the "basics" need to be 
>defined. 
>
>  
>
>>but 
>>there should also be a long-term plan in place.
>>    
>>
>
>Agreed.
>  
>
Yes. Yes. Yes!

>  
>
>>Otherwise, this would just turn into a band-aid
>>solution, which would have to be addressed again in a
>>few months.  The latest version of Plone has a nice
>>history function, which is like a diff of changes.
>>See attached image.
>>
>>    
>>
>>>IMHO a Wiki could be a simple and effective solution
>>>if the
>>>requirements can be implemented.
>>>      
>>>
>>And there's nothing wrong with that.  But, it would be
>>a seperate "island" of content again, different from
>>Docs and Manuals.
>>    
>>
>
>Well that is one issue certainly. The intend was always to have docs.ogo.org 
>and manuals.ogo.org be content providers for ogo.org thereby providing a 
>controlled content harvesting mechanism. We do have over 1500 accounts and a 
>ton of data in docs. 
>
>  
>
>>What I see the needs/requirements as being described
>>as:
>>
>>1.  We need an easier to maintain repository for
>>www.opengroupware.org
>>    
>>
>
>Looking at the current mechanism I would agree. Mario M seems to be working on 
>this. 
>  
>
Will wait with implementation of a testing setup until this 
decision-making process comes to an end. ;-)

>  
>
>>1 (a).  This needs to be comprised of the end user
>>site, and the developers site.>
>>
>>1 (b).  This needs to be accessible by members of the
>>comunity, in order to be more easily updated and take
>>the load off of Franks' shoulders.
>>
>>1 (c).  The content will comprise of Documents, News
>>and PR announcements, Events, FAQ's, File and web
>>links.  Basically what's currently on
>>www.opengroupware.org via the SVN.
>>
>>1 (d).  All content should be searchable.
>>
>>2.  Once the basic structure has been outlined, the
>>following additional requirements are desired by
>>members of the community:
>>
>>2 (a).  It is desireable to have the officially
>>released documentation for OGo available via the
>>website.
>>
>>2 (b)  It is desireable to have user contributed
>>documentation accessible via searches or other method.
>> It should be clearly identified as being
>>user-contributed, and not official documentation.
>>    
>>
>
>2 and 2b are the current process limited as it is. 
>  
>
>>3.  It is desireable to have a consitant interface to
>>all aspects of content for OGo (website, manuals and
>>user-contributed information) in order to maximize
>>effeciency and minimize redundant systems or
>>workflows.
>>    
>>
>
>I would agree here.
>  
>
Yes the consistance of the look and feel should be given in the whole 
ogo world.

>  
>
>>So, what else do we want it to do?  (No, brewing
>>coffee or beer won't be one of the features!)
>>    
>>
>
>bout sums it up.
>  
>
Cheers,
Mario
-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss