Re: xxx.OGo.org Websites

chris h <[email protected]>
Newsgroups gmane.comp.cms.opengroupware.discuss.general
Message-ID <[email protected]>
On June 27, 2005 12:15 pm, Michael Brown wrote:

Ok now we are getting to an area that interests me. Comments in line.


> I think that has to do more with the version of the
> installed Plone/Products than the.  I'm running a
> newer version with Archetypes on my test instance, and
> it's considerably easier than what you describe (and
> what I've experienced with the Docs plone).  I think
> you'll be happier with the current version.

Almost correct but the point is the same. docs and manuals are running on 2.0 
non archetype versions of plone. Current at the time of install. The next rev 
will be updated to latest stable version sometime in August. The issues you 
address are not archetype dependant however rather a system config. 
>
> > 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. 

> 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

> > 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.

> 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. 

> 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.

> 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.

/ch
-- 
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.